ORACLE ARCHITECTURE

TUNING THE SGA

Before tuning the SGA we need to run two SQL scripts

UTLBSTAT and UTLESTAT. They helps us to collect
statistics from running some dynamic performance views
which shows what is happening with the database.
After this we need to concentrate on increasing the
performance of cache hit ratio. The more the cache hit ratio
is, the more will be the over all performance. To compute the
ratio, the following is the formula:
1-(physical reads/(db block gets + consistent gets))
The above values we can get as followed:
select name,value from v$sysstat where name in
(‘physical reads’,’db block gets’,’consistent gets’)
...
Hit ratios are good if they are more then 0.90. The following steps
can be considered to improve the hit ratio.
1.Compute the current hit ratio.
2.Increase size of the buffer cache.
3.Compute the hit ration again until we see no improvements.

The buffer size can be changed in the INIT.ORA. After changing

this, start the instance.
The above procedure should be repeated till we not get any
improvement.
Page 2
Tuning the Library Cache

This is the area in the memory where the SQL statements

or the plans of the SQL statements are stored and are
used incase they are needed again. When we use a SQL
statements, first ORACLE compares that with the cache
by following some rules.
☞The statement text should exactly match with case
sensitiveness.
☞The statements must be from the same object and user.

Page 3
...

We can compute the library cache hit ratio by using the

following formula:
SUM(pins - reloads)/SUM(pins)
The above information can be found from V$LIBRARYCACHE as
followed:
select SUM(pins - reloads)/ SUM(pins) from v$librarycache;
A hit ratio close to 1 is good. If it is less than this we need to
improve this by changing the shared_pool_size in initialization
parameter file. The instance should be restarted after this.
Page 4
Tuning The Dictionary Cache

This cache contains data-dictionary information. Using this

memory greatly reduces the time. We can compute the hit ration
of dictionary cache to determine the efficiency as followed:
select SUM(gets - getmisses - usage -fixed)/ SUM(gets) from
v$rowcache

If the hit ration is 0.85 then it is okay. But we can still try to
improve this by improving the shared_pool_size only. Oracle
automatically determines how much of shared pool memory to
use for the dictionary cache.
Page 5
Tuning the Redo Log Buffer
This buffer contains all redo changes, written by processes.
Multiple processes can write into the redo log buffer at the same
time. Before a process write into this buffer, it needs some place
to write. If space is available, then it goes further smoothly. If all
the spaces are occupied by other users, then we have a contention.
The following queries helps us to see if contention is occurring or
not.
Select name,value from v$sysstat where name=‘redo buffer
allocation retries’;
the above query should be repeated and the result value should be
calculated. If the value is increasing we need to tune the Redo Log
buffer i.e. Increase the LOG_BUFFER size.