In this Document
Goal |
Solution |
One widespread point of view is that in order to lessen the amount of physical I/O, the database buffer cache size should be increased as much as physical memory on the box for this database. That however does not take into account the overhead of serving the bigger buffer cache (at Oracle level, longer search for a required buffer in a much bigger space, in particular), which may outweigh benefits of further reduction in the amount of physical reads, especially if such a reduction is small compared with the portion of the increased buffer cache. Finding the right balance is a difficult task. Buffer Cache Advisory section is a way of addressing this task, as it shows correspondence between the size of the buffer cache and estimated number of physical reads in the context of prospective variations of this size up and down. As seen further from the note, interpreting data in this section is simplified with use of two columns 'Size Factor' and 'Estimated Physical Read Factor'.
There are two conditions for the Buffer Cache Advisory section to appear in the AWR and Statspack reports:
1. buffer cache should not be specified with the parameter db_block_buffers
2. parameter db_cache_advice should be set to 'on' which is default value.
Parameter db_cache_size, if specified, defines the size of default buffer cache. If in addition sga_target > 0 is specified, db_cache_size defines the minimal size of the default buffer cache, and Oracle may allocate bigger size. If sga_target > 0 is specified and db_cache_size is not, then the size of default buffer cache will be allocated by Oracle automatically without low limit. Parameter db_block_size determines the size of the buffers in the default buffer cache.
Apart from default buffer cache - pool (or subpool) which is always present, buffer cache may have other subpools. Buffer Cache Advisory section will then have separate subsection for each of those subpools distinguished from others by a letter in the very left column of the section as follows:
'D' - Default buffer cache (always present),
'K' - Keep buffer cache (if db_keep_cache_size parameter is defined),
'R' - Recycle buffer cache (if db_recycle_cache_size parameter is defined),
<N> - Caches for non-default block sizes (if defined with parameters db_<N>k_cache_size)
Each subsection is read in the same way. So we will illustrate the idea on three real examples for default buffer cache ('D'); other subpools were not defined in the buffer caches of the databases chosen for these examples.
1. In this first example, buffer cache is likely to be reduced by ~2 times.
The Advisory section is read row by row. You start from the row where third field 'Size Factor'= 1.0. If there is more than one such row you can choose any one (below) as figures in all of them for our purpose will be close.
Rows with 'Size Factor' = 1.0 show approximate actual size of the buffer cache during the time interval of the AWR or statspack report. The size itself is shown in the 2nd column 'Size for Estimate(M)' - figure 24,576 in Mb in the example, it has been allocated either automatically if sga_target > 0 or manually.
Last field of this row - 'Estimated Physical Reads' - shows estimation of physical reads for 24,576Mb size of default buffer cache; it is 3,196,928,940. Note also 'Physical Read Factor' 1.0 in the same row.
Figure 3,196,928,940 is absolute figure. Although this can be big as in this example, it is not indicative as such without comparing with figures from other rows in this column.
From this row with 'Size Factor' = 1.0 and 'Est Physical Read Factor' = 1.0, you will look at the neighboring rows up and down.
Rows down show how increasing of buffer cache size would influence reduction of 'Estimated Physical Reads'. Note how 'Size Factor' increases and 'Estimated Phys Read Factor' decreases.
Rows up show how reduction of buffer cache size would influence increasing of 'Estimated Physical Reads'. Note how 'Size Factor' decreases and 'Estimated Phys Read Factor' increases.
Changing 'Size Factor' shows ratio of the proposed size of the buffer cache (increased or decreased) to the approximate actual size currently in use found in the row with 'Size Factor' = 1.0.
Changing 'Estimated Phys Read Factor' shows ratio of the estimated number of Physical Reads for the proposed (increased or decreased) size of the buffer cache to the number of Physical Reads calculated for the current size of buffer cache found in the row with 'Estimated Phys Read Factor' = 1.0.
The two 'Size Factor' and 'Estimated Phys Read Factor' columns show how quickly or slowly number of 'Estimated Physical Reads' goes down or up if the size of the buffer cache would go up or down. They greatly simplify evaluation of the buffer cache situation, as you do not need to compare big figures in columns 'Size for Estimate' and especially 'Estimated Physical Reads'.
So, looking at the rows down from the row where you started ('Size Factor' =1.0 and 'Estimated Physical Read Factor' = 1.0), you see that possible increases of the buffer cache size ('Size Factor' = 1.2 ... 1.5 ... 1.7 ...) would lead to only very moderate reduction of estimated number of physical reads ('Estimated Physical Read Factor' = 0.97 ... 0.93 ... 0.91 ...).
On the other hand, looking at the rows up from the row where you started ('Size Factor' =1.0 and 'Estimated Physical Read Factor' = 1.0), you see that possible reductions of the buffer cache size ('Size Factor' = 0.8 ... 0.5 ...) would lead to only very small increase in the estimated number of physical reads ('Estimated Physical Read Factor' = 1.03 ... 1.08 ...). In other words, reduction of the buffer cache by approximately 2 times would lead to quite insignificant increase in the number of physical reads - strong argument for the actual buffer cache reduction.
2. In the second example Buffer Cache advisory section, it shows that buffer cache size is not sufficient and should be increased.
You will again start from the row with 'Size Factor' = 1.0 and 'Estimated Physical Read Factor'=1.0 and look at the rows up and down.
Rows up show that 'Estimated Physical Read Factor' figures grow faster than respective 'Size Factor' figures reduce. So reduction of the buffer cache is out of question.
Rows down however show that rate of increase of the 'Size Factor' is noticeably less than rate of reduction of the 'Estimated Physical Read Factor'. This means that relatively small increase in the buffer cache size (1.3 ... 1.5 ... 1.7) would lead to much bigger reduction in the Estimated Physical Reads (0.54 ... 0.29 ... 0.06). So that any increase of the buffer cache size would be highly beneficial, provided there are conditions for that in terms of physical RAM available for this database, total SGA size and sizes of other pools within SGA, particularly shared pool size.
3. The third example shows buffer cache advisory section where the size of the buffer cache is considered adequate.
The row to start consideration here is where 'Size Factor' = 1.0 and 'Estimated Physical Read Factor' = 1.00:
It is for the current approximate size of the buffer cache 10,240 Mb with Estimated Physical Reads for this size 1,900,250,999.
From this row you follow the two columns: 'Size Factor' and 'Estimated Physical Read Factor' in both directions up and down. You see that rate of change of the 'Estimated Physical Read Factor' compare with the rate of change of the 'Size Factor' is such that we won't get substantial gains from increasing or decreasing the size of the buffer cache. So interpretation of this or similar data in the advisory section is that the current actual size of the buffer cache is within acceptable range. In cases when sga_target > 0 and db_cache_size is determined automatically, similar data would mean that allocated by Oracle size of the buffer cache is fairly balanced, i.e. not too small to have excessive number of physical reads and not too big to have unnecessary overhead while serving a bigger buffer cache.