||Oracle Tips by Burleson
Oracle Disk Layout
If youíve read up to this point, you should realize that disk layout
is critical to efficient operation of Oracle systems. There are
several questions you need to answer when designing your disk
- What are the sizes of, and available space on, the disks or
arrays to be used with Oracle?
- Is this disk or array used for other non-Oracle
- Has the disk been defragmented (if needed)?
- Is this a raw device (if UNIX)?
- What is the speed of the disk or disks in the array; or what
is the I/O saturation point of the controller channel?
- Is this a RAM or an optical disk?
Letís look at each of these questions to determine how the
answers affect Oracle:
What are the sizes of, and available space on, the disks or arrays
to be used with Oracle?Obviously, if there isnít enough space on the
disk, you canít use it. If the size is too small to handle projected
growth, then you might want to look at another asset. Oracle files
can be moved, but not with that section of the database active. If
you enjoy coming in before or after hours or on weekends, then by
all means put your database files on an inappropriately sized disk
Is this disk or array used for other non-Oracle applications? This
question has a many-sided answer. From the Oracle point of view, if
you have a very active non-Oracle application, it will be in
contention with Oracle for the disk at every turn. If the non-Oracle
application, such as a word processing or a calculation program that
uses intermediate result files, results in disk fragmentation (on
NT) this is bad if the datafile co-located with it has to grow and
canít allocate more contiguous space. From the viewpoint of the
other application, if we are talking about export files, archive log
files, or growing datafiles, an asset we need to operate may be
consumed, thus preventing our operation. Look carefully at the
applications you will be sharing the disk assets with; talk with
their administrators and make logical usage projections.
Has the disk been defragmented (for NT)? This was covered before but
bears repeating. A fragmented disk is of little use to Oracle on NT;
it will be a performance issue. Oracle needs contiguous disk space
for its datafiles. If the disk hasnít been defragmented, have it
checked by the system administrator for fragmentation, and
defragment it if required.
Is the disk a raw device (for UNIX)? If the disk is a raw device,
this restricts your capability for file naming. Be sure you maintain
an accurate log of tablespace mapping to raw devices. Map tablespace
and other asset locations ahead of time. Remember, an entire raw
partition must be used per Oracle datafile; it cannot be
subpartitioned without redoing the entire raw setup. If you must use
raw, plan it!
What is the speed of the disk? By speed of disk we are referring to
the access and seek times. The disk speed will drive disk
throughput. Another item to consider when looking at disk speed is
whether or not the disk is on a single or shared controller. Is the
DSSI chained? All of these questions affect device throughput.
Generally, datafiles and indexes should go on the fastest drives; if
you must choose one or the other, put indexes on the fastest.
Rollback segments and redo logs can go on the slowest drives as can
archive logs and exports.
Is the disk a RAM or an optical disk? Ultimately, the RAM and
optical usage ties back to disk speed. A RAM drive should be used
for indexes due to its high speed. It is probably not a good
candidate for datafiles due to the RAM driveís current size
limitations; this may change in the future. An optical drive, due to
its relative slowness, is excellent for archives and exports, but
probably shouldnít be used for other Oracle files. A possible
exception might be large image files (BLOBs) or large document
files. Usually, unless you have a rewritable CD system, the
tablespaces placed on a CD-ROM will be read-only. With the storage
capacities of most optical drives, they make excellent resources for
archive logs and exports. They can conceivably provide a single
point of access for all required recovery files, even backups. This
solves the biggest recovery bottleneck: restoration of required
files from tape.
Expert Remote DBA
BC is America's oldest and largest Remote DBA Oracle support
provider. Get real Remote DBA experts, call
BC Remote DBA today.