Using RAID with Oracle Oracle Database Tips by Donald Burleson

As you may know, there are more than six different types (called ?levels?) of RAID architectures, each having its own relative advantages and disadvantages. For the purposes of an Oracle database, many of the RAID schemes do not posses the high performance required for an Oracle database, and are omitted from this discussion. Please note that RAID 5 is not considered in this discussion since the processing overhead for updates makes it too slow for most Oracle applications. Here are the most commonly used RAID architectures for Oracle databases:

•  RAID 0 RAID 0 is commonly referred to as block-level striping. This is an excellent method for performing load balancing of the Oracle database on the disk devices, but it does nothing for high availability since none of the data is duplicated. Unlike manual datafile striping, where the Oracle professional divides an Oracle tablespace into small datafiles, with RAID 0, the Oracle datafile is automatically striped one block at a time across all of the disk devices. In this fashion, every datafile has pieces residing on each disk, and the disk I/O load will become very well balanced.

• RAID 1 RAID 1 is commonly called disk mirroring. Since the disks are replicated, RAID 1 may involve double or triple mirroring. The RAID 1 architecture is designed such that a disk failure will cause the I/O subsystem to switch to one of the replicated disks with no service interruption. RAID 1 is used when high availability is critical, and with triple mirroring, the mean time to failure (MTTF) for an Oracle database is measured in decades. (Note that disk controller errors may cause RAID 1 failures, although the disks remain healthy.)

• RAID 0+1 Raid 0+1 is the combination of block-level striping and disk mirroring. The advent of RAID 0+1 has made Oracle-level striping obsolete since RAID 0+1 stripes at the block level, dealing out the table blocks, one block per disk, across each disk device. RAID 0+1 is also a far better striping alternative since it distributes the load evenly across all of the disk devices, and the load will rise and fall evenly across all of the disks. This relieves the Oracle administrator of the burden of manually striping Oracle tables across disks and provides a far greater level of granularity than Oracle striping because adjacent data blocks within the same table

• RAID 5 Raid 5 is commonly used in Oracle data warehouses and other non-OLTP systems where the high I/O overhead of updates is not an issue. In RAID 5, read performance is improved, but every write has to incur the additional overhead of reading old parity, computing new parity, writing new parity, and then writing the actual data, with the last two operations happening while two disk drives are simultaneously locked. This overhead is known as the RAID-5 write penalty. This write penalty can make writes significantly slower. Also, if a disk fails in a RAID-5 configuration, the I/O penalty incurred during the disk rebuild is extremely high.

Note that the use of RAID does not guarantee against catastrophic disk failure. Oracle specifically recommends that all production databases be run in archivelog mode regardless of the RAID architecture, and that periodic Oracle backups should be performed. Remember that there are many components to I/O subsystems? including controllers, channels, disk adapters, SCSI adapters?and a failure of any of these components could cause unrecoverable disk failures of your database. RAID should only be used as an additional level of insurance, and not as a complete recovery method.

Using Oracle with Raw Devices

Because of the high amount of I/O that many Oracle systems experience, many Oracle DBAs consider the use of ?raw? devices. A raw device is defined as a disk that bypasses the I/O overhead created by the Journal File System (JFS) in UNIX. The reduction in overhead can improve throughput, but only in cases where I/O is already the bottleneck for the Oracle database. Furthermore, raw devices require a tremendous amount of manual work for both the Oracle administrator and the systems administrator. Oracle recommends that raw devices should only be considered when the Oracle database is I/O bound. However, for these types of Oracle databases, raw devices can dramatically improve overall performance. If the database is not I/O bound, switching to raw devices will have no impact on performance.

In many UNIX environments such as AIX, raw devices are called virtual storage devices (VSDs). These VSDs are created from disk physical partitions (PPs), such that a single VSD can contain pieces from several physical disks. It is the job of the system administrator to create a pool of VSDs for the Oracle administrator. The Oracle administrator can then take these VSDs and combine them into Oracle datafiles. This creates a situation where an Oracle datafile may be made from several VSDs. This many-to-many relationship between Oracle datafiles and VSDs makes Oracle administration more challenging.

In summary, raw devices for Oracle databases can provide improved I/O throughput only for databases that are already I/O bound.

However, this performance gain comes at the expense of increased administrative overhead for the Oracle administrator. We also know that raw devices will only improve the performance of Oracle databases whose Oracle subsystem is clearly I/O bound. For systems that are not I/O bound, moving to raw devices will not result in any performance gains.

The UNIX iostat utility is great for showing those physical disks that have bottlenecks. Since we know the tablespace and table for each hot datafile, we can intelligently move the hot datafiles to a less active disk. Let's begin by exploring the nature of disk load balancing for Oracle.

 

This is an excerpt from "Oracle9i High Performance tuning with STATSPACK" by Oracle Press.