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 layout:

• 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 applications?
• 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 asset.

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.