Вы находитесь на странице: 1из 7

Oracle Tuning of SGA

1.0 Tuning the shared pool

1. Shared Pool includes:

a. library cache - holds PL/SQL blocks ( Procedures etc..)

b. data dictionary cache - database dictionary objects

c. user global area -

2. init.ora parameters -

a. SHARED_POOL_SIZE. To determine proper size, set size to a very large


amount and then run application. Sum the totals for the following queries:

i. select sum(shareable_mem) from v$db_object_cache where type = ‘PACK-


AGE’ or type = ‘PACKAGE BODY’ or type = ‘FUNCTION’ or type = ‘PROCEDURE’;

ii. select sum(shareable_mem) from v$sqlarea where executions > 5;

iii. select sum(250 * user_opening) from v$sqlarea; during peak application use

or in a test environment

select 250 * value bytes_per_user from v$sesstat s, v$statname n where s.sta-


tistic# = n.statistic# and n.name = ‘opened cursors current’ and s.sid = 15;

iv. Allow a small allowance for dynamic sql

b. SHARED_POOL_SIZE is too small when request_failures > 0 and increasing

3. Tuning the Library Cache

a. Reduce library cache misses by allocating enough memory

b. Ensure SQL statements use generic code and bind variables.

i. V$LIBRARYCACHE - check GETHITRATIO (GETHITS/GETS) > 90%

Oracle Tuning of SGA January 23, 2004 1


ii. V$LIBRARYCACHE - Reloads < (0.01)PINS. If greater than 1% increase
SHARED_POOL_SIZE.

c. Avoid changes to schema object referenced by a sql statement. The resulting


invalidation requires a reload.

i. V$LIBRARYCACHE - check invalidations column

d. Avoid fragmentation

i. Use reserved space for large memory requirements

- initially set SHARED_POOL_RESERVED_SIZE to 10% of


SHARED_POOL_SIZE.

- V$SHARED_POOL_RESERVED

-- goal of request_misses = 0

-- last_failure_size > shared_pool_reserved_min_alloc

-- avg_free_size > shared_pool_reserved_min_alloc

- If SHARED_POOL_RESERVED_SIZE is too small

--increase SHARED_POOL_SIZE and


SHARED_POOL_RESERVED_SIZE

- if SHARED_POOL_RESERVED_SIZE is too large (free_space = >


50% of shared_pool_reserved_size)

ii. Pin often-used large objects

- objects include compiled triggers, sequences, large procedural objects


such as STANDARD and DIUTIL.

- run dbmspool.sql to create package DBMS_SHARED_POOL and the


KEEP and UNKEEP procedures.

iii. Use small PL/SQL packaged functions instead of large anonoymous blocks

- run script select sql_text from v$sqlarea where command_type = 47


and length(sql_text) > 500;

e. Reduce UGA memory usage.

Oracle Tuning of SGA January 23, 2004 2


4. Tuning Data Dictionary Cache

i. V$ROWCACHE: ratio of GETMISSES/GETS < 15% else increase


SHARED_POOLSIZE. The column GETMISSES cannot have a zero value due to load-
ing at startup.

2.0 Tuning the Buffer Cache

1. Buffer Cache: block can be either free buffers, dirty blocks, pinned buffers. Managed by
DBWR process.

2. init.ora parameter DB_BLOCK_BUFFERS

3. Tuning buffer cache

a. cache hit ratio > 90%

i. calculate hit ratio using V$SYSSTAT

- Hit Ratio = 1- (physical reads/ (db block gets + consistent gets))

b. Use utilities to estimate the hit-ratio change when buffers are added or removed.

i. If hit ratio is low test impact of adding buffers by:

- set init.ora DB_BLOCK_LRU_EXTENDED_STATISTICS = ???

- start database for normal use.

- After a period of normal running query table V$RECENT_BUCKET (count)

ii. Use the following queries

- select sum(count) ach from v$recent_bucket where rownum < 20; Use ach
value in statement below.

- select 1- ((phy.value -ach) / (cur.value + con.value )) “CACHE HIT RATIO”


from v$sysstat cur, v$sysstat con, v$sysstat phy where cur.name = ‘db block gets’ and
con.name =’consistent gets’ and phy.name =’physical reads’;

iii. If hit ratio is high and reducing memory usage is desired then:

- set ini.ora DB_BLOCK_LRU_STATISTICS = TRUE and reset when done.

- start database for normal use

Oracle Tuning of SGA January 23, 2004 3


- After a period of normal running query table
V$CURRENT_BUCKET(count).

iv. Use the following queries:

- select sum(count) acm from v$current_bucket where indx


>=(db_block_buffers) - 20;

- select 1- ((phy.value -ach) / (cur.value + con.value )) * 100 “CACHE HIT


RATIO” from v$sysstat cur, v$sysstat con, v$sysstat phy where cur.name = ‘db block gets’
and con.name =’consistent gets’ and phy.name =’physical reads’;

c. Rules for increasing DB_BLOCK_BUFFERS

i. cache hit ratio is less than 90%

ii. There is added memory for other processes as determined by amount of page
faults.

iii. Previous increase of DB_BLOCK_BUFFERS worked.

4. Using Multiple Buffer Pools

a. DBA can define 1,2, or 3 pools. (DEFAULT, KEEP, RECYCLE). ‘DEFAULT’ is


DB_BLOCK_BUFFERS. KEEP buffer pool is for objects(especially large) that are fre-
quently used but may age out of the default pool. RECYCLE buffer pool is for objects
that are only need for a given transaction.

i. BUFFER_POOL_KEEP = (BUFFERS:1200, LRU_LATCHES:1)

ii. BUFFER_POOL_RECYCLE = (BUFFERS:1200, LRU_LATCHES:2)

b. Pool blocks taken from DB_BLOCK_BUFFERS. Total cannot exceed


DB_BLOCK_BUFFERS

c. For 1 latch at least 50 blocks. Latches taken from DB_BLOCK_LRU_LATCHES.


Total defined latches for each pool cannot exceed DB_BLOCK_LRU_LATCHES.

d. Sizing

i. Use analyze...estimate statistics. ex. Analyze Table atable Estimate Statistics.

ii. Select table_name, blocks from dba_tables where owner = ‘??’ and
table_name=’aname’; Sum the blocks from DBA_TABLES, DBA_INDEXES,
DBA_CLUSTERS for each object.

iii.

Oracle Tuning of SGA January 23, 2004 4


3.0 Tuning the Redo Log Buffer
1. Redo Log Buffer - usually a small area not more than 1M. Default value usually 4*max
block size which is OS specific. Size must be a multiple of system block size.

2. init.ora - LOG_BUFFER = ???? in bytes

3. Tuning guidelines:

a. V$SYSSTAT - redo log space requests to the number of redo entries should not be
greater than 1 in 5000.

i. select (req.value*5000)/entries.value “Ratio”

from v$sysstat req, v$sysstat entries

where req.name = ‘redo log space requests’

and entries.name = ‘redo entries’;

ii. increase LOG_BUFFER size until ratio is stable.

b. Check for cause of LGWR slowness

i. Redo log file should be on separate drives

ii. Waits for log switch to occur

- V$SESSION_WAIT - see if there are any waits for log switch. The
SECONDS_IN_WAIT value of the ‘log buffer space’ event indicates time spent waiting
for space in the redo log buffer because log switch has not occured.

-- This indicates that the buffers are being filled up faster then LGWR is writing.

-- This might also mean disk I/O contention on the redo log files.

-- select sid, event, seconds_in_wait, state from v$session_wait

where event like ‘log%’;

iii. Log file switch waits because of log switches

- V$SYSTEM_EVENT : ‘log file switch completion’

-- select event, total_waits, time_waited, average_wait from v$system_event

where event like ‘log file switch completion%’;

-- Increase the size of the redo log files and or add groups.

Oracle Tuning of SGA January 23, 2004 5


iv. LGWR is waiting on DBWR

- grep alert.log for “CHECKPOINT NOT COMPLETE”

- V$SYSTEM_EVENT - check ‘log file switch(checkpoint incomplete)’

-- select event, total_waits, time_waited, average_wait from v$system_event

where event like ‘log file switch (check%’;

-Adjust LOG_CHECKPOINT_INTERVAL, LOG_CHECKPOINT_TIMEOUT

- Adjust size and number of redo log groups

v. LGWR is waiting on the archiver.

- V$SYSTEM_EVENT - check ‘log file switch(archiving needed)’

-- select event, total_waits, time_waited, average_wait from v$system_event

where event like ‘log file switch (arch%’;

- check that archive device is not full

- add redo log groups

- regulate archiving speed: LOG_ARCHIVE_BUFFERS,


LOG_ARCHIVE_BUFFER_SIZE.

- check if LOG_BLOCKCHECKSUM=TRUE. This adds overhead.

Oracle Tuning of SGA January 23, 2004 6


January 23, 2004 7