BC remote Oracle DBA - Call (800) 766-1884  
Oracle Consulting Oracle Training Development

Remote DBA

Remote DBA Plans  

Remote DBA Service

Remote DBA RAC

   
Remote DBA Oracle Home
Remote DBA Oracle Training
Remote DBA SQL Tuning Consulting
Remote DBA Oracle Tuning Consulting
Remote DBA Data Warehouse Consulting
Remote DBA Oracle Project Management
Remote DBA Oracle Security Assessment
Remote DBA Unix Consulting
Burleson Books
Burleson Articles
Burleson Web Courses
Burleson Qualifications
Oracle Links
Remote DBA Oracle Monitoring
Remote DBA Support Benefits
Remote DBA Plans & Prices
Our Automation Strategy
What We Monitor
Oracle Apps Support
Print Our Brochure
Contact Us (e-mail)
Oracle Job Opportunities
Oracle Consulting Prices





   

 

 

 

Remote DBA services

Remote DBA Support

Remote DBA RAC

Remote DBA Reasons

Remote Oracle Tuning

Remote DBA Links

Oracle DBA Support

Oracle DBA Forum

Oracle Disaster

Oracle Training

Oracle Tuning

Oracle Training

 Remote DBA SQL Server

Remote MSSQL Consulting

Oracle DBA Hosting

Oracle License Negotiation

 

 


 

 

 

 

   
  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.



This is an excerpt by Mike Aultís book ďOracle9i Administration & ManagementĒ.  If you want more current Oracle tips by Mike Ault, check out his new book ďMike Aultís Oracle Internals Monitoring & Tuning ScriptsĒ or Aultís Oracle Scripts Download.


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.

Remote DBA Service
 

Oracle Tuning Book

 

Advance SQL Tuning Book 

BC Oracle support

Oracle books by Rampant

Oracle monitoring software

 

 

 

 

 

 

BC Remote Oracle Support

Remote DBA

Remote DBA Services

Copyright © 1996 -  2013 by Burleson. All rights reserved.

Oracleģ is the registered trademark of Oracle Corporation.