The ideal settings depend on the type of IO workload your database will generate, its size, and your attitude towards risk.
- Read Policy: No Read Ahead / Adaptive Read Ahead / Always Read Ahead
If your database contains large blocks of data (eg images stored as BLOBs like in a Sharepoint content database) select Adaptive Read Ahead, otherwise choose No Read Ahead. Read ahead gives better performance if you're reading large chunks of sequential data, because the array predicts the data you're going to read next and gets it ready in cache before SQL even requests it. WIth smaller chunks of data the requests are more random and harder to predict, so the array wastes cache pre-staging data you don't need.
- Write Policy: Write Through / Always Write Back
Write-back allows faster write performance, but involves a small risk of data corruption in a power failure. Write through reduces write performance but is more stable. Choose write-back if you have a battery-backed RAID controller and a stable data center, and want to get the maximum possible performance. Choose Write Through if you aren't absolutely confident about your power supply, or if the integrity of the database is mission-critical.
- IO Policy: Direct IO / Cached IO
For small databases (<4GB) choose Cached IO, ortherwise Direct IO.
- Disk Cache Policy: Enabled / Disabled
The disks in your array have their own cache, as well as the RAID controller. If you have a battery-backed RAID controller make sure Disk cache is disabled, so writes are only cached on the RAID controller where it is protected by the battery. If your RAID controller isn't battery-backed or if data integrity isn't an issue, you may find a performance increase if you enable disk caching. Use with caution!
Let me know if you have any questions!
D
