The following list provides some best practices and recommendations for choosing the best RAID level and hard disks.

• More and faster disks or arrays enhance performance. The key is to maintain low latency and queuing on all disks.

• For high availability and performance (random read/write), configure your array 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).

• Pre-size your data and log files.

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

Ideally, place the tempdb, content databases, and SQL Server 2005 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.

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

For improved performance for large content databases, consider using multiple data files. Follow 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.

• The data files should be 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 (Office SharePoint Server) The use of multiple data files for databases other than content databases is not supported. The use of SQL Server partitioning is not supported for SharePoint databases. Use only simple data files. For more information about creating and managing filegroups, see Physical Database Files and Filegroups

For optimal performance when configuring a physical storage array, adhere to the hardware configuration recommendations supplied by the storage vendor rather than relying on the operating 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 2005. For more information, see Predeployment I/O Best Practices (http://go.microsoft.com/fwlink/?LinkID=105583&clcid=0x409).