Planning and Monitoring SQL Server 2008 Storage for Share Point

8/6/2019 Planning and Monitoring SQL Server 2008 Storage for Share Point

1/21

Planning and Monitoring SQLServer 2008 Storage forSharePoint: Performance

Recommendations and BestPractices

Writers: SharePoint Products and Technologies teams and

Bill Baer, Microsoft Online Services, Hosted SharePoint Technology Architect

Technical Reviewers: Burzin Patel, Senior Program Manager, SQL Server Customer AdvisoryTeam; Doron Bar-Caspi, Senior Program Manager, SharePoint Customer Advisory Team; Nakul

Joshi, Microsoft Consulting Services, Senior Consultant; Craig Schwandt, Microsoft Consulting

Services, Architect

Published: October 2008

Updated: October 2009, Joel Oleson, Sr. SharePoint Architect, Quest Software

Summary:

This paper provides key recommendations and best practices to help administrators ofSharePoint Products and Technologies plan and monitor their SQL Server storage requirementsto support optimal performance and operation of their server farms.


2/21

Copyright

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the

date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a

commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of

publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS

TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of

this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means

(electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of

Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject

matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this

document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mailaddresses, logos, people, places, and events depicted herein are fictitious, and no association

with any real company, organization, product, domain name, e-mail address, logo, person, place,or event is intended or should be inferred.

2009 Microsoft Corporation. All rights reserved.

Microsoft, SharePoint, SQL Server, Windows, and Windows Server are either registered trademarks or trademarks of Microsoft

Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.


3/21

Contents

INTRODUCTION ............................................................................................................................. 1

KNOW YOUR NEEDS AND PLAN AHEAD ................................................................................... 1

PLANNING RECOMMENDATIONS ............................................................................................... 1

Information architecture recommendations ............................................................................... 2Adapt your information architecture design to the software boundaries of SharePoint Products

and Technologies ........................................................................................................................ 2Limit content database size to enhance manageability .............................................................. 2Configure autogrowth settings .................................................................................................... 3Allocate storage for versions and Recycle Bins .......................................................................... 3Use quota templates to manage storage .................................................................................... 3Manage your large lists for performance..................................................................................... 3Plan for data security needs ........................................................................................................ 4

Physical topology guidance ......................................................................................................... 4Start with a dedicated server that is running SQL Server 2008 .................................................. 4Consider scaling out in addition to adding resources ................................................................. 5Follow the SQL Server guidelines when choosing hardware ..................................................... 5

Network topology recommendations ........................................................................................ 10

Physical storage recommendations .......................................................................................... 11Use appropriate disks and RAID arrays .................................................................................... 11Separate and prioritize your data among disks ......................................................................... 11Use multiple data files for large content databases and the SSP search database ................. 12Follow vendor configuration recommendations ........................................................................ 14

MONITORING, MAINTAINING, AND TROUBLESHOOTING ..................................................... 14

Physical servers .......................................................................................................................... 14Disk counters to monitor ........................................................................................................... 15Disk recommended practices .................................................................................................... 16SQL Server recommended practices ........................................................................................ 16

Troubleshooting .......................................................................................................................... 17

SUMMARY .................................................................................................................................... 17

ADDITIONAL RESOURCES ......................................................................................................... 17

FEEDBACK ................................................................................................................................... 18


4/21

IntroductionProper configuration of Microsoft SQL Server including disk and data input/output (I/O)

subsystems is critical to the optimal performance and operation of server farms that are runningSharePoint Products and Technologies (Windows SharePoint Services 3.0 or Microsoft Office

SharePoint Server 2007). This paper describes some of the most common practices that theSharePoint Products and Technologies team recommends with respect to storage configurationand monitoring.

Although SharePoint Products and Technologies can run on SQL Server 2008, SQL Server 2005,

or SQL Server 2000, we strongly recommend that you consider running your environment on

SQL Server 2008 Enterprise Edition to take advantage of the additional performance, availability,security, and management capabilities that it provides. For more information about the benefits of

using SQL Server 2008 Enterprise Edition, seeIntegration of SQL Server 2008 and OfficeSharePoint 2007(http://go.microsoft.com/fwlink/?LinkId=168610).

Proper planning of the infrastructure, regular monitoring, and fine tuning assure that the products

and technologies in the environment are built on a solid foundation, and can scale in terms of size

and availability as your SharePoint environment grows.

Our internal investigations have shown that it is best to plan for capacity from the bottom of the

stack to the top. First plan your SQL Server capacity, and then plan your application server andWeb server capacity.

We have also found that it is best to monitor capacity from the bottom of the stack to the top,

because stress on the server that is running SQL Server is likely to cause stress on application

servers and Web servers. For example, if your server that is running SQL Server is takingsignificantly more time to respond to a request from a Web server, and if the Web server is

receiving requests from end users at the normal rate, requests on the Web server start queuingup, eventually pushing it over its limits.

Know your needs and plan aheadBefore you purchase hardware, determine your information architecture (logical structure andapproximate sizing), reliability, and performance requirements for the environment in which youwill run SharePoint Products and Technologies and SQL Server.

Your resource plan is dependent on the scenario you are deploying for. As you plan your

deployment, review the following planning content:

Planning and architecture for Office SharePoint Server 2007(http://go.microsoft.com/fwlink/?LinkID=105576&clcid=0x409)

Planning and architecture for Windows SharePoint Services 3.0 technology(http://go.microsoft.com/fwlink/?LinkID=105577&clcid=0x409)

If you are upgrading an existing deployment, keep in mind that Windows SharePoint Services 3.0

and Office SharePoint Server 2007 provide a richer platform than their predecessor versions. Tosupport the updated and additional capabilities, the current versions of SharePoint Products and

Technologies consume more infrastructure resources than older versions, even if yourdeployment does not use all of the new capabilities.

Planning recommendationsIn planning, your goals are to optimize performance, scale, data sensitivity, availability, and

manageability.
http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkID=105576&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105576&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105577&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105577&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105577&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105576&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610


5/21

Optimize performance

Get the most performance out of the hardware. Plan and monitor to avoid bottlenecks

on resources when other suitable resources are under-utilized. Proper planning anddeployments may yield better results than increasing hardware resources.

Plan for scale

Always take future growth parameters into account. Plan the SQL Server deployment,the storage space, and the sites and SSP deployment in a way that will allow for future

growth without the need to rebuild any component of the farm, an event that mayrequire relatively long shut-down periods.

Plan for data security

It is important to understand the sensitivity of the content in your databases so that you

can better determine the need for security features such as encryption in yourenvironment. Encryption is available in the SQL Server 2008 Enterprise Edition.

Plan for availability

SharePoint Products and Technologies rely on SQL Server features to ensure

availability. Determine your availability needs to help you determine which features touse. For more information, seePlan for availability (Office SharePoint Server)

(http://go.microsoft.com/fwlink/?LinkId=168607) Plan for manageability

Plan your storage infrastructure so that day-to-day administrative tasks (such as

loading backups or running SQL Server reindexing jobs) and less frequent jobs (such

as restoring content or failing over to a remote site) will be easy to perform.

Information architecture recommendations

Planning your information architecture within the following suggested boundaries can enhance

system performance.

Adapt your information architecture design to the software boundaries ofSharePoint Products and Technologies

For more information about software boundaries, seePlan for software boundaries(http://go.microsoft.com/fwlink/?LinkID=105578&clcid=0x409).

Limit content database size to enhance manageability

Plan for database sizing that will enhance manageability and performance of your environment.

In most circumstances, to enhance the performance of Office SharePoint Server 2007,we discourage the use of content databases larger than 100 GB. If your designrequires a database larger than 100 GB, follow the guidance below: Do not use a database larger than 100 GB for more than a single site collection. Use a differential backup solution, such as SQL Server 2008 or an incremental

backup solution such as Microsoft System Center Data Protection Manager, ratherthan the built-in backup and recovery tools.

Test the server that is running SQL Server 2008 and the I/O subsystem beforemoving to a solution that depends on a 100-GB content database.
http://go.microsoft.com/fwlink/?LinkId=168607http://go.microsoft.com/fwlink/?LinkId=168607http://go.microsoft.com/fwlink/?LinkId=168607http://go.microsoft.com/fwlink/?LinkID=105578&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105578&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105578&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105578&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=168607


6/21

Limit content databases that contain multiple site collections to approximately 100 GB.

Note: The limits we recommend apply only to a server that is running SQL Server 2008 hosting

Office SharePoint Server 2007, and are not general guidance for SQL Server 2008.

Configure autogrowth settings

When you are planning content databases that exceed the recommended size(100 GB), set the database autogrowth value to a fixed number of megabytes insteadof to a percentage. This is to reduce the frequency with which SQL Server increasesthe size of a file. Increasing file size is a blocking operation that involves filling the newspace with empty pages.

Note: SQL Server 2008 that is running on Windows Server 2008 supports instant fileinitialization. Instant file initialization can greatly reduce the performance impact of a filegrowth operation. For more information, seeDatabase file initialization(http://go.microsoft.com/fwlink/?LinkId=132063&clcid=0x409).

When you are planning content databases smaller than the recommended size(100 GB), set the databases to 100 GB when they are created by using the ALTERDATABASE MAXSIZE property.

Allocate storage for versions and Recycle Bins

If you plan to use versioning or Recycle Bins in a site, be aware of the potential impact to the site

quota.

In libraries that have versioning enabled, the storage used for previous versions countstowards the site quota. Be aware of this fact and plan accordingly.

For any site, you can enable one or two Recycle Bin stages. The first stage (user andsite Recycle Bins) counts toward the site quota. The second stage (the site collectionRecycle Bin) does not count toward the site quota. However, the content in the second-stage Recycle Bin is added to the storage used by the site collection. Remember toplan sufficient additional storage space for the second-stage Recycle Bin. Pay closeattention to the number of days you are retaining deleted documents in each RecycleBin stage.

Use quota templates to manage storage

Use quota templates to manage site collections with similar characteristics. A quota template sets

storage limits for site collections, and also provides e-mail alerts when specified storage sizes are

reached. Any change made to a quota template affects only new sites; it will not affect previouslycreated sites.

The quota on existing site collections can be modified by using the SPSite.Quota property in theSharePoint Object Model. For more information, seeSPSite.Quota Property(Microsoft.SharePoint)(http://go.microsoft.com/fwlink/?LinkId=132068&clcid=0x409).

Manage your large lists for performance

SharePoint Products and Technologies support large lists. However, you must carefully control

how end users view the lists to help prevent adverse effects on performance.
http://go.microsoft.com/fwlink/?LinkId=132063&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=132063&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=132063&clcid=0x409http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.quota.aspxhttp://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.quota.aspxhttp://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.quota.aspxhttp://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.quota.aspxhttp://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.quota.aspxhttp://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.quota.aspxhttp://go.microsoft.com/fwlink/?LinkId=132063&clcid=0x409


7/21

For best performance, do not exceed 2,000 items in a list level (for example, the root of

the list or a single folder).

If you must create and browse large lists, use the following best practices:

Index the list on one or more columns.

Change the default view of the list to a customized filtered view that follows these

recommendations:

The view returns fewer than 5,000 items.

The first column that you use to filter the view has an index that

sufficiently reduces the total number of items returned.

The view displays only those columns that are absolutely required.

The view includes as few lookup columns as possible. Each lookup

column in a list that is included in a view causes an additional join and

additional calls to the database.

Evaluate list size with regard to the number of columns in a list. Lists with lots of columnscan perform slowly.

If you plan to, or currently have very large lists, we strongly recommend that you read thefollowing resources:

Manage lists and libraries with many items(http://go.microsoft.com/fwlink/?LinkID=105579&clcid=0x409)

Working with large lists in Office SharePoint Server 2007(http://go.microsoft.com/fwlink/?LinkID=105580&clcid=0x409)

Plan for data security needsSharePoint Products and Technologies can take advantage of Transparent Data Encryption(TDE), the SQL Server 2008 Enterprise Edition feature you can use to encrypt entire databases,which requires no application awareness or modification. TDE encrypts data as it is written to diskand decrypts data as it is read from disk. For more information, seeIntegration of SQL Server2008 and Office SharePoint Server 2007(http://go.microsoft.com/fwlink/?LinkId=168610) andDatabase Encryption in SQL Server 2008 Enterprise Edition(http://go.microsoft.com/fwlink/?LinkId=129383).

Physical topology guidance

The topology of your systems database tier, and your network, physical storage, and caching can

significantly affect system performance. When you plan your hardware, remember that OfficeSharePoint Server 2007 is the last version of Office SharePoint Server that will run on 32-bit

operating systems and databases.

Important: If you are using the gradual upgrade method, to maintain reasonable responsetimes from the server that is running SQL Server 2008, it might be necessary to increase theSQL Server 2008 resources supporting Office SharePoint Server 2007 by at least a factor of

two.

The following sections give recommendations that are based on the best practices we have found

for SQL Server 2008 databases hosting Office SharePoint Server 2007.

Start with a dedicated server that is running SQL Server 2008

The following recommendations apply to the database tier in your topology:
http://go.microsoft.com/fwlink/?LinkID=105579&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105579&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105580&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105580&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=129383&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=129383&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=129383&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkID=105580&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105579&clcid=0x409


8/21

Always put SQL Server 2008 on a dedicated server that is not running any other farmroles, or hosting databases for any other application, unless you are deploying yoursystem on a stand-alone server.

We highly recommend that you install SQL Server 2008 64-bit version on a 64-bitoperating system, unless you have a significant business reason not to.

For optimal performance, use Office SharePoint Server 2007 with SQL Server 2008with the most recent service pack unless you have a significant business reason to usean earlier version.

Ensure that the SQL Server 2008 input/output (I/O) channels to the disks are notshared by other applications, such as the swap file and Internet Information Services(IIS) logs.

Use SQL Server connection aliases when you configure your server farm. Aconnection alias is an alternate name that can be used to make a connection to a SQLServer instance. If a database server fails, you can adjust the alias on the Web serverto point to another server. For more information, seeHow to: Set a SQL Server Alias(SQL Server Management Studio)(http://go.microsoft.com/fwlink/?LinkId=132064&clcid=0x409).

Consider scaling out in addition to adding resources

It is important to track the following three resource components of a server that is running SQL

Server 2008: CPU, memory, and I/O subsystem. When one or more of the components seemstretched, analyze the appropriate course of action based on the current and projected workload.Then, determine whether to add more resources or to scale out to a new server that is running

SQL Server 2008. In general, we recommend that you consider scaling out in addition to addingmore resources. For more information, seeTroubleshooting Performance Problems in SQLServer 2008(http://go.microsoft.com/fwlink/?LinkID=168448).

We recommend that you deploy an additional server running SQL Server 2008 when you have

more than four Web servers that are running at full capacity.

Follow the SQL Server guidelines when choosing hardwareThe following sections contain recommendations from the SQL Server 2008 team for hardware

that can optimize performance of Office SharePoint Server 2007.

Memory

For the purposes of determining the amount of memory required for the computers that are

running SQL Server 2008, first determine whether the planned deployment is small, medium, orlarge in terms of memory consumption.

Determine your deployment size by using the following table:

If your deployment parameters are generally less than the listed values, your deployment

can be considered small.

If your deployment parameters are approximately equivalent to the listed values, your

deployment can be considered medium.

If your deployment parameters are generally greater than the upper limits of most of the

listed values, your deployment can be considered large.
http://msdn.microsoft.com/en-us/library/ms175176.aspxhttp://msdn.microsoft.com/en-us/library/ms175176.aspxhttp://msdn.microsoft.com/en-us/library/ms175176.aspxhttp://msdn.microsoft.com/en-us/library/ms175176.aspxhttp://go.microsoft.com/fwlink/?LinkID=168448http://go.microsoft.com/fwlink/?LinkID=168448http://go.microsoft.com/fwlink/?LinkID=168448http://go.microsoft.com/fwlink/?LinkID=168448http://go.microsoft.com/fwlink/?LinkID=168448http://go.microsoft.com/fwlink/?LinkID=168448http://msdn.microsoft.com/en-us/library/ms175176.aspxhttp://msdn.microsoft.com/en-us/library/ms175176.aspx


9/21

Metric Value

Content database size 50 GB

Number of content databases 20

Number of concurrent requests to SQL Server 2005 200

Users 1000

Number of items in regularly accessed list 2000

Number of columns in regularly accessed list 20

For SQL Server 2008, 4 gigabytes (GB) is the minimum required memory, 8 GB is recommended

for medium size deployments, and 16 GB and larger is recommended for large deployments.

Other factors that can influence your memory requirements include the following:

The use of SQL Server 2008 mirroring.

The frequent use of files larger than 15 megabytes (MB).

CPU cache

On the server that is running SQL Server 2008, we recommend that the L2 cache per CPU havea minimum of 2 MB to improve memory.

Bus bandwidth

Greater bus bandwidth helps improve reliability and performance. Consider that the disk is not the

only user of bus bandwidth for example, you must also account for network access.

The following list provides some best practices and recommendations for optimizing bus

bandwidth:

For medium to large-sized servers, greater bus bandwidth improves the systemsreliability, especially with added multi-pathing software. Conversely, greater busbandwidth does not give a significant increase in reliability for smaller systems. The bus

bandwidths reliability is improved through the redundant paths in the system and by

avoiding single-point-of failure in hardware devices.

Greater bus bandwidth provides improved performance in systems that frequently uselarge block transfers and sequential I/O.

In smaller servers that use mostly sequential I/O, PCI becomes a bottleneck with threedisks. For a small server that has eight disks performing mostly random I/O, PCI is

sufficient. However, it is more common for PCI-X to be found on servers ranging fromsmall to very large.

Greater bus bandwidth is necessary to support a large number of disks.

The capacity of bus bandwidth might be limited by the topology of the system. If thesystem uses direct attached disks, the number of slots limits the bus bandwidth capacity.

However, for storage area network (SAN) systems, there is no physical limiting factor.


10/21

More expensive servers typically have larger and faster buses. There is often no way to

increase the capacity of the buses bandwidth without replacing the servers. However,the largest servers are more configurable. Consult with server providers forspecifications.

Disk and SAN interfaces

The interfaces you use in your system can affect reliability and performance. Larger drives, allelse being equal, increase mean seek time. Use the information in the following table to inform

your choice of interface.

Interface Benefits Disadvantages Notes

Small

Computer

System

Interface

(SCSI)

Supports forcing data to be

written to disk, improving

recoverability.

SCSI with Tagged Command

Queuing (TCQ) supportsmultiple I/O requests.

Supports hot-swapping.

SCSI can have up to 15

drives per channel.

Less restrictive on physical

cable length.

Overloading the

channels increases

the chance of

reaching the transfer

rate limit.

Integrated

Device

Electronics

(IDE)


IDE has high transfer rates

only if there is one driveattached per channel.

Typically greater capacity

than SCSI.

Typically cheaper per GB

than SCSI drives.

Can only handle

one outstanding I/O

request per

channel.

Serial

Advanced

Technology

Attachment

(SATA)

SCSI with TCQ supports

multiple I/O requests.


Most are explicitly designedto support only one drive per

channel; however, multiple

SATA channels of 2 to 12+

on interface cards are also

available.

Typically greater capacity

than SCSI.


11/21

Typically cheaper per GB

than SCSI drives.

Serial-attached

SCSI (SAS)

Very fast.

Supports SCSI protocol.Allows for a larger number of

disks than SCSI.

Applicable to direct-

attached storage

(DAS) only.

Replacement

technology for

parallel SCSI.

Backward

compatible with

SATA drives.

Disk topology

Topology Benefits Disadvantages Notes

SAN Can serve

multiple servers.

No limitations on

the number ofdisks that can beaccessible.

Easier to install

additional servers.Easier to manage

many servers.Easier to

reallocate diskstorage betweenservers.

Maintenance

costs tend to be

lower than DAS.

DAS Greater maximum

bandwidth.

Easier to managefor a smallernumber of

servers.

Initial overheadcosts are lowerthan SAN.

Deployed per server.

The number of disks is

limited by the number ofslots in the server andthe type of interface

used.

Consider DAS if you are

experiencing bottleneckedworkloads.

When the limit on the DAS

storage for a particular server is

reached, you must deploy anadditional server running SQL

Server 2005.


12/21

Network-

attachedstorage

(NAS)

I/O response time

required for SQL Server2005 cannot be

guaranteed normaintained in a NAS

environment.iSCSI can only support

light I/O traffic.

We do not recommend that you

use NAS due to inability toensure sufficient latency. If

networked storage is required,use iSCSI on an iSCSI-

dedicated gigabit Ethernet localarea network (LAN), rather than

NAS.

Database redundancy within a data center

You should provide redundancy for either type of storage within a data center.

For a SAN or for shared disks, clustering is the most common and cost-effective

technology. SharePoint Products and Technologies natively support the use of clusters,

which are available in the SQL Server 2008 Standard Edition. Operations teams may find

that clustering offers a familiar availability solution. For more information, see Configure

availability in a single farm by using SQL Server clustering

(http://technet.microsoft.com/en-us/library/dd207311.aspx).

For dedicated disks or DAS, you can use SQL Server 2008 mirroring. SharePoint is not

natively aware of SQL Server 2008 database mirroring. To change connections when a

mirror fails over, we recommend that you use a SQL Server client alias and that you

manually manage the failover process by modifying the alias to point to the failover

partner. For more information, seeUsing Database Mirroring with Office SharePoint

Server 2007(http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409).

Database redundancy across data centers

Data stored in either SAN or DAS can be mirrored or replicated to support business continuity

requirements, but the technique for mirroring differs as follows:

Most SAN vendors provide data mirroring across multiple sites.

In most DAS-based scenarios, a method of software-based replication is required, either

delivered by the vendor or enabled through technologies such as SQL Server 2008 log

shipping or asynchronous database mirroring.

If you choose to use asynchronous mirroring, SharePoint can take advantage of the SQL

Server 2008 log stream compression capability, and if you are running SQL Server

2008 Enterprise Edition can also take advantage of the ability to use an additional

redo thread per database for every four cores in the system. For more information, see:

o

Plan for availability(http://go.microsoft.com/fwlink/?LinkId=168607)o Configure disaster recovery across SharePoint farms by using SQL Server log

shipping(http://go.microsoft.com/fwlink/?LinkId=168609)

o Integration of SQL Server 2008 and Office SharePoint Server 2007

(http://go.microsoft.com/fwlink/?LinkId=168610).
http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=168607http://go.microsoft.com/fwlink/?LinkId=168607http://go.microsoft.com/fwlink/?LinkId=168609http://go.microsoft.com/fwlink/?LinkId=168609http://go.microsoft.com/fwlink/?LinkId=168609http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168610http://go.microsoft.com/fwlink/?LinkId=168609http://go.microsoft.com/fwlink/?LinkId=168609http://go.microsoft.com/fwlink/?LinkId=168607http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409


13/21

Note: Some Microsoft SQL Server replication technologies, such as transactional replication,

cannot be used with SharePoint Products and Technologies because the replication technologyrequires that a database have a primary key column on all tables. Before you implement

replication technologies, ensure that the technology is supported for both Microsoft SQL Server2008 and SharePoint Products and Technologies.

Snapshot technologies can be used to take point-in-time snapshots of the data hosted on a SAN.DAS, in most cases, does not offer the additional software and services to make snapshot

support available.

Supporting technologies such as Microsoft System Center Data Protection Manager 2007 can be

used to provide additional protection for Microsoft SQL Server and Microsoft Office SharePointProducts and Technologies. Microsoft System Center Data Protection Manager 2007 enables

disk-based and tape-based data protection and recovery for servers in and across ActiveDirectory domains. For additional information on Microsoft System Center Data Protection

Manager 2007, see theMicrosoft System Center Data Protection Manager 2007Web site(http://go.microsoft.com/fwlink/?LinkId=132065&clcid=0x409).

Performance

For both DAS and SAN, the following categories of performance should be measured:

I/O per second

Megabytes per second

Latency

Performance of both DAS and SAN environments is affected by so many variables that simplerecommendations are not possible. Examples of variables include drivers, configuration,

underlying and supporting foundational technologies, and host bus adapters (HBAs).

Fibre-Channel-switched fabric may be beneficial for SAN environments, because Fibre Channelscan provide multiple links through the fabric, and can thereby enable I/O path parallelism so thatthe SAN can process I/O requests more efficiently.

Minimal latency on the I/O subsystem that serves the server that runs SQL Server is very

important. Slow response from the I/O subsystem cannot be compensated for by adding other

types of resources, like CPU or memory, but it can influence and cause issues throughout thefarm. Plan for minimal latency before deployment, and monitor your existing systems as

described in the section onmonitoring.

Network topology recommendations

Plan your network connections within and between farms. We recommend that you use a network

with low latency.

The following list provides some best practices and recommendations:

All servers in the farm should have LAN bandwidth and latency to the server that is

running SQL Server 2008 (up to 1 millisecond (ms) latency).

We do not recommend a wide area network (WAN) topology in which a server that is

running SQL Server 2008 is deployed remotely from other components of the farm with

network latency greater than 1 ms. This topology has not been tested..
http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspxhttp://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspxhttp://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspxhttp://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspx


14/21

Plan for an adequate WAN network if you are planning to use SQL Server 2008

asynchronous mirroring or SQL Server 2008 log shipping to keep a remote site up-to-

date.

Plan to use the backup compression feature of SQL Server 2008 Enterprise Edition. By

setting the compression option in your backup script, or by configuring the application

server running SQL Server 2008 Enterprise Edition to compress by default, you can

significantly decrease the size of your database backups and shipped logs. For more

information, seeBackup Compression (SQL Server)

(http://go.microsoft.com/fwlink/?LinkId=129381&clcid=0x409).

Note: Database compression is not supported for SharePoint Products and

Technologies.

Physical storage recommendationsThe disks and arrays you choose, and how you place data on them, can significantly affect

system performance. If you are unfamiliar with RAID, consult the following resources:

For an introduction to the types of RAID used with SQL Server, seeRAID Levels andSQL Server(http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409).

For a comparison of RAID types used with SQL Server, seeComparing DifferentImplementations of RAID Levels(http://go.microsoft.com/fwlink/?LinkID=105582&clcid=0x409)

Use appropriate disks and RAID arrays

The following list provides some best practices and recommendations for choosing the best RAID

level and hard disks: More and faster disks or arrays enhance performance. The key is to maintain low

latency and queuing on all disks.

For high availability and performance (random read/write), configure your array forRAID 10.

Consult your storage hardware vendor or documentation before configuring RAIDarrays. Take into account whether a database would benefit from faster random readresponse time for example, for static Web content, where RAID 5 and RAID 10provide similar performance. On the other hand, a faster random write response timemight be more important for example, in a collaboration site with mixed read-writeusage, where RAID 10 has the advantage.

When configuring a RAID array, it is very important to align the file system to the offset

supplied by the vendor. In the absence of vendor guidance, refer to theSQL ServerPredeployment I/O Best Practices(http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409).

Separate and prioritize your data among disks

Ideally, place the tempdb, content databases, and SQL Server 2008 transaction logs on separatephysical hard disks.
http://go.microsoft.com/fwlink/?LinkId=129381&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=129381&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=129381&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105582&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105582&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105582&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105582&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105582&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105582&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105581&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=129381&clcid=0x409


15/21

The following list provides some best practices and recommendations for prioritizing data:

When prioritizing data among faster disks, use the following ranking:1. Tempdb data and transaction logs2. Database transaction log files3. Search database4. Database data files

In a heavily read-oriented portal site, prioritize data over logs.

Testing and customer data have shown that Office SharePoint Server 2007 farmperformance can be significantly impeded by insufficient disk I/O for the tempdb. Toavoid this issue, allocate dedicated disks for the tempdb. If a high workload is projectedor monitored that is, the average read operation or the average write operationrequires more than 20 ms you might need to ease the bottleneck by eitherseparating the files across disks, or by replacing your disks with faster disks.

For best performance, place the tempdb on a RAID 10 array. The number of tempdbdata files should equal the number of core CPUs, and the tempdb data files should beset at an equal size. Count dual core processors as two CPUs for this purpose. Counteach processor that supports hyper-threading as a single CPU. For more information,

seeOptimizing tempdb Performance(http://go.microsoft.com/fwlink/?LinkID=148537). Separate database data and transaction log files across different disks. If files must

share disks because the files are too small to warrant a whole disk or stripe, or youhave a shortage of disk space, put fi les that have different usage patterns on the samedisk to minimize simultaneous access requests.

Consult your storage hardware vendor for information about how to configure all logsand the search databases for write optimization for your particular storage solution.

Allocate dedicated spindles for the search database.

Use multiple data files for large content databases and the SSP searchdatabase

For improved performance for large content databases and the SSP search database, considerusing multiple data files. For more information about creating and managing filegroups, seePhysical Database Files and Filegroups(http://go.microsoft.com/fwlink/?LinkId=117909&clcid=0x409).

Notes:

The use of multiple data files for databases other than content databases and the SSPsearch database is not supported.

The use of SQL Server partitioning is not supported for SharePoint databases. Useonly simple data files.

Use multiple data files for content databases

Follow these recommendations for best performance for content databases:

Create files only in the primary filegroup for the database.

Distribute the files across separate disks.

The number of data files should be less than or equal to the number of core CPUs.Count dual core processors as two CPUs for this purpose. Count each processor thatsupports hyper-threading as a single CPU.
http://go.microsoft.com/fwlink/?LinkID=148537http://go.microsoft.com/fwlink/?LinkID=148537http://go.microsoft.com/fwlink/?LinkID=148537http://go.microsoft.com/fwlink/?LinkId=117909&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=117909&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=117909&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=148537


16/21

Create data files of equal size.

Important: Although the backup and recovery tools built in to SharePoint Products and

Technologies can be used to back up and recover multiple data files if you overwrite in the samelocation, the tools cannot restore multiple data files to a different location. For this reason, we

strongly recommend that when you use multiple data files for a content database, you use SQLServer backup and recovery tools. For more information about backing up and recovering

SharePoint, seeChoose backup and recovery tools (Office SharePoint Server)(http://go.microsoft.com/fwlink/?LinkId=117908&clcid=0x409).

Use multiple data files for the SSP search database

For the search database, we recommend that filegroups be used to segregate the tables that are

primarily used for crawl and query processing. The filegroup that hosts the tables most affectedby crawling should be moved to a different set of spindles from the primary filegroup to provide

the most reduction in impact on the I/O subsystem.

The following tables are primarily related to crawling:

MSSAnchorChangeLog MSSCrawlDeletedErrorList

MSSAnchorPendingChangeLog MSSCrawlDeletedURL

MSSAnchorText MSSCrawlErrorList

MSSAnchorTransactions MSSCrawlHostList

MSSCrawlChangedSourceDocs MSSCrawlQueue

MSSCrawlChangedTargetDocs MSSCrawlURL

MSSCrawlContent MSSCrawlURLLog

MSSTranTempTable0

Important: The product group has provided Transact-SQL scripts to use in moving these tables

to a filegroup. These scripts are the only supported mechanism for moving the tables related to

crawling. The scripts are included in the blog postSQL File groups and Search(http://go.microsoft.com/fwlink/?LinkId=132066&clcid=0x409), which is posted on the Microsoft

Enterprise Search blog.

Follow these recommendations for best performance for search databases:

Move the tables out of the primary filegroup for the database.

Distribute the files across separate disks.

Important:

The process of moving tables to a new filegroup is extremely expensive and can take hours to

complete, because it involves dropping and re-creating numerous clustered indexes. Assume thatyour database will be offline during the move.

Knownissues:

Backup and restore. SharePoint backup and restore are not filegroup-aware. There is no way to

indicate where the new filegroup should be restored to. The restore process tries to put the crawl

filegroup on the same drive that it existed on when you made the backup. To restore, you must
http://go.microsoft.com/fwlink/?LinkId=117908&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=117908&clcid=0x409http://go.microsoft.com/fwlink/?LinkId=117908&clcid=0x409http://blogs.msdn.com/enterprisesearch/archive/2008/09/16/sql-file-groups-and-search.aspxhttp://blogs.msdn.com/enterprisesearch/archive/2008/09/16/sql-file-groups-and-search.aspxhttp://blogs.msdn.com/enterprisesearch/archive/2008/09/16/sql-file-groups-and-search.aspxhttp://blogs.msdn.com/enterprisesearch/archive/2008/09/16/sql-file-groups-and-search.aspxhttp://go.microsoft.com/fwlink/?LinkId=117908&clcid=0x409


17/21

have drives for the crawl and primary filegroups with the same drive letter as that of the initial

backup drive.

Future updates, service packs, and hotfixes. Each update, service pack, and hotfix that you

apply to the server has the potential to modify the index that was moved into the CrawlFileGroup,or to add a new index to one of the tables moved to the filegroup. If this happens, the index will

be moved back to or will be re-created in the primary filegroup.

Because of the risk of index modification, after you apply any update you should repeat the

process of moving the index tables to the filegroup by running the scripts provided on the

Enterprise Search blog.

Requires at least SQL Server 2005, SQL Server 2008 preferred. The product team script that

is used to move the indexes uses features that were released in SQL Server 2005 and arecontinued in SQL Server 2008 This optimization can be performed only if you are running SQL

Server 2005 or later..

Follow vendor configuration recommendations

For optimal performance when configuring a physical storage array, adhere to the hardware

configuration recommendations supplied by the storage vendor rather than relying on the

operating systems default values.

If you do not have guidance from your vendor, we recommend that you use the DiskPart.exe disk

configuration utility to configure storage for SQL Server 2008. For more information, seePredeployment I/O Best Practices(http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409).

Monitoring, Maintaining, and TroubleshootingThe following sections list the performance counters that we recommend that you monitor. Also

listed are approximate healthy values for each counter.

For details about how to monitor performance and use performance counters, seeMonitoringPerformance(http://go.microsoft.com/fwlink/?LinkID=105584&clcid=0x409).

Physical servers

Monitor the following counters to ensure the health of your servers:

Processor: % Processor Time: _Total. On the computer that is running SQL Server,this counter should be kept between 50 percent and 75 percent. In case of constantoverloading, investigate whether there is abnormal process activity or if the serverneeds additional CPUs.

System: Processor Queue Length: (N/A). Monitor this counter to ensure that it remainsbelow two times the number of core CPUs.

Memory: Available Mbytes: (N/A). Monitor this counter to ensure that you maintain alevel of at least 20 percent of the total physical RAM available.

Memory: Pages/sec: (N/A). Monitor this counter to ensure that it remains below 100.

For more information and memory troubleshooting methods, seeSQL Server 2005 MonitoringMemory Usage(http://go.microsoft.com/fwlink/?LinkID=105585&clcid=0x409).
http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105584&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105584&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105584&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105584&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105585&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105585&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105585&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105585&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105585&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105585&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105584&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105584&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409


18/21

Disk counters to monitor

Before you deploy a new farm, we recommend that you benchmark the I/O subsystem by usingthe SQLIO disk subsystem benchmark tool. For details, seeSQLIO Disk Subsystem BenchmarkTool(http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409).

Monitor the following counters to ensure the health of your disks. The following values represent

values measured over a period of time, not during a sudden spike and not based on a singlemeasurement.

Logical Disk: Disk Transfers/sec. This counter provides the overall throughput on thespecific disk. Use this counter to monitor growth trends and forecast appropriately.

Logical Disk: Disk Read Bytes/sec & Disk Write Bytes/sec. This counter provides ameasure of the total bandwidth for a particular disk.

Logical Disk: Average Disk sec/Read(Read Latency). This counter indicates the time ittakes the disk to retrieve data. On well-tuned I/O subsystems, ideal values are 1-5 msfor logs (ideally 1 ms on a cached array), and 4-20 ms for data (ideally below 10 ms).Higher latencies can occur in peak times, but if high values are occurring regularly,investigate the cause.

Logical Disk: Average Disk sec/Write(Write Latency). This counter indicates the time it

takes the disk to write the data. On well-tuned I/O subsystems, ideal values would be1-5 ms for log (ideally 1 ms on a cached array), and 4-20 ms for data (ideally below 10ms). Higher latencies can occur in peak times, but if high values are systematicallyoccurring, investigate the cause.

Logical Disk: Average Disk Byte/Read. This counter indicates the size of I/Os beingread. This value may affect disk latency and larger I/Os may result in slightly higherlatency. When used to monitor SQL Server, this tells you the average size of the I/OsSQL Server is issuing.

Logical Disk: Average Disk Byte/Write. This counter indicates the size of I/Os beingwritten. This value may affect disk latency and larger I/Os may result in slightly higherlatency. When used to monitor SQL Server, this will tell you the average size of theI/Os SQL Server is issuing.

Physical Disk: % Disk Time: DataDrive. Monitor this counter to ensure that it remainsbelow two times the number of disks.

Logical Disk: Current Disk Queue Length. For this counter, lower values are better.Values above 20 may indicate a bottleneck in the request waiting to be served by thedisk, and should be investigated. Bottlenecks can create a backlog that may spreadbeyond the current server accessing the disk and result in long wait times for endusers. Possible solutions to a bottleneck may be to add more disks to the RAID array,replace with faster disks, or move some of the data to other disks.

Logical Disk: Average Disk Queue Length. This counter indicates the average numberof outstanding I/O requests. The general rule is that you should be at two or feweroutstanding I/O requests per spindle, but this may be difficult to measure due tostorage virtualization, differences in RAID levels between configurations. Look forhigher than average disk queue lengths in combination with higher than average disk

latencies. This combination could indicate that the storage array cache is being overutilized or that spindle sharing with other applications is affecting performance.

Logical Disk: Average Disk Reads/Secand Logical Disk: Average Disk Write/Sec.These counters indicate the rate of read and write operations on the disk. Monitorthese counters to ensure that they remain below 85 percent of the disk capacity. Diskaccess time increases exponentially if reads or writes are more than 85 percent of diskcapacity. To determine the specific I/O capacity for your hardware, refer to the vendordocumentation, or use the SQLIO disk subsystem benchmark tool to calculate it. For
http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409


19/21

more information, seeSQLIO Disk Subsystem Benchmark Tool(http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409).

When you are using RAID configurations with the Logical Disk: Average DiskReads/Secor Logical Disk: Average Disk Write/Seccounters, use the formulas listed inthe following table to determine the rate of I/Os on the disk.

RAID level Formula

RAID 0 I/Os per disk = (reads + writes) / number of disks

RAID 1 I/Os per disk = [reads + (2 * writes)] / 2

RAID 5 I/Os per disk = [reads + (4 * writes)] / number of disks

RAID 10 I/Os per disk = [reads + (2 * writes)] / number of disks

For example, if you have a RAID 1 system with two physical disks, and your counters

are at the values shown in the following table:

Counter Value

Average Disk Reads/Sec 80

Average Disk Write/Sec 70

Average Disk Queue Length 5

The I/O value per disk can be calculated as follows:

(80 + (2 * 70))/2 = 110

The disk queue length can be calculated as follows:

5/2 = 2.5

In this situation, you have a borderline I/O bottleneck.

Monitor disk latency and analyze trends. The amount of I/O and latency specific to SQLServer data files can be found by using the sys.dm_io_virtual_file_statsdynamicmanagement view in SQL Server 2008. For more information, seesys.dm_io_virtual_file_stats(http://go.microsoft.com/fwlink/?LinkID=105587&clcid=0x409).

Disk recommended practices

The following practices may help your system performance:

In respect to growth potential and peak usage patterns, maintain a level of at least 25percent available space across disks to allow for growth. If you are managing growth

by adding disks to a RAID array or allocating more storage, monitor disk size closely toavoid running out of space.

In cases in which the disk controller uses Disk Write Cache, make sure that thecontroller is backed up by a battery in the event of power failure.

SQL Server recommended practices

The following practices may help your SQL Server performance:
http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105587&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105587&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105587&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409


20/21

Proactively check the integrity of your databases by running DBCC CHECKDB () on a routine basis.

Monitor SQL Server index fragmentation, and follow the SQL Server defragmentationguidelines for SharePoint Products and Technologies provided in the Knowledge BasearticleHow to defragment Windows SharePoint Services 3.0 databases andSharePoint Server 2007 databases

(http://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409). Do not perform unsupported operations on the server that runs SQL Server. For details

about operations that are not supported, see Microsoft Knowledge Base article841057: Support for changes to the databases that are used by Office server productsand by Windows SharePoint Services(http://go.microsoft.com/fwlink/?LinkID=105589&clcid=0x409).

For more detailed recommendations about maintaining the databases that host Office SharePointServer, seeWhite paper: Database maintenance for Office SharePoint Server 2007(http://go.microsoft.com/fwlink/?LinkID=117910&clcid=0x409).

Troubleshooting

If a disk or RAID experiences a bottleneck, consider taking the following actions:

1. Relocate some of the files to a separate disk or RAID array.

2. Add disks to the array.

3. If you cannot separate the content (for example, in the case of a single contentdatabase file), replace the disks with faster ones.

4. Where possible, split the relevant content database into several databases (relocate, orsplit and relocate site collections by using tools such as the Stsadm.exe command-linetool or Microsoft Office SharePoint Designer). If the problem persists, repeat thetroubleshooting steps from step 1.

SummaryProper configuration of the SQL Server and storage subsystem is critical to the optimalperformance and operation of server farms that are running SharePoint Products and

Technologies, and can help you maintain your environment as it grows. We strongly recommendthat you consider running your environment on SQL Server 2008 Enterprise Edition to takeadvantage of the performance, availability, security, and management capabilities that it provides.

Additional ResourcesSharePoint Deployments on SQL Server 2008(http://www.microsoft.com/sqlserver/2008/en/us/sharepoint.aspx)

TechNet Webcast: Considerations for Large-Scale SharePoint Server Deployments on SQL

Server (Level 300)(http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032414992&Culture=en-US)

Integration of SQL Server 2008 and Office SharePoint 2007(http://technet.microsoft.com/en-

us/library/cc990273.aspx)
http://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105589&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105589&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105589&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=117910&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=117910&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=117910&clcid=0x409http://www.microsoft.com/sqlserver/2008/en/us/sharepoint.aspxhttp://www.microsoft.com/sqlserver/2008/en/us/sharepoint.aspxhttp://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032414992&Culture=en-UShttp://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032414992&Culture=en-UShttp://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032414992&Culture=en-UShttp://technet.microsoft.com/en-us/library/cc990273.aspxhttp://technet.microsoft.com/en-us/library/cc990273.aspxhttp://technet.microsoft.com/en-us/library/cc990273.aspxhttp://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032414992&Culture=en-UShttp://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032414992&Culture=en-UShttp://www.microsoft.com/sqlserver/2008/en/us/sharepoint.aspxhttp://go.microsoft.com/fwlink/?LinkID=117910&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105589&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105589&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409http://go.microsoft.com/fwlink/?LinkID=105588&clcid=0x409


21/21

Documents

Planning and Monitoring SQL Server 2008 Storage for Share Point