Scribd Logo
Upload

Welcome to Scribd!

  • 117 views

    02 - Buffer Cache Tuning

    Uploaded by

    AMEY
    The buffer cache stores frequently accessed data blocks in memory to reduce disk I/O. Tuning involves understanding how it works, measuring performance, and making improvements. Key aspects include sizing the cache appropriately, using multiple pools, caching specific tables, and bypassing the cache when needed. Metrics like hit ratio and wait events help evaluate performance.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd

    02 - Buffer Cache Tuning

    Uploaded by

    AMEY
    117 views11 pages
    The buffer cache stores frequently accessed data blocks in memory to reduce disk I/O. Tuning involves understanding how it works, measuring performance, and making improvements. Key aspects include sizing the cache appropriately, using multiple pools, caching specific tables, and bypassing the cache when needed. Metrics like hit ratio and wait events help evaluate performance.

    Original Description:

    oracle performance tuning

    Original Title

    02_Buffer Cache Tuning

    Copyright

    © © All Rights Reserved

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The buffer cache stores frequently accessed data blocks in memory to reduce disk I/O. Tuning involves understanding how it works, measuring performance, and making improvements. Key aspects include sizing the cache appropriately, using multiple pools, caching specific tables, and bypassing the cache when needed. Metrics like hit ratio and wait events help evaluate performance.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    117 views11 pages

    02 - Buffer Cache Tuning

    Uploaded by

    AMEY
    The buffer cache stores frequently accessed data blocks in memory to reduce disk I/O. Tuning involves understanding how it works, measuring performance, and making improvements. Key aspects include sizing the cache appropriately, using multiple pools, caching specific tables, and bypassing the cache when needed. Metrics like hit ratio and wait events help evaluate performance.

    Copyright:

    © All Rights Reserved
    Download as PDF, TXT or read online from Scribd
    Download as pdf or txt
    of 11

    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

    You might also like