Oracle Database Tips by Donald Burleson

The History of Oracle RAM Data Buffering

When Oracle was first introduced in the early 1990's, RAM was very expensive and 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, seven separate RAM data buffers are available 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

Figure 1.2 below shows the plot of the relationship between the size of the RAM data buffers and physical disk reads.  Clearly, there is a non-linear nature of RAM scalability for Oracle.

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 reassign SGA RAM resources to ensure optimal sizing for all seven of the Oracle10g data buffers.  In Calculus, the point of diminishing marginal returns is the second derivative of the equation.

Oracle uses this data to dynamically adjust each of the seven data buffers to keep them at their optimal size.  In AMM, Oracle 10g uses the AWRto collect historical buffer utilization information and stores the buffer advisory information in the dba_hist_db_cache_advice view and offers a host of dba_hist views for Oracle RAM management as shown in Figure 1.3 below. 

When there is not enough RAM to cache the frequently used working set of data blocks, additional RAM is very valuable. Figure 1.4 shows that a small increase in RAM results in a large decrease in disk I/O.

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.4.

However, this marginal benefit does not last forever.  As the Oracle database approaches full caching, it takes a relatively large amount of RAM to reduce physical disk I/O as shown in Figure 1.5.  This is because rarely read data blocks are now being pulled into the SGA data buffers.

This optimal point is easily calculated with the Oracle10g AMM utility.  The following script to display the output from the Oracle v$db_cache_advice utility will show how it works:

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

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

Executing this utility will clearly show the relationship between the RAM buffer size and physical reads.  The values range from ten percent of the current size to double the current size of the db_cache_size.

                                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.  When the data from Oracle's predictive mode is plotted, the tradeoff becomes clear as shown in Figure 1.6.

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

Taking this into consideration, the following section will show how to more intelligently apply this knowledge to the use of SSD for Oracle.

See code depot for complete scripts

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