Databases Reference
In-Depth Information
system sees as a file, and each file is a part of only one tablespace, as described in
Chapter 4
. Placing specific objects in specific tablespaces allows you to accurately
measure and direct the I/O for those objects by tracking and moving the underlying
datafiles as needed.
For example, consider a database with several large, busy tables. Placing multiple
large tables in a single tablespace makes it difficult to determine which table is
causing the I/O to the underlying datafiles. Segregating the objects allows you to
directly monitor the I/O associated with each object. Your Oracle documentation
details the other factors to consider in mapping objects to tablespaces.
Place redo logs and redo log mirrors on the two least-busy devices
This placement maximizes throughput for transactional systems. Oracle writes to
all copies of the redo logfile, and this I/O is not completed until all copies have been
successfully written to. If you have two copies of the redo logfile, one on a slow
device and the other on a fast device, your redo log I/O performance will be con‐
strained by the slower device.
Distribute “system overhead” evenly over the available drives
System overhead consists of I/O to the SYSTEM tablespace for the data dictionary,
the TEMP tablespace for sorting, and the tablespaces that contain rollback segments
for undo information. You should consider the system profile in spreading the
system overhead over multiple drives. For example, if the application generates a
lot of data changes versus data reads, the I/O to the rollback segments may increase
due to higher writes for changes and higher reads for consistent read functionality.
Use a different device for archiving and redo logfiles
To avoid archiving performance issues due to I/O contention, make sure that the
archive log destination uses different devices from those used for the redo logs and
redo log mirrors.
Volume managers
Oracle began providing its own volume manager software for Linux and Windows with
Oracle9
i
Release 2. Since Oracle Database 10
g
, all Oracle Database releases for all sup‐
ported operating systems include a cluster filesystem and volume manager in the da‐
tabase that is leveraged by ASM. When using ASM, an operating system volume man‐
ager will do little to improve database performance.
Older Oracle Database releases were often deployed on operating system-specific non-
Oracle logical volume managers (LVM). An LVM acts as an interface between the op‐
erating system that requests I/O and the underlying physical disks. Volume-
management software groups disks into arrays, which are then seen by the operating
system as single “disks.” The actual disks are usually individual devices attached to con‐
trollers or disks contained in a prepackaged array containing multiple disks and
