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 and Disk Usage

One of the major arguments against relational database systems has been speed. It has been said that relational systems are slow. It has been found, however, that with proper tuning of Oracle applications and operating system, as well as proper file placement, Oracle performance is excellent. In fact I have seen Oracle8i deliver subsecond response times even when searching tables containing billions of rows (yes, I said billions.) Conversely, if you try to place Oracle on an insufficient number of disks, performance will suffer.

How Many Is Enough? 

Some applications will do fine with two disks or volumes. This setup is not great, mind you, but the system will function. Other applications, such as large complex systems involving numerous indexes, data tables, and tablespaces, may require dozens. To reduce disk contention and maximize database reliability, it is suggested that the Remote DBA utilize OFA procedures to place database files. The next subsections cover file placement for some basic disk array layouts. 

One Area (Surely You Jest) 

It is foolish and very dangerous to even consider using a single area to hold all Oracle files for other than DOS, OS/2, WINDOWS NT, or MAC-based single-user databases. Unless you have the latest and greatest EMC array with multiple gigs of storage, hot replacement of disks, and RAID5, a single large area can lead to problems. A single disk failure or crash in a stripe set could completely destroy your system. Since there are no file placement options with one area, let’s go on to the next configuration.

Two Areas (Just Barely Adequate)  

At least with two areas you can achieve separation of data and indexes and can separate redo logs from archive log files. This gives you some redundancies in recovery options. The file placement is shown here.

AREA1. Oracle executables, index datafiles, redo logs, export files, a copy of the control file

AREA2. Data-datafiles, rollback segment datafile, temporary user datafiles, archive log files, a copy of the control file 

As you can see, an attempt is made to spread I/O between the two areas. Indexes and data are on separate controllers, as are redo logs and rollback segments. Additional recoverability in case of disk crash is given by having exports on one drive and archive log files on the other. While infinitely better than only one area, having only two areas is still an extremely vulnerable condition and is not recommended. Again, with the most up-to-date storage areas with large caches, extreme striping, and hot replacement of disks, one or two areas is workable.

See Code Depot


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.