Tkprof results
hii.. i'am using tkprof to learn cost,cpu time .. of my queries.
the test_1 and test_2 tables are same exactly.
i am comparing two states. First state , i am setting arraysize to 1, then i execute "select * from test_1". then, second state, i am setting arraysize to 2500, then i execute "select * from test_2".
so, output of first state of tkprof file is written below :
===
select *
from
test_1
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 10006 0.70 0.72 0 10767 0 10005
total 10008 0.71 0.72 0 10767 0 10005
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
===
and second state of output of tkprof is :
===
select *
from
test_2
call count cpu elapsed disk query current rows
Parse 1 0.00 0.02 0 1 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 5 0.06 0.07 0 28 0 10005
total 7 0.06 0.09 0 29 0 10005
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: SYS
===
i understood lots of things that are related this output. but, i am confused a bit.
1-) why the "disk" column of output is zero ? Is the reason "memory is enough"?
2-) why cpu time of parsing of first output is 0.01, and second's is 0.00 ? ( why differ)
3-) what is the elapsed time exactly? and why elapsed time of firstoutput is 0 and second's is 0.02?
4-)what is the differences "query" and "current" column exactly?
thats enough for the present.
thanx for responses.
Did you really read the link provided to you by Stevecallan?
And you are still asking these questions.
I read
Table 20-4 SQL Trace Statistics for Parses, Executes, and Fetches.
SQL Trace Statistic Meaning
COUNT
Number of times a statement was parsed, executed, or fetched.
CPU
Total CPU time in seconds for all parse, execute, or fetch calls for the statement. This value is zero (0) if TIMED_STATISTICS is not turned on.
ELAPSED
Total elapsed time in seconds for all parse, execute, or fetch calls for the statement. This value is zero (0) if TIMED_STATISTICS is not turned on.
DISK
Total number of data blocks physically read from the datafiles on disk for all parse, execute, or fetch calls.
QUERY
Total number of buffers retrieved in consistent mode for all parse, execute, or fetch calls. Usually, buffers are retrieved in consistent mode for queries.
CURRENT
Total number of buffers retrieved in current mode. Buffers are retrieved in current mode for statements such as INSERT, UPDATE, and DELETE.
The very answers to the questions you are asking!
Are you playing games or what?
Or do you just need a dictionary to look up the meaning of the word 'elapsed'
Sybrand Bakker
Senior Oracle DBA
Similar Messages
-
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?
thankssome 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 -
Different result comparing AWR to TKPROF
Hi,
I runned last night event 10046 on my database using the following commands:
ALTER SYSTEM SET statistics_level = ALL;
ALTER SYSTEM SET events '10046 trace name context forever, level 12';
Today, i compared a single statment from TKPROF result to the AWR and found
big different results:
The TKPROF shows:
Executions is : 1
elpased time is :51.39 seconds
cpu time is : 0.23 second
Gets per Exec is : 72
SELECT CM_CUST_DIM_INST_PROD.INST_PROD_ID, CM_CUST_DIM_INST_PROD.NAP_PRODUCT_ID, CM_CUST_DIM_INST_PROD.NAP_PACKEAGE, CM_CUST_DIM_INST_PROD.PRODUCT_ID, CM_CUST_DIM_INST_PROD.PRODUCT_DESCR, CM_CUST_DIM_INST_PROD.PRODUCT_GROUP, CM_CUST_DIM_INST_PROD.PRODUCT_GROUP_DESCR, CM_CUST_DIM_INST_PROD.PROD_CATEGORY, CM_CUST_DIM_INST_PROD.PROD_CATEGORY_DESCR, CM_CUST_DIM_INST_PROD.PROD_GRP_TYPE, CM_CUST_DIM_INST_PROD.PROD_GRP_TYPE_DESCR, CM_CUST_DIM_INST_PROD.NAP_AREA2, CM_CUST_DIM_INST_PROD.NAP_PHONE_NUM, CM_CUST_DIM_INST_PROD.NAP_CANCEL_DT, CM_CUST_DIM_INST_PROD.NAP_SERVICE_OPN_DT, CM_CUST_DIM_INST_PROD.NAP_MAKAT_CD, CM_CUST_DIM_INST_PROD.NAP_CRM_STATUS, CM_CUST_DIM_INST_PROD.NAP_CRM_STATUS_DESCR, CM_CUST_DIM_INST_PROD.NAP_RTRV_INSPRD_ID
FROM CM_CUST_DIM_INST_PROD ,
cm_ip_service_delta, cm_ip_service_delta cm_ip_service_delta2
WHERE CM_CUST_DIM_INST_PROD.prod_grp_type in ('INTR', 'HOST') and
CM_CUST_DIM_INST_PROD.Inst_Prod_Id = cm_ip_service_delta.inst_prod_id(+) and
CM_CUST_DIM_INST_PROD.Nap_Makat_Cd = cm_ip_service_delta.nap_billing_catnum(+)
and cm_ip_service_delta.nap_billing_catnum is null and
cm_ip_service_delta.inst_prod_id is null
and cm_ip_service_delta2.inst_prod_id = CM_CUST_DIM_INST_PROD.Nap_Packeage
ORDER BY INST_PROD_ID
call count cpu elapsed disk query current rows
Parse 1 0.01 0.03 0 22 0 0
Execute 1 0.02 1.79 0 32 0 0
Fetch 13 0.19 49.56 0 18 0 661
total 15 0.23 51.39 0 72 0 661
The AWR report shows
Executions is : 1
elpased time is :697.91 seconds
cpu time is :41.89 second
Gets per Exec is : 351,105.00
Executions Gets per Exec CPU Time (s) Elapsed Time (s) SQL Id SQL
1 351,105.00 41.89 697.91 6hh4jdx9dvjzw
6hh4jdx9dvjzw
SELECT CM_CUST_DIM_INST_PROD.INST_PROD_ID, CM_CUST_DIM_INST_PROD.NAP_PRODUCT_ID, CM_CUST_DIM_INST_PROD.NAP_PACKEAGE, CM_CUST_DIM_INST_PROD.PRODUCT_ID, CM_CUST_DIM_INST_PROD.PRODUCT_DESCR, CM_CUST_DIM_INST_PROD.PRODUCT_GROUP, CM_CUST_DIM_INST_PROD.PRODUCT_GROUP_DESCR, CM_CUST_DIM_INST_PROD.PROD_CATEGORY, CM_CUST_DIM_INST_PROD.PROD_CATEGORY_DESCR, CM_CUST_DIM_INST_PROD.PROD_GRP_TYPE, CM_CUST_DIM_INST_PROD.PROD_GRP_TYPE_DESCR, CM_CUST_DIM_INST_PROD.NAP_AREA2, CM_CUST_DIM_INST_PROD.NAP_PHONE_NUM, CM_CUST_DIM_INST_PROD.NAP_CANCEL_DT, CM_CUST_DIM_INST_PROD.NAP_SERVICE_OPN_DT, CM_CUST_DIM_INST_PROD.NAP_MAKAT_CD, CM_CUST_DIM_INST_PROD.NAP_CRM_STATUS, CM_CUST_DIM_INST_PROD.NAP_CRM_STATUS_DESCR, CM_CUST_DIM_INST_PROD.NAP_RTRV_INSPRD_ID FROM CM_CUST_DIM_INST_PROD , cm_ip_service_delta, cm_ip_service_delta cm_ip_service_delta2 WHERE CM_CUST_DIM_INST_PROD.prod_grp_type in ('INTR', 'HOST') and CM_CUST_DIM_INST_PROD.Inst_Prod_Id = cm_ip_service_delta.inst_prod_id(+) and CM_CUST_DIM_INST_PROD.Nap_Makat_Cd = cm_ip_service_delta.nap_billing_catnum(+) and cm_ip_service_delta.nap_billing_catnum is null and cm_ip_service_delta.inst_prod_id is null and cm_ip_service_delta2.inst_prod_id = CM_CUST_DIM_INST_PROD.Nap_Packeage ORDER BY INST_PROD_ID
Does one can explain the different results ?
Thank YouHi Virag,
I ran the statment from sqlplus and after that i generated an addm report:
As you can see below TKPROF show that elspaed time was : 50.76 second,
while ADDM show:
"was executed 1 times and had an average elapsed time of 751 seconds."
ALTER SESSION SET max_dump_file_size = unlimited;
ALTER SESSION SET tracefile_identifier = '10046';
ALTER SESSION SET statistics_level = ALL;
ALTER SESSION SET events '10046 trace name context forever, level 12';
SELECT CM_CUST_DIM_INST_PROD.INST_PROD_ID, CM_CUST_DIM_INST_PROD.NAP_PRODUCT_ID, CM_CUST_DIM_INST_PROD.NAP_PACKEAGE, CM_CUST_DIM_INST_PROD.PRODUCT_ID, CM_CUST_DIM_INST_PROD.PRODUCT_DESCR, CM_CUST_DIM_INST_PROD.PRODUCT_GROUP, CM_CUST_DIM_INST_PROD.PRODUCT_GROUP_DESCR, CM_CUST_DIM_INST_PROD.PROD_CATEGORY, CM_CUST_DIM_INST_PROD.PROD_CATEGORY_DESCR, CM_CUST_DIM_INST_PROD.PROD_GRP_TYPE, CM_CUST_DIM_INST_PROD.PROD_GRP_TYPE_DESCR, CM_CUST_DIM_INST_PROD.NAP_AREA2, CM_CUST_DIM_INST_PROD.NAP_PHONE_NUM, CM_CUST_DIM_INST_PROD.NAP_CANCEL_DT, CM_CUST_DIM_INST_PROD.NAP_SERVICE_OPN_DT, CM_CUST_DIM_INST_PROD.NAP_MAKAT_CD, CM_CUST_DIM_INST_PROD.NAP_CRM_STATUS, CM_CUST_DIM_INST_PROD.NAP_CRM_STATUS_DESCR, CM_CUST_DIM_INST_PROD.NAP_RTRV_INSPRD_ID
FROM CM_CUST_DIM_INST_PROD ,
cm_ip_service_delta, cm_ip_service_delta cm_ip_service_delta2
WHERE CM_CUST_DIM_INST_PROD.prod_grp_type in ('INTR', 'HOST') and
CM_CUST_DIM_INST_PROD.Inst_Prod_Id = cm_ip_service_delta.inst_prod_id(+) and
CM_CUST_DIM_INST_PROD.Nap_Makat_Cd = cm_ip_service_delta.nap_billing_catnum(+)
and cm_ip_service_delta.nap_billing_catnum is null and
cm_ip_service_delta.inst_prod_id is null
and cm_ip_service_delta2.inst_prod_id = CM_CUST_DIM_INST_PROD.Nap_Packeage
ORDER BY INST_PROD_ID
ALTER SESSION SET EVENTS '10046 trace name context off';
EXIT
call count cpu elapsed disk query current rows
Parse 1 0.05 0.05 0 0 0 0
Execute 1 0.02 1.96 24 32 0 0
Fetch 46 0.19 48.74 6 18 0 661
total 48 0.26 50.76 30 50 0 661
Rows Row Source Operation
661 PX COORDINATOR (cr=50 pr=30 pw=0 time=50699289 us)
0 PX SEND QC (ORDER) :TQ10003 (cr=0 pr=0 pw=0 time=0 us)
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND RANGE :TQ10002 (cr=0 pr=0 pw=0 time=0 us)
0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 HASH JOIN RIGHT OUTER (cr=0 pr=0 pw=0 time=0 us)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us)
3366 INDEX FAST FULL SCAN IDX_CM_SERVICE_DELTA (cr=9 pr=6 pw=0 time=47132 us)(object id 1547887)
0 HASH JOIN (cr=0 pr=0 pw=0 time=0 us)
0 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND BROADCAST :TQ10001 (cr=0 pr=0 pw=0 time=0 us)
3366 INDEX FAST FULL SCAN IDX_CM_SERVICE_DELTA (cr=9 pr=0 pw=0 time=20340 us)(object id 1547887)
0 PX BLOCK ITERATOR PARTITION: 1 4 (cr=0 pr=0 pw=0 time=0 us)
0 TABLE ACCESS FULL CM_CUST_DIM_INST_PROD PARTITION: 1 4 (cr=0 pr=0 pw=0 time=0 us)
RECOMMENDATION 1: SQL Tuning, 56% benefit (615 seconds)
ACTION: Run SQL Tuning Advisor on the SQL statement with SQL_ID
"6wd7sw8adqaxv".
RELEVANT OBJECT: SQL statement with SQL_ID 6wd7sw8adqaxv and
PLAN_HASH 2594021963
SELECT CM_CUST_DIM_INST_PROD.INST_PROD_ID,
CM_CUST_DIM_INST_PROD.NAP_PRODUCT_ID,
CM_CUST_DIM_INST_PROD.NAP_PACKEAGE, CM_CUST_DIM_INST_PROD.PRODUCT_ID,
CM_CUST_DIM_INST_PROD.PRODUCT_DESCR,
CM_CUST_DIM_INST_PROD.PRODUCT_GROUP,
CM_CUST_DIM_INST_PROD.PRODUCT_GROUP_DESCR,
CM_CUST_DIM_INST_PROD.PROD_CATEGORY,
CM_CUST_DIM_INST_PROD.PROD_CATEGORY_DESCR,
CM_CUST_DIM_INST_PROD.PROD_GRP_TYPE,
CM_CUST_DIM_INST_PROD.PROD_GRP_TYPE_DESCR,
CM_CUST_DIM_INST_PROD.NAP_AREA2, CM_CUST_DIM_INST_PROD.NAP_PHONE_NUM,
CM_CUST_DIM_INST_PROD.NAP_CANCEL_DT,
CM_CUST_DIM_INST_PROD.NAP_SERVICE_OPN_DT,
CM_CUST_DIM_INST_PROD.NAP_MAKAT_CD,
CM_CUST_DIM_INST_PROD.NAP_CRM_STATUS,
CM_CUST_DIM_INST_PROD.NAP_CRM_STATUS_DESCR,
CM_CUST_DIM_INST_PROD.NAP_RTRV_INSPRD_ID
FROM CM_CUST_DIM_INST_PROD ,
cm_ip_service_delta, cm_ip_service_delta cm_ip_service_delta2
WHERE CM_CUST_DIM_INST_PROD.prod_grp_type in ('INTR', 'HOST') and
CM_CUST_DIM_INST_PROD.Inst_Prod_Id =
cm_ip_service_delta.inst_prod_id(+) and
CM_CUST_DIM_INST_PROD.Nap_Makat_Cd =
cm_ip_service_delta.nap_billing_catnum(+)
and cm_ip_service_delta.nap_billing_catnum is null and
cm_ip_service_delta.inst_prod_id is null
and cm_ip_service_delta2.inst_prod_id =
CM_CUST_DIM_INST_PROD.Nap_Packeage
ORDER BY INST_PROD_ID
RATIONALE: SQL statement with SQL_ID "6wd7sw8adqaxv" was executed 1
times and had an average elapsed time of 751 seconds.
RATIONALE: At least one execution of the statement ran in parallel.
Thanks. -
Hi experts,
here i am showing the tkprof result.....
TKPROF: Release 9.2.0.1.0 - Production on Tue Oct 9 13:06:20 2012
Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
Trace file: c:\orcl_ora_4040_kamaltrc.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
DECLARE
P_MONTH VARCHAR2(32767);
P_YEAR VARCHAR2(32767);
BEGIN
P_MONTH := '11';
P_YEAR := '2012';
MOJ_PRD.CALC_PAYROLL ( P_MONTH, P_YEAR );
COMMIT;
END;
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 2 0.76 1.05 0 0 0 1
Fetch 0 0.00 0.00 0 0 0 0
total 3 0.78 1.06 0 0 0 1
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 63 (MOJ_PRD)
DELETE FROM HR_JUDGE_PRE_MONTH_SALARY_TEMP
WHERE 1 = 1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.03 0.09 27 72 6438 1231
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.03 0.09 27 72 6438 1231
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 63 (MOJ_PRD) (recursive depth: 1)
error during execute of EXPLAIN PLAN statement
ORA-00942: table or view does not exist
parse error offset: 80
DELETE FROM HR_JUDGE_ALW_DED_STD_TEMP
WHERE 1 = 1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.02 20 37 969 861
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.02 20 37 969 861
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 63 (MOJ_PRD) (recursive depth: 1)
error during execute of EXPLAIN PLAN statement
ORA-00942: table or view does not exist
parse error offset: 80
SELECT judge_code, date_of_joining, date_of_relieving,CONTRACT_TYPE_CODE
FROM HR_JUDGE_MASTER
WHERE enabled_flag = 'Y'
-- AND judge_code = '114899'
AND workflow_completion_status = 'Y'
AND include_pay = 'Y'
AND judge_status NOT IN ('000003', '000004', '000007')
-- AND date_of_relieving IS NULL
AND ( (date_of_relieving IS NULL)
OR (TO_DATE (TO_CHAR (date_of_relieving, 'MM/YYYY'), 'MM/YYYY') >=
TO_DATE (TO_CHAR (SYSDATE, 'MM/YYYY'), 'MM/YYYY')
AND judge_code IN (SELECT judge_code
FROM JUDGE_TEMP)
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 524 0.04 0.98 288 568 0 522
total 526 0.04 0.98 288 568 0 522
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 63 (MOJ_PRD) (recursive depth: 1)
error during execute of EXPLAIN PLAN statement
ORA-00942: table or view does not exist
parse error offset: 154
INSERT INTO HR_JUDGE_ALW_DED_STD_TEMP
SELECT *
FROM HR_JUDGE_ALW_DED
WHERE percent_value_tag = 'S' AND judge_code = :b1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 261 0.07 3.02 464 2926 269 861
Fetch 0 0.00 0.00 0 0 0 0
total 261 0.07 3.02 464 2926 269 861
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 63 (MOJ_PRD) (recursive depth: 1)
error during execute of EXPLAIN PLAN statement
ORA-00942: table or view does not exist
parse error offset: 140
SELECT NVL (MAX (a.actual_to_date + 1),
b.date_of_joining
) AS start_date
FROM HR_JUDGE_MONTH_SALARY a, HR_JUDGE_MASTER b
WHERE a.judge_code(+) = b.judge_code AND b.judge_code = :b1
GROUP BY b.judge_code, b.date_of_joining
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 261 0.00 0.00 0 0 0 0
Fetch 261 2.01 133.50 28045 194499 0 261
total 522 2.01 133.51 28045 194499 0 261
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 63 (MOJ_PRD) (recursive depth: 1)
error during execute of EXPLAIN PLAN statement
ORA-00942: table or view does not exist
parse error offset: 223
SELECT MIN (a.applied_to_date) AS d1
FROM HR_JUDGE_LEAVE_ATTEN a
WHERE a.applied_to_date >= :b3
AND a.applied_from_date <=
((TO_DATE (:b2, 'dd/MM/rrrr')) + 20
AND a.judge_code = :b1
--AND a.leave_code = 'ORDINARY'
AND a.salary_advance_req = 'Y'
AND a.enabled_flag = 'Y'
AND a.workflow_completion_status = 'Y'
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 261 0.03 0.00 0 0 0 0
Fetch 261 0.00 0.74 103 3547 0 261
total 522 0.03 0.75 103 3547 0 261
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 63 (MOJ_PRD) (recursive depth: 1)
error during execute of EXPLAIN PLAN statement
ORA-00942: table or view does not exist
parse error offset: 117whey all explain plan are failed
can u help me in this regards....
Thanks in advance
kanishEXPLAIN PLAN needs a specific public table installed in the database to store the plan output.
Look in the documentation [url http://docs.oracle.com/cd/E11882_01/server.112/e16638/ex_plan.htm#PFGRF009]here, particularly section 12.2 on the PLAN_TABLE output table.
Looks like either your schema has lost privileges on the plan_table or else the plan_table does not exist. That is a bit unusual so you might cooperate with your DBA in finding out why this is so.
Your DBA might need to execute the catplan.sql script described in the above link. -
Oem explain plan produced doesn't correspond to explain plan with tkprof
Hello all,
I am running OEM on a 10.2.0.3 database and I have a very slow query with cognos 8 BI on my data warehouse.
I went to the dbconsole through OEM and connected to target database I went to look at the query execution and then got an explain plan.
Then I did a trace file and ran it throught tkprof.
When I look at both produced explain plan, I can see the tree looks the same exept the corresponding values. In OEM, it says I am going throug 18000 rows and in the tkprof result it says more like millions of records.
As anybody had these kind of results?
Shall I have more confidence in TKprof then OEM?
It is very important to me since I am being chalanged by an external DBA.I would recommend you to get Christian AntoginiĀ“s book "Troublshooting Oracle Performance", (http://www.antognini.ch/top/) which explains everything you need to know when analyzing Oracle SQL Performance and Explain Plans.
If you properly trace your SQL Statement, you will get "STAT" lines in the trace file. These stat lines show you the actual number of rows processed per row source operation. Explain plan per default does only show you the "estimated" row counts for the row source operations no matter whether you use "explain=" in the tkprof call or OEM to get the explain plan. Tkprof reads the STAT lines from the trace and outputs a section which is similar to an execution plan but contains the "real" number of rows.
However, if you want to troubleshoot Oracle Performance, I would recommend you to run the statement with the hint /*+ GATHER_PLAN_STATISTICS */ or set statistics_level=ALL in your session (not database-wide!).
If you do, you can get an excellent execution plan with DBMS_XPLAN.DISPLAY_CURSOR containing both estimated rows as well as actual rows combined with the "number of starts" for e.g. nested loop joins.
Get the book, read it, and you will be able to discuss this issue with your external dba in a professional way. ;-)
Regards,
Martin
www.ora-solutions.net -
Hi,
We are using Oracle Apps 11.5.10 ; Database 10 g
In Oracle Apps; When we switch on trace (using Help --> Diagnostice --> Trace - Trace with Binds and waits ); Trace is getting generated successfully at unix box.
After switch off trace; connected to unix box and issued tkprof
Syntax:
tkprof <generated_trace_file> MYFILE sys=no explain=<apps>/<appspwd> sort=exeela,prsela,fchela
My Questions/ Issues are:
1. In the genreated tkprof file (MYFILE) ; I could see all select statement; But in the select statements ; few details are appearing as :B1 , :B2 (Example: SELECT CATEGORY, SEVERITY, FND_LOG_SEVERITY
FROM FND_NEW_MESSAGES WHERE MESSAGE_NAME = :B1 AND APPLICATION_ID = :B2); Is it way i can also see actual values instead of :B1 and :B2 ?
2. Also in my tkprof generated file (MYFILE); I have some ORA error; this error is at many places;
Here is the error details
----------------------------- error details --------------------------------------
Optimizer goal: ALL_ROWS
Parsing user id: 173 (APPS) (recursive depth: 2)
unable to set optimizer goal
ORA-01986: OPTIMIZER_GOAL is obsolete
parse error offset: 33
--------------------------- error details ---------------------------------------------------
3. I am using tkprof and trace in wrong manner ? Do i need to do any database settings to get correct results of my tkprof results? Is i am using different version of tkprof?
FYI ; few details on tkprof
-------------------- tkprof details -----------------------------------------------
TKPROF: Release 8.0.6.3.0 - Production on Wed Jan 23 21:18:31 2008
(c) Copyright 1999 Oracle Corporation. All rights reserved.
$
$ which tkprof
~/806/bin/tkprof
------------------------------ tkprof details ---------------------------------------------
Please help this is kind of priority.
Thanks!!Suppose you see the following SQL in the tkprof output:
SELECT DISTINCT SR_CATEGORY_ID
FROM
MSC_ITEM_CATEGORIES WHERE CATEGORY_SET_ID = :b1 AND CATEGORY_NAME = :b2
call count cpu elapsed disk query current rows
Parse 2 0.00 0.75 0 0 0 0
Execute 2 0.02 1.93 0 0 0 0
Fetch 3 0.00 0.00 0 27 0 2
total 7 0.03 2.68 0 27 0 2
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 47 (APPS)
Rows Row Source Operation
1 HASH UNIQUE (cr=13 pr=0 pw=0 time=325 us)
14 PARTITION RANGE ALL PARTITION: 1 2 (cr=13 pr=0 pw=0 time=251 us)
14 TABLE ACCESS BY LOCAL INDEX ROWID MSC_ITEM_CATEGORIES PARTITION: 1 2 (cr=13 pr=0 pw=0 time=229 us)
14 INDEX RANGE SCAN MSC_ITEM_CATEGORIES_N4 PARTITION: 1 2 (cr=3 pr=0 pw=0 time=42 us)(object id 382162)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 HASH (UNIQUE)
14 PARTITION RANGE (ALL) PARTITION: START=1 STOP=2
14 TABLE ACCESS MODE: ANALYZED (BY LOCAL INDEX ROWID) OF
'MSC_ITEM_CATEGORIES' (TABLE) PARTITION: START=1 STOP=2
14 INDEX MODE: ANALYZED (RANGE SCAN) OF
'MSC_ITEM_CATEGORIES_N4' (INDEX) PARTITION: START=1 STOP=2
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 9 0.00 0.00
SQL*Net message from client 9 0.02 0.04
latch: library cache 1 0.00 0.00
If you want to find the bind variables, you need to find the SQL statement in the raw trace file. I would search on 'MSC_ITEM_CATEGORIES'
You see PARSING IN CURSOR #99 in the example below. The BIND #99 are listed below as well. The first one is 2 and the second is 'COMPUTER.DESKTOP'
PARSING IN CURSOR #99 len=111 dep=0 uid=47 oct=3 lid=47 tim=1138043781487272 hv=62812132 ad='650d6fec'
SELECT DISTINCT SR_CATEGORY_ID FROM MSC_ITEM_CATEGORIES WHERE CATEGORY_SET_ID = :b1 AND CATEGORY_NAME = :b2
END OF STMT
PARSE #99:c=4001,e=752066,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=1138043781487264
WAIT #99: nam='SQL*Net message to client' ela= 2 driver id=1952673792 #bytes=1 p3=0 obj#=49254 tim=1138043781488132
WAIT #99: nam='SQL*Net message from client' ela= 197 driver id=1952673792 #bytes=1 p3=0 obj#=49254 tim=1138043781488367
WAIT #99: nam='latch: library cache' ela= 1185 address=1866426996 number=214 tries=1 obj#=49254 tim=1138043781741163
BINDS #99:
kkscoacd
Bind#0
oacdty=02 mxl=22(21) mxlc=00 mal=00 scl=00 pre=00
oacflg=01 fl2=1000000 frm=00 csi=00 siz=56 off=0
kxsbbbfp=b6d0d710 bln=22 avl=02 flg=05
value=2
Bind#1
oacdty=01 mxl=32(16) mxlc=00 mal=00 scl=00 pre=00
oacflg=21 fl2=1000010 frm=01 csi=871 siz=0 off=24
kxsbbbfp=b6d0d728 bln=32 avl=16 flg=01
value="COMPUTER.DESKTOP"
Then run the following SQL in sqlplus or sql developer:
SQL> SELECT DISTINCT SR_CATEGORY_ID
2 FROM MSC_ITEM_CATEGORIES
3 WHERE CATEGORY_SET_ID = 2
4 AND CATEGORY_NAME = 'COMPUTER.DESKTOP';
SR_CATEGORY_ID
1373 -
How To Check Whether Physical Standby is in Sync with the Primary
hi All,
I'm new in data guard. In our current production, my boss is asking me to write a shell scripts monitoring physical standby and primary archive is sync (archive gap)
I'm referring metalink [ID 861595.1], but when i ran the first query in Primary node, the screen hang.
On primary
========
SQL> SELECT THREAD# "Thread",SEQUENCE# "Last Sequence Generated"
FROM V$ARCHIVED_LOG
WHERE (THREAD#,FIRST_TIME ) IN (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)
ORDER BY 1;
I tried to turn on 10046 SQL trace, the SQL consume a lot of CPU, and it full table scan in X$KCCAL table.
TKPROF result look like below:
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 88.29 115.59 0 0 0 0
total 3 88.30 115.60 0 0 0 0
Misses in library cache during parse: 1
Misses in library cache during execute: 1 Optimizer mode: ALL_ROWS Parsing user id: 80
Rows Row Source Operation
0 SORT ORDER BY (cr=0 pr=0 pw=0 time=21 us)
0 FILTER (cr=0 pr=0 pw=0 time=19 us)
1124 FIXED TABLE FULL X$KCCAL (cr=0 pr=0 pw=0 time=40537 us)
0 FILTER (cr=0 pr=0 pw=0 time=115538625 us)
1122 HASH GROUP BY (cr=0 pr=0 pw=0 time=115530193 us)
7465972 FIXED TABLE FULL X$KCCAL (cr=0 pr=0 pw=0 time=94648975 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
control file sequential read 16841 0.05 30.88
SQL*Net break/reset to client 1 0.00 0.00Due to this is production environment, thus i had terminated the session, can anyone teach me or share with me any scripts to monitor physical standby is sync with primary or not? Or do you encounter the above issue when running the SQL?
My db version is Oracle 11.2.0.1.0
Thanks in advance.
Regards,
KlnghauHello;
Note 861595.1 has not been subject to an independent technical review. Not sure if that make it bad or not.
This is what I'm using: ( I spool this to a file and have it e-mailed to me daily)
PROMPT
PROMPT Checking last sequence in v$archived_log
PROMPT
clear screen
set linesize 100
column STANDBY format a20
column applied format a10
SELECT name as STANDBY, SEQUENCE#, applied, completion_time from v$archived_log WHERE DEST_ID = 2 AND NEXT_TIME > SYSDATE -1;
prompt
prompt----------------Last log on Primary--------------------------------------|
prompt
select max(sequence#) from v$archived_log where NEXT_TIME > sysdate -1;
Best Regards
mseberg -
Using max function in PL/SQL
VERY URGENT...
Am new to oracle...
I've written a package that display gif images in form of histogram/bar chart. using html,
I need to use max function to display values proportionately.
please help. i need to complete this assignment by 2/9/00 by 10.00 am at the latest. I've half written a function but I don't know if there's a simpler way fo doing this. html enabledFirst of all Thanks to all gentlemen who replied ..many thanks ...
Tried the ROW_NUMBER() option but still it is taking time...have given output for the query and tkprof results as well. Even when it doesn't fetch any record ( this is a valid cased because the input header id doesn't have any workflow request submitted & hence no entry in the wf_items table)..then also see the time it has taken.
Looked at the RANK & DENSE_RANK options which were suggested..but it is still taking time..
Any further suggestions or ideas as to how this could be resolved..
SELECT 'Y', 'Y', ITEM_KEY
FROM
( SELECT ITEM_KEY, ROW_NUMBER() OVER(ORDER BY BEGIN_DATE DESC) RN FROM
WF_ITEMS WHERE ITEM_TYPE = 'xxxxzzzz' AND ROOT_ACTIVITY = 'START_REQUESTS'
AND SUBSTR(ITEM_KEY,1,INSTR(ITEM_KEY,'-') - 1) = :B1
) T WHERE RN <= 1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 1.57 0 0 0 0
Fetch 1 8700.00 544968.73 8180 8185 0 0
total 2 8700.00 544970.30 8180 8185 0 0
many thanks -
Do you know Timmings for trace files generated?
Hi,
I have done some sql traceing using DBMS_MONITOR package.
We can also enable SQL traceing using DBMS_SESSION.
I want to generate sql trace file for "particuler part of application".
When i did that i got some sql trace files,, now that "particuler part of application" was over application was idle..
but as time goes these files are still populating in size means they are still sql traceing going on...
My question is when and how trace files are generated?
Do you have idea???
Thanks and Regards,
Rushang Kansara
Message was edited by:
Rushalso what content of my sql trace file should i
consider for exacly tracing that "particuler part of
application".
Rushang
Parse Count To Execute Ratio
Take the numbers of parse count and divide it by numbers of time execute count if it is 1 then it means you are parsing the same statment everytime,If this ratio is 1 then it will latch the shared SQL area which will degrade the overall performance.Like if you execute a query which is using bind variable and this query is at yours front end level trigger (Forms) POST_QUERY then it will show you (parse count=execute count) which shows you are parsing for every triggering event which is bad ,for that you should put this seqeuel within PL/SQL procedure which cache the cursor and will turn in (parse count<Execute Count).
Large Diffrence Between Elasped Time And CPU Time
If this diffrence (Elapsed time[b]-CPU time)>1 then it means you are spending yours time in for waiting resources this waiting resources will in turn wait events e.g some one updated the row and dont realease by COMMIT or ROLBACK and the same span of time you want to update then you will see a lock in tkprof result in wait event section.If you read the data from hard disk (as first time you issue it reads from HD and then put into buffer cache during this reading a latch is grabed and will not let you read this data until you perform the alls read from HD to buffer cache this will also show you in wait events which is cache buffers chain
Fetch Calls
If yours Fetch calls=Rows then it means you are not using Bulk fetch and yours this code will take a lot of roundtrips which will in turn jam the network.
Disk Count
If every time yours disk count=current + query mode then you are reading alls block from disk alls the time ,usually oracle read once from disk and put it into SGA and should be found in SGA second time.
And there is many more...depend on yors environemnt setup but above are common.
As you said its reproducing the tkprof again and again ,make sure you terminate the session or you explicitly turn off the tracer by
ALTER SESSION SET SQL_TRACE=FALSE Khurram -
Performance issue with using MAX function in pl/sql
Hello All,
We are having a performance issue with the below logic wherein MAX is being used in order to get the latest instance/record for a given input variable ( p_in_header_id).. the item_key is having the format as :
p_in_header_id - <number generated from a sequence>
This query to fetch even 1 record takes around 1 minutes 30 sec..could someone please help if there is a better way to form this logic & to improve performance in this case.
We want to get the latest record for the item_key ( this we are getting using MAX (begin_date)) for a given p_in_header_id value.
Query 1 :
SELECT item_key FROM wf_items WHERE item_type = 'xxxxzzzz'
AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id
AND root_activity ='START_REQUESTS'
AND begin_date =
(SELECT MAX (begin_date) FROM wf_items WHERE item_type = 'xxxxzzzz'
AND root_activity ='START_REQUESTS'
AND SUBSTR (item_key, 1, INSTR (item_key, '-') - 1) =p_in_header_id);
Could someone please help us with this performance issue..we are really stuck because of this
regardsFirst of all Thanks to all gentlemen who replied ..many thanks ...
Tried the ROW_NUMBER() option but still it is taking time...have given output for the query and tkprof results as well. Even when it doesn't fetch any record ( this is a valid cased because the input header id doesn't have any workflow request submitted & hence no entry in the wf_items table)..then also see the time it has taken.
Looked at the RANK & DENSE_RANK options which were suggested..but it is still taking time..
Any further suggestions or ideas as to how this could be resolved..
SELECT 'Y', 'Y', ITEM_KEY
FROM
( SELECT ITEM_KEY, ROW_NUMBER() OVER(ORDER BY BEGIN_DATE DESC) RN FROM
WF_ITEMS WHERE ITEM_TYPE = 'xxxxzzzz' AND ROOT_ACTIVITY = 'START_REQUESTS'
AND SUBSTR(ITEM_KEY,1,INSTR(ITEM_KEY,'-') - 1) = :B1
) T WHERE RN <= 1
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 1.57 0 0 0 0
Fetch 1 8700.00 544968.73 8180 8185 0 0
total 2 8700.00 544970.30 8180 8185 0 0
many thanks -
To improve performance of select
Hi all,
I premise that I'm not a Dba Administrator, but I must resolve a performance problem.
I read the Rob Van Wijk thread "When your query takes too long ..." and I'll post you my tkprof result
Trace file: c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4220.trc
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
select a.CODI_AVVI, a.DESC_DENO_ENTE, a.DESC_DENO_ENTE_VISU, a.DESC_UFFI_ENTE, a.CODI_SIGL_PROV, a.NUME_AVVI,
a.DESC_OGGE_LAVO_VISU, a.DESC_LAVO DESC_LAVO_VISU, a.IMPO_AVVI_VISU, NVL(a.IMPO_RIBA_visu,0) IMPO_RIBA_visu,
ROUND(DECODE(a.PERC_RIBA,NULL, (((a.IMPO_AVVI-a.IMPO_RIBA)/(DECODE(a.IMPO_aVvi,0,1,a.IMPO_aVvi)))*100),a.PERC_RIBA),3) PERC_RIBA_VISU,
a.DESC_NOTE_IMPO, a.CODI_LEGG_VINC, a.CODI_TIPO_AVVI, a.CODI_AZIE, a.DESC_FINA_0001, a.DESC_FINA_0002, a.DATA_PUBL DATA_PUBL_VISU,
a.DATA_SCAD_VISU, a.DESC_SCAD_ORAA, a.DESC_SCAD_MINU, a.DATA_LICI_ESTE_RISU, a.CODI_IMPR_APPA, a.DESC_IMPR_AGGI, a.DESC_TIPO_AVVI_VISU,
a.DESC_NOTE_ENTE, a.FLAG_CATE_STIM , a.CODI_TIPO_AGGI, a.FLAG_CIRC, a.DESC_caap, a.DESC_prov, a.DESC_NUME_TELE01 , a.DESC_NUME_FAXX01 ,
a.DESC_INDI, a.DESC_ARTI_LEGG_BOLL DESC_ARTI_LEGG
FROM V_ASP_REPOANAGAVVISTAM a
WHERE (a.flag_risu in ('R','S') or (a.flag_risu='N' and a.NUME_DITT_INVI is not null))
AND (to_Date('01/01/2002','dd/mm/yyyy') <= A.DATA_SCAD OR A.DATA_SCAD is null)
and exists (select 1 from relaavvidettcate d where a.codi_avvi=d.codi_avvi and D.CODI_DETT_CATE IN ('114','115') )
and ( a.impo_avvi >= 1000 and a.impo_avvi <= 3000000 )
and decode(LENGTH(A.DATA_LICI), 10,to_date(A.DATA_LICI,'dd/mm/yyyy'), to_date(A.DATA_LICI,'mm/yyyy')) BETWEEN to_Date('04/2007','mm/yyyy') AND to_Date('05/2008','mm/yyyy')
and ( UPPER(a.desc_deno_ente) like '%COMUNE DI ROMA%' )
ORDER BY decode(LENGTH(A.DATA_LICI), 10,to_date(A.DATA_LICI,'dd/mm/yyyy'), to_date(A.DATA_LICI,'mm/yyyy')) DESC
call count cpu elapsed disk query current rows
Parse 1 0.37 0.38 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 11 2.39 3.64 346 109663 0 139
total 13 2.76 4.02 346 109663 0 139
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 385
Rows Row Source Operation
139 SORT ORDER BY (cr=109663 pr=346 pw=0 time=3640309 us)
139 NESTED LOOPS OUTER (cr=109663 pr=346 pw=0 time=3665123 us)
139 NESTED LOOPS OUTER (cr=109659 pr=346 pw=0 time=3638446 us)
139 NESTED LOOPS OUTER (cr=109659 pr=346 pw=0 time=3634127 us)
139 NESTED LOOPS OUTER (cr=109379 pr=346 pw=0 time=3626615 us)
139 NESTED LOOPS OUTER (cr=109256 pr=346 pw=0 time=3621185 us)
139 NESTED LOOPS OUTER (cr=109115 pr=346 pw=0 time=3616587 us)
139 HASH JOIN OUTER (cr=109005 pr=346 pw=0 time=3608065 us)
139 NESTED LOOPS OUTER (cr=108989 pr=346 pw=0 time=36498189 us)
139 NESTED LOOPS (cr=108848 pr=346 pw=0 time=36491383 us)
1285 NESTED LOOPS OUTER (cr=106276 pr=346 pw=0 time=17103682 us)
1285 NESTED LOOPS OUTER (cr=105171 pr=346 pw=0 time=17045852 us)
1285 NESTED LOOPS (cr=103907 pr=346 pw=0 time=16979031 us)
50565 SORT UNIQUE (cr=2775 pr=0 pw=0 time=360760 us)
51193 TABLE ACCESS FULL RELAAVVIDETTCATE (cr=2775 pr=0 pw=0 time=271031 us)
1285 TABLE ACCESS BY INDEX ROWID ANAGAVVI (cr=101132 pr=346 pw=0 time=3041988 us)
50565 INDEX UNIQUE SCAN PK_ANAGAVVI_CODIAVVI (cr=50567 pr=0 pw=0 time=762424 us)(object id 300074)
1262 TABLE ACCESS BY INDEX ROWID PARATIPOAVVI (cr=1264 pr=0 pw=0 time=37709 us)
1262 INDEX UNIQUE SCAN PK_PARATIPOAVVI_CODITIPO (cr=2 pr=0 pw=0 time=18013 us)(object id 300304)
1103 TABLE ACCESS BY INDEX ROWID PARALEGG (cr=1105 pr=0 pw=0 time=35235 us)
1103 INDEX UNIQUE SCAN PK_PARALEGG_CODILEGG (cr=2 pr=0 pw=0 time=16840 us)(object id 300245)
139 TABLE ACCESS BY INDEX ROWID ANAGENTI (cr=2572 pr=0 pw=0 time=44695 us)
1285 INDEX UNIQUE SCAN PK_ANAGENTI_CODIENTE (cr=1287 pr=0 pw=0 time=19447 us)(object id 300099)
139 TABLE ACCESS BY INDEX ROWID PARAPROV (cr=141 pr=0 pw=0 time=4931 us)
139 INDEX UNIQUE SCAN PK_CODIPROV (cr=2 pr=0 pw=0 time=1899 us)(object id 300286)
781 TABLE ACCESS FULL ANAGIMPRPROG (cr=16 pr=0 pw=0 time=3167 us)
54 TABLE ACCESS BY INDEX ROWID ANAGUFFIENTI (cr=110 pr=0 pw=0 time=5719 us)
54 INDEX RANGE SCAN PK_ANAG_UFFI_ENTI_CODIUFFI (cr=56 pr=0 pw=0 time=1685 us)(object id 300135)
139 INDEX UNIQUE SCAN PK_CODIPROVCOMU (cr=141 pr=0 pw=0 time=2599 us)(object id 300214)
53 TABLE ACCESS BY INDEX ROWID ANAGIMPRAPPA (cr=123 pr=0 pw=0 time=3428 us)
53 INDEX UNIQUE SCAN PK_ANAGIMPRAPPA_CODIIMPRAPPA (cr=70 pr=0 pw=0 time=1568 us)(object id 300103)
139 TABLE ACCESS BY INDEX ROWID ANAGAZIERISU (cr=280 pr=0 pw=0 time=4380 us)
139 INDEX UNIQUE SCAN PK_CODIAZIERISU (cr=141 pr=0 pw=0 time=2106 us)(object id 300080)
0 TABLE ACCESS BY INDEX ROWID PARAFINA (cr=0 pr=0 pw=0 time=2975 us)
0 INDEX UNIQUE SCAN PK_PARAFINA_CODIFINA (cr=0 pr=0 pw=0 time=1158 us)(object id 300234)
3 TABLE ACCESS BY INDEX ROWID PARAFINA (cr=4 pr=0 pw=0 time=3210 us)
3 INDEX UNIQUE SCAN PK_PARAFINA_CODIFINA (cr=1 pr=0 pw=0 time=1483 us)(object id 300234)
alter session set sql_trace true
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 385
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.37 0.38 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 11 2.39 3.64 346 109663 0 139
total 14 2.76 4.02 346 109663 0 139
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 34 0.03 0.03 0 0 0 0
Execute 200 0.01 0.01 0 0 0 0
Fetch 820 0.04 0.03 0 1009 0 645
total 1054 0.09 0.08 0 1009 0 645
Misses in library cache during parse: 3
Misses in library cache during execute: 3
2 user SQL statements in session.
200 internal SQL statements in session.
202 SQL statements in session.
Trace file: c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4220.trc
Trace file compatibility: 10.01.00
Sort options: prsela exeela fchela
1 session in tracefile.
2 user SQL statements in trace file.
200 internal SQL statements in trace file.
202 SQL statements in trace file.
25 unique SQL statements in trace file.
2082 lines in trace file.
355 elapsed seconds in trace file.I hope that I have problems on the full access of those table
ANAGAVVI (228650 records)
RELAAVVIDETTCATE (that have a PK of CODI_AVVI of ANAGAVVI and 394587records)
Well... I have yet those indexes on those table
AnagAvvi
1^ index
CREATE INDEX INDX_ANAGAVVI_NUMEAVVI
ON ANAGAVVI("NUME_AVVI")
TABLESPACE "TS_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE ( INITIAL 5120K NEXT 0K MINEXTENTS 1 MAXEXTENTS
2147483645 PCTINCREASE 0)
LOGGING2^ index
CREATE INDEX INDX_ANAGAVVI_NUMEAVVI02
ON ANAGAVVI (SUBSTR("NUME_AVVI",2))
TABLESPACE "TS_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE ( INITIAL 7168K NEXT 0K MINEXTENTS 1 MAXEXTENTS
2147483645 PCTINCREASE 0)
LOGGING3^ index PK_
CREATE UNIQUE INDEX PK_ANAGAVVI_CODIAVVI
ON ANAGAVVI ("CODI_AVVI")
TABLESPACE "TS_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE ( INITIAL 4096K NEXT 0K MINEXTENTS 1 MAXEXTENTS
2147483645 PCTINCREASE 0)
LOGGINGOn table RELAAVVIDETTCATE, I have only this index
CREATE UNIQUE INDEX PK_RELAAVVIDETTCATE_CODI
ON RELAAVVIDETTCATE ("CODI_AVVI_DETT_CATE")
TABLESPACE "TS_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE ( INITIAL 7168K NEXT 0K MINEXTENTS 1 MAXEXTENTS
2147483645 PCTINCREASE 0)
LOGGINGI have just found this configuration, so I didn't because it has done in this way.
If you need more information, I'll give all :)
Thank's for read this post
Paolo from MadridHi Rob and Hi all,
sorry for the answer too late.
I'll post again my problems for the select that you'll find on the tkprof file of this post.
You can see the View V_ASP_REPOANAGAVVISTAM, in one of my messagge above.
When I produced tkprof, I have got this indexes
CREATE INDEX INDX_RELAAVVIDETTCATE_DETTCATE
ON RELAAVVIDETTCATE("CODI_DETT_CATE")
TABLESPACE "TS_SIAG_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE ( INITIAL 5120K NEXT 0K MINEXTENTS 1 MAXEXTENTS
2147483645 PCTINCREASE 0)
LOGGING
CREATE INDEX INDX_RELAAVVIPROV_CODIPROV
ON RELAAVVIPROV("CODI_PROV")
TABLESPACE "TS_SIAG_DATI" PCTFREE 10 INITRANS 2 MAXTRANS 255
STORAGE ( INITIAL 5120K NEXT 0K MINEXTENTS 1 MAXEXTENTS
2147483645 PCTINCREASE 0)
LOGGINGThere aren't on table AnagAvvi.
The Tkprof is this
TKPROF: Release 10.2.0.1.0 - Production on Lun Apr 28 13:50:42 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Trace file: c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4160.trc
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
select CODI_AVVI, NVL(IMPO_RIBA_visu,0) IMPO_RIBA_visu,
ROUND(DECODE(PERC_RIBA,NULL, (((IMPO_AVVI-IMPO_RIBA)/(DECODE(IMPO_aVvi,0,1,IMPO_aVvi)))*100),PERC_RIBA),3) PERC_RIBA_VISU
FROM V_ASP_REPOANAGAVVISTAM
WHERE (flag_risu in ('R','S') or (flag_risu='N' and NUME_DITT_INVI is not null))
AND (to_Date('01/01/2002','dd/mm/yyyy') <= DATA_SCAD OR DATA_SCAD is null)
and exists ( select 1 from relaavvidettcate d where codi_avvi=d.codi_avvi and D.CODI_DETT_CATE IN ('114','115') )
and ( impo_avvi >= 1000 and impo_avvi <= 3000000 )
and decode(LENGTH(DATA_LICI), 10,to_date(DATA_LICI,'dd/mm/yyyy'), to_date(DATA_LICI,'mm/yyyy')) BETWEEN to_Date('04/2007','mm/yyyy')
AND to_Date('05/2008','mm/yyyy') and ( UPPER(desc_deno_ente) like '%COMUNE DI ROMA%' )
ORDER BY decode(LENGTH(DATA_LICI), 10,to_date(DATA_LICI,'dd/mm/yyyy'), to_date(DATA_LICI,'mm/yyyy')) DESC
call count cpu elapsed disk query current rows
Parse 1 0.45 0.46 0 0 0 0
Execute 1 0.00 0.00 0 3 0 0
Fetch 18 0.62 0.61 0 19101 0 251
total 20 1.07 1.08 0 19104 0 251
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 385
Rows Row Source Operation
251 SORT ORDER BY (cr=19104 pr=0 pw=0 time=620275 us)
251 FILTER (cr=19104 pr=0 pw=0 time=628996 us)
251 NESTED LOOPS OUTER (cr=19101 pr=0 pw=0 time=627135 us)
251 NESTED LOOPS OUTER (cr=19100 pr=0 pw=0 time=622610 us)
251 NESTED LOOPS OUTER (cr=19100 pr=0 pw=0 time=617834 us)
251 NESTED LOOPS OUTER (cr=18847 pr=0 pw=0 time=610298 us)
251 NESTED LOOPS OUTER (cr=18716 pr=0 pw=0 time=605522 us)
251 NESTED LOOPS OUTER (cr=18463 pr=0 pw=0 time=597736 us)
251 HASH JOIN OUTER (cr=18370 pr=0 pw=0 time=591443 us)
251 NESTED LOOPS OUTER (cr=18354 pr=0 pw=0 time=159246 us)
251 NESTED LOOPS (cr=18352 pr=0 pw=0 time=127968 us)
3732 NESTED LOOPS OUTER (cr=10886 pr=0 pw=0 time=536807 us)
3732 NESTED LOOPS OUTER (cr=10884 pr=0 pw=0 time=443498 us)
3732 TABLE ACCESS FULL ANAGAVVI (cr=10882 pr=0 pw=0 time=331524 us)
3687 INDEX UNIQUE SCAN PK_PARATIPOAVVI_CODITIPO (cr=2 pr=0 pw=0 time=52258 us)(object id 300304)
3158 INDEX UNIQUE SCAN PK_PARALEGG_CODILEGG (cr=2 pr=0 pw=0 time=47517 us)(object id 300245)
251 TABLE ACCESS BY INDEX ROWID ANAGENTI (cr=7466 pr=0 pw=0 time=124877 us)
3732 INDEX UNIQUE SCAN PK_ANAGENTI_CODIENTE (cr=3734 pr=0 pw=0 time=56423 us)(object id 300099)
251 INDEX UNIQUE SCAN PK_CODIPROV (cr=2 pr=0 pw=0 time=3502 us)(object id 300286)
781 TABLE ACCESS FULL ANAGIMPRPROG (cr=16 pr=0 pw=0 time=3159 us)
91 INDEX RANGE SCAN PK_ANAG_UFFI_ENTI_CODIUFFI (cr=93 pr=0 pw=0 time=2887 us)(object id 300135)
251 INDEX UNIQUE SCAN PK_CODIPROVCOMU (cr=253 pr=0 pw=0 time=3616 us)(object id 300214)
102 INDEX UNIQUE SCAN PK_ANAGIMPRAPPA_CODIIMPRAPPA (cr=131 pr=0 pw=0 time=2804 us)(object id 300103)
251 INDEX UNIQUE SCAN PK_CODIAZIERISU (cr=253 pr=0 pw=0 time=3684 us)(object id 300080)
0 INDEX UNIQUE SCAN PK_PARAFINA_CODIFINA (cr=0 pr=0 pw=0 time=2205 us)(object id 300234)
6 INDEX UNIQUE SCAN PK_PARAFINA_CODIFINA (cr=1 pr=0 pw=0 time=2330 us)(object id 300234)
1 INLIST ITERATOR (cr=3 pr=0 pw=0 time=87 us)
1 INDEX RANGE SCAN INDX_RELAAVVIDETTCATE_DETTCATE (cr=3 pr=0 pw=0 time=40 us)(object id 303246)
alter session set sql_trace true
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.02 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.02 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 385
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 1 0.45 0.46 0 0 0 0
Execute 2 0.00 0.02 0 3 0 0
Fetch 18 0.62 0.61 0 19101 0 251
total 21 1.07 1.10 0 19104 0 251
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 19 0.01 0.19 0 0 0 0
Execute 41 0.07 0.16 0 0 0 0
Fetch 51 0.00 0.03 0 118 0 162
total 111 0.09 0.39 0 118 0 162
Misses in library cache during parse: 5
Misses in library cache during execute: 5
2 user SQL statements in session.
41 internal SQL statements in session.
43 SQL statements in session.
Trace file: c:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_4160.trc
Trace file compatibility: 10.01.00
Sort options: prsela exeela fchela
1 session in tracefile.
2 user SQL statements in trace file.
41 internal SQL statements in trace file.
43 SQL statements in trace file.
10 unique SQL statements in trace file.
455 lines in trace file.
10 elapsed seconds in trace file.While the explain plain is this
PLAN_TABLE_OUTPUT
| Id | Operation | Name
| Rows | Bytes | Cost (%CPU)|
| 0 | SELECT STATEMENT |
PLAN_TABLE_OUTPUT
| 1 | 136 | 2452 (3)|
| 1 | SORT ORDER BY |
| 1 | 136 | 2452 (3)|
| 2 | FILTER |
| | | |
| 3 | NESTED LOOPS OUTER |
| 1 | 136 | 2447 (3)|
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS OUTER |
| 1 | 133 | 2447 (3)|
| 5 | NESTED LOOPS OUTER |
| 1 | 130 | 2447 (3)|
| 6 | NESTED LOOPS OUTER |
| 1 | 125 | 2447 (3)|
| 7 | NESTED LOOPS OUTER |
| 1 | 120 | 2447 (3)|
PLAN_TABLE_OUTPUT
| 8 | NESTED LOOPS OUTER |
| 1 | 114 | 2447 (3)|
| 9 | HASH JOIN OUTER |
| 1 | 110 | 2446 (3)|
| 10 | NESTED LOOPS OUTER |
| 1 | 106 | 2440 (3)|
| 11 | NESTED LOOPS |
PLAN_TABLE_OUTPUT
| 1 | 102 | 2440 (3)|
| 12 | NESTED LOOPS OUTER |
| 1 | 52 | 2439 (3)|
| 13 | NESTED LOOPS OUTER |
| 1 | 49 | 2439 (3)|
| 14 | TABLE ACCESS FULL | ANAGAVVI
| 1 | 46 | 2439 (3)|
PLAN_TABLE_OUTPUT
| 15 | INDEX UNIQUE SCAN | PK_PARATIPOAVVI_CODITIPO
| 1 | 3 | 0 (0)|
| 16 | INDEX UNIQUE SCAN | PK_PARALEGG_CODILEGG
| 1 | 3 | 0 (0)|
| 17 | TABLE ACCESS BY INDEX ROWID| ANAGENTI
| 1 | 50 | 1 (0)|
| 18 | INDEX UNIQUE SCAN | PK_ANAGENTI_CODIENTE
| 1 | | 0 (0)|
PLAN_TABLE_OUTPUT
| 19 | INDEX UNIQUE SCAN | PK_CODIPROV
| 1 | 4 | 0 (0)|
| 20 | TABLE ACCESS FULL | ANAGIMPRPROG
| 781 | 3124 | 5 (0)|
| 21 | INDEX RANGE SCAN | PK_ANAG_UFFI_ENTI_CODIUFFI
| 1 | 4 | 1 (0)|
| 22 | INDEX UNIQUE SCAN | PK_CODIPROVCOMU
PLAN_TABLE_OUTPUT
| 1 | 6 | 0 (0)|
| 23 | INDEX UNIQUE SCAN | PK_ANAGIMPRAPPA_CODIIMPRAPPA
| 1 | 5 | 0 (0)|
| 24 | INDEX UNIQUE SCAN | PK_CODIAZIERISU
| 1 | 5 | 0 (0)|
| 25 | INDEX UNIQUE SCAN | PK_PARAFINA_CODIFINA
| 1 | 3 | 0 (0)|
PLAN_TABLE_OUTPUT
| 26 | INDEX UNIQUE SCAN | PK_PARAFINA_CODIFINA
| 1 | 3 | 0 (0)|
| 27 | INLIST ITERATOR |
| | | |
| 28 | INDEX RANGE SCAN | INDX_RELAAVVIDETTCATE_DETTCATE
| | | 3 (0)|
PLAN_TABLE_OUTPUT
Note
- 'PLAN_TABLE' is old version
[PRE]
Thank's for any suggestion -
I am having one batch job in which query fatching data from various tables and inserting in one table.
It's taking 3-4 hours. On generating explain plan i come to know that query taking more time due to one outer join between one view(say V1) and large table(say T1).
V1.Column(+) =T1.Column1 || '-' || T1.Column2
If i remove this outer join it will improve but according to need i can't do it.
It's oracle8i and its using rule based only
I am planning to create 2 Indexed. 1 on T1.Column1 and other T1.Column2. or any other suggestion from you guys.
It's very urgent i need to do it in 2 days. Please any one help me out
Thanks in advance
ChetanChetanS wrote:
This is my tkprof result
call count cpu elapsed disk query current rows
Parse 1 12.24 12.26 0 0 2 0
Execute 1 0.01 0.02 0 3 9 0
Fetch 438 48.54 153.05 43263 917910 241 438000
total 440 60.79 165.33 43263 917913 252 438000
See below explain plan
you find more cost due to above joinI'm not sure how to interpret your posts. A few comments:
1. You said you're using 8i with rule based optimization. But now you're talking about cost and the plan shows a cost, too. So it looks more like a CBO plan.
2. If you say that "If i remove this outer join it will improve but according to need i can't do it.", what do you mean exactly?
- Turn the the outer join into an inner join?
- Remove the join clause completely?
And what do you mean by "it will improve"? Does it perform better, or do you get simply a lower cost returned by EXPLAIN PLAN?
3. The plan looks convoluted. There are REMOTE objects involved and the DUAL table is referenced multiple times, so it might a very good idea to share the actual query code used. If required, mask the table/view names and replace them with "table1/2/3" etc.
Note that the optimizer often does a suboptimal job when REMOTE objects are involved, so may be this is one of the root causes of your performance issues.
4. Use the \ tag before and after text that should be formatted in fixed font for better readability. Use the "Quote" button in the message editor to see how I did it here.
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
Just Question about Explain Plan.
Q- 1. Is it Possible to trace a current session query from other session without altering that session. If How can i do it. I can not do it with v$session becuase it will be different sessionid. Also i ndon't want to alter session.
Q-2 I have SQl statement gives different EXECUTION PLAN on 9R2 and 10g. Is it possible.
Can any one explain this pleasethank you smoradi and william for your response.
Sorry for Long Post
I tried to post it before also. i did not get the conculsion. This are the final results i got. So can any one Help me.
Following are the information
I have TKPROF result. can any one expalin me this what it means. Where are wait time.
I got the explain plan as unnder can any one explain me please i am still having problem solving this
can any one explain me how to improve the perfomance.
1.SS_SKU_STORE_WEEk is the biggest table around 12 million rows.
2. SS_SKU_STORE 50 thosand rows
3. ITEM 44 thousand
4.Rest all tables are small.
SQL> SELECT /*+ index( ss_sku_store SS_SKU_ST_PK ) */
2 TO_NUMBER( ss_sku_store.sku || ss_sku_store.store_num) rowkey,
3 ss_sku_store.sku psku,
4 ' ' || INITCAP( item.descrip ) description,
5 dept_id,
6 TO_CHAR( dept_id ) || '.' || TO_CHAR( sub_dept_id ) subdepartment,
7 TO_CHAR( dept_id ) || '.' || TO_CHAR( sub_dept_id ) ||'.'|| TO_CHAR( class_id ) class,
8 NVL( vendor_id, -1 ),
9 NVL( buyer_num, -1),
10 NVL( TRIM(pattern_cd), -1),
11 DECODE(Color_Cd, 0, -1, NVL( Color_Cd, -1)) Color_Cd,
12 NVL( size_cd, -1),
13 -1 list_id,
14 ss_sku.sku skuattribute,
15 ss_sku_store.store_num pstore,
16 INITCAP( store.name ) location,
17 store.state,
18 NVL( INITCAP( regional_vp), :cUNASSIGNED) regional_vp,
19 NVL( INITCAP( regional_merch_mgr), :cUNASSIGNED) regional_merch_mgr,
20 NVL( INITCAP( district_mgr), :cUNASSIGNED) district_mgr,
21 NVL( INITCAP( area_mgr), :cUNASSIGNED) area_mgr,
22 NVL( sq_footage, -1),
23 SUBSTR( '000' || fashion_attribute.seq, -3, 3 ) || NVL( store.fashion_att_cd, '' ) fashion_att_cd,
24 SUBSTR( '000' || cust_profile.seq, -3, 3 ) || NVL( store.cust_type_cd, '' ) cust_type_cd,
25 NVL( section_count, -1) section_count,
26 '000' corp_vol_grp_cd,
27 0 storegroup,
28 store.store_num storeattribute,
29 0 storesort,
30 submit_status,
31 DECODE( current_user, :pUserID, shipment_schedules.check_staged_sku(ss_sku_store.sku,-1), 1) lockedflag,
32 '' aggregatedrowkey,
33 '' AttributeDescription,
34 starting_on_hand onhand
35 FROM cust_profile,
36 fashion_attribute,
37 ( SELECT vendor_id,
38 sku
39 FROM item_vendor
40 WHERE sku IN ( SELECT sku
41 FROM ss_session_sku
42 WHERE user_key = :pUserKey)
43 AND primary_flag = :cTRUE ) primaryvendor,
44 ( SELECT SKU,
45 DECODE( status, 0, 0, DECODE( status, 1 ,0 ,1) ) AS submit_status
46 FROM ( SELECT /*+ full(ss_session_sku) use_nl(ss_session_sku,ss_sku_store_week) index(ss_sku_store_week SS_SKU_STR_WK_SKU )*/
47 SS_SKU_Store_Week.SKU,
48 MAX( NVL( ssk_week_status, 0 ) ) AS status
49 FROM ss_session_sku,
50 ss_sku_store_week
51 WHERE user_key = :pUserKey
52 AND ss_sku_store_week.sku = ss_session_sku.sku
53 GROUP BY ss_sku_store_week.sku )
54 ) sku_status,
55 ss_sku,
56 store,
57 ss_sku_store,
58 item
59 WHERE sku_status.sku = item.sku
60 AND sku_status.sku = ss_sku.sku
61 AND sku_status.sku = ss_sku_store.sku
62 AND sku_status.sku = primaryvendor.sku
63 AND sku_status.sku = sku_status.sku
64 AND ss_sku_store.store_num = store.store_num
65 AND store.cust_type_cd = cust_profile.cust_type_cd(+)
66 AND store.fashion_att_cd = fashion_attribute.fashion_att_cd(+)
67 ORDER BY ss_sku_store.sku,
68 ss_sku_store.store_num;
Execution Plan
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=531 Card=3203 Bytes=948088)
1 0 SORT (GROUP BY) (Cost=531 Card=3203 Bytes=948088)
2 1 HASH JOIN (RIGHT OUTER) (Cost=323 Card=3203 Bytes=948088)
3 2 TABLE ACCESS (FULL) OF 'CUST_PROFILE' (TABLE) (Cost=2 Card=16 Bytes=304)
4 2 HASH JOIN (RIGHT OUTER) (Cost=321 Card=3203 Bytes=887231)
5 4 TABLE ACCESS (FULL) OF 'FASHION_ATTRIBUTE' (TABLE) (Cost=2 Card=9 Bytes=162)
6 4 HASH JOIN (Cost=318 Card=3203 Bytes=829577)
7 6 TABLE ACCESS (FULL) OF 'STORE' (TABLE) (Cost=15 Card=1289 Bytes=105698)
8 6 TABLE ACCESS (BY LOCAL INDEX ROWID) OF 'SS_SKU_STORE' (TABLE) (Cost=3 Card=707 Bytes=17675)
9 8 NESTED LOOPS (Cost=302 Card=3203 Bytes=566931)
10 9 HASH JOIN (Cost=287 Card=5 Bytes=760)
11 10 NESTED LOOPS (Cost=284 Card=5 Bytes=655)
12 11 NESTED LOOPS (Cost=273 Card=5 Bytes=270)
13 12 NESTED LOOPS (Cost=252 Card=86 Bytes=3784)
14 13 NESTED LOOPS (Cost=17 Card=13 Bytes=468)
15 14 SORT (UNIQUE) (Cost=1 Card=13 Bytes=130)
16 15 INDEX (RANGE SCAN) OF 'SS_SESS_SKU_PK' (INDEX (UNIQUE)) (Cost=1 Card=13 Bytes=130)
17 14 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM_VENDOR' (TABLE) (Cost=3 Card=1 Bytes=26)
18 17 INDEX (RANGE SCAN) OF 'ITEM_VENDOR_ITEM_FK_IDX' (INDEX) (Cost=2 Card=1)
19 13 PARTITION HASH (ITERATOR) (Cost=65 Card=7 Bytes=56)
20 19 TABLE ACCESS (BY LOCAL INDEX ROWID)OF 'SS_SKU_STORE_WEEK' (TABLE) (Cost=65 Card=7 Bytes=56)
21 20 INDEX (RANGE SCAN) OF 'SS_SKU_STR_WK_SKU' (INDEX) (Cost=14 Card=6427)
22 12 TABLE ACCESS (FULL) OF 'SS_SESSION_SKU'(TABLE) (Cost=0 Card=1 Bytes=10)
23 11 TABLE ACCESS (BY INDEX ROWID) OF 'ITEM' (TABLE) (Cost=2 Card=1 Bytes=77)
24 23 INDEX (UNIQUE SCAN) OF 'ITEM_PK' (INDEX (UNIQUE)) (Cost=1 Card=1)
25 10 TABLE ACCESS (FULL) OF 'SS_SKU' (TABLE) (Cost=3 Card=343 Bytes=7203)
26 9 PARTITION HASH (ITERATOR) (Cost=1 Card=211)
27 26 INDEX (RANGE SCAN) OF 'SS_SKU_ST_PK' (INDEX(UNIQUE)) (Cost=1 Card=211)
EXPLIAN PLAN AND DATA FROM TKPROF
all count cpu elapsed disk query current rows
Parse 2 0.00 0.01 0 0 0 0
Execute 2 1.35 1.30 0 0 0 0
Fetch 5 0.14 0.16 5 2497 0 111
total 9 1.49 1.49 5 2497 0 111
Misses in library cache during parse: 2
Misses in library cache during execute: 2
Optimizer mode: ALL_ROWS
Parsing user id: 30 (MDSEADMIN)
Rows Row Source Operation
0 PX COORDINATOR FORCED SERIAL (cr=797 pr=2 pw=0 time=42745 us)
0 PX SEND QC (ORDER) :TQ10005 (cr=797 pr=2 pw=0 time=42711 us)
0 SORT ORDER BY (cr=797 pr=2 pw=0 time=42701 us)
0 PX RECEIVE (cr=797 pr=2 pw=0 time=42627 us)
0 PX SEND RANGE :TQ10004 (cr=797 pr=2 pw=0 time=42617 us)
0 BUFFER SORT (cr=797 pr=2 pw=0 time=42609 us)
0 NESTED LOOPS OUTER (cr=797 pr=2 pw=0 time=42532 us)
0 NESTED LOOPS OUTER (cr=797 pr=2 pw=0 time=42520 us)
0 NESTED LOOPS (cr=797 pr=2 pw=0 time=42510 us)
0 NESTED LOOPS (cr=797 pr=2 pw=0 time=42502 us)
0 NESTED LOOPS (cr=797 pr=2 pw=0 time=42495 us)
0 NESTED LOOPS (cr=797 pr=2 pw=0 time=42488 us)
0 HASH JOIN (cr=797 pr=2 pw=0 time=42480 us)
1 BUFFER SORT (cr=5 pr=1 pw=0 time=13357 us)
1 PX RECEIVE (cr=5 pr=1 pw=0 time=13300 us)
1 PX SEND HASH :TQ10001 (cr=5 pr=1 pw=0 time=13291 us)
1 TABLE ACCESS BY INDEX ROWID ITEM_VENDOR (cr=5 pr=1 pw=0 time=13280 us)
3 NESTED LOOPS (cr=4 pr=0 pw=0 time=423 us)
1 SORT UNIQUE (cr=1 pr=0 pw=0 time=189 us)
1 INDEX RANGE SCAN SS_SESS_SKU_PK (cr=1 pr=0 pw=0 time=86 us)(object id 25279)
1 INDEX RANGE SCAN ITEM_VENDOR_ITEM_FK_IDX (cr=3 pr=0 pw=0 time=53 us)(object id 24079)
0 PX RECEIVE (cr=792 pr=1 pw=0 time=28530 us)
0 PX SEND HASH :TQ10003 (cr=792 pr=1 pw=0 time=28524 us)
0 VIEW (cr=792 pr=1 pw=0 time=28517 us)
0 HASH GROUP BY (cr=792 pr=1 pw=0 time=28509 us)
0 PX RECEIVE (cr=792 pr=1 pw=0 time=28295 us)
0 PX SEND HASH :TQ10002 (cr=792 pr=1 pw=0 time=28290 us)
0 NESTED LOOPS (cr=792 pr=1 pw=0 time=28284 us)
1 BUFFER SORT (cr=1 pr=0 pw=0 time=139 us)
1 PX RECEIVE (cr=1 pr=0 pw=0 time=45 us)
1 PX SEND BROADCAST :TQ10000 (cr=1 pr=0 pw=0 time=40 us)
1 INDEX RANGE SCAN SS_SESS_SKU_PK (cr=1 pr=0 pw=0 time=34 us)(object id 25279)
0 PX BLOCK ITERATOR PARTITION: KEY KEY (cr=791 pr=1 pw=0 time=28136 us)
0 TABLE ACCESS FULL SS_SKU_STORE_WEEK PARTITION: KEY KEY (cr=791 pr=1 pw=0 time=28084 us)
0 TABLE ACCESS BY INDEX ROWID ITEM (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN ITEM_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24055)
0 TABLE ACCESS BY INDEX ROWID SS_SKU (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN SS_SKU_PK (cr=0 pr=0 pw=0 time=0 us)(object id 25300)
0 PARTITION HASH ITERATOR PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)
0 TABLE ACCESS BY LOCAL INDEX ROWID SS_SKU_STORE PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)
0 INDEX RANGE SCAN SS_SKU_ST_PK PARTITION: KEY KEY (cr=0 pr=0 pw=0 time=0 us)(object id 25547)
0 TABLE ACCESS BY INDEX ROWID STORE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN STORE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 25586)
0 TABLE ACCESS BY INDEX ROWID FASHION_ATTRIBUTE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN FASHION_ATTRIBUTE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24035)
0 TABLE ACCESS BY INDEX ROWID CUST_PROFILE (cr=0 pr=0 pw=0 time=0 us)
0 INDEX UNIQUE SCAN CUST_PROFILE_PK (cr=0 pr=0 pw=0 time=0 us)(object id 24036)
ALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 43 0.10 0.11 0 1 0 0
Execute 861 0.38 0.45 357 622 46 621
Fetch 845 0.21 0.21 128 2626 2 892
total 1749 0.69 0.78 485 3249 48 1513
Misses in library cache during parse: 21
Misses in library cache during execute: 16
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 60 0.00 0.00
SQL*Net message from client 39 0.00 0.16
db file scattered read 82 0.01 0.05
db file sequential read 185 0.01 0.05
log file sync 1 0.00 0.00
191 user SQL statements in session.
23 internal SQL statements in session.
214 SQL statements in session.
37 statements EXPLAINed in this session.Thank you for your help in advance
Message was edited by:
devmiral -
Performance problem on parsing on remote databases.
Hello experts,
We are facing a performance issue on ORACLE 9.2.0.5
1. We do a select on on a SYNONYM (S_ppm) of a VIEW(ppm) . The View is union
of two tables on two databases on two solaris machines (used database links).
create or replace view ppm as select * from ppm_P UNION ALL SELECT * FROM creactor.ppm_P@SMFD ;
drop synonym S_ppm;
create synonym S_ppm for ppm;
We get the tkprof results as for the select statement on (S_ppm)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 7278 3.54 7.88 0 0 1015 0
Execute 7616 1.09 1.53 0 0 0 0
Fetch 7109 2.36 4.03 0 13722 0 6098
total 22003 7.00 13.44 0 13722 1015 6098
Misses in library cache during parse: 5
2. We increase the machine to three . Three database on three solaris machine.
create or replace view ppm as select * from ppm_P UNION ALL SELECT * FROM creactor.ppm_P@SMFD UNION ALL SELECT * FROM creactor.ppm_P@SMFE;
drop synonym S_ppm;
create synonym S_ppm for ppm;
We get the tkprof results as for the select statement on (S_ppm)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 6214 4.96 11.96 0 1 872 0
Execute 6503 1.00 1.31 0 0 0 0
Fetch 6069 3.40 6.28 0 11708 0 5205
total 18786 9.37 19.56 0 11709 872 5205
Misses in library cache during parse: 5
3. Similarly we increase the machine and database to four
We get the tkprof results as for the select statement on (S_ppm)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 6473 7.19 17.79 0 1 908 0
Execute 6774 1.14 1.43 0 0 0 0
Fetch 6323 4.87 9.46 0 12201 0 5424
total 19570 13.21 28.70 0 12202 908 5424
Misses in library cache during parse: 5
3. Similarly we increase the machine and database to five
We get the tkprof results as for the select statement on (S_ppm)
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 6095 8.58 21.91 0 0 849 0
Execute 6379 1.16 1.42 0 0 0 0
Fetch 5954 5.99 11.78 0 11494 0 5108
total 18428 15.73 35.12 0 11494 849 5108
We see that PARSING elapsed time increases abnormally.
From 7.88 to 11.96 to 17.79 to 21.91
What can be the reason ? and how can we improve on that ?
We found a bug on ORACLE 9.2.0.5
Metalink Bug Id= 4913460 "A soft parse occurs each time a query having embedded remote tables over a database
link is executed."
But ORACLE has no patch for 9.2.0.5 and we cant upgrade to any higher versions?
Can any one help ?
Thanks and regards
Rinchenjr_wastebasket.purge_insignificant_versions helps, I drop old versions of forms
Edited by: Vazha_Mantua on Mar 27, 2009 9:24 AM -
Insert data into table 1 but remove the duplicate data
hello friends,
i m trying to insert data into table tab0 using hints,
query is like this..
INSERT INTO /*+ APPEND PARALLEL(tab0) */ tab NOLOGGING
(select /*+ parallel(tab1)*/
colu1,col2
from tab1 a
where a.rowid =(select max (b.rowid) from tab2 b))
but this query takes too much time around 5 hrs...
bz data almost 40-50 lacs.
i m using
a.rowid =(select max (b.rowid) from tab2 b))....
this is for remove the duplicate data..
but it takes too much time..
so please can u suggest me any ohter option to remove the duplicate data so it
resolved the optimization problem.
thanks in advance.In the code you posted, you're inserting two columns into the destination table. Are you saying that you are allowed to have duplicates in those two columns but you need to filter out duplicates based on additional columns that are not being inserted?
If you've traced the session, please post your tkprof results.
What does "table makes bulky" mean? You understand that the APPEND hint is forcing the insert to happen above the high water mark of the table, right? And you understand that this prevents the insert from reusing space that has been freed up because of deleted in the table? And that this can substantially increase the cost of full scans on the table. Did you benchmark the INSERT without the APPEND hint?
Justin
Maybe you are looking for
-
PDF FILE WILL NOT WORK OR OPEN ADOBE READER NOT WORKING CORRECTLY.
PDF FILE WILL NOT OPEN IN A FEW APPLICATIONS AS THEY DID BEFORE. IF I CAN'T VIEW THEM I CAN'T PRINT THEM.
-
I just noticed my itunes app store isnt on my itunes
on my pc itunes will open. the music, movies,tv shows will open but the app store is just a white page . no apps to view
-
Exception handling for NULL?
During the code... throw new AppException("Customer details are missing"); An exception was thrown, showing there was an error. But how do we handle it?
-
(UK) unable to view bill online at o2.co.uk
hi all - excellent news on the reduced tariffs for the uk however i cannot view my bill online and an email back from o2 tell me it is unavailable to view, wait for it, ON A MAC!!! no kidding - has anyone found a workaround - we don't have a pc in th
-
I cannot open itunes on my computer i have re installed and get msvcr80.dill error
i cannot open itunes iget a error msvcr 80.dill after reinstalling itunes and cannot sync i phone or i pad