AWR Analysis

Hi,
My AWR report shows the following
Event Waits Time (s) (ms) Time Wait Class
db file sequential read 43,458,904 101,129 2 12.3 User I/O
db file scattered read 1,632,813 36,253 22 4.4 User I/O
That is "db file sequential read" is having a larger value is there a problem in disk I/O performance.

That is "db file sequential read" is having alarger
value is there a problem in disk I/O performance.Not necessarily. It's more likely the problem is
with the sql being issued... that's if it's a problem
at all.
What kind of system is it oltp/warehouse?
Are users complaining it's slow?
Is the report from a snapshot of an
hour/day/week/month?
There's always going to be a top 5 wait events, so it
doesn't necessarily mean there's an issue.
More info required.My database is is ORACLE10 R2 used for datawarehousing.
Mostly the reports take hours to execute also data uploading is slow.
It is running on Sun Microsystems Inc. SunOS 5.10

Similar Messages

AWR analysing tool.

Hello,
We are using Oracle 11g in windows 2008 environment.
I am trying to analyze the AWR report and this report contains so many statistic.
Is there any tool or document available which can help me in analysis.
Thanks
With Regards
Hemant.

Interpreting AWR is largely the same as interpreting Statspack.
There are a number of online resources that might help you.
Here's a good starting point:
http://jonathanlewis.wordpress.com/statspack-examples/
There are also a number of websites that can analyze the reports for you
e.g. http://www.oraperf.com/

I am developing an AWR analysis tool...

Hi,
I am looking for help with Beta testing a tool that I am developing to analyze Oracle AWR reports (HTML format), produce graphs to assist in finding trends and correlations between the data.
What I can offer is if you can send 2 or more AWR HTML reports (from the same system, up to 24 of them) I will return a HTML report which graphs the key metrics (Instance Summary, Instant Efficiency, Wait Events, Top SQL by (CPU, Wait Time, Elapsed Time), Instance Activity Stats (with correlations against User Calls and DB Calls). There is a caveat to this – the code is in beta, if the tool cannot process the exact format I will work to fix it so that I can generate the report, but I cannot promise any particular time line on this (it may be days or weeks) as I am using my spare time to develop this. My main focus at the moment is on the parsing of the reports, rather than the prettiness of the graphs.
This service is currently provided with no warranty at all, you MUST review all data yourself against your own data, in sending me the reports you release me from any obligations or legal commitments (if you rely solely on this and your nuclear reactor melts down – do not try to blame me!).
{If you can send me one AWR HTML report, I will use it just to improve my parsing, and you will receive my thanks.}
“This all seems a bit suspicious - who is this guy, why is he not even telling me his real name?” Well I guess I probably would be wondering a little about this also. So let me tell you a little about myself. I used to do Oracle performance tuning professionally and it was all I did for more than ten years. During that time I worked on some of Oracles largest OLTP and data warehouse systems. Then I joined a startup company working in a completely different field, and while I now have a nice management job I really miss the performance work. We do have some customers using our software on large Oracle clusters and occasionally I would get a call from Support to help work out what was going wrong on a customers site. This usually meant getting 10+ awr reports emailed to me and having to spend some time wading through them looking for trends, which lead me to become convinced that 1. there must be a better way of reading the reports and 2. I am sure I am not the only one who has to figure out what's going on on a system to which the only connection is a HTML AWR report. So I went away and did some dev and reached a minimally viable product that is ready for someone other than its “daddy” (who thinks the world of it) to either love it or tell me its ugly.
Some of you will be concerned about leaking information (instance names, host names, ip addresses, database structure from SQL (and even real data if your not using bind variables)). So if I get enough people saying “I like the idea of the tool, but I am scared your looking to hack my system” then I will produce (and open source, so you can inspect it) a tool to strip out anything that is likely to be dangerous prior to sending it to me.
Regards,
AWR Reader.

>
I'm afraid what you are trying to do has already been done.
>
ASH is not AWR - it is a subset of AWR
Performance Tuning Guide
http://docs.oracle.com/cd/B28359_01/server.111/b28274/autostat.htm#i27008
>
The statistics collected and processed by AWR include:
•Object statistics that determine both access and usage statistics of database segments
•Time model statistics based on time usage for activities, displayed in the V$SYS_TIME_MODEL and V$SESS_TIME_MODEL views
•Some of the system and session statistics collected in the V$SYSSTAT and V$SESSTAT views
•SQL statements that are producing the highest load on the system, based on criteria such as elapsed time and CPU time
•Active Session History (ASH) statistics, representing the history of recent sessions activity

AWR analysis for sql

Hi Gurus,
db: 10.2.0.4
Please find below an extract from awr report.
SQL ordered by Gets DB/Inst: DBPL0A1/dbpl0a12 Snaps: 32720-32721
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> Total Buffer Gets: 18,026,853
-> Captured SQL account for 35.3% of Total
Buffer Gets Executions Gets per Exec %Total CPU Time (s) Elapsed Time (s) SQL Id
17,640,376 0 N/A 97.9 446.91 1930.96 5nyjrk49p9vbd
Please let me know if this sql would have affected the performance.
The number of executions is "zero" compared to Big number of "Buffer Gets" = 17,640,376. Please let me know.
Also let me know if further information is required.
Thanks.
Edited by: user12582934 on Mar 2, 2010 6:24 PM
Edited by: user12582934 on Mar 2, 2010 6:28 PM

Did you ever receive an answer to your question?
I am running some SQL from within a PL/SQL Stored Procedure. I am building the statement and then doing an EXECUTE IMMEDIATE from within the stored procedure. Here is the basic code:
sql_stmt varchar2(2000);
sql_stmt := 'ALTER index '||v_index_name||' REBUILD PARALLEL';
EXECUTE IMMEDIATE sql_stmt;
This routine is called 3 times, each time with a different value for v_index_name. I see a separate statement within the AWR Report for all 3 calls. However, “Executions” is always Zero. The SQL shows in the “SQL ordered by Elapsed Time”, “SQL ordered by CPU Time”, “SQL ordered by Reads” (where “Reads per Exec” is blank/null).
The call to the PL/SQL Stored Procedure shows in the “SQL ordered by Gets” and “SQL ordered by Reads” and in each places, shows it was executed 3 times.
The call is being made and completing within the AWR Snapshot.
So, why is Executions equal to zero and Reads per Exec blank? Is it because it is being called within a PL/SQL Stored Procedure?

STATSPACK ANALYSIS TOOL

hi guys,
I need to analysis my statspack report of my own. Is there any free tool provided to analyse the report of my own.
TIA,

Hi,
You could take a look at a great set of statspack and AWR analysis tools here http://www.statsviewer.netfirms.com/
Cheers

Statspack Best Practices

Hello Everyone:
Common sense tells me that (within reason) statspack snapshots should be run fairly frequently. I have a set of users who is challenging that notion, saying that Statspack is spiking the system and slowing them down, and so they want me to only take snapshots every 12 hours.
I remember seeing a document (I thought it was on MetaLink, but I dunno...) that spoke of best practices for Statspack snapshots. My customers want to limit me to one snapshot every 12 hours, and I contend that I might as well not run it with that window.
Can someone point me to some best practice or other documentation that will support my contentions that:
1) Statspack is NOT a resource hog, and
2) twice-a-day is not going to provide meaningful data.
Thanks,
Mike
P.S. If I'm all wet, and you know it, I'd like to see that documentation, too!

Hi Mike,
saying that Statspack is spiking the system and slowing them downI wrote both of the Oracle Press STATSPACK books and I've NEVER seen STATSPACK cause a burden. Remember a "snapshot" is a simple dump of the X$ memory structures into tables, very fast . . .
they want me to only take snapshots every 12 hours.Why bother? STATSPACK and AWR reports are elapsed-time reports, and long-term reports are seldom useful . . . .
An important thing to remember is that even if statistics are gathered too frequently with STATSPACK, reporting can always be done on a larger time window. For example, if snapshots are at five-minute intervals and there is a report that takes 30 minutes to run, that report may or may not be slow during any given five-minute period.
After looking at the five-minute windows, the DBA can decide to look at a 30-minute window and then run a report that spans six individual five-minute windows. The moral of the story is to err on the side of sampling too often rather than not often enough.
I have over 600 pages dedicated to STATSPACK and AWR analysis at the link below, if you want a super-detailed explaination:
http://www.rampant-books.com/book_2005_1_awr_proactive_tuning.htm
I'm not as authoritative as the documentation, but even hourly snapshot durations can cause loss of performance details.
Ah, this Oracle Best Practices document may help:
http://www.oracle.com/technology/products/manageability/database/pdf/ow05/PS_S998_273998_106-1_FIN_v1.pdf
By default, every hour a snapshot of all workload andstatistics information is taken and stored in the AWR. The data is retained for 7 days by default and both snapshot interval and retention settings are userconfigurable."
Hope this helps. . .
Donald K. Burleson
Oracle Press author

Performance reports and measures for Online Trading Customer's databases

We have a client from online trading commodity domain. there databases are running in healthy stat.
We on daily basis share with them AWR report of time span 9:30AM to 10:30AM (peak trading hours).
can you suggest what all recommendadtions we can include in this AWR report or how we can study on daily basis this AWR report extracted to mention recommendation to customer.
apart from this what other performance reports we can share with customer which will make cilent view their database stat in terms of performace tunning and all.
We can share daily database checks and all but I am trying to have some good performance end reports which can be extract to share with client??
What performace reports you are sharing or can suggest in this regards??
Thanks friends in advance.

Hi
Ankit Ashok Aggarwal wrote:
We have a client from online trading commodity domain. there databases are running in healthy stat.
We on daily basis share with them AWR report of time span 9:30AM to 10:30AM (peak trading hours). I have written a few blog posts about AWR analysis (http://savvinov.com/category/awr/) -- some of them may be useful to you. However, AWR reports are not so good for monitoring purposes. Monitoring is about trends -- AWR doesn't have that. Plus, application performance should be measured in its native metrics (KPIs or "key performance indicator"). For instance, for an online shop that would be the number of orders processed, average time it takes to process an order etc. Low level stats such as the number of table scans per unit time or IO stats doesn't really tell whether or not an application is performing satisfactorily.
From the database point of view, a simple overview of the OEM Performance Page should be enough to get a basic idea whether the database is ok.
can you suggest what all recommendadtions we can include in this AWR report or how we can study on daily basis this AWR report extracted to mention recommendation to customer.I've seen a lot of such recommendations -- 99% of them are garbage, and the customers treat it accordingly. Unless there are clear signs of a performance issue, recommendations are generally neither necessary, nor possible (without additional information about the application). Ain't broken -- don't fix it.
apart from this what other performance reports we can share with customer which will make cilent view their database stat in terms of performace tunning and all.
We can share daily database checks and all but I am trying to have some good performance end reports which can be extract to share with client??Ideally, you should have SLAs with your customers which should clearly define how much time a certain user action should take. Without an SLA and/or specific complaints from the user there is little you can do about database performance, except for when something obvious shows up on the report.
Best regards,
Nikolay

Db sequential read on undo

Hi,
I am using Oracle 11g 11.1.0.7 and seeing many long runners are having db sequential reads from undo. Kindly let me the way to further tracking of such sessions and which objects are involved in read from undo space.
Appreciate the quick reply.

Thanks for your reply.
O/S: 23 - Oracle Solaris on SPARC (64-bit)
Version: 10
RDBMS Ver: 11.1.0.7.3
We have a 3 node M9000-Solaris10 RAC cluster running Oracle 11gR1.
The long running request trace files have the db file sequential reads from the object undo segments. We suspect because of the high db file sequential reads from undo making the request to run long.
Kindly let me know what portion of the AWR analysis will help me in this analysis.
Edited by: 912103 on Feb 5, 2012 9:58 PM
Edited by: 912103 on Feb 5, 2012 10:15 PM

How to do Detailed AWR Report Analysis

Hi,
Please let me Know how to do analysis AWR report and get it corrected.

The best way to isolate the bottlenecks in Oracle is to analyze the top five wait events for the database and look for any external waits that might be associated with disk, CPU and network.
Oracle provide two scripts to produce workload repository reports (awrrpt.sql and awrrpti.sql). They are similar in format to the statspack reports and give the option of HTML or plain text formats. The two reports give essential the same output but the awrrpti.sql allows you to select a single instance. The reports can be generated as follows.
@$ORACLE_HOME/rdbms/admin/awrrpt.sql
@$ORACLE_HOME/rdbms/admin/awrrpti.sql
The scripts prompt you to enter the report format (html or text), the start snapshot id, the end snapshot id and the report filename. The resulting report can be opend in a browser or text editor accordingly.
http://www.oracle-base.com/articles/10g/automatic-workload-repository-10g.php

Reg:Tkprof, awr, explain plan, autotrace analysis

hi friends.
can any one give description about below subject..........
Tkprof,
awr,
explain plan,
autotrace analysis
if possible kindly mentioned some example for each OR provide some to read.
regards,
Rajnish

They're all described in the Oracle Documentation, example:
http://www.oracle.com/pls/db112/search?remark=quick_search&word=AWR&partno=
Look in the [Performance Tuning Guide|http://download.oracle.com/docs/cd/E11882_01/server.112/e10821/toc.htm] for examples/exaplanations.
Randolf Geist sums it all up very nice here: http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html
More examples can be found on http://asktom.oracle.com
and on this forum by simply doing a search.

Analysing AWR report

DB version:10gR2
After looking at Top 5 wait events and SQL statistics, what is the next most important thing i should be looking for in an AWR report?

This would depend on the top events that you have seen. For example, if you have seen that in the top 5 wait events, there was very high DB File Scattered Read , it means that there are statements which are predominantly going for full table access. So you should look upon for those queries. Or if there is a high Latch Contetion, for example, Shared Pool Latch Conteions ,it means that there are lots of sttement which are going for hard parse and are contending for this latch. So you should look for those sql which are having more cnstants and are not using bind varaibles.
So its not a standard way but it is depending on what you see. Over Jonathan Lewis's blog, there is an excellent series of how to read Statspack report. I shall suggest to read it. This would make a good base to go through with AWR report also.
HTH
Aman....

Performance issue in DB need help with analysing this ADDM report

Hi,
My environment:
Os: RHEL5U3 / 11.1.0.7 64 bit / R12.1.1 64 bit
Issue:
Few days are am facing serious of performance problem in our Production instance. Normally the issue will occur 5 to 10 minutes occasionally per day. At the time of issue we not able to access the EBS application its taking time to load. But backend all the oracle, listener and apps services are up and running. No locks at table and session level. Cpu and memory usage is normal.
We have monitored using "Enterprise Manager" for this issue and we found the wait session present more in Active session tab. At this time EBS application is not able access its loading too time. After some time the in Active session tab the wait session came normal and when we try to access the EBS application its working fine.
We try to find the cause of the issue by running addm report. But am not able to understand what its says. Kindly suggests me
ADDM Report for Task 'TASK_42656'
Analysis Period
AWR snapshot range from 14754 to 14755.
Time period starts at 17-APR-12 11.00.22 AM
Time period ends at 17-APR-12 12.00.33 PM
Analysis Target
Database 'PRD' with DB ID 1789440879.
Database version 11.1.0.7.0.
ADDM performed an analysis of instance PRD, numbered 1 and hosted at
advgrpdb.advgroup.ae.
Activity During the Analysis Period
Total database time was 18674 seconds.
The average number of active sessions was 5.17.
Summary of Findings
Description Active Sessions Recommendations
Percent of Activity
1 Top SQL by DB Time 3.43 | 66.33 5
2 Buffer Busy 2.52 | 48.81 5
3 Buffer Busy 1.39 | 26.81 2
4 Log File Switches .91 | 17.56 1
5 Buffer Busy .56 | 10.87 2
6 Undersized SGA .38 | 7.37 1
7 Commits and Rollbacks .28 | 5.42 1
8 Undo I/O .18 | 3.53 0
9 CPU Usage .13 | 2.57 1
10 Top SQL By I/O .11 | 2.21 1
Findings and Recommendations
Finding 1: Top SQL by DB Time
Impact is 3.43 active sessions, 66.33% of total activity.
SQL statements consuming significant database time were found.
Recommendation 1: SQL Tuning
Estimated benefit is 1.59 active sessions, 30.8% of total activity.
Action
Investigate the SQL statement with SQL_ID "a49xsqhv0h31b" for possible
performance improvements.
Related Object
SQL statement with SQL_ID a49xsqhv0h31b.
SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code,
P.Application_ID, P.Concurrent_Program_ID, P.Concurrent_Program_Name,
R.Enable_Trace, R.Restart, DECODE(R.Increment_Dates, 'Y', 'Y', 'N'),
R.NLS_Compliant, R.OUTPUT_FILE_TYPE, E.Executable_Name,
E.Execution_File_Name, A2.Basepath, DECODE(R.Stale, 'Y', 'C',
P.Execution_Method_Code), P.Print_Flag, P.Execution_Options,
DECODE(P.Srs_Flag, 'Y', 'Y', 'Q', 'Y', 'N'), P.Argument_Method_Code,
R.Print_Style, R.Argument_Input_Method_Code, R.Queue_Method_Code,
R.Responsibility_ID, R.Responsibility_Application_ID, R.Requested_By,
R.Number_Of_Copies, R.Save_Output_Flag, R.Printer, R.Print_Group,
R.Priority, U.User_Name, O.Oracle_Username,
O.Encrypted_Oracle_Password, R.Cd_Id, A.Basepath,
A.Application_Short_Name, TO_CHAR(R.Requested_Start_Date,'YYYY/MM/DD
HH24:MI:SS'), R.Nls_Language, R.Nls_Territory,
R.Nls_Numeric_Characters, DECODE(R.Parent_Request_ID, NULL, 0,
R.Parent_Request_ID), R.Priority_Request_ID, R.Single_Thread_Flag,
R.Has_Sub_Request, R.Is_Sub_Request, R.Req_Information,
R.Description, R.Resubmit_Time, TO_CHAR(R.Resubmit_Interval),
R.Resubmit_Interval_Type_Code, R.Resubmit_Interval_Unit_Code,
TO_CHAR(R.Resubmit_End_Date,'YYYY/MM/DD HH24:MI:SS'),
Decode(E.Execution_File_Name, NULL, 'N', Decode(E.Subroutine_Name,
NULL, Decode(E.Execution_Method_Code, 'I', 'Y', 'J', 'Y', 'N'),
'Y')), R.Argument1, R.Argument2, R.Argument3, R.Argument4,
R.Argument5, R.Argument6, R.Argument7, R.Argument8, R.Argument9,
R.Argument10, R.Argument11, R.Argument12, R.Argument13, R.Argument14,
R.Argument15, R.Argument16, R.Argument17, R.Argument18, R.Argument19,
R.Argument20, R.Argument21, R.Argument22, R.Argument23, R.Argument24,
R.Argument25, X.Argument26, X.Argument27, X.Argument28, X.Argument29,
X.Argument30, X.Argument31, X.Argument32, X.Argument33, X.Argument34,
X.Argument35, X.Argument36, X.Argument37, X.Argument38, X.Argument39,
X.Argument40, X.Argument41, X.Argument42, X.Argument43, X.Argument44,
X.Argument45, X.Argument46, X.Argument47, X.Argument48, X.Argument49,
X.Argument50, X.Argument51, X.Argument52, X.Argument53, X.Argument54,
X.Argument55, X.Argument56, X.Argument57, X.Argument58, X.Argument59,
X.Argument60, X.Argument61, X.Argument62, X.Argument63, X.Argument64,
X.Argument65, X.Argument66, X.Argument67, X.Argument68, X.Argument69,
X.Argument70, X.Argument71, X.Argument72, X.Argument73, X.Argument74,
X.Argument75, X.Argument76, X.Argument77, X.Argument78, X.Argument79,
X.Argument80, X.Argument81, X.Argument82, X.Argument83, X.Argument84,
X.Argument85, X.Argument86, X.Argument87, X.Argument88, X.Argument89,
X.Argument90, X.Argument91, X.Argument92, X.Argument93, X.Argument94,
X.Argument95, X.Argument96, X.Argument97, X.Argument98, X.Argument99,
X.Argument100, R.number_of_arguments, C.CD_Name,
NVL(R.Security_Group_ID, 0), NVL(R.org_id, 0) FROM
fnd_concurrent_requests R, fnd_concurrent_programs P, fnd_application
A, fnd_user U, fnd_oracle_userid O, fnd_conflicts_domain C,
fnd_concurrent_queues Q, fnd_application A2, fnd_executables E,
fnd_conc_request_arguments X WHERE R.Status_code = 'I' And
((R.OPS_INSTANCE is null) or (R.OPS_INSTANCE = -1) or
(R.OPS_INSTANCE =
decode(:dcp_on,1,FND_CONC_GLOBAL.OPS_INST_NUM,R.OPS_INSTANCE))) And
R.Request_ID = X.Request_ID(+) And R.Program_Application_Id =
P.Application_Id(+) And R.Concurrent_Program_Id =
P.Concurrent_Program_Id(+) And R.Program_Application_Id =
A.Application_Id(+) And P.Executable_Application_Id =
E.Application_Id(+) And P.Executable_Id =
E.Executable_Id(+) And P.Executable_Application_Id =
A2.Application_Id(+) And R.Requested_By = U.User_Id(+) And R.Cd_Id
= C.Cd_Id(+) And R.Oracle_Id = O.Oracle_Id(+) And Q.Application_Id =
:q_applid And Q.Concurrent_Queue_Id = :queue_id And (P.Enabled_Flag
is NULL OR P.Enabled_Flag = 'Y') And R.Hold_Flag = 'N' And
R.Requested_Start_Date <= Sysdate And ( R.Enforce_Seriality_Flag =
'N' OR ( C.RunAlone_Flag = P.Run_Alone_Flag And (P.Run_Alone_Flag =
'N' OR Not Exists (Select Null From Fnd_Concurrent_Requests Sr
Where Sr.Status_Code In ('R', 'T') And Sr.Enforce_Seriality_Flag =
'Y' And Sr.CD_id = C.CD_Id)))) And Q.Running_Processes <=
Q.Max_Processes And R.Rowid = :reqname And
((P.Execution_Method_Code != 'S' OR
(R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) IN
((0,98),(0,100),(0,31721),(0,31722),(0,31757))) AND
((R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) NOT IN
((510,40112),(510,40113),(510,41497),(510,41498),(530,41859),(530,418
60),(535,41492),(535,41493),(535,41494)))) FOR UPDATE OF
R.status_code NoWait
Rationale
SQL statement with SQL_ID "a49xsqhv0h31b" was executed 4686 times and
had an average elapsed time of 1.2 seconds.
Rationale
Waiting for event "buffer busy waits" in wait class "Concurrency"
accounted for 85% of the database time spent in processing the SQL
statement with SQL_ID "a49xsqhv0h31b".
Rationale
Waiting for event "log file switch (checkpoint incomplete)" in wait
class "Configuration" accounted for 9% of the database time spent in
processing the SQL statement with SQL_ID "a49xsqhv0h31b".
Recommendation 3: SQL Tuning
Estimated benefit is .56 active sessions, 10.91% of total activity.
Action
Investigate the SQL statement with SQL_ID "5d7957yktf3nn" for possible
performance improvements.
Related Object
SQL statement with SQL_ID 5d7957yktf3nn.
UPDATE ICX_SESSIONS SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
Rationale
SQL statement with SQL_ID "5d7957yktf3nn" was executed 266 times and had
an average elapsed time of 7.6 seconds.
Rationale
Waiting for event "buffer busy waits" in wait class "Concurrency"
accounted for 86% of the database time spent in processing the SQL
statement with SQL_ID "5d7957yktf3nn".
Rationale
Waiting for event "log file switch (checkpoint incomplete)" in wait
class "Configuration" accounted for 7% of the database time spent in
processing the SQL statement with SQL_ID "5d7957yktf3nn".
Finding 2: Buffer Busy
Impact is 2.52 active sessions, 48.81% of total activity.
Read and write contention on database blocks was consuming significant
database time.
Recommendation 1: Application Analysis
Estimated benefit is 1.42 active sessions, 27.44% of total activity.
Action
Trace the cause of object contention due to SELECT statements in the
application using the information provided.
Related Object
Database object with ID 34562.
Rationale
The SELECT statement with SQL_ID "a49xsqhv0h31b" was significantly
affected by "buffer busy" waits.
Related Object
SQL statement with SQL_ID a49xsqhv0h31b.
SELECT R.Conc_Login_Id, R.Request_Id, R.Phase_Code, R.Status_Code,
P.Application_ID, P.Concurrent_Program_ID, P.Concurrent_Program_Name,
R.Enable_Trace, R.Restart, DECODE(R.Increment_Dates, 'Y', 'Y', 'N'),
R.NLS_Compliant, R.OUTPUT_FILE_TYPE, E.Executable_Name,
E.Execution_File_Name, A2.Basepath, DECODE(R.Stale, 'Y', 'C',
P.Execution_Method_Code), P.Print_Flag, P.Execution_Options,
DECODE(P.Srs_Flag, 'Y', 'Y', 'Q', 'Y', 'N'), P.Argument_Method_Code,
R.Print_Style, R.Argument_Input_Method_Code, R.Queue_Method_Code,
R.Responsibility_ID, R.Responsibility_Application_ID, R.Requested_By,
R.Number_Of_Copies, R.Save_Output_Flag, R.Printer, R.Print_Group,
R.Priority, U.User_Name, O.Oracle_Username,
O.Encrypted_Oracle_Password, R.Cd_Id, A.Basepath,
A.Application_Short_Name, TO_CHAR(R.Requested_Start_Date,'YYYY/MM/DD
HH24:MI:SS'), R.Nls_Language, R.Nls_Territory,
R.Nls_Numeric_Characters, DECODE(R.Parent_Request_ID, NULL, 0,
R.Parent_Request_ID), R.Priority_Request_ID, R.Single_Thread_Flag,
R.Has_Sub_Request, R.Is_Sub_Request, R.Req_Information,
R.Description, R.Resubmit_Time, TO_CHAR(R.Resubmit_Interval),
R.Resubmit_Interval_Type_Code, R.Resubmit_Interval_Unit_Code,
TO_CHAR(R.Resubmit_End_Date,'YYYY/MM/DD HH24:MI:SS'),
Decode(E.Execution_File_Name, NULL, 'N', Decode(E.Subroutine_Name,
NULL, Decode(E.Execution_Method_Code, 'I', 'Y', 'J', 'Y', 'N'),
'Y')), R.Argument1, R.Argument2, R.Argument3, R.Argument4,
R.Argument5, R.Argument6, R.Argument7, R.Argument8, R.Argument9,
R.Argument10, R.Argument11, R.Argument12, R.Argument13, R.Argument14,
R.Argument15, R.Argument16, R.Argument17, R.Argument18, R.Argument19,
R.Argument20, R.Argument21, R.Argument22, R.Argument23, R.Argument24,
R.Argument25, X.Argument26, X.Argument27, X.Argument28, X.Argument29,
X.Argument30, X.Argument31, X.Argument32, X.Argument33, X.Argument34,
X.Argument35, X.Argument36, X.Argument37, X.Argument38, X.Argument39,
X.Argument40, X.Argument41, X.Argument42, X.Argument43, X.Argument44,
X.Argument45, X.Argument46, X.Argument47, X.Argument48, X.Argument49,
X.Argument50, X.Argument51, X.Argument52, X.Argument53, X.Argument54,
X.Argument55, X.Argument56, X.Argument57, X.Argument58, X.Argument59,
X.Argument60, X.Argument61, X.Argument62, X.Argument63, X.Argument64,
X.Argument65, X.Argument66, X.Argument67, X.Argument68, X.Argument69,
X.Argument70, X.Argument71, X.Argument72, X.Argument73, X.Argument74,
X.Argument75, X.Argument76, X.Argument77, X.Argument78, X.Argument79,
X.Argument80, X.Argument81, X.Argument82, X.Argument83, X.Argument84,
X.Argument85, X.Argument86, X.Argument87, X.Argument88, X.Argument89,
X.Argument90, X.Argument91, X.Argument92, X.Argument93, X.Argument94,
X.Argument95, X.Argument96, X.Argument97, X.Argument98, X.Argument99,
X.Argument100, R.number_of_arguments, C.CD_Name,
NVL(R.Security_Group_ID, 0), NVL(R.org_id, 0) FROM
fnd_concurrent_requests R, fnd_concurrent_programs P, fnd_application
A, fnd_user U, fnd_oracle_userid O, fnd_conflicts_domain C,
fnd_concurrent_queues Q, fnd_application A2, fnd_executables E,
fnd_conc_request_arguments X WHERE R.Status_code = 'I' And
((R.OPS_INSTANCE is null) or (R.OPS_INSTANCE = -1) or
(R.OPS_INSTANCE =
decode(:dcp_on,1,FND_CONC_GLOBAL.OPS_INST_NUM,R.OPS_INSTANCE))) And
R.Request_ID = X.Request_ID(+) And R.Program_Application_Id =
P.Application_Id(+) And R.Concurrent_Program_Id =
P.Concurrent_Program_Id(+) And R.Program_Application_Id =
A.Application_Id(+) And P.Executable_Application_Id =
E.Application_Id(+) And P.Executable_Id =
E.Executable_Id(+) And P.Executable_Application_Id =
A2.Application_Id(+) And R.Requested_By = U.User_Id(+) And R.Cd_Id
= C.Cd_Id(+) And R.Oracle_Id = O.Oracle_Id(+) And Q.Application_Id =
:q_applid And Q.Concurrent_Queue_Id = :queue_id And (P.Enabled_Flag
is NULL OR P.Enabled_Flag = 'Y') And R.Hold_Flag = 'N' And
R.Requested_Start_Date <= Sysdate And ( R.Enforce_Seriality_Flag =
'N' OR ( C.RunAlone_Flag = P.Run_Alone_Flag And (P.Run_Alone_Flag =
'N' OR Not Exists (Select Null From Fnd_Concurrent_Requests Sr
Where Sr.Status_Code In ('R', 'T') And Sr.Enforce_Seriality_Flag =
'Y' And Sr.CD_id = C.CD_Id)))) And Q.Running_Processes <=
Q.Max_Processes And R.Rowid = :reqname And
((P.Execution_Method_Code != 'S' OR
(R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) IN
((0,98),(0,100),(0,31721),(0,31722),(0,31757))) AND
((R.PROGRAM_APPLICATION_ID,R.CONCURRENT_PROGRAM_ID) NOT IN
((510,40112),(510,40113),(510,41497),(510,41498),(530,41859),(530,418
60),(535,41492),(535,41493),(535,41494)))) FOR UPDATE OF
R.status_code NoWait
UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
Recommendation 1: Schema Changes
Estimated benefit is .03 active sessions, .62% of total activity.
Action
Consider rebuilding the TABLE "APPLSYS.FND_LOGIN_RESP_FORMS" with object
ID 34651 using a higher value for PCTFREE.
Related Object
Database object with ID 34651.
Rationale
The UPDATE statement with SQL_ID "cqc5crhxxt36t" was significantly
affected by "buffer busy" waits.
Related Object
SQL statement with SQL_ID cqc5crhxxt36t.
UPDATE FND_LOGIN_RESP_FORMS FLRF SET END_TIME = SYSDATE WHERE
FLRF.LOGIN_ID = :B2 AND FLRF.LOGIN_RESP_ID = :B1 AND FLRF.END_TIME IS
NULL AND (FLRF.FORM_ID, FLRF.FORM_APPL_ID) = (SELECT F.FORM_ID,
F.APPLICATION_ID FROM FND_FORM F, FND_APPLICATION A WHERE F.FORM_NAME
= :B4 AND F.APPLICATION_ID = A.APPLICATION_ID AND
A.APPLICATION_SHORT_NAME = :B3 )
Symptoms That Led to the Finding:
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 4: Log File Switches
Impact is .91 active sessions, 17.56% of total activity.
Log file switch operations were consuming significant database time while
waiting for checkpoint completion.
This problem can be caused by use of hot backup mode on tablespaces. DML to
tablespaces in hot backup mode causes generation of additional redo.
Recommendation 1: Database Configuration
Estimated benefit is .91 active sessions, 17.56% of total activity.
Action
Verify whether incremental shipping was used for standby databases.
Symptoms That Led to the Finding:
Wait class "Configuration" was consuming significant database time.
Impact is .91 active sessions, 17.63% of total activity.
Finding 5: Buffer Busy
Impact is .56 active sessions, 10.87% of total activity.
A hot data block with concurrent read and write activity was found. The block
belongs to segment "ICX.ICX_SESSIONS" and is block 243489 in file 36.
Recommendation 1: Application Analysis
Estimated benefit is .56 active sessions, 10.87% of total activity.
Action
Investigate application logic to find the cause of high concurrent read
and write activity to the data present in this block.
Related Object
Database block with object number 37562, file number 36 and block
number 243489.
Rationale
The SQL statement with SQL_ID "5d7957yktf3nn" spent significant time on
"buffer busy" waits for the hot block.
Related Object
SQL statement with SQL_ID 5d7957yktf3nn.
UPDATE ICX_SESSIONS SET TIME_OUT = :B2 WHERE SESSION_ID = :B1
Rationale
The SQL statement with SQL_ID "326up1aym56dd" spent significant time on
"buffer busy" waits for the hot block.
Related Object
SQL statement with SQL_ID 326up1aym56dd.
UPDATE ICX_SESSIONS SET LAST_CONNECT = SYSDATE WHERE SESSION_ID = :B1
Recommendation 2: Schema Changes
Estimated benefit is .56 active sessions, 10.87% of total activity.
Action
Consider rebuilding the TABLE "ICX.ICX_SESSIONS" with object ID 37562
using a higher value for PCTFREE.
Related Object
Database object with ID 37562.
Symptoms That Led to the Finding:
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 6: Undersized SGA
Impact is .38 active sessions, 7.37% of total activity.
The SGA was inadequately sized, causing additional I/O or hard parses.
The value of parameter "sga_target" was "4096 M" during the analysis period.
Recommendation 1: Database Configuration
Estimated benefit is .12 active sessions, 2.33% of total activity.
Action
Increase the size of the SGA by setting the parameter "sga_target" to
4608 M.
Symptoms That Led to the Finding:
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Hard parsing of SQL statements was consuming significant database time.
Impact is .13 active sessions, 2.51% of total activity.
Contention for latches related to the shared pool was consuming
significant database time.
Impact is 0 active sessions, .03% of total activity.
Wait class "Concurrency" was consuming significant database time.
Impact is 2.53 active sessions, 48.87% of total activity.
Finding 7: Commits and Rollbacks
Impact is .28 active sessions, 5.42% of total activity.
Waits on event "log file sync" while performing COMMIT and ROLLBACK operations
were consuming significant database time.
Recommendation 1: Host Configuration
Estimated benefit is .28 active sessions, 5.42% of total activity.
Action
Investigate the possibility of improving the performance of I/O to the
online redo log files.
Rationale
The average size of writes to the online redo log files was 163 K and
the average time per write was 68 milliseconds.
Symptoms That Led to the Finding:
Wait class "Commit" was consuming significant database time.
Impact is .28 active sessions, 5.42% of total activity.
Finding 8: Undo I/O
Impact is .18 active sessions, 3.53% of total activity.
Undo I/O was a significant portion (26%) of the total database I/O.
No recommendations are available.
Symptoms That Led to the Finding:
The throughput of the I/O subsystem was significantly lower than
expected.
Impact is .08 active sessions, 1.46% of total activity.
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Finding 9: CPU Usage
Impact is .13 active sessions, 2.57% of total activity.
Time spent on the CPU by the instance was responsible for a substantial part
of database time.
Recommendation 1: SQL Tuning
Estimated benefit is .13 active sessions, 2.57% of total activity.
Finding 10: Top SQL By I/O
Impact is .11 active sessions, 2.21% of total activity.
Individual SQL statements responsible for significant user I/O wait were
found.
Recommendation 1: SQL Tuning
Estimated benefit is .11 active sessions, 2.22% of total activity.
Action
Run SQL Tuning Advisor on the SQL statement with SQL_ID "b3pnc5yctv2z5".
Related Object
SQL statement with SQL_ID b3pnc5yctv2z5.
INSERT INTO ZX_TRANSACTION_LINES_GT( APPLICATION_ID ,ENTITY_CODE
,EVENT_CLASS_CODE ,TRX_ID ,TRX_LEVEL_TYPE ,TRX_LINE_ID ,LINE_CLASS
,LINE_LEVEL_ACTION ,TRX_LINE_TYPE ,TRX_LINE_DATE
,LINE_AMT_INCLUDES_TAX_FLAG ,LINE_AMT ,TRX_LINE_QUANTITY ,UNIT_PRICE
,PRODUCT_ID ,PRODUCT_ORG_ID ,UOM_CODE ,PRODUCT_CODE ,SHIP_TO_PARTY_ID
,SHIP_FROM_PARTY_ID ,BILL_TO_PARTY_ID ,BILL_FROM_PARTY_ID
,SHIP_FROM_PARTY_SITE_ID ,BILL_FROM_PARTY_SITE_ID
,SHIP_TO_LOCATION_ID ,SHIP_FROM_LOCATION_ID ,BILL_TO_LOCATION_ID
,SHIP_THIRD_PTY_ACCT_ID ,SHIP_THIRD_PTY_ACCT_SITE_ID ,HISTORICAL_FLAG
,TRX_LINE_CURRENCY_CODE ,TRX_LINE_CURRENCY_CONV_DATE
,TRX_LINE_CURRENCY_CONV_RATE ,TRX_LINE_CURRENCY_CONV_TYPE
,TRX_LINE_MAU ,TRX_LINE_PRECISION ,HISTORICAL_TAX_CODE_ID
,TRX_BUSINESS_CATEGORY ,PRODUCT_CATEGORY ,PRODUCT_FISC_CLASSIFICATION
,LINE_INTENDED_USE ,PRODUCT_TYPE ,USER_DEFINED_FISC_CLASS
,ASSESSABLE_VALUE ,INPUT_TAX_CLASSIFICATION_CODE ,ACCOUNT_CCID
,BILL_THIRD_PTY_ACCT_ID ,BILL_THIRD_PTY_ACCT_SITE_ID ,TRX_LINE_NUMBER
,TRX_LINE_DESCRIPTION ,PRODUCT_DESCRIPTION ,USER_UPD_DET_FACTORS_FLAG
,DEFAULTING_ATTRIBUTE1 ) SELECT :B4 ,:B3 ,:B2
,PRL.REQUISITION_HEADER_ID ,:B1 ,PRL.REQUISITION_LINE_ID ,'INVOICE'
,NVL(PRL.TAX_ATTRIBUTE_UPDATE_CODE,'UPDATE') ,'ITEM'
,NVL(PRL.NEED_BY_DATE, SYSDATE) ,'N' ,NVL(PRL.AMOUNT,
PRL.UNIT_PRICE*PRL.QUANTITY) ,PRL.QUANTITY ,PRL.UNIT_PRICE
,PRL.ITEM_ID ,(SELECT FSP.INVENTORY_ORGANIZATION_ID FROM
FINANCIALS_SYSTEM_PARAMS_ALL FSP WHERE FSP.ORG_ID=PRL.ORG_ID)
,(SELECT MUM.UOM_CODE FROM MTL_UNITS_OF_MEASURE MUM WHERE
MUM.UNIT_OF_MEASURE=PRL.UNIT_MEAS_LOOKUP_CODE) ,MSIB.SEGMENT1
,PRL.DESTINATION_ORGANIZATION_ID ,PV.PARTY_ID ,PRH.ORG_ID
,PV.PARTY_ID ,PVS.PARTY_SITE_ID ,PVS.PARTY_SITE_ID
,PRL.DELIVER_TO_LOCATION_ID ,(SELECT HZPS.LOCATION_ID FROM
HZ_PARTY_SITES HZPS WHERE HZPS.PARTY_SITE_ID = PVS.PARTY_SITE_ID)
,(SELECT LOCATION_ID FROM HR_ALL_ORGANIZATION_UNITS WHERE
ORGANIZATION_ID=PRH.ORG_ID) ,PRL.VENDOR_ID ,PRL.VENDOR_SITE_ID ,NULL
,NVL(PRL.CURRENCY_CODE, :B9 ) ,NVL2(PRL.CURRENCY_CODE, PRL.RATE_DATE,
SYSDATE) ,NVL2(PRL.CURRENCY_CODE, PRL.RATE, :B8 )
,NVL2(PRL.CURRENCY_CODE, PRL.RATE_TYPE, :B7 )
,FC.MINIMUM_ACCOUNTABLE_UNIT ,NVL(FC.PRECISION, 2) ,NULL
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.TRX_BUSINESS_CATEGORY, NULL),
NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_CATEGORY, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_FISC_CLASSIFICATION,
NULL), NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.LINE_INTENDED_USE, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.PRODUCT_TYPE, NULL), NULL )
,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.USER_DEFINED_FISC_CLASS, NULL),
NULL ) ,DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.ASSESSABLE_VALUE, NULL), NULL )
,DECODE(:B6 , 'REQIMPORT', PRL.TAX_NAME,
DECODE(PRL.TAX_ATTRIBUTE_UPDATE_CODE, 'CREATE',
NVL2(PRL.PARENT_REQ_LINE_ID, ZXLDET.INPUT_TAX_CLASSIFICATION_CODE,
NULL), NULL ) ) ,NVL((SELECT PRD.CODE_COMBINATION_ID FROM
PO_REQ_DISTRIBUTIONS_ALL PRD WHERE PRD.REQUISITION_LINE_ID =
PRL.REQUISITION_LINE_ID AND ROWNUM = 1), MSIB.EXPENSE_ACCOUNT )
,PV.VENDOR_ID ,PVS.VENDOR_SITE_ID ,PRL.LINE_NUM ,PRL.ITEM_DESCRIPTION
,PRL.ITEM_DESCRIPTION ,(SELECT 'Y' FROM DUAL WHERE :B6 = 'REQIMPORT'
AND PRL.TAX_NAME IS NOT NULL) ,PRL.DESTINATION_ORGANIZATION_ID FROM
PO_REQUISITION_HEADERS_ALL PRH, PO_REQUISITION_LINES_ALL PRL,
ZX_LINES_DET_FACTORS ZXLDET, PO_VENDORS PV, PO_VENDOR_SITES_ALL PVS,
MTL_SYSTEM_ITEMS_B MSIB, FND_CURRENCIES FC WHERE
PRH.REQUISITION_HEADER_ID = :B5 AND PRH.REQUISITION_HEADER_ID =
PRL.REQUISITION_HEADER_ID AND ZXLDET.APPLICATION_ID(+) = :B4 AND
ZXLDET.ENTITY_CODE(+) = :B3 AND ZXLDET.EVENT_CLASS_CODE(+) = :B2 AND
ZXLDET.TRX_LEVEL_TYPE(+) = :B1 AND ZXLDET.TRX_LINE_ID(+) =
PRL.PARENT_REQ_LINE_ID AND PV.VENDOR_ID(+) = PRL.VENDOR_ID AND
PVS.VENDOR_SITE_ID(+) = PRL.VENDOR_SITE_ID AND
MSIB.INVENTORY_ITEM_ID(+) = PRL.ITEM_ID AND MSIB.ORGANIZATION_ID(+) =
PRL.ORG_ID AND FC.CURRENCY_CODE(+) = PRL.CURRENCY_CODE AND
NVL(PRL.MODIFIED_BY_AGENT_FLAG, 'N') = 'N' AND NVL(PRL.CANCEL_FLAG,
'N') = 'N' AND NVL(PRL.CLOSED_CODE, 'OPEN') <> 'FINALLY CLOSED' AND
PRL.LINE_LOCATION_ID IS NULL AND PRL.AT_SOURCING_FLAG IS NULL
Rationale
SQL statement with SQL_ID "b3pnc5yctv2z5" was executed 3 times and had
an average elapsed time of 138 seconds.
Rationale
Average time spent in User I/O wait events per execution was 137
seconds.
Symptoms That Led to the Finding:
Wait class "User I/O" was consuming significant database time.
Impact is .7 active sessions, 13.57% of total activity.
Additional Information
Miscellaneous Information
Wait class "Application" was not consuming significant database time.
Wait class "Network" was not consuming significant database time.
Session connect and disconnect calls were not consuming significant database
time.
The database's maintenance windows were active during 100% of the analysis
period.
Regards
Athish

Few days are am facing serious of performance problem in our Production instanceFor production issues, please log a SR.
Was this working before? If yes, any changes been done recently?
Do you have the statistics collected up to date?
Please see these docs.
AutoInvoice Performance Issue When Processing Tax [ID 1059275.1]
R12 : System Hangs When Attempting To Save Blanket Release After Applying Patch 11817843 [ID 1333336.1]
Thanks,
Hussein

Awr questions

Hi,
I have some questions related to AWR:
1) In AWR there is a section on "SQL ordered by Sharable Memory" . I am not clear what is the meaning of sqls ordered by sharable memory? and and how that information could be used for a tuning oppertunity?
2) in the SQL Statistics section of AWR, several sqls are listed under each group (e.g. for sqls ordered by elapsed time, ordered by cpu time etc). Is there a rule that how many sqls will be listed there? I mean say under teh sqls ordered by elapse time category how many sql statements will be listed? In one AWR report I found 16 statements under this category. Now in same AWR report, under "SQL ordered by Reads" category I found 10 statements listed (not 16). So what is the rule? How many statements will be listed by Oracle in the AWR for each of the category?
3) Under "instance activity" section lots of stats are given. Are these stats cumulative since the database startup or they are for the snapshot period for which the AWR report is taken? -I think that the stats should be for the snapshot period, not cumulative but want to confirm if my understanding is correct.
Thanks

What i belive about the query tuning i always start from using Bind Variables.
But if your query is very resource intensive try writing the query in some other manner .
Is your query is using view also if yes check the view if it is meargable or non mergable.
Try to investigate your execution plan for the query and. tune it.
As far as a full table scan is concerned it depends on the selectivity part of your sql query
if the sql is returning high numbers of rows then . it is optimal way to do the operation by
a full table scan.
the best way to tune your sql is to generate the plan output from the trace file of the session
by using the tkprof utility.
sql> alter session set sql_trace=true;
sql>------------do your work...
sql> alter session set sql_trace=false;
then a trace file will be generated in to your udump folder...
which can be analysed for getting the sql execution plan which oracle used
to solve the result.....
Try it if you find some difficulty let me know...
i will help you.
Bi Tc

How to generate AWR report by using ttStats?

Hi all,are there any links or documents to show how to use ttStats toolkit to generate a report like Oracle AWR report?
If no links or document available, could you tell me how to use it?
In fact I want to know how to do a performance analysis for my application and perform some tune.
If any other toolkits are more suitable please let me know and of course the guide that how to use them is much welcome.
Thanks.

The ttStats executable can be found in the <TimesTen_home>/support directory. Before you can run the executable within a command prompt, you'll need to source the ttenv.* file in the <TimesTen_home>/bin directory.
The output of ttStats -h is as follows:
ttStats [-latchstats on|off] [-display-options] [-xml file]
[-statlevel level] <dsn or connstr>
ttStats -s[napshot] [-latchstats on|off] -xml <file> <dsn or connstr>
ttStats -report <xmlfile1> <xmlfile2> <-text|-html> <report_file>
Where parameters in <> are required, and in [] are optional.
-display-options:
This option only works in monitoring mode as
screen filtering. ttStats only displays on the
screen statistics with specified prefixes.
Available prefix options include:
-cg, -ckpt, -conn, -db, -grid, -lock, -log, -repl,
-stmt, -txn, -xla, -zz, where the naming of prefixes
conforms to naming of statistics in TimesTen
sys.systemstats table. If no display option
is specified, all statistics are displayed
by default. For example, run command
ttStats -cg -stmt dsn=TptbmData
to display only cache group and statement
related statistics.
-h[elp] Print help message and exit.
-interval <secs> Collect a set of statistics every <secs> seconds
(default=10).
Note: setting this lower can negatively impact
performance
-xml <file> Write statistics to <file> in XML format. All
statistics will be written to <file> no matter
whether they are displayed on screen or not.
For example ttStats -xml mon.xml dsn=TptbmData
and ttStats -xml mon.xml -cg dsn=TptbmData
write the same file even if the latter only
shows cache related statistics on the screen.
-snapshot One snapshot of all statistics are saved to disk
in the specified file format, then the program
exits. This option should be used together with
the -xml option.
-statlevel <level>
Set the SysStats level, this value of level only
applies to sys.systemstats table.
-report <xmlfile1> <xmlfile2> <-xml|-text|-html> <report_file>
Compare two snapshots, and generate an AWR like
report. At present, each XML file contains only
one snapshot. The difference is computed as the
absolute value of statistic value in <xmlfile2>
minus that in <xmlfile1>. The result can be
written in HTML and plain text formats. XML is
not supported as output format at present.
As an example, you can run the utility as the instance admin user by doing something like:
./ttStats -s -xml tmp.xml <DSN>
You can then open tmp.xml with a web browser and see statistics about the database.
You can also compare two previously captured snaps by doing something like:
./ttStats -report tmp1.xml tmp2.xml -html tmpReport.html

AWR Report tuning

Hi All,
I have created AWR Report .But i can not anlayse what is the problem in that query which is taking more time to execute from that AWR report.
Can any one give me detail document of the AWR Report Events generated .So, I can analyse from that event where is the problem?
Thanks in advance.

Thanks for your reply
Plan hash value: 3677326586
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 3 | 537 | 8018 (1)| 00:01:37 | | |
| 1 | VIEW | VWPREPAIDBALANCEINFORMATION | 3 | 537 | 8018 (1)| 00:01:37 | | |
| 2 | SORT UNIQUE | | 3 | 926 | 8018 (67)| 00:01:37 | | |
| 3 | UNION-ALL | | | | | | | |
| 4 | HASH GROUP BY | | 1 | 252 | 2673 (1)| 00:00:33 | | |
| 5 | NESTED LOOPS SEMI | | 1 | 252 | 2671 (1)| 00:00:33 | | |
|* 6 | HASH JOIN SEMI | | 1 | 218 | 2667 (1)| 00:00:33 | | |
| 7 | PARTITION RANGE ALL | | 583 | 104K| 2035 (1)| 00:00:25 | 1 | 731 |
| 8 | TABLE ACCESS BY LOCAL INDEX ROWID | TBLCDR | 583 | 104K| 2035 (1)| 00:00:25 | 1 | 731 |
|* 9 | INDEX RANGE SCAN | IDX_ACCOUNTID_TBLCDR | 605 | | 1466 (1)| 00:00:18 | 1 | 731 |
|* 10 | TABLE ACCESS FULL | TBLTCUSTOMERPACKAGEHISTORY | 94160 | 3218K| 630 (2)| 00:00:08 | | |
|* 11 | TABLE ACCESS BY INDEX ROWID | TBLMCUSTOMERUSAGEDETAIL | 1 | 34 | 4 (0)| 00:00:01 | | |
|* 12 | INDEX RANGE SCAN | IDX_CUSTOMERID | 3 | | 2 (0)| 00:00:01 | | |
| 13 | HASH GROUP BY | | 1 | 293 | 2669 (1)| 00:00:33 | | |
| 14 | NESTED LOOPS SEMI | | 1 | 293 | 2667 (1)| 00:00:32 | | |
| 15 | NESTED LOOPS | | 1 | 259 | 2663 (1)| 00:00:32 | | |
| 16 | MERGE JOIN CARTESIAN | | 1 | 76 | 630 (2)| 00:00:08 | | |
| 17 | VIEW | index$_join$_006 | 1 | 41 | 1 (100)| 00:00:01 | | |
|* 18 | HASH JOIN | | | | | | | |
| 19 | INDEX FAST FULL SCAN | IDX_PREFIX | 1 | 41 | 0 (0)| 00:00:01 | | |
| 20 | INDEX FAST FULL SCAN | PK_DESTINATION | 1 | 41 | 0 (0)| 00:00:01 | | |
| 21 | BUFFER SORT | | 94160 | 3218K| 630 (2)| 00:00:08 | | |
| 22 | SORT UNIQUE | | 94160 | 3218K| 630 (2)| 00:00:08 | | |
|* 23 | TABLE ACCESS FULL | TBLTCUSTOMERPACKAGEHISTORY | 94160 | 3218K| 630 (2)| 00:00:08 | | |
| 24 | PARTITION RANGE ALL | | 1 | 183 | 2032 (1)| 00:00:25 | 1 | 731 |
|* 25 | TABLE ACCESS BY LOCAL INDEX ROWID | TBLCDR | 1 | 183 | 2032 (1)| 00:00:25 | 1 | 731 |
|* 26 | INDEX RANGE SCAN | IDX_CUSTOEMRID | 605 | | 1463 (1)| 00:00:18 | 1 | 731 |
|* 27 | TABLE ACCESS BY INDEX ROWID | TBLMCUSTOMERUSAGEDETAIL | 1 | 34 | 4 (0)| 00:00:01 | | |
|* 28 | INDEX RANGE SCAN | IDX_CUSTOMERID | 3 | | 2 (0)| 00:00:01 | | |
| 29 | HASH GROUP BY | | 1 | 381 | 2677 (1)| 00:00:33 | | |
|* 30 | FILTER | | | | | | | |
| 31 | NESTED LOOPS ANTI | | 1 | 381 | 2671 (1)| 00:00:33 | | |
|* 32 | HASH JOIN SEMI | | 1 | 347 | 2667 (1)| 00:00:33 | | |
| 33 | PARTITION RANGE ALL | | 583 | 177K| 2035 (1)| 00:00:25 | 1 | 731 |
| 34 | TABLE ACCESS BY LOCAL INDEX ROWID| TBLCDR | 583 | 177K| 2035 (1)| 00:00:25 | 1 | 731 |
|* 35 | INDEX RANGE SCAN | IDX_ACCOUNTID_TBLCDR | 605 | | 1466 (1)| 00:00:18 | 1 | 731 |
|* 36 | TABLE ACCESS FULL | TBLTCUSTOMERPACKAGEHISTORY | 94160 | 3218K| 630 (2)| 00:00:08 | | |
|* 37 | TABLE ACCESS BY INDEX ROWID | TBLMCUSTOMERUSAGEDETAIL | 1 | 34 | 4 (0)| 00:00:01 | | |
|* 38 | INDEX RANGE SCAN | IDX_CUSTOMERID | 3 | | 2 (0)| 00:00:01 | | |
| 39 | NESTED LOOPS | | 1 | 69 | 4 (0)| 00:00:01 | | |
| 40 | TABLE ACCESS BY INDEX ROWID | TBLMDESTINATION | 1 | 41 | 0 (0)| 00:00:01 | | |
|* 41 | INDEX UNIQUE SCAN | PK_DESTINATION | 1 | | 0 (0)| 00:00:01 | | |
|* 42 | TABLE ACCESS BY INDEX ROWID | TBLMCUSTOMERUSAGEDETAIL | 1 | 28 | 4 (0)| 00:00:01 | | |
|* 43 | INDEX RANGE SCAN | IDX_CUSTOMERID | 3 | | 2 (0)| 00:00:01 | | |
-----------------------------------------------------------------------------------------------------------------------------------------

AWR Analysis

Similar Messages

Maybe you are looking for