Storage area networks (SANs) and network-attached storage (NAS) have fundamentally changed the database storage world. A decade or so ago, the word disk referred to physical disks with heads and platters. In today’s storage world, a disk is often a completely virtual entity that is somewhere on the storage network and that can be a single physical disk, a portion of a physical disk, a RAID array, a part of a RAID array, or part of several RAID arrays. Recent enhancements in file system options, such as direct and concurrent I/O, have almost eliminated any performance advantage that using raw devices had over using file systems.
Although Moore’s Law has held for CPU processing power, it does not apply to disk drives. Despite changes in storage communication that were introduced by SAN and NAS, the underlying infrastructure for storing bits remains fundamentally the same. A mechanical spindle rotates a platter of magnetic material, upon which bits of information are encoded using a read/write head on the end of an actuator. Although spindle speeds have increased and caching of data on storage controllers using dynamic random access memory (DRAM) and non-volatile random access memory (NVRAM) has helped, neither of these advancements have kept up with the sheer magnitude of processing power increases over the past decade or so. The result is that relative to CPU processing speeds, disk I/O service times have become much slower. This difference requires an increasingly larger number of physical disks per CPU core to ensure that the system is not I/O bound. Because disk capacities have increased substantially, achieving an appropriate ratio of physical disks per CPU core is often overlooked, therefore leading to disk bottlenecks.
Given the changes in storage, file systems, and CPU processing speeds, the best practices for database storage provisioning and management have also evolved. In the past, a DBA might have been advised to determine which physical disk and which part of each physical disk on which to place individual tables and indexes. In today’s virtualized storage world, for the average DBA, yesterday’s best practices are impractical.
The best practices presented in this document have been developed with the reality of today’s storage systems in mind. For related information about database performance and speed of database operations, refer to the “Best Practices for Physical Database Design” paper. This paper and others are available at the DB2 Best Practices website at http://www.ibm.com/developerworks/data/bestpractices/db2luw/