This may be the best 23 pages you’ll ever read about DB2 LUW Database Storage.  This updated paper just went live and was updated by Aamer Sachedina, Matthew Huras, and Robin Grosman.

Executive summary
In a world with networked and highly virtualized storage, database storage design can seem like a dauntingly complex task for a DBA or system architect to get right.  Poor database storage design can have a significant negative impact on a database server. CPUs are so much faster than physical disks that it is not uncommon to find poorly performing database servers that are significantly I/O bound and underperforming by many times their potential.

The good news is that it is not necessary to get database storage design perfectly right. Understanding the innards of the storage stack and manually tuning the location of database tables and indexes on particular parts of different physical disks is neither generally achievable nor generally maintainable by the average DBA in today’s virtualized storage world.

Simplicity is the key to ensuring good database storage design. The basics involve ensuring an adequate number of physical disks to keep the system from becoming I/O bound.

This document provides basic initial suggestions for a healthy database server through easy-to-follow best practices in database storage, including guidelines and recommendations.

See also my previous posts on Best Practices:

Best Practice Resources for DB2 z/OS

DB2 Best Practices – New or Updated in 2011

And also see the Flashbooks co-authored by Aamer & Matt:

DB2 pureScale: Risk Free Agile Scaling

Thanks again to Kate Kurtz for giving me this information.  She also tells me there is one more to publish before IDUG.

Susan