Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
analyzing statspack report good oracle 9i

analyzing statspack report good oracle 9i



|Views: 8,716|Likes:
Published by arun
good document on statspack analyzing in oracle 9i
good document on statspack analyzing in oracle 9i

More info:

Published by: arun on Apr 21, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less





http://www.pafumi.net/Statspack_Analysis.htmlAnalyzing a Statspack Report
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 problemon 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
is false, wait events are ordered by the number of waits. Thisinformation may indicate which events are of interest, however it may be misleading. An event may bewaited for a large number of times, however the wait time (if it were available for comparison) mayshow 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, andcomparing it to the elapsed time between snapshots. For example, if the wait event accounts for only 30seconds 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 worthinvestigating. There is a warning here, too: even an event which had a wait of 30 minutes in a 45minute snapshot may not be indicative of a problem, when you take into account there were 2000 userson 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 tocross-verify the computed statistic with the actual statistic counts. This acts as a sanity check todetermine 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 duringthe Statspack interval, the soft-parse ratio would be 50%, even though the statistic counts show this isnot an area of concern.
LEVEL 0 - GENERAL PERFORMANCEThis 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 whenStatspack is installed.LEVEL 6 - GENERAL PERFORMANCE + SQL STATEMENTS + SQL PLANS AND SQL PLANUSAGEThis level is new in Oracle9i and it will include all the information collected from the previoussnapshot levels, plus execution path and plan usage information as they relate to high resource SQLstatements. This type of information can prove critical when determining if the execution path or planhas changed for high resource SQL statements. Oracle recommends using this level for when one of thefollowing 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 PLANUSAGE + PARENT AND CHILD LATCHESThis 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 andchild latch information are added to the duration of the previous 2 levels, which are already informationgathering intensive. First, because the information gathered is based on the shared_pool_size andsecondly the volume of information gathered based on SQL statement information, plus the parent andchild latch information. Snapshots taken from this level will take even longer and it is Oracle'srecommendation to only use this level when requested by Oracle technical support personnel.LEVEL SETTING RECOMMENDATIONIt is recommended to set the timed_statistics to true BEFORE the first snapshot because it will help toestablish 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 SNAPSHOTStatspack also provides the capability to gather session specific information. Passing the i_session_idvalue 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 a snapshot interactively can be as easy as accessing SQL*Plus as the PERFSTAT user andusing the SNAPSHOT.SNAP command or automating when a snapshot is executed. The interactivemethod 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 problemis reported at a later time and a comparison needs to be made between two specific times that occurredin the past.
INTERACTIVE METHODAccess SQL*Plus as the PERFSTAT user and execute either method 1, 2 or 3 as discussed in the abovesnapshot Configuration section. The simplest form of the interactive mode is as follows:SQL> EXECUTE STATSPACK.SNAPAUTOMATED METHODThe 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 performanceinformation 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 thenscheduled through the CRON scheduler. For NT, the AT scheduler in combination with .cmd files.
The DBMS_JOB utility provides a way to schedule database related tasks that are controlled within thedatabase. Through the DBMS_JOB utility snapshots can be taken at a scheduled interval. When thespcpkg.sql script was executed as part of the Statspack installation, the DBMS_JOB package wascreated for the PERFSTAT user. One of the requirements to use the DBMS_JOB utility is that theinit.ora parameter job_queue_processes must be set to a value greater than 0. The spauto.sql script isdesigned to setup the automation of executing snapshots once every hour. The following line from thescript 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 generatereports on a routine basis and check the Load Profile for changes in throughput (shown by the per-second statistics) and changes in application characteristics (shown by the per-transaction statistics). Inreactive 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 runningcomparable 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 bevalid.If you are not comparing two reports, it's still a good idea to scan the Load Profile for any rates thatseem 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 beaccompanied by latch contention, so you would expect to see latch free waits in the Top 5 Wait Eventsor high in the complete Wait Events list.
Load Profile~~~~~~~~~~~~ Per Second PerTransaction---------------

Activity (89)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Chen Jason liked this
mtorrico liked this
Hanse69 liked this
mkghai liked this
bprasadreddyin liked this
mkghai liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->