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.
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.