Sqltrace and tkprof

can anyone xplain how to do sqltrace and tkprof
here i am getting an error while executing a query
at firs i gave
set autotrace on
SQL> select * from dept;
DEPTNO DEPT_NAME
500 INFORMATION SYSTEMS
CIVIL
400 INFORMATION TECHNOLOGY
100 computers
200 mechanical
300 electrical
6 rows selected.
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=6
1 0 TABLE ACCESS (FULL) OF 'DEPT' (TABLE) (Cost=3 Car
=96)
Statistics
1 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
360 bytes sent via SQL*Net to client
276 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
6 rows processed
after that
SQL> ed
Wrote file afiedt.buf
1 tkprof pra.trc
2 explain=dthpc/dthpc
3* table=dept
SQL> /
tkprof pra.trc
ERROR at line 1:
ORA-00900: invalid SQL statement
can anyone help me out regarding tkprof

SQL> ed
Wrote file afiedt.buf
+1 tkprof pra.trc+
+2 explain=dthpc/dthpc+
+3* table=dept+
i am confused as what you are trying to do here? are you combining explain plan and tkprof?

Similar Messages

SAP Tools vs. SQLTrace and TKPROF

Experts,
First let me say that I am NOT an oracle expert, I am a basis person. Such is the reason I come seeking wisdom.
We are undergoing somewhat of a knee-jerk performance analysis, based on some user complaints. Our new-to-the-organization dba (who has no experience in SAP) is wanting to set up a small performance tablespace within our Production ECC DB and use sql trace and tkprof to analyze what ever it is that they are wanting to look at.
In the past we have been slightly more methodical about tracking down the problem, and then analyzing it based on traces and information within the ST* and DB* tools of SAP.
my 2 questions are:
- Is there any concern with setting up perf gathering tablespace within the production DB
- Does SQLTrace and TKProf give information not readily available within SAPs performance and administration txn's? (DBACockpit, ST* tools, Etc.)
(edit: environment is Solaris 10 64-bit/Oracle 10.2.0.2 64-bit e2900 64/GB Mem)
Thank you in advance,
Phillip
Edited by: Phil May on Oct 9, 2009 1:47 PM

Hi Stefan,
> At first i think, that the analyze possibilities inside SAP for performance issues are one of the best i have ever seen.
True and sad at the same time.
There would be so much more necessary to really have an end-to-end performance view of data processing processes in heterogeneous and distributed systems like SAP landscapes are.
>So in my opinion you can mostly identify and track down the performance issues within SAP itself (ST05, ST04, STAD, etc.).
> > Does SQLTrace and TKProf give information not readily available within SAPs performance and administration txn's?
> Of course .. the raw SQL trace is much more detailed (wait events, etc.), but to be honest .. mostly you don't need it in a SAP environment.
Hmm... I think this (being able to solve most problems with the currently available tool set) only partly comes from the completeness of the tool set.
At least for a part of it, I think it's something like 'When-all-you-have-got-i-a-hammer-everything-look-like-a-nail"-effect.
Usually the "Wait Event Evangelists" (like Cary Milsap) will tell you that the extended SQL trace is all you'll ever need to track down all of your performance issues.
Then there is a whole group of people that try to catch everything by staring at execution plans and theorizing about what execution step would be the problem cause (e.g. the bad hash join or the bad bad bad full table scan).
The DB-agnostic counterpart will say that the NetWeaver platform already covers everything necessary and that look out for additional indexes or ABAP parameters.
I think the truth lies (as usual) somewhere in between.
All in all I think the key point is to get an angle to the problems at all.
As soon as one can describe the problems in a structured way, (s)he has at least a chance to figure out what is happening when
the systems becomes slow.
Given that I'd also vote for the most convenient approach - and that is to use the GUI tools provided by NetWeaver.
And the more experienced Oracle tuning-super-heroes can always take a step further and emply the sql_id-data-collection script or one of the endless number of special scripts that are available through report RSORASTT nowadays.
Just my 2 pence...
regards,
Lars
Edited by: Lars Breddemann on Oct 10, 2009 10:31 AM

SQL Trace and TKprof

Hello,
Can someone tell me what is SQL trance and TKprof?
when we will apply and what need of this?
why i should give alter session set sql trace = true?
if someone could give me an idea of what is a TKprof do, would be apprecaited.

if someone could give me an idea of what is a TKprof doThe doc has an idea : http://download-uk.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm#PFGRF01010
Nicolas.

Trace file and TKPROF

Hi All,
While tuning procedures generally I go through all queries, generate explain plans to check which is expensive and try yo tune that.Recently I got some procedures in top buffer gets list.when I gone through all queries. All using Indexes and cost is very low and accessing small tables.The number of iterations in the loop also not much.But it is taking 3 million bufffer gets for each execution.
How can I find out which part of procedure is causing these many buffer gets? Currently I dont have acces to trace files and TKprof.If I get access How it is going to help me in tuning the above procedure.
I need to explain effictively to DBA the use of trace and TKprof to get this access.

TKPROF will give buffer gets usage by query. If the same query (with bind variables) is executed several times, you will get a summary for all executions of the same query. You can also switch on and off trace with ALTER SESSION statement to limit tracing and even do it from another session (see
http://asktom.oracle.com/pls/ask/f?p=4950:8:12005269305828706290::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:330817260752)
For SQL trace and TKPROF usage, see
http://download-uk.oracle.com/docs/cd/B10501_01/server.920/a96533/sqltrace.htm#1018

Link to download sqlloader and tkprof

Hi,
I installed oracle 11g in my machine from oracle site ,but not able to open tkprof and sqlldr . When click it open and disappear immediately . Where do i get these , i want to download it.
Thanks
Vasudevan

user5003725 wrote:
When click it open and disappear immediately Sqlldr and tkprof are not GUI's. These are to be accessed from command prompt. It is better to learn what it does and how it works before actually trying to use it.
HTH,
Prazy

Sql trace and tkprof result

When I use sql trace and tkprof. After I use tkprof, I get the result statistics. However, I don't understand one point that I see many queries which I didn't run. I mean how come these queries executed? and by who?
thanks

some could be recursive sql statemets run by oracle. Post some example what you are running and what you are seeing?
The SQL statements can be listed in a TKPROF report in the order of how much resource they used, if desired. Also, recursive SQL statements issued by the SYS user to manage the data dictionary can be included or excluded.
How to Use and Understand the TKPROF utility

Enable awr and tkprof for particular sid

Hi all,
how to enable awr and tkprof for particular sid.
it is very urgent
Thanks
mano

Trace a session.
1)Logout all sessions from the database
2)Login to application (ensure that only one session is available)
3)sqlplus trace/trace@026
4)check the sid and serial# of the session from v$session
Use the following query
SQL> select username,to_char(logon_time,'DD-MON-YYYY HH:MI:SS') from v$session where username='<db username>' order by logon_time;
SQL>exec sys.dbms_system.set_sql_trace_in_session(sid,serial#,TRUE);
5)now execute the report/transaction.
6)once the activity is over
SQL>exec sys.dbms_system.set_sql_trace_in_session(sid,serial,FALSE);
7)Now the trace file will be available in the udump folder of the database ip 10.44.0.26
Userid/password: trace/trace
The trace wil be available in /oracle/admin/orcl/udump
8)To find the name of the trace file use the below query
select spid from v$process where addr=(select paddr from v$session where sid=<enter the SID>);
This will give the name of the file
If you are not able to identify the trace file then please remove all files in udump before starting trace.
9) ftp the trace fil to ur local pc and issue the tkprof command
TKPROF <trace file (like D:\orcl_8853.trc)> D:\trace.txt explain=Oracle username/password (application user) sort=(prsela,exeela,fchela)
This will give trace file in readable format(you need to have 10g client on your pc for tkprof to work)

About SQL_TRACE and TKPROF

I have got a trace file, most of the part I understand we it mean. But I want to ask what is the meaning of "Overall totals for all non-recursive statements" and "Overall totals for all recursive statements" at the bottom of the report.
What's included in these 2 parts?
If I want to analysis the time taken for TDE to encrypt a column, which part of the report should be used.
I think the data for this statment "alter table accounts modify(name encrypt)" should not be the data used to analysis the time taken for encryption. Since the result is too small. Should I use the overall totals for all recursive statements?
Thanks in advance.

If you have access to the source code, it should be possible to execute a SQL statement like this to enable a 10046 extended trace at level 12 (waits and binds):
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12';If you do not have access to the source code, you can remotely enable an extended trace for another session with:
* Logon trigger that executes the above SQL statement for a specific user/application.
* System wide 10046 extended trace (change SESSION in the above SQL statement to SYSTEM).
* Session specific 10046 trace remotely enabled using:
EXEC SYS.DBMS_SYSTEM.SET_EV(SID,SERIAL#,10046,12,'');
-or-
EXEC SYS.DBMS_SUPPORT.START_TRACE_IN_SESSION(SID,SERIAL#,WAITS=>TRUE,BINDS=>FALSE);
-or-
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(SESSION_ID=>sid,SERIAL_NUM=>serial#,WAITS=>TRUE,BINDS=>TRUE)
-or-
EXEC SYS.DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(SID,SERIAL#,TRUE);The SID and SERIAL# may be retrieved from V$SESSION.
The SYS.DBMS_SYSTEM.SET_EV method is unsupported, but it works fine on older versions of Oracle where the other methods do not exist.
Oracle will create the trace files in the server's udump directory.
Before executing any of the above (especially the system wide method), determine how to disable a 10046 trace, depending on how it was started:
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';
-or-
EXEC SYS.DBMS_SYSTEM.SET_EV(SID,SERIAL#,10046,0,'');
-or-
EXEC SYS.DBMS_SUPPORT.STOP_TRACE_IN_SESSION(SID,SERIAL#);
-or-
EXEC SYS.DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(SID,SERIAL#,FALSE);Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

SQL tracing and TKPROF tool, how to get object name

Hi,
I set sql_trace = ture for my session.
Then I use TKPROF (on trace file) to get the explain plan (for my stored procedure). but the explain plan shows obj# (object number), HOW do I get TKPROF to show object name on explain plan (I have checked the SYBEX book, it has no info on that)?
Also can you get explain plan from SQL (without sql_trace) for stored procs, if so HOW?
Thanks

SELECT
SERVERPROPERTY('MachineName') AS [ServerName],
SERVERPROPERTY('ServerName') AS [ServerInstanceName],
SERVERPROPERTY('InstanceName') AS [Instance],
SERVERPROPERTY('Edition') AS [Edition],
SERVERPROPERTY('ProductVersion') AS [ProductVersion],
Left(@@Version, Charindex('-', @@version) - 2) As VersionName
|
Blog: MSBICOE.com |
MCITP - BI, SQL Developer & DBA
Hate to mislead others, if I'm wrong slap me. Thanks!

Tkprof and mutiple cursors

Hi
I am looking into a performance issues on the following; Oracle 8.1.7.3 on OpenVms and a Pro*C/C++ server application.
I run sql_trace and tkprof for some Pro*C/C++ operations and I get the following from tkprof
INSERT INTO VV4_RANGE.TRANSACTION_DETAIL (CALCULATED_VALUE,VALUE,
CALL_DURATION,CREDIT_BALANCE,FILE_TYPE_UID,FILE_UID,IN_PLATFORM_UID,
CALLED_PARTY,PROVIDER_ID,RECORD_NUMBER,START_OF_CALL,SUBSCRIBER_UID,
TARIFF_CORRECT,END_OF_CALL,TRANSACTION_TYPE_UID,EVENT_CAUSE) SELECT
CALCULATED_VALUE,CALL_CHARGE,CONNECTION_DURATION,CREDIT_BALANCE,
FILE_TYPE_UID,FILE_UID,IN_PLATFORM_UID,NVL(CALLED_PARTY,LAST_CALLED_PARTY),
PROVIDER_ID,RECORD_NUMBER,START_DATE,SUBSCRIBER_ID,TARIFF_CORRECT,
TIME_STAMP,TRANSACTION_TYPE_UID,decode(CALL_STATUS,-1,NULL,CALL_STATUS)
FROM DATALOADER1_1_8
call count cpu elapsed disk query current rows
Parse 1 0.00 0.01 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.01 0 0 0 0
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 28 (VV4_LOAD)
This is strange there is only a parse and nothing else. I then checked out the raw trace files, as below
PARSING IN CURSOR #18 len=567 dep=0 uid=28 oct=2 lid=28 tim=190280724 hv=832202509 ad='5d41c08'
INSERT INTO VV4_RANGE.TRANSACTION_DETAIL (CALCULATED_VALUE,VALUE,CALL_DURATION,CREDIT_BALANCE,FILE_TYPE_UID,FILE_UID,IN_PLATFORM_UID,CALLED_PARTY,PROVIDER_ID,RECORD_NUMBER,START_OF_CALL,SUBSCRIBER_UID,TARIFF_CORRECT,END_OF_CALL,TRANSACTION_TYPE_UID,EVENT_CAUSE) SELECT CALCULATED_VALUE,CALL_CHARGE,CONNECTION_DURATION,CREDIT_BALANCE,FILE_TYPE_UID,FILE_UID,IN_PLATFORM_UID,NVL(CALLED_PARTY,LAST_CALLED_PARTY),PROVIDER_ID,RECORD_NUMBER,START_DATE,SUBSCRIBER_ID,TARIFF_CORRECT,TIME_STAMP,TRANSACTION_TYPE_UID,decode(CALL_STATUS,-1,NULL,CALL_STATUS) FROM DATALOADER1_1_8
END OF STMT
PARSE #18:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=190280724
FETCH #15:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=4,tim=190280724
FETCH #15:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=4,tim=190280724
FETCH #15:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=4,tim=190280724
FETCH #15:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=4,tim=190280724
FETCH #15:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=4,tim=190280724
FETCH #15:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=4,tim=190280724
FETCH #15:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=4,tim=190280724
FETCH #15:c=0,e=1,p=0,cr=0,cu=0,mis=0,r=2,dep=0,og=4,tim=190280725
EXEC #16:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=190280725
FETCH #16:c=0,e=4,p=0,cr=156,cu=9,mis=0,r=0,dep=0,og=4,tim=190280729
From this I can see there are "exec" and "fetch" is occuring in different cursors to the SQL statement cursor used for the parse.
My question is now what would cause something like this for an insert statement?
Thanks
Patrick

There are several examples and a detailed explanation of Explain Plan at:
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/ex_plan.htm
Regarding TKPROF:
http://download-west.oracle.com/docs/cd/B19306_01/server.102/b14211/sqltrace.htm Check the 20.4 point

Diffrence between cpu and elapse time in tkprof

Hi All
i found huge diffrence between cpu and elapsed time in tkprof. can you please advice me on this issue.
>call count cpu elapsed disk query current rows
==================================================
Parse 1 0.12 1.36 2 11 0 0
Execute 1 14.30 720.20 46548 190520 205 100
Fetch 0 0.00 0.00 0 0 0 0
======================================================
total 2 14.42 721.56 46550 190531 205 100
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 173 (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on Times waited Max. Wait Total Waited
===========================================
db file sequential read 46544 0.49 632.12
db file scattered read 1 0.00 0.00
my select statement
SELECT cst.customer_id> ,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.trx_date) / COUNT(cr.deposit_date))) avgdays
> ,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.due_date) / COUNT(cr.deposit_date))) avgdayslate
> ,NVL(SUM(DECODE(SIGN(cr.deposit_date - ps.due_date),1, 1, 0)), 0) newlate
> ,NVL(SUM( DECODE(SIGN(cr.deposit_date - ps.due_date),1, 0, 1)), 0) newontime
>
> FROM ar_receivable_applications_all ra
> ,ar_cash_receipts_all cr
> ,ar_payment_schedules_all ps
> ,zz_ar_customer_summary_all cst
> WHERE ra.cash_receipt_id = cr.cash_receipt_id
> AND ra.apply_date BETWEEN ADD_MONTHS(SYSDATE, -12) AND SYSDATE
> AND ra.status = 'APP'
> AND ra.display = 'Y'
> AND ra.applied_payment_schedule_id = ps.payment_schedule_id
> AND ps.customer_id = cst.customer_id
> AND NVL(ps.receipt_confirmed_flag,'Y') = 'Y'
> group by cst.customer_id ;
Thanks,
Anu

user653066 wrote:
Hi All
i found huge diffrence between cpu and elapsed time in tkprof. can you please advice me on this issue.
call     count       cpu    elapsed       disk      query    current        rows
================================================================================
Parse        1      0.12       1.36          2         11          0           0
Execute      1     14.30     720.20      46548     190520        205         100
Fetch        0      0.00       0.00          0          0          0           0
================================================================================
total        2     14.42     721.56      46550     190531        205         100
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 173     (recursive depth: 1)
Elapsed times include waiting on following events:
Event waited on                      Times waited   Max. Wait Total Waited
===========================================================================
db file sequential read                     46544        0.49        632.12
db file scattered read                          1        0.00          0.00
SELECT cst.customer_id
         ,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.trx_date) / COUNT(cr.deposit_date))) avgdays
         ,DECODE(COUNT(cr.deposit_date), 0, 0, ROUND(SUM(cr.deposit_date - ps.due_date) / COUNT(cr.deposit_date))) avgdayslate
         ,NVL(SUM(DECODE(SIGN(cr.deposit_date - ps.due_date),1, 1, 0)), 0) newlate
         ,NVL(SUM( DECODE(SIGN(cr.deposit_date - ps.due_date),1, 0, 1)), 0) newontime
          FROM ar_receivable_applications_all ra
              ,ar_cash_receipts_all           cr
              ,ar_payment_schedules_all       ps
              ,zz_ar_customer_summary_all cst
          WHERE ra.cash_receipt_id                 = cr.cash_receipt_id
          AND   ra.apply_date                BETWEEN ADD_MONTHS(SYSDATE, -12) AND SYSDATE
          AND   ra.status                          = 'APP'
          AND   ra.display                         = 'Y'
          AND   ra.applied_payment_schedule_id     = ps.payment_schedule_id
          AND   ps.customer_id                     = cst.customer_id
          AND   NVL(ps.receipt_confirmed_flag,'Y') = 'Y'
          group by cst.customer_id    ;           Toon Koppelaars seems to have pinpointed the problem. Where are the 74 seconds unaccounted for seconds (I might have calculated it incorrectly, but I arrived at 88.08 seconds of unaccounted for time: 721.56 total - 1.36 parse - 632.12 db file sequential reads)?
It is interesting that the maximum wait for a single block read reported by TKPROF is 0.49 seconds - this might be an indication of excessive competition for the server's CPU - processes are waiting in the CPU run queue, and therefore not on the CPU. As Toon indicated, 632.12 of the 721.56 seconds were spent waiting for single block reads to complete with 46,544 blocks read. Note also that the query executed at dep=1, and TKPROF may be providing misleading information about what actually happened during those executions. An example of misleading information:
CREATE TABLE T11 (
C1 NUMBER,
C2 VARCHAR2(30));
CREATE TABLE T12 (
C1 NUMBER,
C2 VARCHAR2(30));
CREATE TABLE T13 (
C1 NUMBER,
C2 VARCHAR2(30));
CREATE TABLE T14 (
C1 NUMBER,
C2 VARCHAR2(30));
CREATE OR REPLACE TRIGGER HPM_T11 AFTER
INSERT OR DELETE OR UPDATE OF C1 ON T11
REFERENCING OLD AS OLDDATA NEW AS NEWDATA FOR EACH ROW
BEGIN
IF INSERTING THEN
    INSERT INTO T12
    SELECT
      ROWNUM,
      DBMS_RANDOM.STRING('A',25)
    FROM
      DUAL
    CONNECT BY
      LEVEL <= 100;
END IF;
END;
CREATE OR REPLACE TRIGGER HPM_T12 AFTER
INSERT OR DELETE OR UPDATE OF C1 ON T12
REFERENCING OLD AS OLDDATA NEW AS NEWDATA FOR EACH ROW
BEGIN
IF INSERTING THEN
    INSERT INTO T13
    SELECT
      ROWNUM,
      DBMS_RANDOM.STRING('A',25)
    FROM
      DUAL
    CONNECT BY
      LEVEL <= 100;
END IF;
END;
CREATE OR REPLACE TRIGGER HPM_T13 AFTER
INSERT OR DELETE OR UPDATE OF C1 ON T13
REFERENCING OLD AS OLDDATA NEW AS NEWDATA FOR EACH ROW
BEGIN
IF INSERTING THEN
    INSERT INTO T14
    SELECT
      ROWNUM,
      DBMS_RANDOM.STRING('A',25)
    FROM
      DUAL
    CONNECT BY
      LEVEL <= 100;
END IF;
END;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'MY_TEST_FIND_ME2';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
SET TIMING ON
INSERT INTO T11 VALUES (1,'MY LITTLE TEST CASE');
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT OFF';The partial TKPROF output:
INSERT INTO T11
VALUES
(1,'MY LITTLE TEST CASE')
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          8          0           0
Execute      1      0.00       0.00          0       9788         29           1
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.00       0.00          0       9796         29           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=9788 pr=7 pw=0 time=0 us)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
SQL*Net message to client                       1        0.00          0.00
SQL*Net message from client                     1        0.00          0.00
SQL ID : 6asaf110fgaqg
INSERT INTO T12 SELECT ROWNUM, DBMS_RANDOM.STRING('A',25) FROM DUAL CONNECT
BY LEVEL <= 100
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.04       0.09          0          2        130         100
Fetch        0      0.00       0.00          0          0          0           0
total        2      0.04       0.09          0          2        130         100
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 1)
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=9754 pr=7 pw=0 time=0 us)
    100   COUNT (cr=0 pr=0 pw=0 time=0 us)
    100    CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=0 us)
      1     FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
SQL ID : db46bkvy509w4
INSERT INTO T13 SELECT ROWNUM, DBMS_RANDOM.STRING('A',25) FROM DUAL CONNECT
BY LEVEL <= 100
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute    100      1.31       1.27          0         93      10634       10000
Fetch        0      0.00       0.00          0          0          0           0
total      101      1.31       1.27          0         93      10634       10000
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 2)
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=164 pr=0 pw=0 time=0 us)
    100   COUNT (cr=0 pr=0 pw=0 time=0 us)
    100    CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=0 us)
      1     FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
SQL ID : 6542yyk084rpu
INSERT INTO T14 SELECT ROWNUM, DBMS_RANDOM.STRING('A',25) FROM DUAL CONNECT
BY LEVEL <= 100
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute 10001     41.60      41.84          0       8961      52859     1000000
Fetch        0      0.00       0.00          0          0          0           0
total    10003     41.60      41.84          0       8961      52859     1000000
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 3)
Rows     Row Source Operation
      0 LOAD TABLE CONVENTIONAL (cr=2 pr=0 pw=0 time=0 us)
    100   COUNT (cr=0 pr=0 pw=0 time=0 us)
    100    CONNECT BY WITHOUT FILTERING (cr=0 pr=0 pw=0 time=0 us)
      1     FAST DUAL (cr=0 pr=0 pw=0 time=0 us cost=2 size=0 card=1)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
log file switch completion                      2        0.07          0.07
********************************************************************************In the above note that the "INSERT INTO T11" is reported as completing in 0 seconds, but it actually required roughly 42 seconds - and that would be visible by manually reviewing the resulting trace file. Also note that the log file switch completion wait was not reported for the "INSERT INTO T11" even though it impacted the execution time.
Back to the possibility of CPU starvation causing lost time. Another test with an otherwise idle server, followed by a second test with the same server having 240 other processes fighting for CPU resources (a simulated load).
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'MY_TEST_QUERY_NO_LOAD';
ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 8';
SET TIMING ON
SELECT
COUNT(*)
FROM
T14;
SELECT
SYSDATE
FROM
DUAL;
SQL> SELECT
2    COUNT(*)
3 FROM
4    T14;
COUNT(*)
   1000000
Elapsed: 00:00:01.37With no load the COUNT(*) completed in 1.37 seconds. The TKPROF output looks like this:
SQL ID : gy8nw9xzyg3bj
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ NO_PARALLEL("T14") FULL("T14") NO_PARALLEL_INDEX("T14") */
:"SYS_B_2" AS C1, :"SYS_B_3" AS C2 FROM "T14" SAMPLE BLOCK (:"SYS_B_4" ,
:"SYS_B_5") SEED (:"SYS_B_6") "T14") SAMPLESUB
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.01       0.84        523        172          1           1
total        3      0.01       0.84        523        172          1           1
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 1)
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=172 pr=523 pw=0 time=0 us)
   8733   TABLE ACCESS SAMPLE T14 (cr=172 pr=523 pw=0 time=0 us cost=2 size=12 card=1)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         3        0.02          0.04
db file parallel read                           1        0.31          0.31
db file scattered read                         52        0.03          0.47
SQL ID : 96g93hntrzjtr
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#,
sample_size, minimum, maximum, distcnt, lowval, hival, density, col#,
spare1, spare2, avgcln
from
hist_head$ where obj#=:1 and intcol#=:2
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.06          2          2          0           0
total        3      0.00       0.06          2          2          0           0
Misses in library cache during parse: 0
Optimizer mode: RULE
Parsing user id: SYS   (recursive depth: 2)
Rows     Row Source Operation
      0 TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=2 pr=2 pw=0 time=0 us)
      0   INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=2 pr=2 pw=0 time=0 us)(object id 413)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         2        0.02          0.04
SELECT
COUNT(*)
FROM
T14
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          1          1          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.03       0.43       6558       6983          0           1
total        4      0.03       0.44       6559       6984          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=6983 pr=6558 pw=0 time=0 us)
1000000   TABLE ACCESS FULL T14 (cr=6983 pr=6558 pw=0 time=0 us cost=1916 size=0 card=976987)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         1        0.02          0.02
SQL*Net message to client                       2        0.00          0.00
db file scattered read                        111        0.02          0.38
SQL*Net message from client                     2        0.00          0.00Note that TKPROF reported that it only required 0.44 seconds for the query to execute while the SQL*Plus timing indicate that it required 1.37 seconds for the SQL statement to execute. The SQL optimization (parse) with dynamic sampling query accounted for the remaining time, yet TKPROF provided no indication that this was the case.
Now the query with 240 other processes competing for CPU time:
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SESSION SET TRACEFILE_IDENTIFIER = 'MY_TEST_QUERY_WITH_LOAD';
SELECT COUNT(*) FROM T14;
SELECT
SYSDATE
FROM
DUAL;
SQL> SELECT COUNT(*) FROM T14;
COUNT(*)
   1000000
Elapsed: 00:00:59.03The query this time required just over 59 seconds. The TKPROF output:
SQL ID : gy8nw9xzyg3bj
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),:"SYS_B_0"),
NVL(SUM(C2),:"SYS_B_1")
FROM
(SELECT /*+ NO_PARALLEL("T14") FULL("T14") NO_PARALLEL_INDEX("T14") */
:"SYS_B_2" AS C1, :"SYS_B_3" AS C2 FROM "T14" SAMPLE BLOCK (:"SYS_B_4" ,
:"SYS_B_5") SEED (:"SYS_B_6") "T14") SAMPLESUB
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.28        423         69          0           1
total        3      0.00       0.28        423         69          0           1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 56     (recursive depth: 1)
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=69 pr=423 pw=0 time=0 us)
   8733   TABLE ACCESS SAMPLE T14 (cr=69 pr=423 pw=0 time=0 us cost=2 size=12 card=1)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file scattered read                         54        0.01          0.27
db file sequential read                         2        0.00          0.00
SQL ID : 7h04kxpa13w1x
SELECT COUNT(*)
FROM
T14
call     count       cpu    elapsed       disk      query    current        rows
Parse        1      0.00       0.03          1          1          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        2      0.06      58.71       6551       6983          0           1
total        4      0.06      58.74       6552       6984          0           1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 56
Rows     Row Source Operation
      1 SORT AGGREGATE (cr=6983 pr=6551 pw=0 time=0 us)
1000000   TABLE ACCESS FULL T14 (cr=6983 pr=6551 pw=0 time=0 us cost=1916 size=0 card=976987)
Elapsed times include waiting on following events:
Event waited on                             Times   Max. Wait Total Waited
----------------------------------------   Waited ---------- ------------
db file sequential read                         1        0.02          0.02
SQL*Net message to client                       2        0.00          0.00
db file scattered read                        110        1.54         58.59
SQL*Net message from client                     1        0.00          0.00Note in the above that the max wait for the db file scattered read is 1.54 seconds due to the extra CPU competition - about 3 times longer than your max wait for a single block read. On your database platform with single block reads, it might be possible that the time in the CPU run queue is not always counted in the db file sequential read wait time or the CPU wait time - what if your operating system is slow at returning timing information to the database instance due to CPU saturation - this might explain the 74 (or 88) lost seconds.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.
Edited by: Charles Hooper on Aug 28, 2009 10:26 AM
Fixing formatting problems

Get the session trace files and also the TKPROF reports for storedprocedure

Hi ,
I am trying to find out the bottlenecks on a storedprocedure, which does a insert into a table, where the target table has lot of indexes/constraints, so i want to see, which indexes/constraints is causing the problem. so in order to do I want to get the session trace files and also the TKPROF reports to see the bottlenecks for a oracle stored procedure,
Could you please give us the list of steps to get the tracefiles and tkprof reports.

781649 wrote:
Thanks for input, i am using oracle10g standard edition. i dont think i have these tools available (DBMS_PROFILER or DBMS_HPROF). Did you even bother to try the following?
SQL> DESC DBMS_PROFILER
SQL> DESC DBMS_HPROF
I understand it would be too much to expect you to actually Read The Fine Manual
I am using bulk collect for all in my storedprocedure to insert the rows into a big table. In order to perform analysis on this bulk collect which tool will help me to identify the bottlenecks .
I want to compare background session properties for both runs (like inserting the data with indexes/constraints vs without indexes/constraints). please let me know..I am willing to bet you the problem/slowness is on the SELECT side & not the INSERT!
Just Curious
Handle:      781649
Status Level:      Newbie
Registered:      Jul 12, 2010
Total Posts:      35
Total Questions:      17 (14 unresolved)
Why so many unanswered questions?
Edited by: sb92075 on Jan 17, 2012 3:13 PM

TKPROF and DB mismatch

Hi,
Right now we have the Oracle DB version 9.2.0.5.0, and TKPROF version is 8.0.6.3.0 as I get the following in the TKPROF header and I have taken the TKPROF from UNIX Box(Application Tier)
TKPROF: Release 8.0.6.3.0 - Production on Mon Dec 14 15:53:15 2009
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Trace file: xxxxxxxxx.trc
Sort options: default
I want to take the TKPROF from the latest version 9.2.0.5.0
Any pointers on how do i take the TKPROF from 9.2.0.5.0 rather than 8.0.6.3.0
Thanks,
Kiran

Hi,
there are three ORACLE_HOME in Oracle Apps, Two for Application Tier (Middleware) and One in Database Tier.
*ORACLE_HOME 1 : On Application Tier used to store 8.0.6 techstack software. this is used by forms, reports & discoverer. ORACLE_HOME should point to this ORACLE_HOME while applying Apps Patch.
* ORACLE_HOME 2: On Application Tier used by iAS (web server) techstack software. this is used by Web Listener & Apache.
* ORACLE_HOME 3: On Database Tier used by Database Software 8i,9i or 10g database.
Regards

What is the difference between tkprof and explainplan

Hi,
what is the difference between tkprof and explainplan.

Execution Plans and the EXPLAIN PLAN Statement
Before the database server can execute a SQL statement, Oracle must first parse the statement and develop an execution plan. The execution plan is a task list of sorts that decomposes a potentially complex SQL operation into a series of basic data access operations. For example, a query against the dept table might have an execution plan that consists of an index lookup on the deptno index, followed by a table access by ROWID.
The EXPLAIN PLAN statement allows you to submit a SQL statement to Oracle and have the database prepare the execution plan for the statement without actually executing it. The execution plan is made available to you in the form of rows inserted into a special table called a plan table. You may query the rows in the plan table using ordinary SELECT statements in order to see the steps of the execution plan for the statement you explained. You may keep multiple execution plans in the plan table by assigning each a unique statement_id. Or you may choose to delete the rows from the plan table after you are finished looking at the execution plan. You can also roll back an EXPLAIN PLAN statement in order to remove the execution plan from the plan table.
The EXPLAIN PLAN statement runs very quickly, even if the statement being explained is a query that might run for hours. This is because the statement is simply parsed and its execution plan saved into the plan table. The actual statement is never executed by EXPLAIN PLAN. Along these same lines, if the statement being explained includes bind variables, the variables never need to actually be bound. The values that would be bound are not relevant since the statement is not actually executed.
You don’t need any special system privileges in order to use the EXPLAIN PLAN statement. However, you do need to have INSERT privileges on the plan table, and you must have sufficient privileges to execute the statement you are trying to explain. The one difference is that in order to explain a statement that involves views, you must have privileges on all of the tables that make up the view. If you don’t, you’ll get an “ORA-01039: insufficient privileges on underlying objects of the view” error.
The columns that make up the plan table are as follows:
Name Null? Type
STATEMENT_ID VARCHAR2(30)
TIMESTAMP DATE
REMARKS VARCHAR2(80)
OPERATION VARCHAR2(30)
OPTIONS VARCHAR2(30)
OBJECT_NODE VARCHAR2(128)
OBJECT_OWNER VARCHAR2(30)
OBJECT_NAME VARCHAR2(30)
OBJECT_INSTANCE NUMBER(38)
OBJECT_TYPE VARCHAR2(30)
OPTIMIZER VARCHAR2(255)
SEARCH_COLUMNS NUMBER
ID NUMBER(38)
PARENT_ID NUMBER(38)
POSITION NUMBER(38)
COST NUMBER(38)
CARDINALITY NUMBER(38)
BYTES NUMBER(38)
OTHER_TAG VARCHAR2(255)
PARTITION_START VARCHAR2(255)
PARTITION_STOP VARCHAR2(255)
PARTITION_ID NUMBER(38)
OTHER LONG
DISTRIBUTION VARCHAR2(30)
There are other ways to view execution plans besides issuing the EXPLAIN PLAN statement and querying the plan table. SQL*Plus can automatically display an execution plan after each statement is executed. Also, there are many GUI tools available that allow you to click on a SQL statement in the shared pool and view its execution plan. In addition, TKPROF can optionally include execution plans in its reports as well.
Trace Files and the TKPROF Utility
TKPROF is a utility that you invoke at the operating system level in order to analyze SQL trace files and generate reports that present the trace information in a readable form. Although the details of how you invoke TKPROF vary from one platform to the next, Oracle Corporation provides TKPROF with all releases of the database and the basic functionality is the same on all platforms.
The term trace file may be a bit confusing. More recent releases of the database offer a product called Oracle Trace Collection Services. Also, Net8 is capable of generating trace files. SQL trace files are entirely different. SQL trace is a facility that you enable or disable for individual database sessions or for the entire instance as a whole. When SQL trace is enabled for a database session, the Oracle server process handling that session writes detailed information about all database calls and operations to a trace file. Special database events may be set in order to cause Oracle to write even more specific information—such as the values of bind variables—into the trace file.
SQL trace files are text files that, strictly speaking, are human readable. However, they are extremely verbose, repetitive, and cryptic. For example, if an application opens a cursor and fetches 1000 rows from the cursor one row at a time, there will be over 1000 separate entries in the trace file.
TKPROF is a program that you invoke at the operating system command prompt in order to reformat the trace file into a format that is much easier to comprehend. Each SQL statement is displayed in the report, along with counts of how many times it was parsed, executed, and fetched. CPU time, elapsed time, logical reads, physical reads, and rows processed are also reported, along with information about recursion level and misses in the library cache. TKPROF can also optionally include the execution plan for each SQL statement in the report, along with counts of how many rows were processed at each step of the execution plan.
The SQL statements can be listed in a TKPROF report in the order of how much resource they used, if desired. Also, recursive SQL statements issued by the SYS user to manage the data dictionary can be included or excluded, and TKPROF can write SQL statements from the traced session into a spool file.
How EXPLAIN PLAN and TKPROF Aid in the Application Tuning Process
EXPLAIN PLAN and TKPROF are valuable tools in the tuning process. Tuning at the application level typically yields the most dramatic results, and these two tools can help with the tuning in many different ways.
EXPLAIN PLAN and TKPROF allow you to proactively tune an application while it is in development. It is relatively easy to enable SQL trace, run an application in a test environment, run TKPROF on the trace file, and review the output to determine if application or schema changes are called for. EXPLAIN PLAN is handy for evaluating individual SQL statements.
By reviewing execution plans, you can also validate the scalability of an application. If the database operations are dependent upon full table scans of tables that could grow quite large, then there may be scalability problems ahead. On the other hand, if large tables are accessed via selective indexes, then scalability may not be a problem.
EXPLAIN PLAN and TKPROF may also be used in an existing production environment in order to zero in on resource intensive operations and get insights into how the code may be optimized. TKPROF can further be used to quantify the resources required by specific database operations or application functions.
EXPLAIN PLAN is also handy for estimating resource requirements in advance. Suppose you have an ad hoc reporting request against a very large database. Running queries through EXPLAIN PLAN will let you determine in advance if the queries are feasible or if they will be resource intensive and will take unacceptably long to run.

Htmldb_collection and db read

Is there a way to force sequential read over scattered read when using htmldb_collection.add_member?
I have traced an issue with response time to the following section of my code:
if length(dcg) > 1 then
          htmldb_collection.add_member(
               p_collection_name => 'DCGCOLLECTION',
               p_c001 => shuttle_rec.obt_seq_id,
               p_c002 => dcg,
               p_generate_md5 => 'NO');
end if;
Here is what I am seeing in TKPROF (sorry I can not get the execution report section formatted better). I attempted to recreate the same flow each time, but because I can not predict when the different reads will happen it is difficult. Therefore I have cut and pasted the corresponding sections of the two trace and tkprof output files below.
You will see that when the system responds as desired, it is using INDEX RANGE SCAN WWV_FLOW_COLLECTION_MEMBERS_PK and db file sequential read. When response time is slow it uses INDEX FAST FULL SCAN WWV_FLOW_COLLECTION_MEMBERS_PK and db file scattered read.
FAST RESPONSE:
TRACE FILE just enough to show the collection name (value=)
SELECT NVL(MAX(SEQ_ID),0) MAXSEQ FROM WWV_FLOW_COLLECTIONS$ C, WWV_FLOW_COLLECTION_MEMBERS$ M WHERE C.SESSION_ID = V('SESSION') AND C.USER_ID = :B4 AND C.SECURITY_GROUP_ID = :B3 AND C.FLOW_ID = :B2 AND C.ID = M.COLLECTION_ID AND C.COLLECTION_NAME = UPPER(:B1 )
END OF STMT
PARSE #53:c=0,e=81,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=1,tim=4046522821
BINDS #53:
bind 0: dty=1 mxl=2000(255) mal=00 scl=00 pre=00 oacflg=03 oacfl2=206001 size=2080 offset=0
bfp=091722d4 bln=2000 avl=04 flg=05
value="RICH"
bind 1: dty=2 mxl=22(21) mal=00 scl=00 pre=00 oacflg=03 oacfl2=206001 size=0 offset=2000
bfp=09172aa4 bln=22 avl=09 flg=01
value=1807302131050935
bind 2: dty=2 mxl=22(21) mal=00 scl=00 pre=00 oacflg=03 oacfl2=206001 size=0 offset=2024
bfp=09172abc bln=22 avl=03 flg=01
value=106
bind 3: dty=1 mxl=32(13) mal=00 scl=00 pre=00 oacflg=03 oacfl2=206001 size=0 offset=2048
bfp=09172ad4 bln=32 avl=13 flg=01
value="DCGCOLLECTION"
TKPROF
SELECT NVL(MAX(SEQ_ID),0) MAXSEQ
FROM
WWV_FLOW_COLLECTIONS$ C, WWV_FLOW_COLLECTION_MEMBERS$ M WHERE C.SESSION_ID =
V('SESSION') AND C.USER_ID = :B4 AND C.SECURITY_GROUP_ID = :B3 AND
C.FLOW_ID = :B2 AND C.ID = M.COLLECTION_ID AND C.COLLECTION_NAME =
UPPER(:B1 )
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 226 0.03 0.07 0 0 0 0
Fetch 226 0.01 0.03 3 1145 0 226
total 454 0.04 0.10 3 1145 0 226
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 67 (recursive depth: 2)
Rows Row Source Operation
2 SORT AGGREGATE (cr=10 pr=3 pw=0 time=18198 us)
0 NESTED LOOPS (cr=10 pr=3 pw=0 time=18167 us)
2 TABLE ACCESS BY INDEX ROWID WWV_FLOW_COLLECTIONS$ (cr=4 pr=0 pw=0 time=277 us)
2 INDEX UNIQUE SCAN WWV_FLOW_COLLECTIONS_UK (cr=2 pr=0 pw=0 time=238 us)(object id 52046)
0 INDEX RANGE SCAN WWV_FLOW_COLLECTION_MEMBERS_PK (cr=6 pr=3 pw=0 time=17876 us)(object id 52050)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 3 0.00 0.01
INSERT INTO WWV_FLOW_COLLECTION_MEMBERS$( COLLECTION_ID, SEQ_ID, C001, C002,
C003, C004, C005, C006, C007, C008, C009, C010, C011, C012, C013, C014,
C015, C016, C017, C018, C019, C020, C021, C022, C023, C024, C025, C026,
C027, C028, C029, C030, C031, C032, C033, C034, C035, C036, C037, C038,
C039, C040, C041, C042, C043, C044, C045, C046, C047, C048, C049, C050,
MD5_ORIGINAL )
VALUES
( :B53 , :B52 , :B51 , :B50 , :B49 , :B48 , :B47 , :B46 , :B45 , :B44 , :B43 ,
:B42 , :B41 , :B40 , :B39 , :B38 , :B37 , :B36 , :B35 , :B34 , :B33 , :B32
, :B31 , :B30 , :B29 , :B28 , :B27 , :B26 , :B25 , :B24 , :B23 , :B22 ,
:B21 , :B20 , :B19 , :B18 , :B17 , :B16 , :B15 , :B14 , :B13 , :B12 , :B11 ,
:B10 , :B9 , :B8 , :B7 , :B6 , :B5 , :B4 , :B3 , :B2 , :B1 )
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 59 0.12 0.12 7 30 311 59
Fetch 0 0.00 0.00 0 0 0 0
total 60 0.14 0.13 7 30 311 59
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 67 (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 6 0.00 0.02
UPDATE WWV_FLOW_COLLECTIONS$ SET COLLECTION_CHANGED = 'Y'
WHERE
ID = :B1 AND COLLECTION_CHANGED = 'N'
call count cpu elapsed disk query current rows
Parse 2 0.01 0.00 0 0 0 0
Execute 226 0.01 0.02 0 452 18 6
Fetch 0 0.00 0.00 0 0 0 0
total 228 0.03 0.03 0 452 18 6
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 67 (recursive depth: 2)
Rows Row Source Operation
2 UPDATE (cr=4 pr=0 pw=0 time=476 us)
2 TABLE ACCESS BY INDEX ROWID WWV_FLOW_COLLECTIONS$ (cr=4 pr=0 pw=0 time=66 us)
2 INDEX UNIQUE SCAN WWV_FLOW_COLLECTIONS_PK (cr=2 pr=0 pw=0 time=38 us)(object id 52045)
SLOW RESPONSE:
TRACE FILE just enough to show the collection name (value=)
SELECT NVL(MAX(SEQ_ID),0) MAXSEQ FROM WWV_FLOW_COLLECTIONS$ C, WWV_FLOW_COLLECTION_MEMBERS$ M WHERE C.SESSION_ID = V('SESSION') AND C.USER_ID = :B4 AND C.SECURITY_GROUP_ID = :B3 AND C.FLOW_ID = :B2 AND C.ID = M.COLLECTION_ID AND C.COLLECTION_NAME = UPPER(:B1 )
END OF STMT
PARSE #39:c=0,e=89,p=0,cr=0,cu=0,mis=0,r=0,dep=2,og=1,tim=1298905691
BINDS #39:
bind 0: dty=1 mxl=2000(255) mal=00 scl=00 pre=00 oacflg=03 oacfl2=206001 size=2080 offset=0
bfp=06250cb8 bln=2000 avl=04 flg=05
value="RICH"
bind 1: dty=2 mxl=22(21) mal=00 scl=00 pre=00 oacflg=03 oacfl2=206001 size=0 offset=2000
bfp=06251488 bln=22 avl=09 flg=01
value=1807302131050935
bind 2: dty=2 mxl=22(21) mal=00 scl=00 pre=00 oacflg=03 oacfl2=206001 size=0 offset=2024
bfp=062514a0 bln=22 avl=03 flg=01
value=106
bind 3: dty=1 mxl=32(13) mal=00 scl=00 pre=00 oacflg=03 oacfl2=206001 size=0 offset=2048
bfp=062514b8 bln=32 avl=13 flg=01
value="DCGCOLLECTION"
TKPROF
SELECT NVL(MAX(SEQ_ID),0) MAXSEQ
FROM
WWV_FLOW_COLLECTIONS$ C, WWV_FLOW_COLLECTION_MEMBERS$ M WHERE C.SESSION_ID =
V('SESSION') AND C.USER_ID = :B4 AND C.SECURITY_GROUP_ID = :B3 AND
C.FLOW_ID = :B2 AND C.ID = M.COLLECTION_ID AND C.COLLECTION_NAME =
UPPER(:B1 )
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 224 0.10 0.06 0 0 0 0
Fetch 224 32.37 603.54 1916959 1923042 0 224
total 449 32.48 603.61 1916959 1923042 0 224
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 67 (recursive depth: 2)
Rows Row Source Operation
224 SORT AGGREGATE (cr=1923042 pr=1916959 pw=0 time=603553959 us)
6160 NESTED LOOPS (cr=1923042 pr=1916959 pw=0 time=73040535 us)
224 TABLE ACCESS BY INDEX ROWID WWV_FLOW_COLLECTIONS$ (cr=448 pr=0 pw=0 time=21810 us)
224 INDEX UNIQUE SCAN WWV_FLOW_COLLECTIONS_UK (cr=224 pr=0 pw=0 time=18572 us)(object id 52046)
6160 INDEX FAST FULL SCAN WWV_FLOW_COLLECTION_MEMBERS_PK (cr=1922594 pr=1916959 pw=0 time=73009271 us)(object id 52050)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file scattered read 124352 0.03 588.32
INSERT INTO WWV_FLOW_COLLECTION_MEMBERS$( COLLECTION_ID, SEQ_ID, C001, C002,
C003, C004, C005, C006, C007, C008, C009, C010, C011, C012, C013, C014,
C015, C016, C017, C018, C019, C020, C021, C022, C023, C024, C025, C026,
C027, C028, C029, C030, C031, C032, C033, C034, C035, C036, C037, C038,
C039, C040, C041, C042, C043, C044, C045, C046, C047, C048, C049, C050,
CLOB001, MD5_ORIGINAL )
VALUES
( :B54 , :B53 , :B52 , :B51 , :B50 , :B49 , :B48 , :B47 , :B46 , :B45 , :B44 ,
:B43 , :B42 , :B41 , :B40 , :B39 , :B38 , :B37 , :B36 , :B35 , :B34 , :B33
, :B32 , :B31 , :B30 , :B29 , :B28 , :B27 , :B26 , :B25 , :B24 , :B23 ,
:B22 , :B21 , :B20 , :B19 , :B18 , :B17 , :B16 , :B15 , :B14 , :B13 , :B12 ,
:B11 , :B10 , :B9 , :B8 , :B7 , :B6 , :B5 , :B4 , :B3 , :B2 , :B1 )
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 224 0.39 0.57 190 11 1319 224
Fetch 0 0.00 0.00 0 0 0 0
total 225 0.39 0.57 190 11 1319 224
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 67 (recursive depth: 2)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 188 0.00 0.06
UPDATE WWV_FLOW_COLLECTIONS$ SET COLLECTION_CHANGED = 'Y'
WHERE
ID = :B1 AND COLLECTION_CHANGED = 'N'
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 224 0.01 0.03 0 448 12 4
Fetch 0 0.00 0.00 0 0 0 0
total 225 0.01 0.03 0 448 12 4
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 67 (recursive depth: 2)
Rows Row Source Operation
4 UPDATE (cr=448 pr=0 pw=0 time=9004 us)
4 TABLE ACCESS BY INDEX ROWID WWV_FLOW_COLLECTIONS$ (cr=448 pr=0 pw=0 time=7205 us)
224 INDEX UNIQUE SCAN WWV_FLOW_COLLECTIONS_PK (cr=224 pr=0 pw=0 time=4003 us)(object id 52045)
Thanks for any help.

Vikas,
     pga_aggregate_target = 25165824
     workarea_size_policy = AUTO
I have not run statistics on all tables in my development database, so I believe I am operating in Rules Based Optimization.
However, all pages running against tables in my database operate fine. It is not until I create an htmldb_collection by running a query against another htmldb_collection that I see slow response times.
Here is an overview of the process, and the steps I went through when tracing:
User logs in and is brought to the main page.
User selects Locate Agreements from a sidebar menu and is sent to a page with reports region built on the AGREEMENTS table (currently 450 rows in development).
User selects Costa Rica from a select list of terminating countries and the page is submitted and refreshed showing only Costa Rica agreements.
User clicks on the Edit link for an agreement and is sent to the details page for the selected record.
     Now that a specific agreement has been selected, this page fires the on-demand process load tier collections on load, after footer. This process is viewable by going to http://htmldb.oracle.com/pls/otn/f?p=23228:2:218044503435049191::::: and downloading. Processing time to this point is fine.
User selects Tiers from the sidebar menu and is sent to a page built on the htmldb_collection OBTCOLLECTION which was created by the load tier collections process.
     Here is where the delay occurs. This page fires the on-demand process load shuttle collections on load, after footer. This process is viewable by going to http://htmldb.oracle.com/pls/otn/f?p=23228:2:218044503435049191::::: and downloading. This process creates multiple htmldb_collections for use on the next page. Using a cursor to move through the OBTCOLLECTION (created earlier), four fields, each containing semi-colon delimited strings, are parsed and the values are inserted into the appropriate collections (DCGCOLLECTION, CITYCOLLECTION, PRODCOLLECTION, PRDCOLLECTION). It would appear, after looking at the trace files, that the creation of the DCGCOLLECTION is causing the biggest delay. This page will load in seconds when operating correctly, but takes as much as 10 minutes when it is not. I have seen this happen at all times of the day, and there is nothing else (nor anyone else) running on the server.
Richard

Sqltrace and tkprof

Similar Messages

Maybe you are looking for