Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 









Oracle Database Tips by Donald Burleson


RAM Access Speed with Oracle Databases

Now that inexpensive Solid-state disk is available, Oracle professionals are struggling to understand how to leverage this hardware for Oracle databases. Understanding the nature of Oracle RAM caching can help demonstrate the importance of this issue.  The following sections will cover these topics:

  • The history of Oracle RAM data buffering

  • The problem of duplicate RAM caches

  • The issue of expensive logical I/O

A review of the existing research will provide insight into the best placement for SSD in an Oracle environment.

The History of Oracle RAM data buffering

When Oracle was first introduced in the early 1990's RAM was very expensive and very few databases could afford to run large data buffer regions.  Because RAM was such a limited resource, Oracle utilized a least-frequently-used algorithm within the data buffer to ensure that only the most-frequently referenced data remained in the data buffer cache. 

As of Oracle10g there are seven RAM data buffers to hold incoming data blocks.  These RAM areas define RAM space for incoming data blocks and are governed by the following Oracle10g parameters.  The sum of all of these parameter values determines the total space reserved for Oracle data blocks.

  • db_cache_size

  • db_keep_cache_size

  • db_recycle_cache_size

  • db_2k_cache_size

  • db_4k_cache_size

  • db_8k_cache_size

  • db_16k_cache_size

  • db_32k_cache_size

The following graphic plots the relationship between the size of the RAM data buffers and physical disk reads showing the non-linear nature of RAM scalability for Oracle (Figure 1.2).

This relationship can be expressed mathematically as:

RAM Buffer Size =             n          .      
                                Physical reads

Where n = an observed constant

This relationship is the basis of the Automatic Memory Management(AMM) features of Oracle10g.  Because the Automatic Workload Repository (AWR) is polling the efficiency of the data buffer, the AMM component can compute the point of diminishing marginal returns and re-assign SGA RAM resources to ensure optimal sizing for all seven Oracle10g data buffers.

Oracle uses this data to dynamically adjust each of the seven data buffers to keep them at their optimal size.  AMM in Oracle 10g uses the AWR to collect historical buffer utilization information. The dba_hist_db_cache_adviceview can be used to access this information for Oracle RAM management (Figure 1.3). 

Additional RAM is very valuable when there is not enough RAM to cache the frequently-used data blocks. The diagram below demonstrates how a small increase in RAM results in a large decrease in disk I/O (Figure 1.4).

Traditionally, the optimal size of the Oracle RAM data buffer cache has been the point where the marginal benefit begins to decline, as measured by the acceleration of the curve denoted in Figure 1.2.

However, this marginal benefit does not last forever.  As full-caching of the Oracle database is approached, a relatively large amount of RAM is required to reduce physical disk I/O (Figure 1.5). This occurs because rarely read data blocks are now being pulled into the SGA data buffers.

This optimal point is calculated using the Oracle10g Automatic Memory Management(AMM) utility.  To begin, take a look at the script to display the output from the Oracle v$db_cache_adviceutility:

-- *************************************************
-- Copyright © 2003 by Rampant TechPress
-- This script is free for non-commercial purposes
-- with no warranties.  Use at your own risk.
-- To license this script for a commercial purpose,
-- contact
-- *************************************************

column c1   heading 'Cache Size (m)'              format 999,999,999,999
column c2   heading 'Buffers'                          format 999,999,999
column c3   heading 'Estd Phys|Read Factor'  format 999.90
column c4   heading 'Estd Phys| Reads'          format 999,999,999

   size_for_estimate                 c1,
   buffers_for_estimate            c2,
   estd_physical_read_factor   c3,
   estd_physical_reads            c4
   name = 'DEFAULT'
   block_size  = (SELECT value FROM V$PARAMETER
                   WHERE name = 'db_block_size')
   advice_status = 'ON';

When this utility is executed, the relationship between the RAM buffer size and physical reads is demonstrated.  Note that the values range from 10 percent of the current size to double the current size of the

                                Estd Phys    Estd Phys
 Cache Size (MB)      Buffers Read Factor        Reads
---------------- ------------ ----------- ------------
              30        3,802       18.70  192,317,943 
10% size
              60        7,604       12.83  131,949,536
              91       11,406        7.38   75,865,861
             121       15,208        4.97   51,111,658
             152       19,010        3.64   37,460,786
             182       22,812        2.50   25,668,196
             212       26,614        1.74   17,850,847
             243       30,416        1.33   13,720,149
             273       34,218        1.13   11,583,180
             304       38,020        1.00   10,282,475  Current Size
             334       41,822         .93    9,515,878
             364       45,624         .87    8,909,026
             395       49,426         .83    8,495,039
             424       53,228         .79    8,116,496
             456       57,030         .76    7,824,764
             486       60,832         .74    7,563,180
             517       64,634         .71    7,311,729
             547       68,436         .69    7,104,280
             577       72,238         .67    6,895,122
             608       76,040         .66    6,739,731
2x size

This predictive model is the basis for Oracle10g AMM.  Figure 1.6 shows the tradeoff that occurs when data is taken from Oracle's predictive mode and plotted.

The main point of the relationship between RAM buffering and physical reads is that all Oracle databases have data that is accessed at different frequencies.  In sum, the larger the number of frequently referenced data blocks, the greater the benefit from speeding-up block access.

The next step is to apply this knowledge to the use of SSD for Oracle.

This is an excerpt from the book Oracle Solid State Disk Tuning.  You can get it for more than 30% by buying it directly from the publisher and get immediate access to working code examples.

Market Survey of SSD vendors for Oracle:

There are many vendors who offer rack-mount solid-state disk that work with Oracle databases, and the competitive market ensures that product offerings will continuously improve while prices fall.  SearchStorage notes that SSD is will soon replace platter disks and that hundreds of SSD vendors may enter the market:

"The number of vendors in this category could rise to several hundred in the next 3 years as enterprise users become more familiar with the benefits of this type of storage."

As of January 2015, many of the major hardware vendors (including Sun and EMC) are replacing slow disks with RAM-based disks, and Sun announced that all of their large servers will offer SSD.

Here are the major SSD vendors for Oracle databases (vendors are listed alphabetically):

2008 rack mount SSD Performance Statistics

SearchStorage has done a comprehensive survey of rack mount SSD vendors, and lists these SSD rack mount vendors, with this showing the fastest rack-mount SSD devices:

manufacturer model technology interface performance metrics and notes
IBM RamSan-400 RAM SSD

Fibre Channel

3,000MB/s random sustained external throughput, 400,000 random IOPS
Violin Memory Violin 1010 RAM SSD


1,400MB/s read, 1,00MB/s write with ×4 PCIe, 3 microseconds latency
Solid Access Technologies USSD 200FC RAM SSD

Fibre Channel

391MB/s random sustained read or write per port (full duplex is 719MB/s), with 8 x 4Gbps FC ports aggregated throughput is approx 2,000MB/s, 320,000 IOPS
Curtis HyperXCLR R1000 RAM SSD

Fibre Channel

197MB/s sustained R/W transfer rate, 35,000 IOPS

Choosing the right SSD for Oracle

When evaluating SSD for Oracle databases you need to consider performance (throughput and response time), reliability (Mean Time Between failures) and TCO (total cost of ownership).  Most SSD vendors will provide a test RAM disk array for benchmark testing so that you can choose the vendor who offers the best price/performance ratio.

Burleson Consulting does not partner with any SSD vendors and we provide independent advice in this constantly-changing market.  BC was one of the earliest adopters of SSD for Oracle and we have been deploying SSD on Oracle database since 2005 and we have experienced SSD experts to help any Oracle shop evaluate whether SSD is right for your application.  BC experts can also help you choose the SSD that is best for your database.  Just  call 800-766-1884 or e-mail.:  for SSD support details.

DRAM SSD vs. Flash SSD

With all the talk about the Oracle “flash cache”, it is important to note that there are two types of SSD, and only DRAM SSD is suitable for Oracle database storage.  The flash type SSD suffers from serious shortcomings, namely a degradation of access speed over time.  At first, Flash SSD is 5 times faster than a platter disk, but after some usage the average read time becomes far slower than a hard drive.  For Oracle, only rack-mounted DRAM SSD is acceptable for good performance:

Avg. Read speed

Avg. write speed

Platter disk

10.0 ms.

  7.0 ms.


 0.4 ms.

  0.4 ms.

Flash SSD    

 1.7 ms.

 94.5 ms.



HTML-DB support:

For HTML-DB development support just call to get an Oracle Certified professional for all HTML-DB development projects.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.