Buffer Cache Tuning

Main Points

Understand How Buffer Cache Works

Measure Buffer Cache Performance
Improve Buffer Performance

Why use Buffer Cache

Data accessed from Memory is faster than data
accessed from disk.

Understand Buffer Cache Working

What is in buffer cache
o Blocks for - Tables, Indexes, Clusters,
o Blocks for - LOB Segments, LOB Indexes
o Blocks for - Rollback Segments (UNDO)
o Blocks for - Temporary Space
What is involved in managing buffer Cache
o Different types of Block

Free block not currently used

Pinned block currently used by server
process

Clean block that was just used and now
is ready to be re-used

Dirty block that needs to be written to
disk because it contains committed data
o LRU list

Data blocks from data files are put on the
MRU side of the LRU list (exception is
FTS)
o Dirty List

Keeps track of dirty blocks
o User Server Processes (Shared Server Processes)

First check if the data requested by user
is already in the buffer cache

If not, it searches LRU list to find out
free blocks. (Statistics: Free Buffer
Inspected)

Reads data from data file into free blocks
in buffer cache
o DBWR process

Moves dirty blocks from LRU list to Dirty
list

Write dirty blocks to Data file

Measure Buffer Cache Performance

Hit Related Stats (V$SYSSTAT)

o Buffer Cache Hit Ratio (should be > 95% for OLTP)

Physical Reads

Physical Reads Direct

Physical Reads Direct(LOB)

Session Logical Reads

Non-hit related Stats (V$SYSTEM_EVENT & V$SYSSTST)

o Free buffers inspected (v$sysstat)
o Free buffer wait (v$system_event)
o Buffer Busy Wait (v$system_event)

What is stored in V$SYSSTAT

All system wide events and their cumulative values from
the last instance startup
STATISTIC#
Statistics ID
NAME
The name of the statistic
CLASS
Category the statistic falls into
o 1 User
o 2 Redo
o 4 Enqueue
o 8 Cache
o 16 Operating System
o 32 Real Application Cluster
o 64 SQL
o 128 Debug
VALUE
Current value of statistic
There are over 200 different statistics tracked by the
V$SYSSTAT view. However, only four of these are used when
calculating the performance of the Database Buffer Cache

Hit Related Stats (Increase hit ratio)

Physical Reads: This statistic indicates the number of

data blocks (i.e. tables, indexes, and rollback
segments) read from disk into the Buffer Cache since
instance startup.

Physical Reads Direct This statistic indicates the

number of reads that bypassed the Buffer Cache because
the data blocks were read directly from disk instead.
Because direct physical reads are done intentionally

by Oracle when using certain features like export or

Parallel Query.

Physical Reads Direct (LOB) This statistic indicates

the number of reads that bypassed the Buffer Cache
because the data blocks were associated with a Large
Object (LOB) datatype

Session Logical Reads This statistic indicates total

number of reads requested for data. This value
includes requests satisfied by access to buffers in
memory and requests that caused physical I/O.

Non-hit related stats (Minimize them)

Free Buffer Inspected Number of Buffer Cache buffers

inspected by user Server Processes before finding a
free buffer.
SELECT
name, value
FROM
v$sysstat
WHERE
name IN (free buffer inspected)
Free Buffer Waits These waits occur whenever the
Server Process had to wait for Database Writer to
write a dirty buffer to disk (DBWR)
SELECT
FROM
WHERE

event, total_waits
v$system_event
event = free buffer waits

Buffer Busy Waits These waits occur whenever a buffer

requested by user Server Processes is already in

memory, but is in use by another process. These waits

can occur for rollback segment buffers as well as data
and index buffers. (DBWR)
SELECT
FROM
WHERE

event, total_waits, average_wait

v$system_event
event = buffer busy waits

Improve Buffer Cache Performance

Overall Strategy
Make Buffer cache bigger
Use multiple buffer pools (keep, recycle)
Cache tables in memory
Bypass buffer cache
Use indexes properly (to avoid FTS)
Make it bigger. (DB_CACHE_SIZE, SGA_MAX_SIZE)
Set Value of DB_BUFFER_CACHE (in bytes). The total
size of the Buffer Cache, Shared Pool, and Redo Log
Buffer cannot exceed SGA_MAX_SIZE.
How much of buffer cache is enough
o Set DB_CACHE_ADVICE=ON (consumes memory & CPU to
collect statistics for providing advice.
SELECT
name, size_for_estimate,
estd_physical_reads,
estd_physicai_read_factor
(physical/total)  not shown below
FROM
v$db_cache_advice
WHERE
block_size = 8192
AND
advice_status = ON;

Use multiple Buffer Pools

There types of buffer pools

o Keep (DB_KEEP_CACHE_SIZE): cache segments that
should rarely leave Buffer Cache.
o Recycle (DB_REYCLE_CACHE_SIZE): cache segments
that should be rarely retained. (Large tables)
o Default (DB_CACHE_SIZE): All objects that are not
assigned to the above two pools
Notes:
o Total size of buffer cache = DB_KEP_CACHE_SIZE +
DB_RECYCLE_CACHE_SIZE + DB_CACHE_SIZE
o If multiple block sizes are being used, a Keep,
Recycle, and Default Pool can be created for each
block sizes Buffer Cache
How to determine which segments to cache
o Oracle recommends you consider caching in the
Keep Pool frequently accessed segments whose
total size is less than 10 percent of the Default
Pool size.
o Oracle recommends that you consider caching in
the Recycle Pool segments
whose blocks will not be accessed outside of
individual transactions
whose total size is more than twice the size
of the Default Pool.
How to determine sizes of the above pools

o Use DBA_TABLES.BLOCKS or DBA_INDEXES.BLOCKS to

find out the size of the segments to be kept in
these pools
How to assign segments to the above pools
o ALTER TABLE apps.employee STORAGE (BUFFER_POOL
KEEP);
o ALTER INDEX apps.employee_first_name_idx STORAGE
(BUFFER_POOL KEEP);
o ALTER TABLE apps.sales_history STORAGE
(BUFFER_POOL RECYCLE);
How to find out which objects are in which pool
SELECT owner, segment_type,
segment_name, buffer_pool
FROM
dba_segments

How to find out the sizes of these buffer pools

SELECT
FROM

name, block_size, current_size

v$buffer_pool;

How to find out hit ratios of these buffer pools

SELECT

FROM
ORDER

name "Buffer Pool",

1-(physical_reads / (db_block_gets +
consistent_gets)) "Buffer Pool Hit Ratio"
v$buffer_pool_statistics
BY name;

Cache tables in Buffer Cache

No matter how many Buffer Pools you decide to use,

each one is still managed by LRU
Small tables that require FTS will be always at the
LRU end of the LRU list. Therefore they would be
kicked out of buffer cache earlier. To avoid this cache them

You can cache a table using three methods

Table creation
CREATE TABLE phone_list
( employee_id number,
phone_number varchar2(11),
extension varchar2(4))
TABLESPACE appl_tab
STORAGE (INITIAL 50K NEXT 50K PCTINCREASE 0)
CACHE;

Alter table
ALTER TABLE employee CACHE;
Use hint (caches table only for the query time)
SELECT
/*+ CACHE */
last_name,
first_name
FROM
employee;

How to decide which tables are already cached

SELECT
FROM
WHERE

owner,
table_name
dba_tables
LTRIM(cache) = Y;

Bypass the Buffer Cache

We can bypass buffer cache using Direct Path read and
direct insert commands
o export  DIRECT=TRUE (Direct Path reading)
o SQL DIRECT=TRUE in sqlldr (Direct Path inserting)

Additional Side Notes:

With Oracle 10g it is possible to flush the buffer

cache with alter system flush buffer cache

9i has an undocumented command as follows to flush

buffer cache - Alter session set events = immediate
trace name flush_cache;

You can view the contents of buffer cache by querying

v$BH view as follows.
SELECT decode(c.name,null,'UNUSED',c.name)
ts_name,
a.file#
file_number,
COUNT(a.block#)
Blocks,
FROM
V$BH a,
file$ b,
ts$ c
WHERE
a.file#=b.file#(+)
AND
b.ts#=c.ts#(+)
GROUP BY a.file#,decode(c.name,null,'UNUSED',c.name)

TS_NAME
FILE_NUMBER BLOCKS
------------------------------ ----------- -----UNUSED
0
7177
SYSTEM
1
3149

RBS
TOOLS
PERFSTAT
TEST_2K

2
5
8
9

707
441
333
2