microsoftdownload.microsoft.com/download/0/8/c/08c8e79f-9644-454f... · web viewsharepoint guidance...

SharePoint guidance for MicrosoftSQL Server 2008 database administrators

Microsoft Corporation

Published: October 2009

Author: Microsoft Office System and Servers Team ([email protected])

AbstractThis book is a guide for database administrators who implement or maintain Microsoft Office SharePoint Server 2007. It provides guidelines for improving the performance of SharePoint Server solutions running on Microsoft® SQL Server™ 2008.

This guide provides information about key considerations for configuring storage and SQL Server before installing SharePoint Server; the required steps in installing SharePoint Server when using DBA-created databases; backup and recovery considerations for SharePoint Server, including what can and cannot be protected by SQL Server backups; and maintaining and monitoring SQL Server databases that support a SharePoint Server implementation.

The content in this book is a copy of selected content in the Office SharePoint Server technical library (http://go.microsoft.com/fwlink/?LinkId=84739) as of the publication date. For the most current content, see the technical library on the Web.

http://go.microsoft.com/fwlink/?LinkId=84739


mailto:[email protected]?subject=Feedback%20on%20SharePoint/SQL%20Server%20paper

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 document 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-mail addresses, 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.

Active Directory, Excel, Outlook, SharePoint, Microsoft, Windows, Windows Server, and Windows Vista 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.

ii

ContentsGetting Help............................................................................................................................ vii

I. Configuring storage and SQL Server for use with SharePoint...............................................1

Introduction to storage..............................................................................................................2Know your needs and plan ahead............................................................................................2

Planning recommendations................................................................................................3

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

Memory.............................................................................................................................. 5CPU cache......................................................................................................................... 6Bus bandwidth................................................................................................................... 6Disk and SAN interfaces....................................................................................................7Disk topology................................................................................................................... 10

Physical storage recommendations........................................................................................12Use appropriate disks and RAID arrays.................................................................................12Proactively manage data and log file growth..........................................................................12

Limit content database size to enhance manageability....................................................13Separate and prioritize your data among disks......................................................................14Use multiple data files for large content databases and the SSP search database................15

Use multiple data files for content databases...................................................................15Use multiple data files for the SSP search database.......................................................15

Follow vendor configuration recommendations......................................................................17

II: Deploying SharePoint using DBA-created databases........................................................19

Deploy using DBA-created databases....................................................................................20About deploying by using DBA-created databases................................................................20Required database hardware and software............................................................................21Required accounts.................................................................................................................21Create and configure the databases......................................................................................23

Database types and descriptions...........................................................................................30Office SharePoint Server 2007 deployed in a server farm environment.................................30

After installation...............................................................................................................31After creating a Web application......................................................................................32After starting the search service.......................................................................................32After creating an SSP......................................................................................................33

After server setting for single sign-on...............................................................................33Office SharePoint Server 2007 deployed in a stand-alone environment................................33

After installation...............................................................................................................33After server setting for single sign-on...............................................................................35

III: Backing up and recovering SharePoint.............................................................................37

Choose what to protect...........................................................................................................38Protecting content databases.................................................................................................38Protecting content stored in external data sources.................................................................38Protecting search................................................................................................................... 39Protecting SSP databases......................................................................................................39Protecting single sign-on........................................................................................................40Protecting configuration settings............................................................................................40

Protecting and recovering IIS configuration settings........................................................40Protecting and recovering the configuration database and the Central Administration

content database..........................................................................................................41Protecting customizations.......................................................................................................43

Protecting solution packages...........................................................................................43Protecting customizations that are not packaged as solutions.........................................43

Protecting binary files.............................................................................................................44

Choose backup and recovery tools........................................................................................45Available tools........................................................................................................................ 46Built-in backup and recovery tools..........................................................................................49

Central Administration......................................................................................................52Stsadm command-line tool...............................................................................................53

External backup and recovery tools.......................................................................................55Microsoft SQL Server 2008 backup and recovery............................................................55Microsoft System Center Data Protection Manager 2007................................................56Windows Server Backup..................................................................................................57

Third-party solutions and custom tools...................................................................................58Third-party solutions........................................................................................................58Solutions built on Volume Shadow Copy Service.............................................................58

IV: Maintain and monitor databases and storage...................................................................59

Maintain the databases that support Office SharePoint Server 2007.....................................60

Shrink data files......................................................................................................................61Shrinking a database by using Transact-SQL commands......................................................62

DBCC SHRINKDATABASE..............................................................................................62

NOTRUNCATE compacts the data in data files by moving allocated pages from the end of a file to unallocated pages in the front of the file....................................................................63

DBCC SHRINKFILE.........................................................................................................64

Summary................................................................................................................................ 64

Fine tune index performance by setting fill factor...................................................................65

Measure and reduce fragmentation........................................................................................66Measure fragmentation in a SQL Server 2008 database (sys.dm_db_index_physical_stats) 66Measure fragmentation in a SQL Server 2000 database (DBCC SHOWCONTIG)................68Reducing Fragmentation for a Database................................................................................69Reducing fragmentation for a specific table and its indexes...................................................71

Using ALTER INDEX........................................................................................................73About DBCC CHECKDB........................................................................................................73DBCC CHECKDB and performance.......................................................................................75

Monitoring and troubleshooting storage.................................................................................76Monitor and troubleshoot storage performance......................................................................76Physical server counters to monitor.......................................................................................76Disk counters to monitor.........................................................................................................76Other monitoring tools............................................................................................................78Troubleshooting...................................................................................................................... 79

Additional references..............................................................................................................80

Getting HelpEvery effort has been made to ensure the accuracy of this book. This content is also available online in the Office System TechNet Library, so if you run into problems you can check for updates at:

http://technet.microsoft.com/office

If you do not find your answer in our online content, you can send an e-mail message to the Microsoft Office System and Servers content team at:

[email protected]

If your question is about Microsoft Office products, and not about the content of this book, please search the Microsoft Help and Support Center or the Microsoft Knowledge Base at:

http://support.microsoft.com

vii

I. Configuring storage and SQL Server for use with SharePoint

1

Introduction to storageProper configuration of Microsoft® SQL Server® and data input/output (I/O) subsystems is critical to the optimal performance and operation of server farms that are running Windows® SharePoint® Services 3.0 or Microsoft Office SharePoint Server 2007. (The term SharePoint Products and Technologies is often used to refer to either or both Windows SharePoint Services and Office SharePoint Server.) This topic describes some of the most common practices that the SharePoint Products and Technologies team recommends with respect to storage configuration and monitoring.

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.

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 and front-end Web 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 front-end Web servers. For example, if your server that is running SQL Server is taking significantly more time to respond to a request from a front-end Web server, and if the front-end Web server is receiving requests from end users at the normal rate, requests on the front-end Web server start queuing up, eventually pushing it over its limits.

Know your needs and plan ahead Before you purchase hardware, determine your information architecture (logical structure and approximate sizing), reliability, and performance requirements for the environment in which you will 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. To support the updated and additional capabilities, the current versions of SharePoint Products and Technologies consume more infrastructure resources than older versions, even if your deployment does not use all of the new capabilities.

2

http://go.microsoft.com/fwlink/?LinkID=105577&clcid=0x409


Planning recommendations In planning, your goals are to optimize performance, scale, and manageability.

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 and deployments 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 may require relatively long shut-down periods.

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.

3

Physical topology recommendationsThe topology of your system’s database tier, and your network, physical storage, and caching can significantly affect system performance.

When you plan your hardware, remember that Office SharePoint 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 response times from the server running SQL Server 2008, it might be necessary to increase the SQL 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 running SQL Server 2008The following recommendations apply to the database tier in your topology:

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

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

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

Use SQL Server connection aliases when you configure your server farm. A connection alias is an alternate name that can be used to make a connection to a SQL Server instance. If a database server fails, you can adjust the alias on the front-end Web server to point to another server. For more information, see How to: Set a SQL Server Alias (SQL Server Management Studio) (http://msdn.microsoft.com/en-us/library/ms175176.aspx).

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

4

http://msdn.microsoft.com/en-us/library/ms175176.aspx

http://msdn.microsoft.com/en-us/library/ms175176.aspx

Consider scaling out in addition to adding resourcesIt is important to track the following three resource components of a server running SQL Server 2005: CPU, memory, and I/O subsystem. When one or more of the components seem stretched, analyze the appropriate course of action based on the current and projected work load. Then, determine whether to add more resources or to scale out to a new server running SQL Server 2005. In general, we recommend that you consider scaling out in addition to adding more resources. For more information, see Troubleshooting Performance Problems in SQL Server 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 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.

MemoryFor the purposes of determining the amount of memory required for the computers running SQL Server 2008, first determine whether the planned deployment is small, medium, or large 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.

Metric Value

Content database size 100 GB

Number of content databases 20

Number of concurrent requests to SQL Server 2008

200

Users 1000

Number of items in regularly accessed list 2000

5

http://go.microsoft.com/fwlink/?LinkID=168448


Metric Value

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 greater is recommended for large deployments.

Other factors that can influence your memory needs include:

The use of SQL Server 2008 mirroring.

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

CPU cacheOn the server running SQL Server 2008, we recommend that the L2 cache per CPU have a minimum of 2 MB to improve memory.

Bus bandwidthGreater 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 system’s reliability, especially with added multi-pathing software. Conversely, greater bus bandwidth does not give a significant increase in reliability for smaller systems. The bus bandwidth’s 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 use large block transfers and sequential I/O.

In smaller servers that use mostly sequential I/O, PCI becomes a bottleneck with three disks. 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 from small 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 the system 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.

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 for specifications.

6

Disk and SAN interfacesThe interfaces you use in your system can affect reliability and performance. Larger drives, all else 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 Queueing (TCQ) supports multiple 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 drive attached per channel.

Typically greater capacity than SCSI.

Typicallly cheaper per GB than SCSI drives.

Can only handle one outstanding I/O request per channel.

7



Serial Advanced Technology Attachment (SATA)

SCSI with TCQ supports multiple I/O requests.


Most are explicitly designed to 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.

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.

Database redundancy within a data centerYou 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://go.microsoft.com/fwlink/?LinkId=168606).

For dedicated disks or direct attached storage (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

8



client alias and that you manually manage the failover process by modifying the alias to point to the failover partner. For more information, see Using Database Mirroring with Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409).

Database redundancy across data centersData stored in either SAN and 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).

Note: Some SQL Server 2008 technologies, such as transactional replication, cannot be used with SharePoint Products and Technologies because the replication technology requires that a database have a primary key column on all tables. Before you implement replication technologies, ensure that the technology is supported for both SQL Server 2008 and Microsoft Office SharePoint Server 2007.

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 SharePoint Products and Technologies. Microsoft System Center Data Protection Manager 2007 enables disk-based and tape-based data protection and recovery for servers in and across Active Directory® domains. For additional information on Microsoft System Center Data Protection Manager 2007, see the Microsoft System Center Data Protection Manager 2007 Web site (http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspx).

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

I/O per second

9

http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/default.aspx





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


Megabytes per second

Latency

Performance of both DAS and SAN environments is affected by so many variables that simple recommendations are not possible. Examples of variables include drivers, configuration, underlying and supporting foundational technologies, and host bus adapters (HBAs).

Fibre-Channel-switched fabric can be beneficial for SAN environments, because Fibre Channels can provide multiple links through the fabric, and can thereby enable I/O path parallelism so that the 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 the farm. Plan for minimal latency before deployment, and monitor your existing systems as described in the section on Monitoring and Troubleshooting Storage.

Network topology recommendationsPlan 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.

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, see Backup Compression (SQL Server) (http://go.microsoft.com/fwlink/?LinkId=129381&clcid=0x409).

Note:

Database compression is not supported for SharePoint Products and Technologies.

Disk topologyThe disk topology that you use in your system can affect reliability and performance.

You should minimize latency on the I/O subsystem that serves the server running SQL Server 2008. Slow response from the I/O subsystem cannot be compensated for by adding other types

10


of resources (for example, CPU or memory), but can influence and cause issues throughout the farm.

Use the information in the following table to inform your choice of topology.

Topology Benefits Disadvantages Notes

SAN Can serve multiple servers.

No limitations on the number of disks that can be accessible.

Easier to install additional servers. Easier to manage many servers.

Easier to reallocate disk storage between servers.

Maintenance costs tend to be lower than Direct-attached Storage (DAS).

DAS Greater maximum bandwidth.

Easier to manage for a smaller number of servers.

Initial overhead costs are lower than SAN.

Deployed per server.

The number of disks is limited by the number of slots in the server and the type of interface used.

Consider DAS if you are experiencing bottlenecked workloads.

When the limit on the number of DAS for a particular server is reached, you must deploy an additional server running SQL Server 2008.

Network-attached storage (NAS)

I/O response time required for SQL Server 2008 cannot be guaranteed nor maintained in a NAS environment.

iSCSI can only support light I/O traffic.

We do not recommend that you use NAS due to inability to ensure sufficient latency. If networked storage is required, use iSCSI on an iSCSI- dedicated gigabit Ethernet local area network (LAN), rather than NAS.

11

Physical storage recommendationsThe disks and arrays you choose — and how you place data on those disks and arrays — can significantly affect system performance. If you are unfamiliar with Redundant Array of Independent Disks (RAID), see the following resources:

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

For a comparison of RAID levels used with SQL Server 2008, see Comparing Different Implementations of RAID Levels (http://go.microsoft.com/fwlink/?LinkID=105582&clcid=0x409)

Use appropriate disks and RAID arraysThe 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 for RAID 10.

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

When configuring a RAID array, it is crucial to align the file system to the offset supplied by the vendor. In the absence of vendor guidance, refer to the SQL Server Predeployment I/O Best Practices (http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409).

For more information about provisioning RAID, and the SQL Server I/O subsystem, see SQL Server Best Practices Article (http://go.microsoft.com/fwlink/?LinkId=168612).

Before you deploy a new farm, we recommend that you benchmark the I/O subsystem by using the SQLIO disk subsystem benchmark tool. For details, see SQLIO Disk Subsystem Benchmark Tool (http://go.microsoft.com/fwlink/?LinkID=105586).

Proactively manage data and log file growthYou should proactively manage data and log file growth by following these recommendations.

Pre-size your data and log files.

12











Do not rely on Autogrowth. Instead, manually manage the growth of data and log files. You can enable Autogrowth for safety reasons, but you should proactively manage the growth of the data files.

Configure autogrowth settings to meet the needs of your deployment.

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

Note: SQL Server 2008 that is running on Windows Server 2003 supports instant file initialization. Instant file initialization can greatly reduce the performance impact of a file growth operation. For more information, see Database 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 ALTER DATABASE MAXSIZE property.

If disk space is limited or databases cannot be sized, you should configure the autogrowth value to a fixed percentage. For example, configure the autogrowth value to 10 percent for databases under 500 GB and to a fixed number of megabytes if a database exceeds 500 GB.

Limit content database size to enhance manageability Plan for database sizing that will enhance manageability and performance of your environment. .

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.

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 design requires 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 Microsoft System Center Data Protection Manager 2007, rather than the built-in backup and recovery tools.

Test the server that is running SQL Server 2008 and the I/O subsystem before moving to a solution that depends on a 100-GB content database.

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

13


Separate and prioritize your data among disksIdeally, place the tempdb, content databases, and SQL Server 2008 transaction logs on separate physical hard disks.

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 logs

2. Database transaction log files

3. Search database

4. 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 farm performance can be significantly impeded by insufficient disk I/O for the tempdb. To avoid this issue, allocate dedicated disks for the tempdb. If a high workload is projected or monitored — that is, the average read operation or the average write operation requires more than 20 milliseconds (ms) — you might need to ease the bottleneck by either separating 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 tempdb data files should equal the number of core CPUs, and the tempdb data files should be set at an equal size. Count dual core processors as two CPUs for this purpose. Count each processor that supports hyper-threading as a single CPU. For more information, see Optimizing tempdb Performance (http://go.microsoft.com/fwlink/?LinkID=148537).

Separate database data and transaction log file across different disks. If files must share disks because the files are too small to warrant a whole disk or stripe or you have a shortage of disk space, put files that have different usage patterns on the same disk to minimize simultaneous access requests.

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

Allocate dedicated spindles for the search database.

14



Use multiple data files for large content databases and the SSP search databaseFor improved performance for large content databases and the SSP search database, consider using multiple data files.

Note: The use of multiple data files for databases other than content databases and the SSP

search database is not supported.

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

Use multiple data files for content databasesFollow these recommendations for best performance:

Only create files 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 that supports hyper-threading as a single CPU.

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 same location, 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 SQL Server backup and recovery tools. For more information about backing up and recovering Office SharePoint Server 2007, see Choose backup and recovery tools

For more information about creating and managing filegroups, see Physical Database Files and Filegroups (http://go.microsoft.com/fwlink/?LinkId=117909&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 affected by 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.

15



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 post SQL 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 that your database will be offline during the move.

Known issuesThe following sections describe known issues with using filegroups for the search database.

Backup and restoreSharePoint 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 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 hotfixesEach 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

16


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 are continued in SQL Server 2008. This optimization can be performed only if you are running SQL Server 2005 or later.

Follow vendor configuration recommendationsFor 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 system’s 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, see Predeployment I/O Best Practices (http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409).

17


II: Deploying SharePoint by using DBA-created databases

19

Deploy by using DBA-created databases In this topic:

About deploying by using DBA-created databases

Required database hardware and software

Required accounts

Create and configure the databases

About deploying by using DBA-created databasesIn many IT environments, database administrators (DBAs) create and manage databases. Security policies and other policies in your organization might require that DBAs create the databases required by Microsoft Office SharePoint Server 2007.

This article discusses how DBAs can create these databases and farm administrators configure them. This article describes how to deploy Office SharePoint Server 2007 in an environment in which DBAs create and manage databases. The deployment includes all the required databases, one portal site, a Shared Services Administration Web site, My Sites, and one Shared Services Provider (SSP). This article applies to farms that use Microsoft SQL Server 2008, SQL Microsoft SQL Server 2005, or Microsoft SQL Server 2000 with the most recent service pack.

Some procedures in this article use the Psconfig or Stsadm command-line tools. These tools are located in the following folder: Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN.

Note: This article does not cover using the Office SharePoint Server 2007 graphical user interface tools to create or configure databases. For information about creating and configuring databases by using the Office SharePoint Server 2007 graphical user interface tools, see Simple farm deployment (http://technet.microsoft.com/en-us/library/cc262243.aspx).

Using these procedures, the DBA will create databases and the farm administrator will perform other configuration actions in the following order:

The configuration database (only one per farm).

The content database for Central Administration (only one per farm).

Central Administration Web application (only one per farm, created by Setup).

The Windows SharePoint Services search database (only one per farm).

Start the Office SharePoint Search service.

20

http://technet.microsoft.com/en-us/library/cc262243.aspx

For each portal site:

Portal site Web application content database.

For each SSP:

A content database for the My Sites Web application (if the SSP is using its own Web application).

A content database for the Shared Services Administration Web application (if the SSP is using its own Web application).

SSP Search database (one per SSP).

SSP Web application (created by Setup if the SSP is using its own Web application).

Note: As part of the Web site and application pool creation process, a Web application is also created in Internet Information Services (IIS). Extending a Web application will create an additional Web site in IIS, but not an additional application pool.

Required database hardware and softwareBefore you install and configure the databases, be sure that your database servers have the recommended hardware and software. For more information about these requirements, see Determine hardware and software requirements (http://technet.microsoft.com/en-us/library/cc262485.aspx).

There are also requirements specific to the database server, and, if you are using SQL Server 2008 or SQL Server 2005 database software, the DBA must configure surface area settings so that local and remote connections use TCP/IP only.

All of the databases required by Office SharePoint Server 2007 use the Latin1_General_CI_AS_KS_WS collation. All of the databases require that the Setup user account be assigned to them as the database owner (dbo, or db_owner). For more information about the security requirements for these databases, see Plan for administrative and service accounts (http://technet.microsoft.com/en-us/library/cc263445.aspx).

Required accountsThe DBA needs to create SQL Server logins for the accounts that are used to access the databases for Office SharePoint Server 2007 and add them to roles

For more information about the required accounts, including specific permissions and roles required for these accounts, see Plan for administrative and service accounts (http://technet.microsoft.com/en-us/library/cc263445.aspx).

21





The following table describes the accounts that are used to access the databases for Office SharePoint Server 2007.

Account Purpose Requirements

SQL Server Service Account

This account is used as the service account for the following SQL Server services:

MSSQLSERVER

SQLSERVERAGENT

If you are not using the default instance, these services will be shown as:

MSSQL$InstanceName

SQLAgent$InstanceName

SQL Server prompts for this account during SQL Server Setup. You have two options:

Assign one of the built-in system accounts (Local System, Network Service, or Local Service) to the logon for the configurable SQL Server services. For more information about these accounts and security considerations, refer to the Setting Up Windows Service Accounts topic (http://go.microsoft.com/fwlink/?LinkId=121664&clcid=0x409) in the SQL Server documentation.

Assign a domain user account to the logon for the service. However, if you use this option you must take the additional steps required to configure Service Principal Names (SPNs) in Active Directory in order to support Kerberos authentication, which SQL Server uses.

Setup user account

The Setup user account is used to run the following:

Setup on each server

The SharePoint Products and Technologies Configuration Wizard

The PSConfig command-line tool

The Stsadm command-line tool

Domain user account

Member of the Administrators group on each server on which Setup is run

SQL Server login on the computer running SQL Server

Member of the following SQL Server security roles:

securityadmin fixed server role

dbcreator fixed server role

If you run Stsadm command-line tool commands that read from or write to a database, this account must be a member of the db_owner fixed database role for the database.

22



Account Purpose Requirements

Server farm account/Database access account

The Server farm account is used to:

Act as the application pool identity for the SharePoint Central Administration application pool.

Run the Windows SharePoint Services Timer service.

Domain user account.

If the server farm is a child farm with Web applications that consume shared services from a larger farm, this account must be a member of the db_owner fixed database role on the configuration database of the larger farm.

Additional permissions are automatically granted for this account on Web servers and application servers that are joined to a server farm.

This account is automatically added as a SQL Server login on the computer running SQL Server and added to the following SQL Server security roles:

dbcreator fixed server role

securityadmin fixed server role

db_owner fixed database role for all databases in the server farm

Note: If you are using the least-privilege principle for added security, use a different account for each service, process, and application pool identity for each Web application. Each SSP will use two accounts, one for the SSP service account and one for the application pool identity for the Shared Services Administration Web application.

Create and configure the databasesUse the procedures in this section to create the required databases and give the accounts membership in the database Users security group and database roles.

The procedures require action by the DBA and the Setup user account. Each step is labeled [DBA] or [Setup] to indicate which role performs the action.

The following procedure will only have to be performed once for the farm, on the server you want to run the Central Administration Web site. The farm only has one configuration database and one content database for Central Administration.

Create and configure the configuration database, the Central Administration content database, and the Central Administration Web application

1. [DBA] Create the configuration database and the Central Administration content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [Setup] Run Setup on each server computer in the farm. You must run Setup on at least

23

one of these computers by using the Complete installation option.

Note: The rest of the farm servers will be configured after the procedures in the article are finished and the farm is established. You will run the SharePoint Products and Technologies Configuration Wizard on these servers by selecting the Yes, I want to connect to an existing server farm option, instead of by using the commands used in this procedure.

3. [Setup] On the server on which you used the Complete installation option, do not run the SharePoint Products and Technologies Configuration Wizard after Setup. Instead open the command line, and then run the following command to configure the databases:

Psconfig –cmd configdb –create –server <SqlServerName> –database <SqlDatabaseName> –user <DomainName\UserName> –password <password> –admincontentdatabase <SqlAdminContentDatabaseName>

Note: <SqlDatabaseName> is the configuration database. -user is the server farm account. <SqlAdminContentDatabaseName> is the Central Administration content database.

4. [Setup] After the command has completed, run the SharePoint Products and Technologies Configuration Wizard and complete the remainder of the configuration for the server. This creates the Central Administration Web application and performs other setup and configuration tasks.

5. [DBA] After the SharePoint Products and Technologies Configuration Wizard has completed, perform the following actions for both the configuration database and the Central Administration content database:

Add the Office SharePoint Server Search account, default content access account, and the SSP service account to the Users group.

Add the Office SharePoint Server Search account, default content access account, and the SSP service account to the WSS_Content_Application_Pools role.

6. [Setup] To confirm that the databases were created and correctly configured, verify that the home page of the Central Administration Web site can be accessed. However, do not configure anything by using Central Administration at this time. If the Central Administration page does not render, verify the accounts used in this procedure and ensure that they are properly assigned.

The following procedure will only have to be performed once for the farm. The farm has only one Windows SharePoint Services search database.

Create and configure the Windows SharePoint Services Search database and start the Windows SharePoint Services Search service

1. [DBA] Create the Windows SharePoint Services Search database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo)

24

to be the Setup user account.

2. [Setup] Open the command line, and then run the following command to configure the database and start the Windows SharePoint Services Search service:

stsadm -o spsearch -action start -farmserviceaccount <DomainName\UserName> -farmservicepassword <password> -farmcontentaccessaccount <DomainName\UserName> -farmcontentaccesspassword <password> -databaseserver <server\instance> -databasename <DatabaseName>

Note: -farmserviceaccount is the server farm account. -farmcontentaccessaccount is the Office SharePoint Services Search service account. For -databaseserver, if you are using the default instance of SQL Server, you only have to specify the name of the computer running SQL Server.

The following procedure must be performed once for each server running indexing or search queries in the farm.

Start the Office SharePoint Server Search service on each server that will run search queries or indexing

1. [Setup] Open the command line, and then run the following command:

stsadm -o osearch -action start -role <OsearchRole>-farmcontactemail <FarmContactEmail> -farmserviceaccount <DomainName\UserName> -farmservicepassword <password>For additional information, see Osearch (http://technet.microsoft.com/en-us/library/cc262920.aspx).

Note: farmserviceaccount is the server farm account. role specifies what type of server role the server plays. The values for OsearchRole can be "Index", "Query", or "IndexQuery". For more information about these options, see Add query servers to expand a farm (http://technet.microsoft.com/en-us/library/cc297192.aspx).

The following procedure will only have to be performed once for the farm. The farm only has one My Sites database. The My Sites Web application typically is hosted by its own SSP.

Create and configure the content database and Web application for My Sites

1. [DBA] Create the My Sites content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [DBA] Add the SSP service account to the db_owner role for the My Sites Web application content database.

3. [Setup] Open the command line, and then run the following command to configure the My Sites content database:

stsadm.exe -o extendvs -url <url> -donotcreatesite -exclusivelyusentlm -

25




databaseserver <DatabaseServerName> -databasename <DatabaseName> -apidtype configurableid -description <IISWebSiteName> -apidname <AppPoolName> -apidlogin <DomainName\UserName> -apidpwd <password>For additional information, see Extendvs (http://technet.microsoft.com/en-us/library/cc263040.aspx).

Note: url is the URL (in the form http://hostname:port) of the My Sites Web application. databasename is the content database for the My Sites Web application. description is the text name you give to the Web site in IIS. apidname is the text name that you give to the Web application pool in IIS. apidlogin is the identity for the application pool in IIS. This is the application pool process account. If you are using Kerberos v5 authentication rather than NTLM authentication, use the negotiate parameter rather than the exclusivelyusentlm parameter

Important: This command must be run on the same computer that is indicated in the url parameter. This is the same computer that is running the My Sites Web application. The host name and port combination must not describe a Web application that already exists or an error will result without creating the Web application.

4. [Setup] Open the command line, and then run the following command to restart IIS: iisreset /noforce.

You must create a Shared Services Administration site Web application for every SSP in the farm.

Create the content database and the Web application for the Shared Services Administration site

1. [DBA] Create the Shared Services Administration site content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [DBA] Using SQL Server Management Studio, add the SSP service account to the Users group and then to the db_owner role for the Shared Services Administration site content database.

3. [Setup] Open the command line, and then run the following command to create the Shared Services Administration site Web application and configure the content database:

stsadm.exe -o extendvs -url <url> -donotcreatesite -exclusivelyusentlm -databaseserver <DatabaseServerName> -databasename <DatabaseName> -apidtype configurableid -description <IISWebSiteName> -apidname <AppPoolName> -apidlogin <DomainName\UserName> -apidpwd <password>

For additional information, see Extendvs (http://technet.microsoft.com/en-us/library/cc263040.aspx).

26



Note: url is the URL (in the form http://hostname:port) of the Shared Services Administration site Web application. databasename is the content database for the Shared Services Administration site Web application. description is the text name you give to the Web site in IIS. apidname is the text name that you give to the application pool in IIS. apidlogin is the identity for the application pool in IIS. This is the application pool process account. If you are using Kerberos v5 authentication rather than NTLM authentication, use the negotiate parameter rather than the exclusivelyusentlm parameter

Important: This command must be run on the same computer that is indicated in the url parameter. This is the same computer that is running the Shared Services Administration Web application. The host name and port combination must not describe a Web application that already exists or an error results and the Web application is not created.


The following procedure will have to be performed once for each portal site in the farm.

Create and configure the portal site Web application content database

1. [DBA] Create the portal site Web application content database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [DBA] Using Microsoft SQL Server Management Studio, add the SSP Service account to the Users group and then to the db_owner role for the portal site Web application content database.

3. [Setup] Open the command line, and then run the following command to configure the portal site Web application content database:

stsadm.exe -o extendvs -url <url> -donotcreatesite -exclusivelyusentlm -databaseserver <DatabaseServerName> -databasename <DatabaseName> -apidtype configurableid -description <IISWebSiteName> -apidname <AppPoolName> -apidlogin <DomainName\UserName> -apidpwd <password>For additional information, see Extendvs (http://technet.microsoft.com/en-us/library/cc263040.aspx).

Note: url is the URL (in the form http://hostname:port) of the portal site Web application. databasename is the content database for the portal site Web application. description is the text name you give to the Web site in IIS.

27


apidname is the text name that you give to the Web application pool in IIS. apidlogin is the identity for the application pool in IIS. This is the application pool process account. If you are using Kerberos v5 authentication rather than NTLM authentication, use the negotiate parameter rather than the exclusivelyusentlm parameter.

Important: This command must be run on the same computer that is indicated in the url parameter. This is the same computer that is running the Web application. The host name and port combination must not describe a Web application that already exists or an error results and the Web application is not created.


The following procedure must be performed once for each SSP in the farm.

Create and configure the SSP content database and SSP Search database, and then create and configure the SSP

1. [DBA] Create the SSP content database and the SSP Search database using the LATIN1_General_CI_AS_KS_WS collation sequence and set the database owner (dbo) to be the Setup user account.

2. [DBA] Using Microsoft SQL Server Management Studio, add the following accounts to the Users group and then to the db_owner role in both databases:

Server farm account

SSP Service account

Windows SharePoint Services Search service account

Office SharePoint Server Search service account

Application pool process account. This is the Web application pool identity for each Web application associated with the SSP. In this article, these are the Shared Services Administration Web application and the My Sites site Web application.

3. [Setup] Open the command line, and then run the following command to create the SSP (the SSP will use the DBA-created SSP content database and the SSP Search database):

stsadm -o createssp -title <SSPName> -url <url> -mysiteurl <url>-ssplogin <UserName> -ssppassword <password> -indexserver <IndexServerName>-indexlocation <IndexFilePath>-sspdatabaseserver <SSPDatabaseServerName> -sspdatabasename <SSPDatabaseName> -searchdatabaseserver <SearchDatabaseServer> -searchdatabasename <SearchDatabaseName>For additional information, see Createssp (http://technet.microsoft.com/en-us/library/cc262773.aspx).

Note:

28


url is the URL (in the format http://hostname:port/ssp/admin) of the Shared Services Administration site. mysiteurl is the URL (in the format http://hostname:port) of the My Sites Web site. ssplogin is the SSP service account in the format domain\username. indexserver is the name of the server that the index is hosted on. indexlocation is the directory on the index server where the farm administrator specified the index to be stored. By default this is SystemDrive:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications.

Important: This command must be run on the same computer that is indicated in the url parameter. This is the same computer that is running the Web applications. In this article, this is the server where the Shared Services Administration site Web application and the My Sites Web application are running.

Note: For more information about properly sizing these databases, see Estimate performance and capacity requirements (http://technet.microsoft.com/en-us/library/cc261716.aspx) and Estimate performance and capacity requirements for portal collaboration environments (http://technet.microsoft.com/en-us/library/cc263100.aspx).

29





Database types and descriptionsIn this article:

Office SharePoint Server 2007 deployed in a server farm environment

Office SharePoint Server 2007 deployed in a stand-alone environment

This article provides information about the database types and their descriptions, such as configuration, search, and content database. It provides details about the name, purpose, location, and restoration of databases that are created by using Microsoft Office SharePoint Server 2007 in a server farm or stand-alone environment.

Note: The database names specified in the tables in this article are the default names for the databases. You can specify the name of the database, when you create it, except SharePoint_AdminContent_GUID database.

Office SharePoint Server 2007 deployed in a server farm environmentWhen you install Microsoft Office SharePoint Server 2007 for a server farm, the database server must be running Microsoft SQL Server 2008, Microsoft SQL Server 2005 or Microsoft SQL Server 2000 with the latest service pack installed. You do not need to set up or create specific databases for Office SharePoint Server 2007. The Office SharePoint Server 2007 Setup program creates the necessary databases when you install and configure Office SharePoint Server 2007.

30

After installationThe following table lists the name, purpose, location, and restoration information for databases that are created when you install Office SharePoint Server 2007 in the server farm environment.

Default database name Purpose Location

SharePoint_AdminContent_GUID

Content databases store all Office SharePoint Server 2007 content. Use the SharePoint Central Administration Web site to add new databases.

Note:

When provisioning the initial configuration database, we recommend that you create the administration database by using a name other than _GUID.

For example:

psconfig -cmd configdb -create -server <SQL Server Alias> -database <CustomerConfiguration> -user <Domain>\<Username> -password <Password> -admincontentdatabase <Customer>_Administration_Content>>

<install drive>\%PROGRAMFILES%\Microsoft SQL Server\MSSQL.1\MSSQL\Data

SharePoint_Config The configuration database contains data about all the databases used, all Internet Information Services (IIS) Web sites or Web applications, solutions, Web Part packages, site templates, and Web application and farm settings specific to SharePoint technologies, such as default quota, blocked file types, and configuration.


31

After creating a Web applicationThe following table lists the name, purpose, location, and restoration information for databases that are created when you create a Web application.

Default database name

Purpose Location

WSS_Content This database contains data specific to a Web application and its site collections. It contains the content data, such as a document uploaded to a list or a library. By default, a single content database is created for each Web application. As new site collections are added to a Web application, the content for that site collection is stored in the database assigned to the parent Web application.


After starting the search serviceThe following table lists the name, purpose, location, and restoration information for databases that are created when you start the search service.


WSS_Search This database is used for the search services. It contains the information that is required for searching content.


32

After creating an SSPThe following table lists the name, purpose, location, and restoration information for databases that are created when you create a Shared Services Provider (SSP).


SharedServicesN_DB Each SSP requires a database for service-specific data.


SharedServicesN_Search_DB

In addition to the SSP database, a separate database is required for frequently changing search-related data.


After server setting for single sign-onThe following table lists the name, purpose, location, and restoration information for databases that are created when you specify settings for single sign-on (SSO).


SSO This database stores the settings and account information for single sign-on.


Office SharePoint Server 2007 deployed in a stand-alone environmentWhen you deploy Office SharePoint Server 2007 on a single server by using the default settings, the Setup program automatically installs Microsoft SQL Server 2005 Express Edition and uses it to create the configuration database and content database for the SharePoint sites. In addition, the Setup program creates an SSP, installs Central Administration, and creates the first site collection and site.

After installationThe following table lists the name, purpose, location, and restoration information for databases that are created when you install Office SharePoint Server 2007 in a stand-alone environment.

33


SharePoint_AdminContent_GUID

Content databases are used to store all Office SharePoint Server 2007 content. You can add new databases by using Central Administration.

<install drive>\%PROGRAMFILES%\Microsoft Office Servers\12.0\Data\MSSQL.N\MSSQL\Data

SharePoint_Config The configuration database contains data about all the databases used, all of the IIS Web sites, Web applications, solutions, Web Part packages, site templates, and Web application and farm settings specific to SharePoint technologies, such as default quota, blocked file types, and configuration.


SharedServicesN_DB Each SSP requires a database for service-specific data.


SharedServicesN_Search_DB

In addition to the SSP database, a separate database is required for frequently changing search-related data.


SharedServicesContent This database is dedicated for the shared services content.


WSS_Content This database contains data specific to a Web application and its site collections. It contains the content data, such as the document uploaded to a list or a library. By default, a single content database is created for each Web application. All new site collections added to a Web application use the same database.

<install drive>\%PROGRAMFILES%\Microsoft Office Servers\12.0\Data\MSSQL.N\M MSSQL\Data

WSS_Search This database is used for the <install drive>\

34


_ComputerName search services. It contains the information that is required for searching content.

%PROGRAMFILES%\Microsoft Office Servers\12.0\Data\MSSQL.N\MSSQL\Data

After server setting for single sign-onThe following table lists the name, purpose, location, and restoration information for databases that are created when you specify settings for single sign-on.


SSO This database stores the settings and account information for single sign-on.


See AlsoGeneral Reference (http://technet.microsoft.com/en-us/library/cc700388.aspx)

Installation points for Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc678869.aspx)

SharePoint Timer Job Reference (http://technet.microsoft.com/en-us/library/cc678870.aspx)

Temporary files created during backup, import/export, and upgrade (http://technet.microsoft.com/en-us/library/cc678867.aspx)

35





III: Backing up and recovering SharePoint

37

Choose what to protect Within a farm, there are many components that require protection:

Content stored in SQL Server 2008, SQL Server 2005, or SQL Server 2000 databases

Content stored in external storage devices

Shared services, such as the search service database and index, and single sign-on

Configuration settings for Microsoft Office SharePoint Server 2007 that are stored in Internet Information Services (IIS) and the configuration database

Customizations

Binary files for both the operating system and Office SharePoint Server 2007

In this article:

Protecting content databases

Protecting content stored in external data sources

Protecting search

Protecting SSP databases

Protecting single sign-on

Protecting configuration settings

Protecting customizations

Protecting binary files

Protecting content databasesOffice SharePoint Server 2007 content is stored in SQL Server databases. We recommend that you back up all content databases by using any of the following tools:

Office SharePoint Server built-in tools

SQL Server tools

Third-party tools that are built on supported Application Programming Interfaces (APIs) and SharePoint Products and Technologies, such as the Volume Shadow Copy Service (VSS)

Your backup and recovery strategy should address each of these components on the servers in your system.

Protecting content stored in external data sourcesAn external storage API is available for Office SharePoint Server 2007. The external storage API lets you store documents or files on an external storage application other than Microsoft SQL Server. This API also lets you upgrade existing Office SharePoint Server 2007 sites to point to an

38

external storage application. The API is available in Office SharePoint Server 2007 with SP1, and also in hotfix 937901: An external storage API is available for Windows SharePoint Services 3.0 on the Microsoft Help and Support Web site (http://go.microsoft.com/fwlink/?LinkID=106214&clcid=0x409). You cannot use the backup and recovery tools built in to Office SharePoint Server 2007 to back up data stored in external data sources, but you can use the Stsadm export and import operations. For more information about export and import, see:

Export: Stsadm operation (http://technet.microsoft.com/en-us/library/cc262759.aspx)

Import: Stsadm operation (http://technet.microsoft.com/en-us/library/cc261866.aspx)

Protecting searchSearch content for Microsoft Office SharePoint Server 2007 is stored both in the Shared Services Provider name_Search database and in the search index file. Because search data in the database and index must be synchronized, you should only back search up using SharePoint Products and Technologies tools such as the Stsadm command-line tool, or Central Administration backup and recovery, or tools based on the SharePoint Volume Shadow Copy Service (VSS), such as Microsoft System Center Data Protection Manager 2007. These tools synchronize the database backup with the search index file backup, and both can be restored together. For more information about these tools, see Choose backup and recovery tools.

We do not recommend that you back up the search databases by using SQL Server, because the search indexes are not stored in SQL Server and cannot be synchronized with the search database after a database-only backup. If you must restore a search database backed up with SQL Server tools, Office SharePoint Server must re-create the index and perform a full crawl of the content.

Search consists of the following services:

Office SharePoint Server Search. Enables searching of content that is defined as searchable.

Windows SharePoint Services Help Search (optional). Enables searching of the Help system that is built into Office SharePoint Server 2007.

Each service is used to crawl, index, and query content, and each service uses a separate index.

You must back up all search databases and indexes in your system to be able to restore search.

Protecting SSP databasesConfiguration information for Office SharePoint Server 2007 SSPs is stored in Microsoft SQL Server databases. We recommend that you back up all SSP databases, except Search databases by using any of the following tools:

Office SharePoint Server built-in tools

SQL Server tools

Third-party tools that are built on supported Application Programming Interfaces (APIs) and SharePoint Products and Technologies, such as the Volume Shadow Copy Service (VSS)

39




The tool you choose to back up your SSP databases determines the granularity with which you can restore objects from a database. For more information about choosing tools, see Choose backup and recovery tools.

Protecting single sign-onIf your environment includes a single sign-on (SSO) shared service, back it up weekly, or when any changes are made. To successfully back up SSO, you must back up both the SSO database and the SSO encryption key.

The SSO database can be backed up by using any supported database backup tool.

The SSO encryption key can be backed up from the Manage Encryption Key page in Central Administration. You should back up the encryption key after initially setting up SSO and then back up the key again each time it is regenerated. The encryption key cannot be backed up remotely. You must be a member of the SSO administrator account and logged onto the encryption-key server locally to back up the encryption key. The encryption key can only be backed up to a removable storage media.

The removable storage device that contains the SSO encryption key must be physically located at the secondary farm before attempting the steps required on the secondary farm.

For more information about single sign-on, see Plan for single sign-on (http://technet.microsoft.com/en-us/library/cc262305.aspx).

Protecting configuration settingsConfigurations include Internet Information Services (IIS) configuration settings and configuration settings for Office SharePoint Server 2007.

Protecting and recovering IIS configuration settingsYou can set IIS configurations in IIS Manager or on the SharePoint Central Administration Web site. IIS configurations are stored in the IIS metabase on each front-end Web server in your system.

You can also set IIS configurations on any front-end Web computers that are running Microsoft SQL Server Reporting Services.

IIS configurations include the following:

Application pool settings, including service accounts

HTTP compression settings

Time-out settings

Custom Internet Server Application Programming Interface (ISAPI) filters

Computer domain membership

Internet Protocol security (IPsec) settings

Network Load Balancing settings

40


Host header entries

Secure Sockets Layer (SSL) certificates

Dedicated IP address settings

In previous versions of SharePoint Products and Technologies, we recommended that you back up the IIS metabase. Conversely, for this version of SharePoint Products and Technologies, we recommend that you document all IIS configurations for each front-end Web server, if possible, by using a tool that provides Desired Configuration Monitoring (DCM).

Protecting and recovering the configuration database and the Central Administration content databaseConfigurations in Office SharePoint Server 2007 are set in Central Administration and stored in the configuration database.

Important Although the configuration database and Central Administration content database can be

backed up, restoring backups of the configuration database and Central Administration content database taken from a running farm by using the tools built in to SharePoint Products and Technologies or SQL Server is not supported.

This is because data in these databases may not be synchronized with data in other Office SharePoint Server 2007 or Windows SharePoint Services 3.0 databases. Therefore, the tools built in to SharePoint Products and Technologies do not recover these databases during a farm-level restore operation.

If this data is not synchronized, users might experience various random errors. For more information, see Microsoft Knowledge Base article 948725: Restoration of the configuration database is not supported in SharePoint Server 2007 and in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=117755&clcid=0x409).

You can recover a farm, including the configuration database and Central Administration content database, in the following ways:

You can use farm-level backups of a running farm taken with System Center Data Protection Manager to recover an entire farm, including the configuration database and Central Administration content database. For more information, see How to Recover a Windows SharePoint Services Farm (http://go.microsoft.com/fwlink/?LinkId=102831&clcid=0x409).

You can restore a backup of the configuration database and Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (http://technet.microsoft.com/en-us/library/cc512725.aspx).

If the configuration and Central Administration content databases of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products and Technologies Configuration Wizard or Psconfig command-line tool.

41







To protect the configuration database and Central Administration content database:

Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Recover from a corrupt configuration database (http://technet.microsoft.com/en-us/library/cc512815.aspx)

Consider a redundancy solution, such as clustering or mirroring, for the computer running SQL Server that is hosting the configuration database. For more information about using mirroring, see Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409).

We strongly recommend that you document all configuration settings and all your customizations, so that you can correctly re-create the configuration and Central Administration content databases.

Configuration settings in Office SharePoint Server 2007 that you should document include:

Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).

Alternate access mapping settings.

Farm-level search settings.

External service connection settings.

Workflow management settings.

E-mail settings.

A/V settings.

Usage analysis processing settings.

Diagnostic logging settings.

Content deployment settings.

Timer job settings.

HTML viewer settings.

Recycle Bin settings and other Web application general settings.

Administrator-deployed form templates.

Default quota templates.

Database names and locations.

Web application names and databases. Be sure to document the content database names associated with each Web application.

Crawler impact rules.

Activated features.

Blocked file types.

42





Protecting customizationsCustomizations to SharePoint sites can include:

Master pages, page layouts and cascading style sheets. These objects are stored in the content database for a Web application.

Web Parts, site or list definitions, custom columns, new content types, custom fields, custom actions, coded workflows, or workflow activities and conditions.

Third-party solutions and their associated binary files and registry keys, such as IFilters.

Changes to standard XML files.

Custom site definitions (Webtemp.xml).

Protecting solution packagesWe recommend that you use solution packages whenever possible to deploy site customizations. A solution is a container for one or more customizations. Solutions can contain features, Web Parts, security policy changes, and other files with a detailed guide to allow the automated deployment to the file system by the deployment mechanisms in SharePoint Products and Technologies. Solutions include IFilters. Features are portions of solutions that can be activated by the server administrator against the farm, a specific Web application, a specific site collection, or a specific Web site. For more information about solutions, see: Solutions Overview (http://go.microsoft.com/fwlink/?LinkID=103011&clcid=0x409).

You can use solution packages to simplify the backup and recovery process. Back up each solution package, both onsite and offsite, and then, in the event of a disaster, redeploy the solution to the appropriate servers.

Protecting customizations that are not packaged as solutionsFor systems in which customizations are not or cannot be packaged as solutions, backing up and restoring customizations is a more complex process. The following table lists the locations where customizations are often stored on front-end Web servers.

Location Description

%COMMONPROGRAMFILES% \Microsoft Shared\Web server extensions\12

Commonly updated files, custom assemblies, custom templates, custom site definitions. In particular, the Web.config file is often modified.

Inetpub Location of IIS virtual directories.

C:\WINNT\assembly Global assembly cache (GAC). The GAC is a protected operating system location where .NET Framework code assemblies are installed to provide full system access.

43


Consult with your development team or customization vendor to determine whether your customizations involve additional add-in software or files in other locations. We recommend that you back up these directories by using Windows Server 2003 Backup.

Protecting binary filesIn the event that you need to restore a system, we recommend that you reinstall the operating system, Office SharePoint Server 2007, and software updates. Keep copies of all the operating system, software, and software update media both onsite and offsite.

See AlsoPlan for backup and recovery (http://technet.microsoft.com/en-us/library/cc261687.aspx)

Protecting and recovering Office SharePoint Server 2007 (http://technet.microsoft.com/en-us/library/cc263053.aspx)

44



Choose backup and recovery toolsIn this article:

Available tools

Built-in backup and recovery tools

External backup and recovery tools

Third-party solutions and custom tools

The tools that you choose to use for backing up and recovering your system are based on your needs, constraints, and the service level agreements (SLAs) that you have in place with your customer groups.

Key factors to consider in determining which tools to use include:

Backup type supported (full, differential, incremental).

Completeness of recovery and types of objects that can be recovered.

Complexity of managing solution.

Ability of solution to adapt to your maintenance window and database size.

In some business situations, you may be able to use a high-availability solution, such as database clustering, log shipping, or mirroring to meet your data protection and recovery needs. For more information about planning for high availability, see Plan for availability (http://technet.microsoft.com/en-us/library/cc748824.aspx).

45


Available toolsThe following table lists Microsoft tools that you can use for disaster recovery.

Tool Source of tool

User Interface

Backup type

Level of backup and recovery

Notes

Office

SharePoint

Server:

Central

Admin.

Built-in Graphical Full and

differential

Farm

Web application

Shared Services

Providers (SSPs),

including Search

database and

Search index

Content database

Cannot be used to schedule

backups.

As part of a farm backup, can

back up the configuration

database and the Central

Administration content database,

but will not restore them. For more

information, see Recovering the

configuration database and

Central Administration content

database.

Cannot back up directly to tape.

Office

SharePoint

Server:

Stsadm.exe

backup and

recovery

operations

Built-in Command

line

Full and

differential

Farm

Web application

SSPs, including

Search database

and Search index

Content database

Site collection

Can be used with Windows Task

Scheduler to schedule backup

jobs.

Can back up the configuration

database and the Central


but will not restore them. For more

information, see Recovering the

configuration database and


database.

Cannot back up directly to tape.

46

Tool Source of tool

User Interface

Backup type


Notes

Microsoft

SQL Server

2008

Backup and

Recovery

Graphical Full and

differential

Content database

Single sign-on

(SSO) database

Configuration

database and

Central

Administration

content database

Can be used to schedule

backups.


database and Central


but restoring is not supported. For

more information, see Recovering

the configuration database and


database.

Not recommended for use with

search, because indexes are not

stored in SQL Server. If used for

search, requires a full crawl on

recovery.

Can back up directly to tape.

Offers backup compression in

SQL Server 2008 Enterprise

Edition.

Microsoft

System

Center Data

Protection

Manager

2007

Incre-

mental

Farm

Database

SSP, including

search database

and search index

Site

Content item


backups.

Can back up files and folders

containing customizations.





and restore as part of a farm

recovery. For more information,

see Recovering the configuration


Administration content database.

Windows

Server 2003

Backup tool

(Ntbackup.exe)

Graphical Full Specified folder and

file


backups.

Can back up files and folders

containing customizations.

47

Tool Source of tool

User Interface

Backup type


Notes

Windows

Server 2008

Backup

As of Office

SharePoint

Server 2007

with SP1,

you can now

install Office

SharePoint

Server 2007

on Windows

Server 2008.

Graphical Full Specified folder and

file

You must configure specific

registry keys for Windows Server

Backup to work. For more

information, see Windows

SharePoint Services 3.0 does not

appear in the list of the

components that can be backed

up when you use Windows Server

Backup in Windows Server 2008

(http://go.microsoft.com/fwlink/?

LinkId=108244&clcid=0x409) in

the Microsoft Knowledge Base.

48




Built-in backup and recovery toolsOffice SharePoint Server 2007 provides two built-in backup and recovery tools: Central Administration and the Stsadm command-line tool.

The following figure illustrates how built-in Office SharePoint Server backup works. A backup is triggered from either Central Administration or the Stsadm command-line tool. The Central Administration application pool writes files to the specified file server and triggers a SQL Server database backup to the same file server. The path provided to the backup is the location where a folder is created for backup (spbr0000, spbr0001, and so on).

The following table compares the functionality available in the built-in backup and recovery tools.

Functionality Central Administration Stsadm command-line tool

Back up the server farm Yes Yes

Recover the server farm, except the configuration and Central Administration databases

Yes Yes

Recover the configuration and Central Administration databases

No No

49

Functionality Central Administration Stsadm command-line tool

Back up Web applications Yes Yes

Back up an SSP Yes Yes

Back up site collections No Yes

Back up content databases Yes Yes

Back up customizations No No

Schedule backups No Yes, if used with Windows task scheduler

PerformanceYour hardware configuration and the size of the database, site collection, or Web application that you are working with can significantly affect the performance of the built-in backup and recovery tools.

Note: Search databases can become very large. One way to manage the size of your search backup is to ensure that the database index is defragmented. You may want to use the defragmentation script provided in the Microsoft Knowledge Base article How to defragment Windows SharePoint Services 3.0 databases and SharePoint Server 2007 databases (http://go.microsoft.com/fwlink/?LinkId=102795&clcid=0x409).

If your system exceeds the following limits, or if backing up your system exceeds the maintenance window that you have available, we recommend that you consider using external backup and recovery tools, such as Microsoft SQL Server 2008 Back and Recovery or Microsoft System Center Data Protection Manager.

Content databases larger than 100 gigabytes (GB).

Site collections that are larger than 15 GB that you want to back up by using the Stsadm command-line tool.

50




Recovering the configuration database and Central Administration content databaseConfigurations are set in Central Administration and stored in the configuration database.

Important Although the configuration database and Central Administration content database can be

backed up, restoring backups of the configuration database and Central Administration content database taken from a running farm by using the tools built in to SharePoint Products and Technologies or SQL Server is not supported.

This is because data in these databases may not be synchronized with data in other Office SharePoint Server 2007 or Windows SharePoint Services 3.0 databases. Therefore, the tools built in to SharePoint Products and Technologies do not recover these databases during a farm-level restore operation.

If this data is not synchronized, users might experience various random errors. For more information, see Microsoft Knowledge Base article 948725: Restoration of the configuration database is not supported in SharePoint Server 2007 and in Windows SharePoint Services 3.0 (http://go.microsoft.com/fwlink/?LinkId=117755&clcid=0x409).

You can recover a farm, including the configuration database and Central Administration content database, in the following ways:

You can use farm-level backups of a running farm taken with System Center Data Protection Manager to recover an entire farm, including the configuration database and Central Administration content database. For more information, see How to Recover a Windows SharePoint Services Farm (http://go.microsoft.com/fwlink/?LinkId=102831&clcid=0x409).

You can restore a backup of the configuration database and Central Administration content database taken from a fully stopped farm. For more information, see Move all databases (http://technet.microsoft.com/en-us/library/cc512725.aspx).

If the configuration and Central Administration content databases of a farm become unsynchronized, you must re-create both databases by using the SharePoint Products and Technologies Configuration Wizard or Psconfig command-line tool.

To protect the configuration database and Central Administration content database:

Document all configuration settings and all your customizations so that you can correctly re-create the databases. For more information about recovering a farm, see Recover from a corrupt configuration database (http://technet.microsoft.com/en-us/library/cc512815.aspx)

Consider a redundancy solution, such as clustering or mirroring, for the computer running SQL Server that is hosting the configuration database. For more information about using mirroring, see Using Database Mirroring with Office SharePoint Server and Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=83725&clcid=0x409).

We strongly recommend that you document all configuration settings and all your customizations, so that you can correctly re-create the configuration and Central Administration content databases.

51











Central AdministrationCentral Administration provides an easy way to back up your Office SharePoint Server system.

The processes that are running and the accounts that they are running as — that is, the Central Administration application pool and the account that the SQL Server services are running as — must be granted permissions to write to the directory that you are backing up to. To perform a backup, you must be a member of the Farm Administrators group. To run a recovery operation, you must be a farm administrator and a member of the Administrators group on each front-end Web server. For a detailed overview of preparing to back up, see Demo: Prepare to back up Office SharePoint Server 2007 (http://go.microsoft.com/fwlink/?LinkId=114573&clcid=0x409).

You can back up and recover at various levels, the highest being the entire farm and the lowest being a content database. Full and differential backups are also available. The backup and recovery jobs for Central Administration are run by the SPTimer service.

Using Central Administration to back up and recover your system provides the following benefits:

Ability to back up and recover at the farm, Web application, SSP, and content database level.

Restorable backups for Search.

For backups that initially run 17 hours, the system automatically restarts the backup and allots an appropriate amount of time for the process to perform (longer than 17 hours).

Using Central Administration to back up and recover your system has the following limitations:

As part of a farm backup, backs up, but cannot be used to restore the configuration database or Central Administration content database. For more information, see Recovering the configuration database and Central Administration content database.

Does not provide scheduling functionality.

Cannot back up directly to tape. The backup location must be a UNC path or local drive.

Does not provide automatic deletion of old backup files. You may want to use the backup file deletion script provided in the following Microsoft Knowledge Base article: How to automate the deletion of backups in SharePoint Server 2007 and in Windows SharePoint Services 3.0 by using a Visual Basic script (http://go.microsoft.com/fwlink/?LinkId=102617&clcid=0x409).

Does not back up any configuration changes, including:

Internet Information Services (IIS) settings including host headers, dedicated IP addresses, and Secure Sockets Layer (SSL) certificates.

Alternate access mappings.

The Inetpub directory.

Application pool settings, including service accounts (all accounts that run as Web applications, including the crawler account and the search account).

Farm-level search settings.

External service connection settings.

Workflow management settings.

52






E-mail settings.

A/V settings.




Timer job settings.



Does not back up any customizations, including:

The %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12 directory.

Any customizations made to the Web.config file.


Blocked file types.

Administrator-deployed form templates.

Database names and locations.

Web application names and databases. Be sure to document the content database names associated with each Web application.

Crawler impact rules.

Activated features.

If a backup or recovery job is not successful, the unsuccessful job must be manually deleted from the Timer job list on the Backup and Restore Status page. If the failed job is not deleted manually, subsequent backup or recovery jobs fail.

For more information about using Central Administration, see Back up Office SharePoint Server 2007 by using Central Administration (http://technet.microsoft.com/en-us/library/cc262946.aspx).

Stsadm command-line toolOffice SharePoint Server 2007 includes the Stsadm command-line tool for administration of servers and sites. You can use the Stsadm backup and restore operations to protect and recover your data.

The account that you use to run the Stsadm command-line tool must be a member of the Administrators group on the local computer, as well as a member of the dbowner fixed database role in SQL Server.

The Stsadm command-line tool has the following benefits:

Provides the ability to back up and restore at the farm level, Web application level, or site collection level.

Provides restorable backups for Search.

53



Can be used with Windows Task Scheduler to schedule backups.

For backups that initially run 17 hours, the system automatically restarts the backup and allots an appropriate amount of time for the process to perform (longer than 17 hours).

The Stsadm command-line tool has the following limitations:

As part of a farm backup, backs up, but cannot be used to restore the configuration database or Central Administration content database. For more information, see Recovering the configuration database and Central Administration content database.

Site collection backups affect performance, and they can cause access errors. They should only be used when the site collection is locked. Site collection backups can be slow when working with collections larger than 15 GB. We recommend that you use database backups if you are working with site collections larger than 15 GB.

Note: If you want to individually back up a site collection that is larger than 15 GB, we recommend that you move it to its own database, and then use a database backup.

Cannot back up directly to tape. The backup location must be a UNC path or local drive.

Does not provide automatic deletion of old backup files. You may want to use the backup file deletion script provided in the Microsoft Knowledge Base article, How to automate the deletion of backups in SharePoint Server 2007 and in Windows SharePoint Services 3.0 by using a Visual Basic script (http://go.microsoft.com/fwlink/?LinkID=102617&clcid=0x409).


IIS settings including host headers, dedicated IP addresses, and SSL certificates.



E-mail settings.


A/V settings.




Timer job settings.




Any customizations made to the Web.config file.


Blocked file types.

54




For more information, see the following resources:

Backup: Stsadm operation (http://technet.microsoft.com/en-us/library/cc263441.aspx)

Restore: Stsadm operation (http://technet.microsoft.com/en-us/library/cc262087.aspx)

External backup and recovery toolsYou can protect Office SharePoint Server 2007 by using other Microsoft backup and recovery tools.

These include:

Microsoft SQL Server 2008

Microsoft System Center Data Protection Manager

Windows Server Backup tool

Microsoft SQL Server 2008 backup and recoveryThe SQL Server databases that Office SharePoint Server 2007 uses contain site content — they are key components to protect. If your company has database administrators that back up other SQL Server databases, you may want to include the databases used by Office SharePoint Server in your standard processes. The following list describes the benefits and limitations of using SQL Server backups.

Benefits:

Existing SQL Server data protection strategies can be re-used.

Full and differential backups can be configured with added verification.

Can be faster than Office SharePoint Server 2007 backups.


Limitations:

Although SQL Server can be used to back up running instances of the configuration database and Central Administration content database, restoring these databases is not supported. For more information, see Recovering the configuration database and Central Administration content database.

Should not be used to back up the search database, because the search indexes are not stored in SQL Server and cannot be synchronized with the search database after a database-only backup.

Requires that you manually reattach your databases to Web applications after a recovery.

Cannot be used to recover at any level smaller than a database. Recovering a single item using a restored database can be complex.


IIS settings including host headers, dedicated IP addresses, and SSL certificates.


55




E-mail settings.


A/V settings.




Timer job settings.




Any customizations made to the Web.config file


Blocked file types.

For more information about using SQL Server backup and recovery, see the following resources:

Backing up and Restoring databases in SQL Server (http://go.microsoft.com/fwlink/?LinkID=102629&clcid=0x409)

Optimizing Backup and Restore Performance in SQL Server (http://go.microsoft.com/fwlink/?LinkId=102803&clcid=0x409).

Microsoft System Center Data Protection Manager 2007System Center Data Protection Manager 2007 (DPM) enables disk-based and tape-based data protection and recovery for servers in and across Active Directory directory service domains. DPM performs replication, synchronization, and recovery point creation to provide reliable protection and rapid recovery of data both by system administrators and by end users.

DPM can be used to protect Office SharePoint Server 2007 in addition to Microsoft SQL Server 2008, SQL Server 2005, and SQL Server 2000, ; Exchange Server 2003 with SP2 and Exchange Server 2007; Microsoft Virtual Server 2005 R2 with SP1 and its virtual machines; Windows Server 2008 operating system; files on workstations and laptops running Windows XP Professional with SP2 and all Windows Vista Editions except the Home Edition; files and application data on clustered servers; and the server system state.

The following list describes the benefits of this tool.

Benefits:

Provides the ability to back up and restore at the farm, database, Web application, site, index, or content item level.

Provides the ability to back up and restore directories that contain customizations.

56



Can be used to back up and recover the server system state, including IIS configuration settings.

Farm-level backups taken while the system is running can be used to recover a farm, including the configuration database and the Central Administration database. For more information, see Recovering the configuration database and Central Administration content database.

Can back up to tape.

Requires less processing on the server.

If DPM has not already been purchased for your environment, you may require additional funding and equipment.

For more information about installing, deploying, and configuring DPM, see System Center Data Protection Manager 2007 (http://go.microsoft.com/fwlink/?LinkId=102807&clcid=0x409).

DPM can be used to recover content items, sites, Web applications, farms, and indexes. For more information, see the following resources:

How to Recover a Windows SharePoint Services Item (http://go.microsoft.com/fwlink/?LinkId=102815&clcid=0x409)

How to Recover a Windows SharePoint Services Site (http://go.microsoft.com/fwlink/?LinkId=102826&clcid=0x409)

How to Recover a Windows SharePoint Services Farm (http://go.microsoft.com/fwlink/?LinkId=102831&clcid=0x409)

Protecting MOSS 2007 Indexes (http://go.microsoft.com/fwlink/?LinkId=155921)

Recovering Indexes in MOSS 2007 (http://go.microsoft.com/fwlink/?LinkId=155908)

Windows Server BackupYou can use the Windows Server Backup tool to back up your home directories, Web.config file, custom assemblies, customizations, site definitions, and list definitions.

Note: As of Office SharePoint Server 2007 with SP1, you can now install Office SharePoint Server 2007 on Windows Server 2008. You must configure specific registry keys for Windows Server Backup to work. For more information, see Windows SharePoint Services 3.0 does not appear in the list of the components that can be backed up when you use Windows Server Backup in Windows Server 2008 (http://go.microsoft.com/fwlink/?LinkId=108244&clcid=0x409) in the Microsoft Knowledge Base.

The Windows Server Backup tool has the following benefits:

Provides the ability to back up and restore directories that contain customizations. For more information, see Choose what to protect.

Can back up to tape.

57











The Windows Server Backup tool has the following limitation:

Cannot be used to back up databases, farms, Web applications, or Search.

Third-party solutions and custom toolsBased on the needs of your business, you may want to choose a third-party solution or build a custom tool to meet your needs.

Third-party solutionsTo find third-party solutions built by Microsoft partners, built on technologies supported by Microsoft, visit Solution Finder (http://go.microsoft.com/fwlink/?LinkId=102834&clcid=0x409) and search on the following parameters:

Solution type = Software Offering

Product category = Microsoft Office 2007 System

Product = Microsoft Office SharePoint Server 2007

Keywords: SharePoint Backup Restore Disaster Recovery

Solutions built on Volume Shadow Copy ServiceThe Volume Shadow Copy Service (VSS) was introduced in Windows XP and Windows Server 2003. VSS is a framework that facilitates communication between applications, storage subsystems, and storage management applications (including backup applications). This framework enables you to define, persist, and use point-in-time copies of storage data. The Windows SharePoint Services VSS Writer is a new service in Office SharePoint Server 2007 and in the server products in the 2007 Office release. This writer service enables a requestor (http://go.microsoft.com/fwlink/?LinkId=90911&clcid=0x409) to ask a front-end Web server to provide a VSS backup (full or differential), and Office SharePoint Server 2007 then points the requestor to the SQL databases and the search index to be backed up by using VSS. For more information about VSS, see the MSDN article Volume Shadow Copy Service (http://go.microsoft.com/fwlink/?LinkId=90912&clcid=0x409). You download the Volume Shadow Copy Service SDK 7.2 (http://go.microsoft.com/fwlink/?LinkId=90914&clcid=0x409) from the Microsoft Download Center.

See AlsoPlan for backup and recovery (http://technet.microsoft.com/en-us/library/cc261687.aspx)

Choose what to protect

58







IV: Maintain and monitor databases and storage

59

Maintain the databases that support Office SharePoint Server 2007Routine database maintenance is essential for the smooth operation of databases that support Microsoft Office SharePoint Server 2007. This chapter describes the database maintenance tasks supported for SharePoint Products and Technologies databases

The recommended maintenance tasks for SharePoint Products and Technologies databases are described in the following topics:

Check for and repair consistency errors by using DBCCC CHECKDB

Measure and reduce fragmentation

Fine tune index performance by setting fill factor

Shrink data files

Note: In this paper, we present detailed examples only for SQL Server 2008 and SQL Server 2005. References for how to perform the same database maintenance tasks with SQL Server 2000 are included.

Before you implement any database maintenance tasks or modify your SharePoint Products and Technologies databases, read the following support articles:

1. Article ID: 841057: Support for changes to the databases that are used by Office server products and by Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=110812&clcid=0x409)

2. Article ID: 932744: Information about the Maintenance Plan Wizard in SQL Server 2005 and about tasks that administrators can perform against SharePoint databases (http://go.microsoft.com/fwlink/?LinkId=110813&clcid=0x409)

60





Shrink data filesIn SQL Server 2008, SQL Server 2005 and SQL Server 2000, you can shrink each file within a database (extensions .mdf, .ldf, and .ndf) to remove unused pages and recover disk space. SharePoint Products and Technologies databases to do not automatically shrink data files, although many activities create white space in the database. Activities that can create white space include running the Mergecontentdbs: Stsadm operation (http://msdn.microsoft.com/library/829cfa96-89b1-4a7b-b980-6d5d3e2a3ee1.aspx), and deleting documents, document libraries, lists, list items, and sites.

Free space is released from the end of the file — for example, a content database file of 60 GB with a specified target size of 40 GB will free as much space as possible from the bottom 20 GB of the database file. If used pages are included in the bottom 20 GB, those pages will subsequently be relocated to the upper 40 GB of the file that is retained.

You can shrink database files individually or as a group. Shrink operations are most effective following a large file or site that has the potential to generate a large quantity of unused space. Database files can only be reduced to the point where there is no free space remaining; therefore a content database in which content is infrequently deleted may see minimal benefit from shrinking. Repeated shrinking may result in increased fragmentation because the operation reorders the physical pages of the database. You do not need to shrink database files as frequently as you defragment indexes. However, in environments where data is often deleted from the SharePoint Products and Technologies database, you may want to schedule database file shrinking more frequently.

Notes Database and database files can be shrunk manually to recover space by executing the DBCC SHRINKFILE and DBCC SHRINKDATABASE statements, by using SQL Server 2008 Management Studio.

61

http://msdn.microsoft.com/library/829cfa96-89b1-4a7b-b980-6d5d3e2a3ee1.aspx

Shrinking a database by using Transact-SQL commandsDBCC SHRINKDATABASE shrinks the data and log files for a specific database. To shrink individual files, use DBCC SHRINKFILE.

DBCC SHRINKDATABASESyntax:

DBCC SHRINKDATABASE

( 'database_name' | database_id | 0

[ ,target_percent ]

[ , { NOTRUNCATE | TRUNCATEONLY } ]

)

[ WITH NO_INFOMSGS ]

database_name | database_id | 0 specifies the database name or ID. To select the current database, use 0.

target_percent is the free space in a percentage you wish to retain after the database has been shrunk.

NOTRUNCATE compacts the data in data files by moving allocated pages from the end of a file to unallocated pages in the front of the file.

TRUNCATEONLY releases all free space at the end of the file to the operating system but does not perform any page movement inside the file.

For more information, see DBCC SHRINKDATABASE (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110852&clcid=0x409).

62


DBCC SHRINKFILESyntax:

DBCC SHRINKFILE

(

{ 'file_name' | file_id }

{ [ , EMPTYFILE ]

| [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]

}

)

[ WITH NO_INFOMSGS ]

file_name | file_id specifies the file name or ID.

EMPTYFILE Migrates all data from the specified file to other files in the same filegroup.

target_size is the target size for the file in megabytes, expressed as an integer.

NOTRUNCATE compacts the data in data files by moving allocated pages from the end of a file to unallocated pages in the front of the file.

TRUNCATEONLY releases all free space at the end of the file to the operating system but does not perform any page movement inside the file.

For more information, see DBCC SHRINKFILE (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110853&clcid=0x409).

Summary Consistently maintaining the databases that host SharePoint Products and Technologies can significantly improve the health and performance of your system. As much as possible, set any maintenance operations or maintenance plans to run during off hours to minimize the performance impact to users. Before you implement maintenance operations and maintenance plans:

Ensure that you have reliable backups for all databases.

Test the impact of the operations on your system, and the time required to run them.

63


Fine tune index performance by setting fill factorFill factor can be used to further improve index data storage and performance. When indexes are created or rebuilt, the fill factor value (1-100) determines the percentage of space on each leaf level page that can be filled with data. The remaining space is reserved for future growth. For many situations the default server-wide fill factor level of 0 is optimal; however, for Microsoft Office SharePoint Server 2007, a server-wide setting of 70 is optimal to support growth and minimize fragmentation.

Although it is possible, we do not recommend that you set the fill factor for individual tables or indexes.

To view the fill factor value of one or more indexes, query the sys.indexes catalog view. For more information about the view, see sys.indexes (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110850&clcid=0x409).

To configure the server-wide fill factor value, use the sp_configure system stored procedure. For more information, see sp_configure (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110851&clcid=0x409).

64



Measure and reduce fragmentationFragmentation occurs when the logical and physical storage allocation of a database contains many scattered areas of storage that are not physically contiguous. The fragmentation level of an index is the percentage of blocks that are logically linear and physically nonlinear. Fragmentation can be the result of many inserts, updates, or deletes to a table. When a table becomes fragmented, the indexes defined on the table also become fragmented. Indexes fragment more rapidly than tables.

Over time, database fragmentation results in performance degradation and inefficient space utilization. For queries that scan part or all of the indexes of a table, fragmentation can cause additional page reads, which hinders parallel scanning of data and can significantly affect search performance.

To mitigate fragmentation and minimize the rate at which fragmentation occurs, manually set the size of content databases to be as large as possible given your business requirements and database architecture. For example, if you have a requirement to limit content databases to 100 gigabytes (GB), after you have created your content databases, set their size to 100 GB in SQL Server Management Studio.

Note: Although you can defragment tables, defragmenting indexes is more beneficial to database performance, and is much faster. This topic only describes how to defragment indexes.

Before implementing a database fragmentation maintenance plan, you need to understand which tables and indexes are most fragmented and then create a maintenance plan to rebuild or reorganize those indexes. In Microsoft Office SharePoint Server 2007, an example of a table that often becomes fragmented is AllDocs, which contains document libraries, their associated documents and lists and list items, and their respective metadata.

Measure fragmentation in a SQL Server 2008 database (sys.dm_db_index_physical_stats)In SQL Server 2008, use the sys.dm_db_index_physical_stats dynamic management view to determine fragmentation for the indexes on specified table or view.

Notes For measuring fragmentation, we recommend that you monitor the column avg_fragmentation_in_percent. The value for avg_fragmentation_in_percent should be as close to zero as possible for maximum performance. However, values from 0 percent through 10 percent may be acceptable. For more information see sys.dm_db_index_physical_stats (http://go.microsoft.com/fwlink/?LinkId=110839&clcid=0x409)

65


The following table shows sample results from sys.dm_db_index_physical_stats, with a value of 9.375 for avg_fragmentation_in_percent in one row.

Sample results from sys.dm_db_index_physical_stats

database_id index_type_desc alloc_unit_type_desc avg_fragmentation_in_percent

10 CLUSTERED INDEX

IN_ROW_DATA 0

10 NONCLUSTERED INDEX

IN_ROW_DATA 0


IN_ROW_DATA 0

10 CLUSTERED INDEX

IN_ROW_DATA 0


IN_ROW_DATA 0

10 CLUSTERED INDEX

IN_ROW_DATA 0


IN_ROW_DATA 0

10 CLUSTERED INDEX

IN_ROW_DATA 0


IN_ROW_DATA 0


IN_ROW_DATA 0

10 CLUSTERED INDEX

IN_ROW_DATA 0


IN_ROW_DATA 0

10 CLUSTERED INDEX

IN_ROW_DATA 9.375

To use the sys.dm_db_index_physical_stats dynamic management view

1. On the taskbar, click Start, point to All Programs, point to Microsoft SQL Server 2008,

66

and then click SQL Server Management Studio.

To use sys.dm_db_index_physical_stats with a database object you must know the database ID, and object ID.

2. Select the content database in the Object Explorer, and then click New Query. Execute the following script.

SELECT DB_ID() AS [Database ID];

Note: When using DB_ID without specifying a database name, the compatibility level of the current database must be 90 (a SQL Server 2005 database) or 100 (a SQL Server 2008 database). If you have upgraded from a previous version of SQL Server, or are using SQL Server 2000, you must specify a database name in the statement. For more information about compatibility levels, see sp_dbcmptlevel (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110840&clcid=0x409).

3. Execute sys.dm_db_index_physical_stats on the database or object you have selected. You can specify not only the database, but a table or index.

Syntax:

sys.dm_db_index_physical_stats ( { database_id | NULL | 0 | DEFAULT } , { object_id | NULL | 0 | DEFAULT } , { index_id | NULL | 0 | -1 | DEFAULT } , { partition_number | NULL | 0 | DEFAULT } , { mode | NULL | DEFAULT } )

Measure fragmentation in a SQL Server 2000 database (DBCC SHOWCONTIG)To check the fragmentation of database tables, an administrator can use the DBCC SHOWCONTIG function to report on logical and extent scan fragmentation. For a complete explanation of DBCC SHOWCONTIG results, see DBCC SHOWCONTIG (http://go.microsoft.com/fwlink/?LinkId=110841&clcid=0x409).

For measuring fragmentation, we recommend you monitor the scan density value returned by DBCC SHOWCONTIG. In tables in which everything is contiguous, scan density is 100.

67




The following table of results shows a scan density of 20.97%, indicating that defragmentation may be beneficial.

Scan Density (Fragmented)

DBCC SHOWCONTIG scanning 'AllDocs' table...

Table: 'AllDocs' (53575229); index ID: 1, database ID: 10

TABLE level scan performed.

- Pages Scanned................................: 104

- Extents Scanned..............................: 19

- Extent Switches..............................: 61

- Avg. Pages per Extent........................: 5.5

- Scan Density [Best Count:Actual Count].......: 20.97% [13:62]

- Logical Scan Fragmentation ..................: 78.85%

- Extent Scan Fragmentation ...................: 84.21%

- Avg. Bytes Free per Page.....................: 3326.7

- Avg. Page Density (full).....................: 58.90%

Reducing Fragmentation for a DatabaseTo reduce the level of index fragmentation, follow the guidance below.

Run the Database Statistics timer jobRun the Database Statistics timer job. This job was updated significantly in Windows SharePoint Services 3.0 with Service Pack 2 (SP2) to also rebuild database indexes. The job is run by default daily between 22:00:00 and 05:00:00, and performs the following tasks:

If you have not installed Windows SharePoint Services 3.0 with SP2, the job updates the query optimization statistics by performing a full scan of key tables every time that it runs, which can be resource-intensive.

If you have installed Windows SharePoint Services 3.0 with SP2:

The job updates the query optimization statistics by sampling key tables every time that it runs, instead of performing a full scan.

If you are running SQL Server 2008 or SQL Server 2005, the job rebuilds all indexes in the content databases every time that it runs.

If you are running the Enterprise Edition of SQL Server 2008 or SQL Server 2005, the job rebuilds most indexes online.

68

If you are running the Standard edition of SQL Server 2008 or SQL Server 2005, the job rebuilds the indexes offline.

If you are running Microsoft SQL Server 2000, the job does not rebuild any indexes.

Run the Defragmentation stored procedureTo reduce the level of index fragmentation, run the SQL Server stored procedure in the article How to defragment Windows SharePoint Services 3.0 databases and SharePoint Server 2007 databases (http://go.microsoft.com/fwlink/?LinkId=110843&clcid=0x409) in the Microsoft Knowledge Base.

After determining the level of fragmentation of your databases, you can schedule the stored procedure to be run daily, weekly, or monthly depending on your needs and the overall rate of change in your environment. Generally, we recommend that you establish a weekly defragmentation schedule, at a minimum. We also recommend that you schedule defragmentation operations after running DBCC CHECKDB REPAIR operations.

Note: This stored procedure changes your content database indexes. Any modification to the stored procedure is not supported. For additional information on the changes that are supported for SharePoint Products and Technologies content databases see Support for changes to the databases that are used by Office server products and by Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=110844&clcid=0x409) in the Microsoft Knowledge Base.

If the performance of a heavily fragmented database or table is not measurably improved by frequent defragmentation, you should check the database object allocation and structural integrity by using DBCC CHECKDB. For more information, see Check for and repair consistency errors by using DBCCC CHECKDB.

69






The following table of results shows the improved scan density after running the defragmentation script described above.

Scan Density (Defragmented)

DBCC SHOWCONTIG scanning 'AllDocs' table...

Table: 'AllDocs' (53575229); index ID: 1, database ID: 10

TABLE level scan performed.

- Pages Scanned................................: 64

- Extents Scanned..............................: 12

- Extent Switches..............................: 13

- Avg. Pages per Extent........................: 5.3

- Scan Density [Best Count:Actual Count].......: 57.14% [8:14]

- Logical Scan Fragmentation ..................: 9.38%

- Extent Scan Fragmentation ...................: 91.67%

- Avg. Bytes Free per Page.....................: 345.

- Avg. Page Density (full).....................: 95.73%

Reducing fragmentation for a specific table and its indexesIf you want to defragment the index associated with a particular table, rather than an entire database, you can either reorganize or rebuild the index.

Reorganizing an index specifies that the index leaf level will be reorganized. Index reorganization defragments and compacts clustered and non-clustered indexes on tables and views and can significantly improve index scanning performance. Reorganization is always performed online, so that the underlying table is available to users. Reorganization is equivalent to the SQL Server 2000 DBCC INDEXDEFRAG statement.

Rebuilding an index specifies that the index will be rebuilt using the same columns, index type, uniqueness attribute, and sort order. Rebuilding improves the performance of index scans and seeks. You can rebuild the index with a table either on or offline. Rebuilding is equivalent to the SQL Server 2000 DBCC DBREINDEX statement.

For more information, see Clustered Index Structures (http://go.microsoft.com/fwlink/?LinkId=110847&clcid=0x409).

70


The fragmentation level of an index determines the method you should use to defragment it, and whether it can remain online, or should be taken offline.

Fragmentation level Defragmentation method

Up to 10% Reorganize (online)

10-75% Rebuild (online)

75% Rebuild (offline)

Note: Using the DROP INDEX and CREATE INDEX commands is not supported on SharePoint Products and Technologies databases.

You can reorganize and rebuild indexes by using the SQL Server 2008 or SQL Server 2005 ALTER INDEX statement, the SQL Server 2008 or SQL Server 2005 Maintenance Wizard, the SQL Server 2000 DBCC INDEXDEFRAG and DBCC DBREINDEX statements, or the SQL Server 2000 Maintenance Wizard. This paper presents only the SQL Server 2008 options in detail. For more information about SQL Server 2000 options, see the following resources:

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

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

Database Maintenance Plan Wizard (http://go.microsoft.com/fwlink/?LinkId=110849&clcid=0x409)

71




Using ALTER INDEXALTER INDEX permits a database administrator to perform maintenance operations against an existing table or view index. It can be used to disable, rebuild, and reorganize indexes or optionally setting options on the index. ALTER INDEX replaces the DBCC DBREINDEX and DBCC INDEXDEFRAG statements.

In most cases you can rebuild indexes while the database is online, because there are no significant gains in an offline rebuild of the indexes. However, it is important to note that when an index is being rebuilt, a shared table lock is put on the table, preventing all operations with the exception of SELECT operations from being performed. SharePoint Products and Technologies databases use clustered indexes specifically. When a clustered index is being rebuilt, an exclusive table lock is put on the table, preventing any table access by end-users.

You can customize the following sample script to rebuild all indexes on a table

USE Contoso_Content_1

GO

ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name

REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON,

STATISTICS_NORECOMPUTE = ON)GO

Check for and repair consistency errors by using DBCCC CHECKDB

Perform regular consistency checks to ensure that your data and indexes are not corrupted. You can use the DBCC (Database Console Command) CHECKDB statement to perform an internal consistency check of the data and index pages, and to repair errors.

Database consistency may be affected when a database server is improperly shut down or a drive fails. Although database consistency checks are most important after database or database server failure, a weekly database consistency check can provide important information on the health of your SharePoint Products and Technologies databases.

About DBCC CHECKDBDBCC CHECKDB checks the logical and physical integrity of all the objects in the specified database by performing the following operations:

Runs DBCC CHECKALLOC (http://go.microsoft.com/fwlink/?LinkId=110815&clcid=0x409) on the database.

Runs DBCC CHECKTABLE (http://go.microsoft.com/fwlink/?LinkId=110833&clcid=0x409) on every table and view in the database.

Runs DBCC CHECKCATALOG (http://go.microsoft.com/fwlink/?LinkId=110834&clcid=0x409) on the database.

Validates the contents of every indexed view in the database.

72




Validates the Service Broker data in the database.

You do not need to run the DBCC CHECKALLOC, DBCC CHECKTABLE, or DBCC CHECKCATALOG commands run separately from DBCC CHECKDB. We recommend that you run DBCC CHECKDB rather than the individual operations because it identifies and repairs the widest possible errors and is generally safe to run in a production environment.

We recommend that you first run DBCC CHECKDB, and then, if it reveals errors, use DBCC CHECKDB with the REPAIR argument to repair all errors. If only one type of error is revealed, you may want to run one of the individual operations with the REPAIR argument, such as DBCC CHECKALLOC.

The sample output is from DBCC CHECKDB.

DBCC results for 'Contoso_Content_1'.

Service Broker Msg 9675, State 1: Message Types analyzed: 14.

Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.

Service Broker Msg 9667, State 1: Services analyzed: 3.

Service Broker Msg 9668, State 1: Service Queues analyzed: 3.

Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.

Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.

Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.

DBCC results for 'sys.sysrowsetcolumns'.

There are 2663 rows in 21 pages for object "sys.sysrowsetcolumns".

DBCC results for 'sys.sysrowsets'.

There are 309 rows in 4 pages for object "sys.sysrowsets".

…more

CHECKDB found 0 allocation errors and 0 consistency errors in database 'Contoso_Content_1'.

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

For more information about using DBCC CHECKDB with SQL Server 2008, see DBCC CHECKDB (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110835&clcid=0x409). For more information about using DBCC CHECKDB with SQL Server 2000, see DBCC CHECKDB (http://go.microsoft.com/fwlink/?LinkId=110836&clcid=0x409).

73




DBCC CHECKDB and performanceWe recommend that you run consistency checks during non-production hours, because DBCC CHECKDB acquires schema locks that prevent metadata changes. If you specify the TABLOCK argument, DBCC CHECKDB also acquires shared table locks.

Database consistency checks on large databases can be time-consuming. If you have large databases to check, you may want to perform consistency checks on a table-by-table basis. To perform table-level consistency checks, you cannot use SQL Server 2008, SQL Server 2005 or SQL Server 2000 maintenance plans, because they perform consistency checks at the database level only. Instead, create a SQL Server Agent job that runs against the individual objects you want to check, using a command such as DBCC CHECKTABLE.

74

Monitoring and troubleshooting storage

Monitor and troubleshoot storage performanceThis topic lists the performance counters that we recommend that you use to monitor the performance of the SQL Server databases that you are running in your Microsoft Office SharePoint Server 2007 environment. Also listed are approximate healthy values for each counter.

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

Physical server counters to monitorMonitor the following counters to ensure the health of your servers:

Processor: % Processor Time: _Total This counter shows the percentage of time that the processor is executing application or operating system processes other than Idle. On the computer that is running SQL Server, this counter should be kept between 50 percent and 75 percent. In case of constant overloading, investigate whether there is abnormal process activity or if the server needs additional CPUs.

System: Processor Queue Length: (N/A) This counter shows the number of threads in the processor queue. Monitor this counter to ensure that it remains less than two times the number of core CPUs.

Memory: Available Mbytes: (N/A) This counter shows the amount of physical memory, in bytes, available to processes running on the computer. Monitor this counter to ensure that you maintain a level of at least 20 percent of the total physical RAM available.

Memory: Pages/sec: (N/A) This counter shows the rate at which pages are read from or written to disk to resolve hard page faults. Monitor this counter to ensure that it remains below 100.

For more information and memory troubleshooting methods, see SQL Server 2005 Monitoring Memory Usage (http://go.microsoft.com/fwlink/?LinkID=105585&clcid=0x409).

Disk counters to monitorMonitor the following counters to ensure the health of your disks. Note that the following values represent values measured over time, not values that occur during a sudden spike and not values that are based on a single measurement.

75





Physical Disk: % Disk Time: DataDrive This counter shows the percentage of elapsed time that the selected disk drive is busy servicing read or write requests. Monitor this counter to ensure that it remains below two times the number of disks.

Logical Disk: Disk Transfers/sec This counter shows the rate at which read and write operations are performed on the disk. Use this counter to monitor growth trends and forecast appropriately.

Logical Disk: Disk Read Bytes/sec and Logical Disk: Disk Write Bytes/sec These counters show the rate at which bytes are transferred from the disk during read or operations.

Logical Disk: Avg Disk Bytes/Read This counter shows the average number of bytes transferred from the disk during read operations. This value can reflect disk latency—larger reads can result in slightly higher latency.

Logical Disk: Avg. Disk Byte/Write This counter shows the average number of bytes transferred to the disk during write operations. This value can reflect disk latency—larger writes can result in slightly higher latency.

Logical Disk: Current Disk Queue Length This counter shows the number of requests outstanding on the disk at the time that the performance data is collected. For this counter, lower values are better. Values above 2 per disk may indicate a bottleneck and should be investigated. This means that a value of up to 8 may be acceptable for a LUN comprised of 4 disks. Bottlenecks can create a backlog that can spread beyond the current server that is accessing the disk, and result in long wait times for users. Possible solutions to a bottleneck are to add more disks to the RAID array, replace existing disks with faster disks, or move some data to other disks.

Logical Disk: Avg. Disk Queue Length . This counter shows the average number of both read and write requests that were queued for the selected disk during the sample interval. The general rule is that you should be at two or fewer outstanding read and write requests per spindle, but this can be difficult to measure because of storage virtualization and differences in RAID levels between configurations. Look for higher than average disk queue lengths in combination with higher than average disk latencies. This combination can indicate that the storage array cache is being over-utilized or that spindle sharing with other applications is affecting performance.

Logical Disk: Avg. Disk sec/Read and Logical Disk: Avg. Disk sec/Write These counters show the average time, in seconds, of a read or write operation to the disk. Monitor these counters to ensure that they remain below 85 percent of the disk capacity. Disk access time increases exponentially if reads or writes are more than 85 percent of disk capacity. To determine the specific capacity for your hardware, refer to the vendor documentation, or use the SQLIO Disk Subsystem Benchmark Tool to calculate it. For more information, see SQLIO Disk Subsystem Benchmark Tool (http://go.microsoft.com/fwlink/?LinkID=105586&clcid=0x409).

Logical Disk: Avg. Disk sec/Read This counter shows the average time, in seconds, of a read operation from the disk. On a well-tuned system, ideal values are from 1 through 5 milliseconds (ms) for database transaction logs (ideally 1 ms on a cached array), and

76





from 4 through 20 ms for data (ideally below 10 ms). Higher latencies can occur in peak times, but if high values are occurring regularly, you should investigate the cause.

Logical Disk: Avg. Disk sec/Write This counter shows the average time, in seconds, of a write operation to the disk. On a well-tuned system, ideal values are from 1 through 5 ms for database transaction logs (ideally 1 ms on a cached array), and from 4 through 20 ms for data (ideally below 10 ms). Higher latencies can occur in peak times, but if high values are occurring regularly, you should investigate the cause.

When you are using RAID configurations with the Avg. Disk sec/Read or Avg. Disk sec/Write , use the formulas listed in the following table to determine the rate of input and output 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 that are shown in the following table:

Counter Value

Avg. Disk sec/Read 80

Logical Disk: Avg. Disk sec/Write 70

Avg. 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.

Other monitoring toolsYou can also monitor disk latency and analyze trends by using the sys.dm_io_virtual_file_stats dynamic management view in SQL Server 2008. For more information, see

77

sys.dm_io_virtual_file_stats (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkID=105587&clcid=0x409).

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

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

2. Add disks to the array.

3. If you cannot separate the content (for example, if there is a a single content database file), replace the disks with faster ones.

4. Where possible, split the relevant content database into several databases; that is, relocate, or split and relocate site collections by using tools such as the Stsadm.exe command-line tool or Microsoft Office SharePoint Designer. If the problem persists, repeat the troubleshooting steps from step 1.

78


Additional referencesThis book is a compilation of the following content from the Office System TechNet Library:

Physical topology recommendations (http://go.microsoft.com/fwlink/?LinkID=119415)

Physical storage recommendations (http://go.microsoft.com/fwlink/?LinkID=119416)

Deploy using DBA-created databases (http://go.microsoft.com/fwlink/?LinkID=109001)

Database types and descriptions (http://go.microsoft.com/fwlink/?LinkID=152496)

Choose what to protect (http://go.microsoft.com/fwlink/?LinkId=163883)

Choose backup and recovery tools (http://go.microsoft.com/fwlink/?LinkId=117908)

Database maintenance for Office SharePoint Server 2007: white paper (http://go.microsoft.com/fwlink/?LinkId=117910)

Monitor and troubleshoot storage performance (http://go.microsoft.com/fwlink/?LinkId=163884)

79









microsoftdownload.microsoft.com/download/0/8/c/08c8e79f-9644-454f... · web viewsharepoint guidance...

Documents