 Database Storage
In a world with networked and highly virtualized storage, database storage design can appear 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 spindles that it is not uncommon to find poorly performing database servers that are significantly I/O bound and underperforming by many times their true potential.
The good news is that it is more important to not get database storage design wrong than it is to get it perfectly right. Trying to understand the innards of the storage stack and hand tuning which database tables and indexes should be stored on which part of what spindle is an exercise that is neither generally achievable nor 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 spindles to keep the system from becoming I/O bound.
This document provides a recipe to a healthy database server through easy to follow best practices in database storage, including guidelines and recommendations for each of the following areas:
- Spindles and logical unit numbers (LUNs)
- Transaction logs and data
- File systems versus raw devices
- Redundant Array of Independent Disks (RAID) devices
- Registry variable and configuration parameter settings
|
