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.

Sign up to vote on this title
UsefulNot useful