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

Ratios – Historical Introduction 

Tuning has always been an important part of a Remote DBA’s job, ranking right next to backup and recovery.  It has often been viewed as “black magic.”  That perception originated from the tuning process that was taught by many experts and touted in the many books on tuning.  That process centered on using ratios to determine the health of a database or component of the database.   

According to the ratio school of thought, if the Buffer Cache Hit Ratio (BCHR) is too low, then the size of the buffer cache should be increased to improve performance.  If this fixed the problem and the database ran better, then the Remote DBA was awarded guru status and managers would likely follow almost any recommendations made.  If these changes showed no improvement or made things worse, another Remote DBA would be brought in. The new Remote DBA might determine that another ratio was out of line and make a different change, or simply increase the magnitude of the initial changes.  If this change made performance better, then the new Remote DBA became the guru.   

This school of thought is based, at least in part, on the rationale that it is faster to access data blocks from memory (RAM) than from disk.  Therefore, if too many data blocks were being read from disk, then a possible cause of performance degradation is the buffer cache being too small to keep enough data blocks available for the users.  Usually, the solution to that problem was to increase the buffer cache.   

To better understand ratios, it may help to illustrate using a non-database example.  Theoretically it is faster to get to work if there are no stoplights to wait for. So to reduce commute time, try and reduce the time spent at stoplights.  One way would be to simply keep going even when the lights are red, but that could get dangerous and cause increased insurance premiums, so another way would be to tune or change the commute.


The above book excerpt is from:

Oracle Wait Event Tuning

High Performance with Wait Event Interface Analysis 

ISBN 0-9745993-7-9  

Stephen Andert 

http://www.rampant-books.com/book_2004_2_wait_tuning.htm

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.