Instance Tuning

After the initial configuration of a database, tuning an instance is important to Eliminate any performance bottlenecks. This contains the following sections 1 Performance Tuning Principle 2 Performance Tuning Steps 3 Wait Events 4 Idwl Wait Events 1 Performance Tuning Principles Tuning principle is identifying the most significant bottelnecks and making the appropriate changes to reduce or eliminate the effect of that bottleneck. 1.1 Base line: This can be used for comparision if a performance issue raise. For example all DBAs knows their system peak usage time. For example, the peak periods could be between 10.00am and 12.00pm and also between 1.30pm and 3.00pm. This could include a batch window of 12.00am midnight to 6am. We install a monitoring tool that gathers performance data for those times. Baseline data gathered should include the following 1 Application statistics 2 Database statistics 3 operating system statistics 4 Disk I/O statistics 5 Network statistics

1.1.2 When to Tune There are two distinct types of tuning: proactive monitoring and bottleneck elimination. Proactive monitoring This occurs on a regularly scheduled interval, where a number of performance statistics to know the system behavior and resource usage has changed. Proactive monitoring also can be called proactive tuning. Usually monitoring does not give any changes on the system until we get problem. Bottleneck Elimination: Tuning is used to fixing the performance problems. So we can say tuning is should be part of lifecycle of an application i.e analysis, design, coding, production and maintenance stage. Another purpose is to reduce resource consumption or reduce elapsed time for an operation to complete. So our goal is to improve the effective use of a particular resource. 2 Performance Tuning Steps 1 get the candid feedback from users about the scope of the performance problem. Define the problem. 2 Examine the host system and Examine the Oracle Statistics. 3 Consider the list of common performance errors to see this we can suggests that problem. 4 Build a conceptual model of what is happening on the system using the performance data gathered. 5 Implement and Measure Change

2.1 Define the Problem: By seeing this we have good understanding of the purpose of the tuning. Gather the following data. 1 Identify the performance objective 2 identifying the scope of the problem 3 identify the time frame when the problem occurs 4 Quantify slowdown 5 Identify any changes 2.2 Examine the host system We look at the load on the database server as well as the database instance. Here we consider the operating system, the I/O subsystem and network statistics. CPU Usage If there is a significant amount of idle CPU, i.e wait I/O should be considered as idle CPU. If there is high CPU usage then check whether the CPU is being used effectively. If the CPU is used by a small number of high-usage programs, then look at the programs to determine the cause. Non-Oracle Processes If the programs are not Oracle programs, then identify whether they are legitimately requiring that amount of CPU. Oracle-processes If a small number of Oracle processes consumes most of the CPU resources, then use SQL_TRACE and TKPROF to identify the SQL or PL/SQL statements to see if a particular query or PL/SQL program unit can be tuned. Oracle CPU Statistics Oracle CPU statistics are available in three V$ views 1 V$SYSSTAT show oracle CPU usage for all sessions 2 V$SESSTAT : shows oracle CPU usage for each session

3 V$RSRC_CONSUMER_GROP: show CPU utilization statistics for each consumer group when the Oracle Database Resource Manager is running Detecting I/O Problems An overly active I/O system can be evidenced by disk queue lengths greater than two, or disk service times that are over 20-30ms. If the I/O system is overly active, then check for potential hot spots that could benefit from distributing the I/O across more disks. Tool such as sar d(or iostat) on many UNIX systems Network Using operating system utilities, look at the network round-trip ping time and the number of collisions. If the network is causing large delays in response time, then investigate possible causes. 2.3 Examine the Oracle Statistics The goal is to tune the Oracle instance, then look at the Oracle statistics to identify the resource bottleneck from Oracles perspective before implementing corrective action. Setting the Level of Statistics Collection From oracle 9ir2 provide the initialization parameter STATISTICS_LEVEL, which controls all major statistics collections. Depending on the setting of STATISTICS_LEVEL certain advisories and statistics are collected as follows: Buffer cache advisory MTTR advisory Shared Pool sizing advisory Segment level statstics PGA target advisory Time operating system statistics Time statistics

System Statistics V$system_event indicate that the largest wait event V$waitstat to see which block type has the highest wait count and highest wait time V$sysstat : this contains overall statistics for many difference parts of Oracle V$filestat: This contains detailed file I/O statistics for each file V$rollstat: contains detailed rollback and undo segment statistics for each segment V$enqueue_stat: this contains enqueue statistics for each enqueue V$latch: This contains detailed latch usage statistics for each latch Segment_level Statistics V$system_event V$segment_statistics 2.3Implement and Measure change After fixing problem, we identify two or three changes that could potentially eliminate the problem. To identify which change provides the most benefit, it is recommended that only one change be implemented at a time. Typically, most sites with dire performance problems implement a number of overlapping changes at once, and thus cannot identify which changes provided any benefit. 2.4 Using Wait Event Statistics to Drill Down to Bottlenecks Whenever an oracle process waits for something, it records the wait using one of a set of predefined wait events. See v$event_name for a list of all wait events Some of these events are termed idle events, because the process is idle, waiting for work to perform.

The most effective way to use wait event data is to order the events by the wait time. This is only possible if TIMED_STATISTICS is set to true. Otherwise, the wait events can only be ranked by the number of times waited, which is often not the ordering that best represents the problem. To get an indication of where time is spent, follow these steps: 1 examine the data collection for V$SYSTEM_EVENT. Example Select * from v$system_event where event=latch free;

Top Wait Events and Potential Causes Wait Event Buffer busy waits General Area Buffer cache, DBWR Possible Causes Depends on buffer type. For example waits for an index block may be caused by a primary key that is based on an ascending sequence. Buffer cache, DBWR, I/O Slow DBWR(possible due to I/O) cache too small I/O, SQL statement tuning Poorly tuned SQL, Slow I/O system I/O, SQL statement tuning Poorly tuned SQL, Slow I/O system Locks Depends on type of enqueue Latch contention Depends on latch Log buffer, I/O Log buffer small, slow I/O system I/O, over-committing Slow disk that store the online logs, Un-batched commits.

Free buffer waits Db file scattered read Db file sequential read Enqueue Latch free Log buffer space Log file sync

Wait Events The view V$SESSION_WAIT, V$SESSION_EVENT and V$SYSTEM_EVENT provide information on what resources were waited for, and if the configuration parameter TIMED_STATISTICS is set to true. The three views contain related, but different views of the same data: V$SESSION_WAIT is a current stat view. It list either the event currently being waited for or the event last waited for on each session. V$SESSION_EVENT lists the cumulative history of events waited for on each session.

V$SYSTEM_EVENT lists the events and times waited for by the whole instance since instance startup. db file scattered read This event signifies that the user process is reading buffers into the SGA buffer cache and is waiting for a physical I/O call to return. A db file scattered read issues a scatter-read to read the data into multiple discontinuous memory locations. A scattered read is usually a multi block read. It can occur for a fast full scan (of an index) in addition to a full table scan. Check in V$SESSION_WAIT parameter columns db file sequential read This event signifies that the user process is reading buffers into the SGA buffer cache and is waiting for a physical I/O call to return. This call differs from a scattered read, because a sequential read is reading data into contiguous memory space. A sequential read is usually a single-block read. Single block I/Os are usually the result of using indexes. Rarely, full table scan calls could get truncated to a single block call due to extent boundaries, or buffers already present in the buffer cache. These waits would also show up as db file sequential read'. Check in V$SESSION_WAIT parameter columns direct path read (lob) When a session is reading buffers from disk directly into the PGA, it waits on this event. If the I/O subsystem does not support asynchronous I/Os, then each wait corresponds to a physical read request. If the I/O subsystem supports asynchronous I/O, then the process is able to overlap issuing read requests with processing the blocks already existing in the PGA. When the process attempts to access a block in the PGA that has not yet been read from disk, it then issues a wait call and updates the statistics for this event.

Hence, the number of waits is not necessarily the same as the number of read requests. Check in V$SESSION_WAIT parameter columns