Quick Oracle 9i Performance Tuning Tips & Scripts

Introduction
Oracle is a database software, Oracle is not an operating system, but it is installed on an operating system (viz UNIX, Windows2000, Red Hat Linux). That is, it needs an operating system, it can't be installed straight, on hardware only. As database software Oracle hosts Applications Software, like a database of hotel booking developed by application developers in the business, or appllications Software bought straight from a software house like Sage Sterling Financial Controler software. There is a catch here; What to tune on a database system, which in production, is interacting with applications software, where the whole thing sits on an operating system? What if the Application Software you use, which has its database stored on an Oracle server, is not tuned? What if the application design is bad? No matter how much tuning you do on an Oracle Server, if your Application Design is bad - with implications on performance- you will not achieve a lot. Again, if your operating system (OS) installation is not optimized and tuned to operate optimally, tuning only the oracle server won't help much either. This web page aims to give you tips on how to find out what you can fine-tune on an already installed and running Oracle production server. It is NOT a reference for application software tuning, and it is NOT an operating system tuning refernce either. We will examine areas where we can improve the performance of the Oracle Server. We will draw a generic plan on how to start tuning the Oracle server and we will look at scripts and examples for the performance tuning of Oracle 9i database server.

How to start tuning the Oracle Database?

There are 2 very common methods of tuning which, are also suggested from Oracle and these are "Top-down" approach "Performance tuning principles" approach "Top-down" approach "Performance tuning principles" approach

Top-down approach is suitable for development database systems. Steps followed are:

Performance tuning approach is suitable for production database systems. Steps followed are:

1. 2. 3. 4. 5.

Tuning Tuning Tuning Tuning Tuning

the Data Design the application design memory allocation I/O and physical structure Resource contention

1. Define problem, fomulate tuning goal 2. Examine host OS, gather oracle 3. 4. 5. 6.
statistics Compare identified problem with common problems identified by oracle. Use statistics gathered in step 2 to get a picture of what's going on Identify the changes to be made and implement them Determine whether the objectives identified in step 1 are met.

Steps 1 & 2 are not much in the DBA's hands if the application is already developed. If it is in the process of development, then the DBA can contribute a lot.

Which approach you use depends on the system you are going to tune. In the topdown approach which dominates the development database systems the main areas of tuning considered here are memory tuning inside System Global Area (SGA), overall database I/O tuning (Redo Logs, Disk I/O) and resource contention (CPU bottlenecks).

Generic Plan
Always start by examining your database instance's following areas memory tuning disk I/O tuning resource contention (CPU)

memory tuning - sort out your SGA... The four main components of the SGA Oracle memory area are:

1. Shared Pool
1.1 Library Cache 1.2 Data dictionary cache 1.3 User Global Area UGA

2. Database buffers cache 3. Other SGA areas: Large pool, java pool, shared server comps

4. Tuning Redo mechanisms with Redo Log Buffer

Certain performance metrics (performance goals) must have been already established from you the DBA in accordance with the performance requirements of your business. Once the metrics are established, then you can run V$ dynamic performance views to measure the current metrics and then take action accordingly.

1. Shared Pool
Shared pool is the portion of the SGA which caches the SQL and PL/SQL statements that have been recently issued by application users. Is managed by LRU (Least Recently Used Algorithm). It is all about caching the frequently used SQL and PL/SQL statements so that they can be re-used straight from memory RAM rather than be read again from the disk (HDD) which consumes time throuh extra I/O. 1.1 Library Cache Library cache is the location where Oracle caches the SQL and PL/SQL statements, that have been recently issued by application users. The first V$ dynamic performanc view you should look at to get a rough idea is V$LIBRARYCACHE and in particulare the columns retrieved from the following SQL statement.

SQL> select namespace, gethitratio, pinhitratio, reloads, invalidations from v$librarycache;

NAMESPACE GETHITRATIO PINHITRATIO RELOADS INVALIDATIONS --------------- ----------- ----------- ---------- ------------SQL AREA .979002787 .987618452 23 3 TABLE/PROCEDURE .823852923 .598268839 0 0 BODY .75 .681818182 0 0 TRIGGER .692307692 .692307692 0 0 INDEX 0 0 0 0 CLUSTER .984962406 .983050847 0 0 OBJECT 1 1 0 0 PIPE 1 1 0 0 JAVA SOURCE 1 1 0 0 JAVA RESOURCE .5 .5 0 0 JAVA DATA 0 .666666667 0 0 This statetment will produce library-cache-hit-ratio metrics which oracle reccomends shouldn't be less than 80%. NAMESPACE shows the source of the cached code. GETHITRATIO 91.5% means users are finding the SQL statements they are issuing already in the Library Cache 91.5% of the time. PINHITRATIO 93.7% means how frequently executed statements found the associated parsed SQL already in the Library Cache. RELOADS shows the number of times that an executed statement had to be re-parsed

because the Library Cache had aged out or invalidated the parsed version of the statement. To measure if we are re-parsing statements that were previously loaded in the Library Cache very often. Well-tuned systems are those with reload ratios of less than 1%. INVALIDATIONS these occur when a cached SQL statement is marked as invalid and therefore forced to parse even though it was already in the Library Cache. 1.2 Data dictionary cache In Data Dictionary Cache, Oracle caches information related with dictionary elements of the SQL statements such as, tables referenced in the statement, data types , column names, privileges etc..The view which provides you the information is V$ROWCACHE.

SQL> SELECT 1-(SUM(GETMISSES)/SUM(GETS)) "Data Dictionary Hit Ratio" FROM V$ROWCACHE;

Data Dictionary Hit Ratio ------------------------.98629891

The result .98629891 shows that your application is finding the data dictionary information it needs, already in memory, 96,9 % of the time, Oracle reccommends values NOT less than 80%. 1.3 User Global Area UGA This is when you use shared server configuration and is measuring shared server performance. Here in most of the cases, you just have to increase the memory size of your RAM chip.

2. Database buffers cache

The role of the Database Buffer Cache is to provide the users not only cached statements in the memory as the library cached did but also to provide data, which is cached in RAM memory. The Database Buffer Cache holds copies of the data blocks of the segments of tables, indexes and etc... the application users have been most recently accessing in the database. Each database buffer in the Database Buffer Cache corresponds in size to, and holds the contents of, one database block. The blocks cached can be of: Tables, Indexes, Clusters, Large Object (LOB) Segments, Rollback segments, Temporary segments. The usage of these buffers in the Database Buffer Cache is managed by a combination

of mechanisms including: LRU list User Server Processes Database Writer (DBW0) Background Process

LRU list: Each individual's user process is responsible from reading the data from the disks to the Database Buffer Cache. The data is placed to the LRU list which manages the Database Buffer Cache memory. The LRU works as a conveyor belt. When a full table scan is performed on a table the table blocks are place at the end of the LRU conveyor belt to prevent large objects from occupying the whole or the Database Buffer Cache. The buffers that the LRU maintains can be in one of the following four states: 1. 2. 3. 4. Free Pinned Clean Dirty

The Database Buffer Cache not only contains the blocks read from the disks, but also has the changed, update version of those blocks which have to be written back to the disks. The mechanism for managing these changed, updated-dirty buffers is called the Dirty List or Write List. The DBW0 background process-Database writer writes these blocks back to the disk. User Server Process: User server process is the one which makes use of LRU list and the Dirty list. The Free Buffer Inspected statistic is the indicator of the number of buffers each server process is examining while in the process of finding a free buffer. Rollback segment rows which ensure transaction concurrency and consistency are cached in the Database Buffer Cache as well! Database Writer: Is DBW0, and is responsible to write the dirty buffers from the Database Buffer Cache to disk when certain conditions occur. 1. When dirty list reaches it threshold limit. (DBW0 writes dirty buffers from Dirty List) 2. When LRU List is searched too long without finding a free buffer (DBW0 writes dirty buffers directly from the LRU list) 3. When three seconds pass ( DBW0 moves dirty buffers from the LRU list to the dirty list. If the threshold length is exceeded, a write to disk also occurs. 4. At checkpoint (DBW0 moves all dirty buffers from the LRU list to the dirty list and then writes them to disk. 5. At database shutdown (Unless a SHUTDOWN ABORT is used, DBW0 always writes all dirty buffers to disk at database shutdown) 6. At tablespace hot backup ( DBW0 moves the dirty buffers for that tablespace from the LRU list to the Dirty List and then writes them to disk. 7. At tablespace offline temporary (DBW0 moves the dirty buffers for that tablespace from the LRU list to the Dirty List and then writes them to disk) 8. Ad Drop Segment (Dropping a table or index causes DBW0 to first write the dirty blocks for that segment to disk.

Like the Shared Pool one indicator of the Database Buffer Cache is the cache-hit ratio. That is, cache hits occur whenever a user is able to find data buffer needed by their SQL statement already cached in memory. High cache hit ratios indicate that the application are finding cached data very frequently. The hit-ratio information can be found in many places; V$SYSSTAT STATSPACK utility

Additionally there are also non-hit ratio measures of Database Buffer Cache effectiveness found in V$SYSTEM_EVENT, including: Free Buffer Inspected waits, Buffer Busy Wait events, Free Buffer Wait events if these events appear in the V$SYSTEM_EVENT and are constantly increasing then you should look to improve your Database Buffer Cache. OK, lets find out the cache-hit ratio which oracle recommends that we should strive to be above 90% in most OLTP systems, here it is:

SQL> select 1 - (( physical.value - direct.value lobs.value)/logical.value) "Buffer Cache Hit Ratio" from 2 v$sysstat physical, 3 v$sysstat direct, 4 v$sysstat lobs, 5 v$sysstat logical 6 where 7 physical.name = 'physical reads' 8 and lobs.name = 'physical reads direct (lob)' 9 and direct.name ='physical reads direct' 10* and logical.name = 'session logical reads' Buffer Cache Hit Ratio ---------------------.994841472
.994841472 is a good hit.

3. Other SGA areas: Large pool, java pool, shared server comps 4. Tuning Redo mechanisms with Redo Log Buffer

disk I/O tuning I/O is all about the cost of retrieving data from the disk (HDD) and placing data to the disk. There are some good Oracle V$ views to control the I/O statistics of your disks. It is all about the physical writes and physical disk which occur from the actual Hard Disks during database operation. I/O on an Oracle Server can be caused indirectly due

to the following events. Database Writer (DBW0) activity. DBW0 writing data to rollback segment blocks to maintain read consistency. User Server Processes reading data blocks into the Database Buffer Cache. Log Writer (LGWR) writing transactions recovery information from the Redo Log Buffer to the online redo log Archiver (ARC0) reading the contents of redo logs and writing those contents to the archive destination Application user activity temporarily writing large sort requests to disk.

Goals when tuning physical I/O are

1. Minimize physical I/O whenever possible by properly sizing SGA. 2. Perform any remaining physical I/O as fast as possible when it is required.
Disk I/O tuning concerns these database structures Datafiles (includes Tablespaces) DBW0 Individual Segment data blocks Sort ctivity and temporary segments Rollback segments