html Analyzing a Statspack Report Introduction Executing Snapshots Load Profile Section Top 5 Timed Events Section Resolving Event Waits Section Common Wait Events, Explanation SQL Information Section Instance Activity Stats Section Tablespace I/O Stats Section Buffer cache Activity Information Enqueue Activity Undo Segment Information Latch Information Library Cache Statistics A guide to the detail sections of the Statspack report Wait Events Quick Reference Guide Common Idle Events Web tools to analyze Reports

If you could choose just two Oracle utilities to find and monitor performance problems in your Database system, those two utilities would be Oracle Enterprise Manager and Statspack. Which area of the Summary page you will focus will depend on whether you are investigating a performance problem on monitoring the load of changes, you should start checking the top 5 wait events section.

When statistics and wait events can be misleading
There are certain checks which can be performed to help identify whether a statistic or event is really of interest. When timed_statistics is false, wait events are ordered by the number of waits. This information may indicate which events are of interest, however it may be misleading. An event may be waited for a large number of times, however the wait time (if it were available for comparison) may show the actual time waited is small despite the high count, hence the event is not really of interest. If wait time is available, a useful comparison can be made by taking the total wait time for an event, and comparing it to the elapsed time between snapshots. For example, if the wait event accounts for only 30 seconds out of a two hour period, there is probably little to be gained by investigating this event. However, if the event accounts for 30 minutes of a 45 minute period, the event may be worth investigating. There is a warning here, too: even an event which had a wait of 30 minutes in a 45 minute snapshot may not be indicative of a problem, when you take into account there were 2000 users on the system, and the host hardware was a 64 node machine. When interpreting computed statistics (such as percentages, or per-second rates), it is important to cross-verify the computed statistic with the actual statistic counts. This acts as a sanity check to determine whether the derived rates are really of interest. On initial examination, a soft-parse ratio of 50% would normally indicate a potential tuning area. However if the actual statistic counts are small,

this would not be an area of interest. For example, if there was one hard parse and one soft parse during the Statspack interval, the soft-parse ratio would be 50%, even though the statistic counts show this is not an area of concern. SNAPSHOT LEVELS LEVEL 0 - GENERAL PERFORMANCE This level can be used to gather general performance information about the database. LEVEL 5 - GENERAL PERFORMANCE + SQL STATEMENTS (DEFAULT) This snapshot level will gather all the information from the previous levels, plus it will collect performance data on high resource SQL statements. This is also the default snapshot level when Statspack is installed. LEVEL 6 - GENERAL PERFORMANCE + SQL STATEMENTS + SQL PLANS AND SQL PLAN USAGE This level is new in Oracle9i and it will include all the information collected from the previous snapshot levels, plus execution path and plan usage information as they relate to high resource SQL statements. This type of information can prove critical when determining if the execution path or plan has changed for high resource SQL statements. Oracle recommends using this level for when one of the following situations has occurred: - A plan has possibly changed after large volumes of data have been added. - Obtaining new optimizer setting information. LEVEL 10 - GENERAL PERFORMANCE + SQL STATEMENTS + SQL PLANS AND SQL PLAN USAGE + PARENT AND CHILD LATCHES This level will include all the information collected from previous snapshot levels, plus the addition of parent and child latch information. This level will take even longer to complete since the parent and child latch information are added to the duration of the previous 2 levels, which are already information gathering intensive. First, because the information gathered is based on the shared_pool_size and secondly the volume of information gathered based on SQL statement information, plus the parent and child latch information. Snapshots taken from this level will take even longer and it is Oracle's recommendation to only use this level when requested by Oracle technical support personnel. LEVEL SETTING RECOMMENDATION It is recommended to set the timed_statistics to true BEFORE the first snapshot because it will help to establish a better baseline, otherwise another baseline will be needed AFTER it is turned on. This can be done with the Alter SYSTEM command and/or setting it in the init.ora file. SESSION SPECIFIC SNAPSHOT Statspack also provides the capability to gather session specific information. Passing the i_session_id value to the Statspack.snap procedure will enable this option. The following is an example of using this feature: SQL> EXECUTE STATSPACK.SNAP(i_session_id=>20); EXECUTING SNAPSHOTS Executing a snapshot interactively can be as easy as accessing SQL*Plus as the PERFSTAT user and using the SNAPSHOT.SNAP command or automating when a snapshot is executed. The interactive method is highly beneficial for when a problem is reported in the database and a snapshot could prove beneficial for troubleshooting, whereas the value of an automated snapshot is realized when a problem is reported at a later time and a comparison needs to be made between two specific times that occurred in the past.

INTERACTIVE METHOD Access SQL*Plus as the PERFSTAT user and execute either method 1, 2 or 3 as discussed in the above snapshot Configuration section. The simplest form of the interactive mode is as follows: SQL> EXECUTE STATSPACK.SNAP AUTOMATED METHOD The ability to automate a snapshot is another one of the great features of the Statspack utility. Automating and scheduling when to take snapshots allows for the collection of database performance information that would be beneficial for troubleshooting performance problems that occurred earlier. The following are two ways that snapshots can be automated: - Oracle's DBMS_JOB utility to schedule snapshots. This utility will be discussed in greater detail. - An operating specific job scheduler. For example on Unix, shell scripts can be written and then scheduled through the CRON scheduler. For NT, the AT scheduler in combination with .cmd files. DBMS_JOB UTILITY The DBMS_JOB utility provides a way to schedule database related tasks that are controlled within the database. Through the DBMS_JOB utility snapshots can be taken at a scheduled interval. When the spcpkg.sql script was executed as part of the Statspack installation, the DBMS_JOB package was created for the PERFSTAT user. One of the requirements to use the DBMS_JOB utility is that the init.ora parameter job_queue_processes must be set to a value greater than 0. The spauto.sql script is designed to setup the automation of executing snapshots once every hour. The following line from the script is how the job is added to the schedule: dbms_job.submit(:jobno, 'statspack.snap;', trunc(sysdate+1/24,'HH'), - 'trunc(SYSDATE+1/24,''HH'')', TRUE, :instno); The benefits of using the spauto.sql script is that it: - Displays the job number assigned - Identifies the number of job_queue_processes set for the database - The next time that the snapshot will occur

Load Profile Section
The Load Profile section of the Statspack report is useful primarily in comparing two reports to see if the load characteristics from the two report periods are similar. In proactive tuning, you generate reports on a routine basis and check the Load Profile for changes in throughput (shown by the persecond statistics) and changes in application characteristics (shown by the per-transaction statistics). In reactive tuning, you use the Load Profile to verify the validity of comparing a report generated during a problem period with a report generated during a baseline period. Make sure the systems were running comparable workloads during the two report periods. For example, if one report showed a majority of read-only activity and the second was very update-intensive, comparing the two reports would not be valid. If you are not comparing two reports, it's still a good idea to scan the Load Profile for any rates that seem high, irrespective of a baseline. For example, a high hard-parse rate (say, greater than 100 per second) may have serious implications for performance. High hard-parse rates are likely to be accompanied by latch contention, so you would expect to see latch free waits in the Top 5 Wait Events or high in the complete Wait Events list. Load Profile ~~~~~~~~~~~~ Transaction Per Second --------------Per

81 351.02 4.24 50.71 1.73 0.00 Sorts: 0. High hard parse rates cause serious performance issues.91 473. User Calls: The number of queries generated . Physical Reads: The number of requests for a block that caused a physical I/O. Check whether waits for ‘latch free’ appear in the top-5 wait events.68 User calls: 25.44 Transactions: % Blocks changed per Read: Rollback per transaction %: 19.--------------Redo size: 8 5.449.530.92 1.73 -0.37 Logical reads: 108.64 Block changes: 20.71 20. Hard Parses: Those parses requiring a completely new parse of the SQL statement. . examine the latching sections of the Statspack report. Of course. Parses: Total of all parses: both hard and soft . Redo size: This is the amount of redo generated during this report.77 Physical reads: 0. A high hard parse rate is usually accompanied by latch contention on the shared pool and library cache latches. . Physical Writes: The number of physical writes issued. A ‘hard parse’ rate of greater than 100 per second indicates there is a very high amount of hard parsing on the system.68 37.12 2.67 Where: .01 Parses: 0.17 Recursive Call %: Rows per Sort: 4.01 15. Block changes: The number of blocks modified during the sample interval . . we want a low number here.75 Physical writes: 2.10 Hard parses: 0.00 Executes: 9. .007.31 Logons: 0. and must be investigated. Logical Reads: This is calculated as Consistent Gets + DB Block Gets = Logical Reads . and if so.72 134.

and so on .93 End -----43. For example. such values can be misleading your system may be doing something efficiently that it would be better off not doing at all. Basically. A high soft parse rate could be anywhere in the rate of 300 or more per second. along with which related sections of the report you should look at when investigating suspicious values: . looking at the per-transaction statistics allows you to identify changes in the application characteristics by comparing these to the corresponding statistics from the baseline report. Unnecessary soft parses also limit application scalability. we are looking at a very good hard parse number and a fairly high system load.00 97. where user response time is less critical than in an online transaction processing (OLTP) environment. Similarly. ‘block changes’ and ‘pct of blocks changed per read’ would indicate the instance is performing more inserts/updates/deletes.99 Redo NoWait %: Buffer Hit %: -45. Soft Parses: Not listed but derived by subtracting the hard parses from parses.99 Interpreting the ratios in this section can be slightly more complex than it may seem at first glance.when you're evaluating the Instance Efficiency Percentages. you need to keep in mind the characteristics of your application . optimally a SQL statement should be soft-parsed once per session. While high values for the ratios are generally good (indicating high efficiency).07 73. • an increase in the ‘redo size’ without an increase in the number of ‘transactions per second’ would indicate a changing transaction profile. low values aren't always bad.64 100. and executed many times. a low in-memory sort ratio (indicating a low percentage of sorts performed in memory) would not necessarily be a cause for concern in a decisionsupport system (DSS) environment. Sorts and Logons are all self explanatory . Transactions: how many transactions per second we process This gives an overall view of the load on the server.57 In-memory Sort %: Library Hit %: 99.08 77.79 76.66 % Non-Parse CPU: Shared Pool Statistics Memory Usage %: % SQL with executions>1: % Memory for SQL w/exec>1: Begin -----42. For example: • a significant increase in ‘redo size’.e.55 99. In this case.11 99.75 Latch Hit %: Parse CPU to Parse Elapsd %: 52.whether it is queryintensive or update-intensive. The per-second statistics show you the changes in throughput (i. Executes: how many statements we are executing per second / transaction .. . Similarly.53 75. whether the instance is performing more work per second). Here's how each ratio is calculated.89 Soft Parse %: Execute to Parse %: -1. Evaluating the Instance Efficiency Percentages Section Instance Efficiency Percentages (Target 100%) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Buffer Nowait %: 99. whether it involves lots of sorting.72 99. A soft parse reuses a previous hard parse and hence consumes far fewer resources.

A low buffer hit ratio does not necessarily mean the cache is too small. If value is negative. gives the percentage of block requests that were satisfied within the cache without requiring physical I/O. Similarly. Execute to Parse. it gives the percentage of those requests in which the requested buffer is immediately available. that the system did not make correct use of bind variables in the application. This is another form of thrashing which also degrades performance tremendously. it could be indicative of a shared pool that is too small (SQL is prematurely aging out). you may be able to reduce the amount of switching by increasing the size of the online redo logs. This ratio relates to requests that a server process makes for a specific buffer. either because the logs are not filling up very often or because the database is able to switch to a new log quickly whenever the current log fills up. This ratio indicates the amount of redo entries generated for which there was space available in the redo log. a high buffer hit ratio (say. Optimally. the buffer cache is too small and the data in is being aged out before it can be used so it must be retrieved again. This ratio gives the percentage of parses that were soft. All buffer types are included in this statistic. Thus. a value close to 100 percent for the redo nowait ratio indicates minimal time spent waiting for redo logs to become available. For example. If the log switches are not frequent. it may be that potentially valid full-table scans are artificially reducing what is otherwise a good ratio. If your alert log shows that you are switching logs frequently (that is. A pin hit occurs when the SQL or PL/SQL code to be executed is already in the library cache and is valid to execute. If the soft parse ratio is also low. Sometimes you can identify a too-small buffer cache by the appearance of the write complete waits event. but this assumption may not always be valid. rather than requiring a disk-sort segment to complete the sort. When these buffers are read. This ratio gives the percentage of sorts that were performed in memory. this ratio should be high. which means you could put the files on faster disks. Setting the PGA_AGGREGATE_TARGET (or SORT_AREA_SIZE) initialization parameter effectively will eliminate this problem. This is very BAD!! Buffer Nowait Ratio. 99 percent) normally indicates that the cache is adequately sized. Another cause for a negative execute to parse ratio is if the shared pool is too small and queries are aging out of the shared pool and need to be reparsed. gives the percentage of pin requests that result in pin hits. If these disks are not overloaded. check the disks on which the redo logs reside to see why the switches are not happening quickly. check the Buffer Wait Statistics section of the report for more detail on which type of block is being contended for. frequently executed SQL statements that repeatedly refer to a small number of buffers via indexed lookups can create a misleadingly high buffer hit ratio. This is a form of thrashing which degrades performance immensely.It is possible for both the 'buffer hit ratio' and the 'execute to parse' ratios to be negative. it means that the number of parses is larger than the number of executions. which indicates that hot blocks (that is. Redo Nowait Ratio. also known as the buffer-cache hit ratio. Library Hit Ratio. This ratio. This inflation makes tuning the buffer cache a challenge. check the Wait Events list for evidence of this event. Although historically known as one of the most important statistics to evaluate. also known as the library-cache hit ratio. A soft . this ratio can sometimes be misleading. The percentage is calculated as follows: 100 x (1. In the case of the buffer hit ration. Soft Parse Ratio. as opposed to hard. iterative access to these buffers can artificially inflate the buffer hit ratio.(redo-log space requests/redo entries)) The redo-log space-request statistic is incremented when an Oracle process attempts to write a redo-log entry but there is not sufficient space remaining in the online redo log. more than once every 15 minutes). blocks that are still being modified) are aging out of the cache while they are still needed. or just as likely. In-Memory Sort Ratio. If the "Library Hit ratio" is low. check whether there's a parsing issue. they are placed at the most recently used (MRU) end of the buffer cache. in an OLTP environment. If the ratio is low. they may be slow. This ratio. Buffer Hit Ratio.

as the data is rolled up over all latches. which might indicate a parsing or latching problem. If the rates are low (for example. Ideally. and can record CPU utilization for 'b'.this is a indication that the shared pool needs to be increased (especially if the "Begin" value is much smaller) ***Please see the following NOTES on shared pool issues [NOTE:146599.1] SCRIPT TO SUGGEST MINIMUM SHARED POOL SIZE  Top 5 Timed Events Section Just knowing the breakdown of time into the above 3 categories is not very useful so Oracle has a set of 'Wait Events' for activities in 'a' and 'c'. Before you jump to any conclusions about your soft parse ratio. if the "End" value is in the high 95%-100% range . investigate whether you can share SQL by using bind variables or force cursor sharing by using the init. ~~~~~~~~ Waiting for 'SQL*Net message from client'. Also check the "Shared Pool Statistics". on the other hand. Hard parsing is an expensive operation and should be kept to a minimum in an OLTP environment. Latch Hit Ratio. For a typical OLTP system. all data (such as the optimizer execution plan) pertaining to the statement in the shared pool is equally applicable to the statement currently being issued. This is best illustrated with a simplified example of few seconds in the life of an Oracle shadow process: State ~~~~~ IDLE Notes. look at the sharedpool and library-cache latches in the Latch sections of the report for indications of contention on these latches. occurs when the current SQL statement is either not in the shared pool or not there in a shareable form. The Soft Parse % value is one of the most important (if not the only important) ratio in the database. When the soft parse ratio falls much below 80 percent. However.1] Understanding and Tuning the Shared Pool [NOTE:105813.. it should be as near to 100% as possible.1. parsing may not be a significant issue in your system. be sure to compare it against the actual hard and soft parse rates shown in the Load Profile.ora parameter cursor_sharing (new in Oracle8 i Release 8. In other words. A hard parse. 1 parse per second). A low value for this ratio indicates a latching problem. Cross-check this value with the Top 5 Wait Events to see if latch free is in the list. Another useful standard of comparison is the proportion of parse time that was not CPU-related.. This is the ratio of the total number of latch misses to the number of latch gets for all latches. and refer to the Latch sections of the report. . execute many times. Latch Hit % of less than 99 percent is usually a big problem. given by the following ratio: (parse time CPU) / (parse time elapsed) A low value for this ratio could mean that the non-CPU-related parse time was spent waiting for latches. The aim is to parse once. however. the soft parse ratio should be greater than 95 percent. You quite simply do not hard parse after the database has been up for a while in your typical transactional / general-purpose database. To investigate further. An example of the latter case would be when the SQL statement in the shared pool is textually identical to the current statement but the tables referred to in the two statements resolve to physically different tables.1] Diagnosing and Resolving Error ORA­04031 [NOTE:62143. whereas a high value is generally good. a high latch hit ratio can artificially mask a low get rate on a specific latch.parse occurs when a session attempts to execute a SQL statement and a usable version of the statement is already in the shared pool.6).

This section of the report shows the top 5 wait events. ON CPU Scans for the SQL statement in the shared pool. The idle wait events .Foreground Wait Events: Foreground wait events are those associated with a session or client process waiting for a resource .695 1. you must narrow down the list by investigating the granular reports within other sections of Statspack. & begins to execute. Listing 1 shows a large number of waits related to reading a single block (db file sequential read) as well as waits for latches (latch free). To identify which of these are major issues. frees latch . the events are ordered by the number of waits. the full list of wait events. . This section is among the most important and relevant sections in the Statspack report.221. Constructs a SQL*Net packet to send back to the user containing the first row of data.006 503. WAITING Waits on 'SQL*Net message to client' for an acknowledgement that the SQL*Net packet was reliably delivered.Receives a SQL*Net packet requesting 'parse/execute' of a statement ON CPU decodes the SQL*Net packet.104 22. finds a match. and the background wait events.490 2. Code Listing 1: Statspack report showing waits related to reading a single block Top 5 Wait Events -----------------------------------Event Waits Time (s) % Total Elap. this section includes a new event: CPU time When you are trying to eliminate bottlenecks on your system.773 2. They indicate waits encountered by system and non-system processes.977.057. the events are ordered in time waited. Here is where you find out what events (typically wait events) are consuming the most time. In Oracle9i Release 2.230 1. ON CPU Block read has completed so execution can continue. WAITING Waits for 'db file sequential read' as we need a block which is not in the buffer cache.496 9.571 82. IDLE Waits on 'SQL*Net message from client' for the next thing to do..49 Wait Events Information Section The following section will describe in detail most of the sections provided in a statspack report. You can see in this listing high waits for some of the writing to datafiles and log files.016.Background Wait Events: Background wait events are those not associated with a client process.054. for examples the enqueue and latch free events.755 404.55 log file sync 1. Time -----------------------------------------------------------------------------db file sequential read 18.29 latch free 4. An example of a non-system background process would be a parallel query slave. If TIMED_STATISTICS is false.70 log file parallel write 1.85 db file parallel write 1. Note that it is possible for a wait event to appear in both the foreground and background wait events statistics. sets up links to the shared cursor etc. your Statspack report's Top 5 Timed Events section is the first place to look. If your system's TIMED_STATISTICS initialization parameter is set to true. Ie: Waiting for an IO to complete. since all events don't show the waits. Examples of background system processes are LGWR and DBWR.598. which is preferable.224 733.379. WAITING Waits for 'latch free' to obtain the a 'library cache' latch Gets the latch.

starting with Oracle9i Release 2 the "Top 5 Wait Events" section has been renamed to "Top 5 Timed Events". Here is the statistic that measures 'Service Time' from the same report: Statistic CPU used by this session Total per Second 358.105 6.---------. The following is the "Top 5 Wait Events" section of a Statspack report generated from two snapshots 46 minutes apart: Top 5 Wait Events -----------------------------------Event Waits Time (s) % Total Elap. In situations where 'Service Time' i.827 (a) 52. Resolving Wait Events Section A critical activity in Database Performance Tuning is Response Time Analysis: this consists of finding out where time is being spent in a database.------------.-------------------direct path read 4. This means that it is now easier to accurately measure the impact of Wait Events in overall 'Response Time' and to correctly target the subsequent tuning effort.e.appear at the bottom of both sections and can generally safely be ignored. it is very likely that investigating Wait Events will not produce significant savings in 'Response Time'.---------- . 'Service Time' as measured by the statistic 'CPU used by this session' is listed as 'CPU time'.264 30. one should always compare the time taken by the top wait events to the 'CPU used by this session' and direct the tuning effort to the biggest consumers. Note: To address this possible source of confusion.232 10.---------. Response Time Analysis for an Oracle Database is done using the following equation: Response Time = Service Time + Wait Time 'Service Time' is measured using the statistic 'CPU used by this session' 'Wait Time' is measured by summing up time spent on Wait Events When presented with such a list of top Wait Events it sometimes becomes easy to simply start dealing with the listed Wait Events and to forget evaluating their impact on overall Response Time first. Therefore. CPU usage is much more significant than 'Wait Time'. Time ----------------------------.63 Based on this listing we may be tempted to immediately start looking at the causes between the 'direct path read' and 'db file scattered read' waits and to try to tune them. Here.372.09 direct path write 1.806 130. This approach would not take into account 'Service Time'.992 3.6 ------------------------.268 15.70 control file parallel write 893 198 . Typically these type of events keep record of the time while the clien is connected to the database but not requests are being made to the server.95 db file parallel write 40 131 .---------. MISINTERPRETING THE IMPACT OF WAIT EVENTS: AN EXAMPLE Here is a real life example of why it is important to look at both 'Wait Time' and 'Service Time' when investigating database performance.5 per Trans 12.01 (b) db file scattered read 6.

85% = 1.1] 'direct path read (lob)' 'direct path write (lob)' Controlfile I/O-Related Wait Events: 'control file parallel write' 'control file sequential read' 'control file single write' Redo Logging I/O-Related Wait Events: 'log file parallel write' [NOTE:34583.05% It is now obvious that the I/O-related Wait Events are not really a significant component of the overall Response Time and that subsequent tuning should be directed to the Service Time component i.e.817 = 379.1] 'db file parallel read' 'direct path read' [NOTE:50415.623 cs If we now calculate percentages for all the 'Response Time' components: CPU time direct path read db file scattered read direct path write db file parallel write = 94.1] 'db file scattered read' [NOTE:34558.1] 'log file sync' [NOTE:34592. the improved "Top 5 Timed Events" section in Statspack starting with Oracle9i Release 2 would show output similar to our calculated listing.817 cs 'Service Time' = 358.806 cs 'Response Time' = 358.03% control file parallel write = 0.1] 'direct path write' [NOTE:50416.1] 'log file sequential read' 'log file single write' 'switch logfile command' 'log file switch completion' 'log file switch (clearing log file)' 'log file switch (checkpoint incomplete)' 'log switch/archive' .Let's do some simple math from these figures: 'Wait Time' = 10. Datafile I/O-Related Wait Events: 'db file sequential read' [NOTE:34559.01% (b) = 20.806 + 20. CPU consumption.65% = 0. In this section we list the I/O-related Wait Events that occur most often in Oracle databases together with reference notes describing each wait.52% = 2. Incidentally.827 (a) x 100% / 52.86% = 0.

various Sort Areas etc. For example.000 requests of size 100Kb each or 10. o Reduce the I/O requirements of the database by tuning SQL: o Reduce the I/O requirements of the database by tuning instance parameters: This works in two ways: a) Using memory caching to limit I/O: The amount of I/O required by the database is limited by the use of a number of memory caches e.000 requests of 10Kb each (up to 10MB) o Optimizing I/O at the Operating System level This involves making use of I/O capabilities such as Asynchronous I/O or using Filesystems with advanced capabilities such as Direct I/O (bypassing the Operating System's File Caches). Common WAIT EVENTS If you want quick instancewide wait event status. the likelihood of them being exhausted during a sorting operation and having to use a temporary tablespace on disk is reduced. SAN or NAS o Redistribute database I/O by manual placement of database files across different filesystems. you can use the following query : . Another possible action is to raise the limit of maximum I/O size per transfer (referred to as max_io_size in this article).'log file switch (archiving needed)' Buffer Cache I/O-Related Wait Events: 'db file parallel write' [NOTE:34416.1] 'db file single write' 'write complete waits' 'free buffer waits' Approaches for handling General I/O problems Some of these approaches can be used regardless of the particular Wait Event. controllers and physical devices This is an approach used in the absence of advanced modern storage technologies. showing which events are the biggest contributors to total wait time. multiblock I/Os are executed faster when there are fewer larger I/Os than when there are more smaller I/Os. b) Tuning the size of multiblock I/O: The size of individual multiblock I/O operations can be controlled by instance parameters. up to a point. It is harder to get right than the previous approach and most often less successful. Up to a limit. Again the aim is to distribute the database I/O so that no single set of disks or controller becomes saturated from I/O requests when there is still unused disk throughput.g. Increasing the Buffer Cache. the Log Buffer. results in more buffer accesses by database processes (logical I/Os) being satisfied from memory instead of having to go to disk (physical I/Os). o Balancing the database I/O by usage of Striping. transferring 100Mb of data will complete faster if it is done in 100 requests of size 1Mb each than if it is done in 1. With larger Sort Areas in memory. RAID. the Buffer Cache.

'virtual circuit'. If you have a high wait time for this event.ora parameter db_file_multiblock_read_count specifies the maximum numbers of blocks read in that way. Typically. 'parallel deque wait'. The event. as IO is a normal activity on a healthy instance. since a full table scan is put at the cold end of the LRU (Least Recently Used) list. resulting in unnecessary or inefficient IO operations • The IO system is overloaded and performing poorly • The IO system is under-configured for the load • IO operations are taking too long If this Wait Event is a significant portion of Wait Time then a number of approaches are possible: o Find which SQL statements perform Full Table or Fast Full Index scans and tune them to make sure . You can use the Statspack report to help identify the query in question and fix it. the SQL statements are poorly tuned). 'smon timer'. '%SQL*Net%'. Try to cache small tables to avoid reading them in over and over again. this parameter should have values of 4-16 independent of the size of the database but with higher values needed with smaller Oracle block sizes. As full table scans are pulled into memory. total_waits. by getting faster disks or by distributing your I/O load better. EVENT -----------------------db file sequential read latch free db file scattered read enqueue buffer busy waits log file parallel write TOTAL_WAITS ------------35051309 1373973 2958367 2837 444743 146221 TIME_WAITED ------------15965640 1913357 1840810 370871 252664 123435 1. they rarely fall into contiguous buffers but instead are scattered throughout the buffer cache. e. Although it may be more efficient in your situation to perform a full table scan than an index scan.g. check to ensure that full table scans are necessary when you see these waits. The appearance of the‘db file scattered read’ and ‘db file sequential read’events may not necessarily indicate a problem. you either need to reduce the cost of I/O. they can indicate problems if any of the following circumstances are true: • The data-access method is bad (that is. or you need to reduce the amount of full table scans by tuning SQL statements. 'rdbms ipc reply'. 'client message'. That generally happens during a full scan of a table or Fast Full Index Scans. A large number here indicates that your table may have missing or suppressed indexes.time_waited from V$system_event where event NOT IN ('pmon timer'. DB File Scattered Read. However. 'NULL event') order by time_waited desc.

by getting faster disks or by distributing your I/O load better. 2. Parallel DML (PDML) such as parallel updates. The sequential read event identifies Oracle reading blocks sequentially. If that is the case. such as inefficient SQL. o In cases where such multiblock scans occur from optimal execution plans it is possible to tune the size of multiblock I/Os issued by Oracle by setting the instance parameter DB_FILE_MULTIBLOCK_READ_COUNT so that: DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT = max_io_size of system Query tuning should be used to optimize online SQL to use indexes. . to see if it might be helpful to tune the statements with the highest resource usage. Problematic hash-area joins should show up in the PGA memory.hash_value and p. unselective indexing or you either need to reduce the cost of I/O.operation='INDEX' and p. Check to ensure that index scans are necessary.hash_value=p. v$sql_plan p where t.piece. or you need to reduce the amount of I/O by increasing the buffer cache or by tuning SQL statements. The DB_CACHE_SIZE will also be a determining factor in how often these waits show up.hash_value and p. When they occur in conjunction with the appearance of the 'db file scattered read' and 'db file sequential read' in the Top 5 Wait Events section. but they're also memory hogs that could cause high wait numbers for sequential reads. These circumstances are usually interrelated. e. DB File Sequential Read. t. v$sql_plan p where t.hash_value. well-tuned system. t. examine the OS I/O statistics for .these scans are necessary and not the result of a suboptimal plan.options='FULL SCAN' order by p. and check join orders for multiple table joins.piece. You may tune the PGA AGGREGATE TARGET parameter to reduce waits on sequential reads. A large number of waits here could indicate poor joining orders of tables.. For Fast Full Index scans: select sql_text from v$sqltext t. but it can indicate problems in some circumstances. rebuilding the index will compact it and will produce to visit less blocks. first you should examine the SQL Ordered by Physical Reads section of the report.options='FULL' order by p. It is normal for this number to be large for a high-transaction.g. to determine whether there is a potential I/O bottleneck. It could be because the indexes are fragmented.hash_value=p.Starting with Oracle9i the new view V$SQL_PLAN view can help: For Full Table scans: select sql_text from v$sqltext t.e. You should correlate this wait statistic with other known issues within the Statspack report.hash_value. Then. i. This wait event will be generated while waiting for writes to TEMP space generally (direct loads. They can also show up as direct path read/write waits.operation='TABLE ACCESS' and p. one after each other.

There are also latch waits related to bugs. you may want to consider accelerating incremental checkpointing. If latch free waits are in the Top 5 Wait Events or high in the complete Wait Events list. you need to reduce the data density on the table driving this consistent read or increase the DB_CACHE_SIZE. you can address this by adding rollback segments. you should investigate the issue. using more DBWR processes. Free Buffer. To decrease waits in this area. increase the freelists on the table. To address this. buffer cache contention issues (cache buffers LRU chain). you should rebuild the index. it will post the database writer process asking it to flush dirty blocks. you can move data to another block to avoid this hot block. ITL). Most latch problems are related to the failure to use bind variables (library cache latch). Latches are low-level queuing mechanisms (they're accurately referred to as mutual exclusion mechanisms) used to protect shared memory structures in the system global area (SGA). 4. Waits in this category may indicate that you need to increase the DB_BUFFER_CACHE. If the wait is on a data block. If the wait is on an undo header. To investigate if this is an I/O problem. and hot blocks in the buffer cache (cache buffers chain). To prevent buffer busy waits related to data blocks.corresponding symptoms. This normally indicates that there is a substantial amount of DML (insert/update/delete) being done and that the Database Writer (DBWR) is not writing quickly enough. or use Locally Managed Tablespaces (LMTs). If the latch is not available. This typically happens during massive parallel inserts if your tables do not have free lists and it can happen if you have too few rollback segments. if all your SQL is ). When latch miss ratios are greater than 0. if it's on an undo block.5 percent. you can increase the initrans. check MetaLink for bug reports if you suspect this is the case (oracle. look at the statspack file I/O Statistics. Latches are used to prevent concurrent access to a shared memory structure." When a DML (insert/update/ delete) occurs. causing great inefficiency. or use a reverse key index. partition the index. If it's on an index block. Latch Free. or increasing the number of physical disks. increase the freelist groups or increase the pctused to pctfree gap. Free buffer waits could also indicate that unselective SQL is causing data to flood the buffer cache with index blocks. Buffer busy waits can be reduced by using reverse-key indexes for busy indexes and by partitioning busy tables 5. You can also increase the pctfree on the table where this block exists (this writes the ITL information up to the number specified by maxtrans. A buffer busy wait happens when multiple processes concurrently want to modify the same block in the buffer cache. Oracle Database writes information into the block. redo generation issues (redo allocation latch). . re-examine the host hardware for disk bottlenecks and check the host-hardware statistics for indications that a disk reconfiguration may be of benefit. I/O for sequential reads can be reduced by tuning SQL calls that result in full table scans and using the partitioning option for large tables. Buffer Busy Waits. Buffer busy waits should not be greater than 1 percent. Check the Buffer Wait Statistics section (or V$WAITSTAT) to find out if the wait is on a segment header. a latch free miss is recorded. leaving none for this particular statement that is waiting for the system to process. the buffer cache could be full of multiple versions of the same buffer. When a session needs a free buffer and cannot find one. Block reads are fairly inevitable so the aim should be to minimize unnecessary I/O. look at the latch-specific sections of the Statspack report to see which latches are contended for. Latches are like locks on memory that are very quickly obtained and released. If many I/O-related events appear high in the Wait Events list. 3. Also look at the average time per read in the Tablespace and File I/O sections of the report. which will create the space in the block to allow multiple ITL slots. when there are not enough slots built with the initrans that is specified). you can also use a smaller block size: fewer records fall within a single block in this case. so it's not as "hot. If this is the case. including all users who are "interested" in the state of the block (Interested Transaction List.

you need to commit/rollback to free the enqueue. 7..1 'Sessions Wait Forever for 'global cache cr request' Wait Event in OPS or RAC'. 9. a block-level lock could occur. 10. You might even consider using solid-state disks. Large wait times for this event can also be caused by having too few CPU resources available for the redolog writer process. All commit requests are waiting for "logfile switch (archiving needed)" or "logfile switch (chkpt. or try to preallocate extents or at least make the next extent larger for problematic dictionary-managed tablespaces. increase the size of the log files. This wait occurs because you are writing the log buffer faster than LGWR can write it to the redo logs. Log Buffer Space. The log file sync process must wait for this to successfully complete. An enqueue includes a queuing mechanism. when a select for update is executed. first out). TX4 enqueue waits are usually the result of one of three issues. DBWR may be too slow because of I/O. The third and most likely issue is when multiple users are updating the same block. I/O wait events would be the top wait events but since we are avoiding I/O's with RAC and OPS the 'global cache cr request' wait event often takes the place of I/O wait events. In some cases the 'global cache cr request' wait event may be perfectly normal if large buffer caches are used and the same data is being accessed concurrently on multiple instances. e. Note that Oracle's latching mechanism is not FIFO. and you may potentially need to add database writers if the DBWR is the problem. HW enqueues are used with the high-water mark of a segment. When a user commits or rolls back data. global cache cr request: (OPS) This wait event shows the amount of time that an instance has waited for a requested data block for a consistent read and the transferred block has not yet arrived at the requesting instance. If there are no free ITL slots. An enqueue is a lock that protects a shared resource. To reduce wait events here. the HW enqueue. Idle Event. or alternate redo logs on different physical disks. the LGWR flushes the session's redo from the log buffer to the redo logs. There are several idle wait events listed after the output. Incomplete). you can ignore them. you need to issue a commit or rollback to free the enqueue when multiple users are trying to update the same fragment. Don't use RAID 5. You can easily avoid this scenario by increasing the initrans and/or maxtrans to allow multiple ITL slots and/or by increasing the pctfree on the table. If you have foreign keys. Enqueue. such as data in a record. the TX4 enqueue. try to commit more records (try to commit a batch of 50 instead of one at a time. TX4s are the most common enqueue waits. Enqueue waits usually point to the ST enqueue. or because log switches are too slow. In a perfectly tuned. since it is very slow for applications that write a lot. You may need to add more or larger redo logs. Put redo logs on a faster disk. 11. Log File Sync. Locks protect shared resources.6. 8. and it will indicate if your actual problem is with the log file I/O. TM enqueues occur during DML to prevent DDL to the affected object. Idle events are listed in the stats$idle_event table. The associated event. Idle events are generally listed at the bottom of each section and include such things as SQL*Net message to/from client and other background-related timings. for their high speed. which is FIFO (first in. potentially consider using file system direct I/O or raw devices. to reduce the archiving effect on LGWR. Since a single bitmap fragment may contain multiple rowids. Use LMTs. or increase the size of the log buffer. be sure to index them to avoid this general locking issue. To address this problem. ‘log buffer parallel write’ is used by the redo log writer process. and the TM enqueue." Ensure that the archive disk is not full or slow. The ST enqueue is used for space management and allocation for dictionary-managed tablespaces. which are very fast at writing information. The second is multiple updates to the same bitmap index fragment. Finally.g. . manually allocating the extents can circumvent this wait. Log File Switch. The first issue is duplicates in a unique index. to prevent two people from updating the same data at the same time application. or get faster disks to write to. for example). See Note 157766. non-OPS/RAC database.

This is done during recovery operations or when buffer prefetching is being used as an optimization i. 13. CPU time is not really a wait event (hence. requires CPU cycles and interprocess IO. In a heavily loaded system. forcing the use of an index when a full scan should have been used). Retrieving more data than needed. Generally speaking. It actually is in the neighborhood of 67 times and actually almost . SQL ordered by Buffer Gets . 14. which could be the cause of the bottleneck. Log file parallel write waits can be reduced by moving log files to the faster disks and/or separate disks where there will be less contention. If you have DEFAULT parallelism on your object you can decrease the value of PARALLEL_THREADS_PER_CPU. library cache pin Library cache latch contention may be caused by not using bind variables. instead of performing multiple single-block reads. Hence the wait time depends on the time it takes the OS to complete all requests.e.12. DB File Parallel Read This Wait Event is used when Oracle performs in parallel reads from multiple datafiles to non-contiguous buffers in memory (PGA or Buffer Cache). Block accesses are also known as Buffer Gets and Logical I/Os. SQL Information Section The SQL that is stored in the shared pool SQL area (Library cache) is reported in this section in different ways: . SQL ordered by Executions . . If the system workload is high consider to decrease the degree of parallelism. 15. the cost of physical I/O is not 10. Maybe we could increase parallel_execution_message_size to try to eliminate some of these waits or we might decrease the degree of parallelism. Have in mind DEFAULT degree = PARALLEL_THREADS_PER_CPU * #CPU's 16. follow the same guidelines as 'db file sequential read'. Statspack lists such SQL statements in section SQL ordered by Gets. SQL ordered by Physical Reads . even from the buffer cache.Many DBAs feel that if the data is already contained within the buffer cache the query should be efficient. LGWR needs to wait for the last I/O to be on disk before the parallel write is considered complete. but rather the sum of the CPU used by this session. PX qref latch Can often mean that the Producers are producing data quicker than the Consumers can consume it. or the amount of CPU time used during the snapshot window.000 times more expensive. if the CPU time event is the biggest event. that could point to some CPU-intensive processing (for example. The wait occurs in log writer (LGWR) as part of normal activity of copying records from the REDO log buffer to the current online log.SQL ordered by Gets: This section reports the contents of the SQL area ordered by the number of buffer gets and can be used to identify the most CPU Heavy SQL. the new name). It is due to excessive parsing of sql statement. Waits for log file parallel writes can be identified by looking at the "Top 5 Timed Events" or "Wait Events" section of the Statspack report. Log File Parallel Writes. When CPU Other is a significant component of total Response Time the next step is to find the SQL statements that access the most blocks. This could not be further from the truth. SQL ordered by Parse Calls . Log file parallel write waits occur when waiting for writes of REDO records to the REDO log files to complete. Even though the writes may be issued in parallel. The actual wait time is the time taken for all the outstanding I/O requests to complete. If this wait is an important component of Wait Time.

SQL ordered by Executions: This section reports the contents of the SQL area ordered by the number of query executions. . large Clustering Factor in index etc. then execute the scrip to generate the execution plan. Remember the "Old Hash Value" from the report above (1279400914). index fragmentation.SQL ordered by Reads: This section reports the contents of the SQL area ordered by the number of reads from the data files and can be used to identify SQL causing IO bottlenecks which consume the following resources. .ora (100 is usually the suggested starting value). .cursor_sharing is set to exact (this should NOT be changed without considerable testing on the part of the client). See enhancement bug 1589185 for an explanation of the change that shifts some of the load from the library cache to the user session cache. It is primarily useful in identifying the most frequently used SQL within the database so that they can be monitored for if the data is stored in the UNIX buffer cache. . .SQL ordered by Parse Calls (9i Only): This section shows the number of times a statement was parsed as compared to the number of times it was executed.CPU time needed to fetch unnecessary data. . you may want to check the execution plan. .File IO resources to fetch unnecessary data. .ora parameter session_cached_cursors was not set in the init. . Possible reasons for high Reads per Exec are use of unselective indexes require large numbers of blocks to be fetched where such blocks are not cached well in the buffer cache.Bind variables are not being used.Additional CPU time to process the query once the data is retrieved into the buffer. in this example: 1279400914 SQL Text ~~~~~~~~ create table test as select * from all_objects .High buffer gets generally correlates with heavy CPU usage .The shared pool may be too small and the parse is not being retained long enough for multiple executions. a small performance increase on a frequently used query provides greater gains than a moderate performance increase on an infrequently used query. . Generally speaking. Generate Execution Plan for given SQL statement If you have identified one or more problematic SQL statement.sql Enter the Hash Value. One to one parse/executions may indicate that: . . sqlplus perfstat/perfstat SQL> @?/rdbms/admin/sprepsql.On RDBMS version 8172 and higher the init.The statements of interest are those with a large number of gets per execution especially if the number of executions is high.Buffer resources to hold unnecessary data.

Known Optimizer Plan(s) for this Old Hash Value ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Shows all known Optimizer Plans for this database instance. and so may not be indicative of current values -> Rows indicates Cardinality. Bytes and Cost .--------------. PHV is Plan Hash Value -> ordered by Plan Hash Value ------------------------------------------------------------The values for Rows. will appear multiple times if the cost has changed -> ordered by Snap Id First Snap Id First Snap Time Plan Hash Value 1386862634 52 Cost A Plan Hash Value --------.-----------.these values often change over time. and the Snap Id's they were first found in the shared pool.---------6 14 Nov 04 11:26 Plans in shared pool between Begin and End Snap Ids ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Shows the Execution Plans found in the shared pool between the begin and end snapshots specified. shown below are those which existed at the time the first-ever snapshot captured this plan .

1386862634 .------------------| Operation Rows | Bytes| Cost | | PHV/Object Name | ------------------------------------------------------------------------------|CREATE TABLE STATEMENT ----| | | VIEW 1K| | | | 1K| | 29 | | 3K| | 1 | | 1 | | 5 | | 1 | | 216K| | HASH JOIN 151K| 464 | 249K| 7 | | NESTED LOOPS 115 | 10 | 16 | |I_OBJAUTH1 |X$KZSRO | | 2 | INDEX RANGE SCAN FIXED TABLE FULL 38 | |USER$ |OBJ$ |IND$ |I_IND1 | | | | | | 2 | 35 | 2 | 1 | TABLE ACCESS FULL TABLE ACCESS FULL TABLE ACCESS BY INDEX ROWID INDEX UNIQUE SCAN 44 | | | | | | FILTER | | | | | | | 52 | | |LOAD AS SELECT |----.

5 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 65 | 26 | 26 | 26 | 26 | 26 | 26 | 26 | 26 | 26 | 26 | 26 | 26 | 26 | 14 | |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR | | | | | | | | | | | | | | 14 | 14 | 14 | 14 | 14 | 14 | 14 | 14 | 14 | 14 | 14 | 14 | 14 | FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL .

---------------.1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | | 1 | 26 | 26 | 26 | 26 | 26 | 26 | 26 | VIEW 13 | FAST DUAL | 14 | |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR |X$KZSPR | 2 | | 2 | | | | | | | | | 14 | 14 | 14 | 14 | 14 | 14 | FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL FIXED TABLE FULL ------------------------------------------------------------------------------- Instance Activity Stats Section The statistics section shows the overall database statistics.161 23. Instance Activity Stats for DB: PHS2 Instance: phs2 Snaps: 100 -104 Statistic Total per Second per Trans --------------------------------.4 . A list of the statistics maintained by the RDBMS kernel can be found in Appendix C of the Oracle Reference manual for the version being utilized.----------------------CPU used by this session 84. These are the statistics that the summary information is derived from.

2 DBWR free buffers found 0.. 196. the v$sql view contain a column.0.0 0.924. If most work done in PL/SQL is procedural processing (rather than executing SQL). unnecessary parting of implicit SQL statements can be avoided by increasing the cursor cache (MAXOPENCURSORS parameter) and by reusing cursors. that should be avoided by reusing SQL statements as much as possible. which directly shows the cpu time associated with executing the SQL statement. that is parsed often or is only executed once per parse. In programs using Oracle Call Interface.0 AND not using job_queue_processes AND CPU_PER_CALL = default) recursive cpu usage = This component can be high if large amounts of PL/SQL are being processed.825.0. CPU_TIME. finding the ones with the highest CPU load and optimize these.5 Of particular interest are the following statistics. The v$sql view contains PARSE_CALLS and EXECUTIONS columns.1 DBWR checkpoints 0. The formula to calculate the CPU usage breakdown is: Service (CPU) Time = other CPU + parse time CPU Other CPU = "CPU used by this session" .0.0 DBWR checkpoint buffers written 0. PARSE TIME CPU or RECURSIVE CPU USAGE: These numbers are useful to diagnose CPU saturation on the system (usually a query tuning issue). In precompiler programs. It can generally be assumed. It is outside the scope of this document to go into detail with this. In your statspack report. but you will need to identify your complete set of PL/SQL.3.1.1 11.1. you should identify and sort SQL statements by buffer gets in v$sql. parse time cpu= Parsing SQL statements is a heavy operation.CPU USED BY THIS SESSION.8 CR blocks created 0.1) = 8. . In Oracle9i. that the CPU time spent by a SQL statement is approximately proportional to the number of buffer gets for that SQL statements.2 DBWR buffers scanned 0.2 and 9. The rule to decide if you can use these metrics is: Trustworthy if : (db version>= 8.5 DBWR cross instance writes 0. Start tuning SQL statements from the top of this list.2 32.0 0.0 ..1) OR ((db version >= 9.0 1. . so that it reexecutes (in stead of reparse) cursors with frequently executed SQL statements.6.parse time CPU Some releases do not correctly store this data and can show huge numbers. look at the part ‘SQL ordered by Gets for DB’..7. other cpu= The source of other cpu is primarily handling of buffers in the buffer cache.346 709 0 245 33 93 0 54.0 4. including stored procedures. you need to write the code. hence.5 CPU used when call started 8. a high recursive cpu usage can actually indicate a potential tuning effort. that can be used to identify SQL.

You may also need to tweak optimizer_index_caching and optimizer_index_cost_adj. In general if recursive calls is greater than 30 per process.e. The difference between this and "dirty buffers inspected" is the number of buffers that could not be used because they were busy or needed to be written after rapid aging out. check the db_file_multiblock_read_count parameter setting. to be able to write a database buffer.Table Scans (long tables) is the total number of full table scans performed on tables with more than 5 database blocks. when foreground is looking for a buffer to reuse. In some cases (i. should be eliminated by rebuilding the table.REDO WASTAGE: Number of bytes "wasted" because redo blocks needed to be written before they are completely full.REDO BUFFER ALLOCATION RETRIES: total number of retries necessary to allocate space in the redo buffer. or to switch logs . but the ANALYZE table command should be used to further investigate the chaining. the performance of normal database operations improve but recovery after instance failure is slower. .DBWR CHECKPOINTS: the number of checkpoints messages that were sent to DBWR and not necessarily the total number of actual checkpoints that took place. or being read/written. (divide by write requests to get average queue length after write completion) . . a waiter.ora parameter LOG_BUFFER so that zero Redo Log Space Requests are made. These are the times that DBWR looked for buffers to idle write. tables with long columns) this is unavoidable. This includes rows that were accessed using an index and rows that were accessed using the statement where rowid = 'xxxxxxxx. .RECURSIVE CALLS: Recursive calls occur because of cache misses and segment extension.FREE BUFFER INSPECTED: the number of buffers skipped over from the end of the LRU queue in order to find a free buffer.SUMMED DIRTY QUEUE LENGTH: the sum of the lruw queue length after every write request completes.Table Scans (short tables) is the number of full table scans performed on tables with less than 5 . . . and where possible. Try increasing the init. This should be zero if DBWR is keeping up with foregrounds. During a checkpoint there is a slight decrease in performance since data blocks are being written to disk and that causes I/O. Note that this includes scans for reasons other than make free buffer requests. Segments include tables. . . the data dictionary cache should be optimized and segments should be rebuilt with storage clauses that have few large extents. If the number of full table scans is high the application should be tuned to effectively use Oracle indexes.REDO LOG SPACE REQUESTS: indicates how many times a user process waited for space in the redo log buffer.DBWR BUFFERS SCANNED: the number of buffers looked at when scanning the lru portion of the buffer cache for dirty buffers to make clean. They may have a user. Early writing may be needed to commit transactions. should be used on long tables if less than 10-20% (depending on parameter settings and CPU count) of the rows from the table are returned.xxxx'.. NOTE: PL/SQL can generate extra recursive calls which may be unavoidable.TABLE FETCH BY CONTINUED ROW: indicates the number of rows that are chained to another block. Divide by "dbwr lru scans" to find the average number of buffers scanned. Retries are needed because either the redo writer has gotten behind. or because an event (such as log switch) is occurring . indexes.xxxx.DBWR TIMEOUTS: the number of timeouts when DBWR had been idle since the last timeout. if they exist. and temporary segments. The average buffers scanned may be different from the average scan depth due to write batches filling up before a scan is complete. . Indexes. If this is not the case. . rollback segment. This count includes both dirty and clean buffers. .DIRTY BUFFERS INSPECTED: the number of times a foreground encountered a dirty buffer which had aged out through the lru queue. If the number of checkpoints is reduced. It may be too high.TABLE FETCH BY ROWID: the number of rows that were accessed by a rowid.

it is due to data block contention with large average wait times.Avg. Blocks / Read .database blocks.Buffer Wait Statistics: This section shows a breakdown of each type of object waited for. A baseline of the database's buffer pool statistics should be available to compare with the current statspack buffer pool statistics. This section follows the Instance Recovery Stats for DB.The queries against the contents of the owning tablespace should be examined and tuned so that less data is retrieved. . . Buffer Waits / Milisecond Note that Oracle considers average read times of greater than 20 ms unacceptable.File I/O Stats for DB: Ordered alphabetically by tablespace.The contents of that datafile should be redistributed across several disks/logical volumes to more easily accommodate the load. A change in that pattern unaccounted for by a change in workload should be a cause for concern. If the statistic "Buffer Waits" for a tablespace is greater than 1000.---------.Buffer Waits .Buffer Pool Statistics: This section can have multiple entries if multiple buffer pools are allocated.1. Buffer wait Statistics for DB: PHS2 Instance: phs2 -> ordered by wait time desc.Tablespace I/O Stats for DB: Ordered by total IO per tablespace. Also check the Buffer Pool Advisory to identify if increasing that parameter (db_cache_size) would help to reduce Physical Reads. . Read / Second . If a datafile consistently has average read times of 20 ms or greater then: . like the example below: Buffer wait Statistics for DB: GLOVP Instance: glovp Snaps: 454 .7 many other columns were included as follow: .Avg.Avg. check the disk controller layout. . less IO.If the tablespace contains indexes. It is optimal to perform full table scans on short tables rather than using indexes. In Oracle 8. Typically. Buffer cache Activity Information The buffer statistics are comprised of two sections: . It may be that the datafiles need to be distributed across more disk sets. when there is buffer contention. another option is to compress the indexes so that they require less space and hence. Writes / Second .455 .--------undo header 42 21 1 data block 18 6 0 Snaps: 100 -104 The above shows no real contention. . Tablespace I/O Stats Section IO Activity Input/Output (IO) statistics for the instance are listed in the following sections/formats: . you may want to consider tablespace reorganization in order to spread tables within it across another tablespaces. filename.Avg.If the disk layout seems optimal. waits desc Tot Wait Avg Class Waits Time (cs) Time (cs) -----------------.----------.

401 0 3 2.ST (Space management enqueue): Usually caused by too much space management occurring.--------data block 9.698 17. The most common lock waits are generally for: .478 TX 13. update. This lock/enqueue is acquired when performing an insert.270 44.----------. .93 0 JD 165.560 165.097 2 undo block 210 1.19 13 US 4.547 418.717 5. This section is particularly useful when monitoring session memory usage on Windows servers Enqueue Activity An enqueue is simply a locking mechanism. This section is very useful and must be used when the wait event "enqueue" is listed in the "Top 5 timed events".809 0 4.354 69.547 0 1.64 2 CI 67.072. It is used mainly as a queuing mechanism so that other resources can wait for a transaction to complete.845 619.494 0 33. The TX lock is acquired when a transaction initiates its first change and is held until the transaction does a COMMIT or ROLLBACK.912 4. For example: create table as select on large tables on busy instances. small extent sizes.325 8.355 4.912 0 282 45.-----------TC 44.251 15. particularly if foreign key constraints have not been indexed.10 19 PS 5.Tot Wait Avg Class Waits Time (cs) Time (cs) -----------------. Enqueue activity for DB: S901 Instance: S901 Snaps: 2 -3 -> Enqueue stats gathered prior to 9i should not be compared with 9i data -> ordered by waits desc.00 0 HW 56.532.189.37 5.----------. .864 13.TM (DML enqueue): Generally due to application issues.----------. or delete on a parent or child table. lots of sorting.532.---------.060 67.225 6 segment header 259 367 1 undo header 259 366 1 file header block 24 1 33 system undo header 1 0 0 Instance Recovery Statistics This section was added in 9i and is useful for monitoring the recovery and redo information PGA Memory Statistics This section was added in 9i and helps when using the new model to allocate PGA in Oracle9i using PGA_AGGREGATE_TARGET.401 56.518 641. Waits desc Avg Wt Wait Eq Requests Succ Gets Failed Gets Waits Time (ms) Time (s) -. .16 13 PR 8.325 0 11 213.072.78 159 SQ 418.950.67 0 The action to take depends on the lock type that is causing the most problems.270 0 8.-----------.-----------.899 CU 5.TX (Transaction Lock): Generally due to application concurrency mechanisms.381 .560 0 1 261.494 5. etc.060 0 15 18. or table setup issues.72 2.------------.366 761.

Undo Segment Stats The examples below show typical performance problem related to Undo (rollback) segments: . It should be noted that 9i introduces an optional init.Undo Segment Summary .-------.unexpired Stolen. This parameter.expired Released.-------.unexpired reUsed -> eS .-------------.------. Should the client encounter SMU problems. several sortings occurring on the disk).756 8 12 0 0 0/0/0/0/0/0 12-Mar 16:01 1.unexpired Released. so the retention period should not be arbitrarily set too high. .964 8 12 0 0 0/0/0/0/0/0 The description of the view V$UNDOSTAT in the Oracle9i Database Reference guide provides some insight as to the columns definitions.561 208 3 12 0 0 0/0/0/0/0/0 This section provides a more detailed look at the statistics in the previous section by listing the information as it appears in each snapshot. monitoring this view every few minutes would provide more useful information.Undo Segment Summary for DB Undo Segment Summary for DB: S901 Instance: S901 Snaps: 2 -3 -> Undo segment block stats: -> uS .These enqueues are caused if a lot of space management activity is occurring on the database (such as small extent size.expired Stolen. . Undo Segment Information Undo information is provided in the following sections: .---------.-------. The UNDO tablespace still must be sized appropriately. is defined universally for all undo segments. Use of UNDO_RETENTION can potentially increase the size of the undo segment for a given period of time. eR .ora parameter called UNDO_RETENTION which allows the DBA to specify how long the system will attempt to retain undo information for a committed transaction without being overwritten or recaptured. uU . uR .expired reUsed Undo Undo Num Max Qry Max Tx Snapshot Out of uS/uR/uU/ TS# Blocks Trans Len (s) Concurcy Too Old Space eS/eR/eU ---.284 1. eU . based in units of wall-clock seconds.------.-----------------1 20. The following calculation can be used to determine how much space a given undo segment will consume given a set value of UNDO_RETENTION.Undo Segment Stats for DB Undo Segment Stats for DB: S901 -> ordered by Time desc Instance: S901 Snaps: 2 -3 Undo Num Max Qry Max Tx Snap Out of uS/uR/uU/ End Time Blocks Trans Len (s) Concy Too Old Space eS/eR/eU -----------.-----------.-------.-----------------12-Mar 16:11 18.723 1.---------.

in particular during hard parse. Using the X$BH fixed table can identify if some hash chains have many buffers associated with them. On versions 8. shared pool= The shared pool latch is heavily used during parsing. the more common latches to watch are: cache buffer chain= The cache buffer chain latch protects the hash chain of cache buffers.1. you will have high contention on this latch. When the retention period has expired. Latch contention is indicated by a Pct Miss of greater than 1. done by scanning each transaction table for undo timestamps and deleting the information from the undo segment extent map. an UNDO_RETENTION of 5 minutes (default) with 50 undo blocks/second (8k blocksize) will generate: Undo Segment Space Required = (300 seconds * 50 blocks/ seconds * 8K/block) = 120 M The retention information (transaction commit time) is stored in every transaction table block and each extent map block.1 'Understanding and Tuning the Shared Pool for an excellent discussion of this topic. Latch Sleep breakdown . If you have high contention for this latch. This section is particularly useful for determining latch contention on an instance. such as an index root block. library cache= The library cache latch is heavily used during both hard and soft parsing. See Note 62143. you can set the cursor_sharing parameter in init.0% or a relatively high value in Avg Sleeps/Miss. If your application is written so that it generally uses literals in stead of bind variables. Only during extreme space constraint issues will retention period not be obeyed. Applications that are coded to only parse once per cursor and execute multiple times will almost completely avoid contention for the shared pool latch. Latch Information Latch information is provided in the following three sections: .ora to the value ‘force’ provides some reduction in the library cache latch needs for hard parses. • • Literal SQL is being used. Latch contention generally indicates resource contention and supports indications of it in other sections. Latch Miss Sources This information should be checked whenever the "latch free" wait event or other latch wait events experience long waits. In Oracle9i. this is a shared latch. session_cached_cursors might need to be set. While each latch can indicate contention on some resource. Contention for this latch can often only be reduced by reducing the amount of access to cache buffers. SMON will be signaled to perform undo reclaims. which can be . Contention on this latch confirms a hot block issue. There is minor contention for this latch involved in executing SQL statements.6 and later. your application should be modified to avoid parsing if at all possible. Contention on this latch in conjunction with reloads in the SQL Area of the library cache section indicates that the shared pool is too small. and is used for each access to cache buffers.1. Latch Activity .2 and higher. and setting the session_cached_cursors sufficiently high provides some reduction in the library cache latch needs for repeated soft parsing within a single session.Undo Segment Space Required = (undo_retention_time * undo_blocks_per_seconds) As an example. See enhancement bug 1589185 for details. a single hot block.ora to the value ‘force’ to reduce the hard parsing and reduce some of the contention for the shared pool latch. Setting the cursor_sharing parameter in init. can cause contention for this latch. In release 8. Often. which minimizes contention for blocks being read only.7.

6 0 0 INDEX 14.-----------.0 310.190. the cursor_sharing parameter can be used to completely avoid the row cache latch lookup during parsing. and Rows Processed Instance Activity Statistics Compare with baseline report. (No longer available in 9i. if the application is properly written to parse statements once and execute multiple times. row cache= The row cache latch protects the data dictionary information.0 0 0 CLUSTER 1.089.-----.---------.602 0.-------BODY 310. Library Cache Activity for DB: S901 Instance: S901 Snaps: 2 -3 ->"Pct Misses" should be very low Get Pct Pin Pct InvaliNamespace Requests Miss Requests Miss Reloads dations --------------.reduced further by setting cursor_space_for_time=true. To confirm this.1. PGA Aggr Section Shared Pool Advisory Section Use this section to evaluate your shared pool size parameter.007 0.0 91.3 1. drill down to specific problems Figure out which SQL statements to tune SQL Ordered by Buffer Gets.) Values in Invalidations in the SQL Area indicate that a table definition changed while a query was being run against it or a PL/SQL package being used was recompiled.713 0. A guide to the detail sections of the Statspack report Section(s) Wait Events What You Can Use the Section(s) for Look for excessive waits and wait times.591 0. In release 8. cache buffer lru chain= The buffer cache has a set of chains of LRU block. compute additional statistics .880 0.0 2 0 Values in Pct Misses or Reloads in the SQL Area. consistent values (not sporadic) in Pct Misses or Reloads in the Index row indicate that the buffer cache is too small. Tables/Procedures or Trigger rows indicate that the shared pool may be too small.592 1.-------------. Physical Reads.2 17.184.809 0. During hard parsing.355 38.3 0 0 SQL AREA 14.9 5.421 TABLE/PROCEDURE 46. Contention for this latch can often be reduced by increasing the db_block_lru_latches parameter or by reducing the amount of access to cachebuffers.6 and above.843.204 0.0 825 0 TRIGGER 148.009 0.-----.879 0. each protected by one of these latches. this latch is used extensively.1 313.902 0.809 0.0 148. such as information about tables and columns. Library Cache Statistics This section of the report shows information about the different sub-areas activity in the library cache.793.

identify files and tablespaces with heavy I/O Identify specific buffer pools with high contention or I/O Identify types of buffers with large number of buffer waits Investigate specific lock types that are causing the most waits Investigate waits for rollback segment headers Identify latching bottlenecks. tune the code.Tablespace and File I/O Investigate I/O bottlenecks. diagnose and related problems Buffer Pool Buffer Wait Statistics Enqueue Activity Rollback Segment Statistics and Storage Latch Activity. DB File parallel read Free Buffer Buffer Busy Buffer Busy . Data block: separate "hot" data. Similar to db file sequential read Increase the DB_CACHE_SIZE. shorten the checkpoint.ora Diagnose problems with shared pool Look for unnecessary or problematic parameter definitions Wait Events Quick Reference Guide Wait Problem DB File Scattered Read DB File Sequential Read Potential Fix Wait for Multi-block read of a table or index (full scan): tune the code and/or cache small tables. Wait for single block read of a table or index. Latch Miss Sources Library Cache Non-default init. Latch Sleep Breakdown. Indicates many index reads: tune the code (especially joins). Used when Oracle performs in parallel reads from multiple datafiles to noncontiguous buffers in memory (PGA or Buffer Cache). use reverse key indexes and/or smaller blocks. Segment header: add freelists or freelist groups.

Log Buffer Space Increase the log buffer.Buffer Busy Buffer Busy Buffer Busy Latch Free Enqueue-ST Enqueue-HW Enqueue-TX4 Enqueue-TM Data block: increase initrans and/or maxtrans. use faster redo log disks or raw devices. Log File Switch Log File Sync Archive destination slow or full. add more or larger redo logs. check application locking of tables. Undo header: add rollback segments or areas. use larger rollback segments or areas. Preallocate extents above high-water mark. Index foreign keys. Direct Path Read Used by Oracle when reading directly into PGA (sort or hash) Direct Path Write Used by Oracle when writing directly into PGA (sort or hash) Idle Event Ignore it. Investigate the latch detail. Common Idle Events Event Dispatcher timer Lock manager wait for remote message Pipe get Idle Event Type Shared server Oracle9i Real Application Clusters User process . Use LMTs or preallocate large extents. Undo block: commit more often. Increase initrans and/or maxtrans on the table or index. Commit more records at a time. use faster disks for the redo logs.

html spReporter 1.shtml .com/ http://www.htm Good Links with more Information http://jonathanlewis.softpedia.statspackanalyzer.0.30 http://www.pmon timer PX Idle wait PX Deq Credit: need buffer PX Deq Credit: send blkd rdbms ipc message smon timer SQL*Net message from client virtual Circuit status Background process Parallel query Parallel query Parallel query Background process Background process User process Shared server Web tools to analyze Reports

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.