|
|
|
Re: tkprof trace analyze for recommendataion [message #504225 is a reply to message #504224] |
Fri, 22 April 2011 07:55 |
John Watson
Messages: 8960 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
There are 8159 user statements in that file! You will have to identify the statement(s) that is (are) causing a problem, then perhaps it can be looked at. For example, the very first statment took nearly 2 hours of elapsed time, but as that was close to a million executions, it probably isn't a problem - particularly as it looks like internal code, not user code. The second statement was 912 executions in 1033 seconds, and is definitely user code. But is it a problem? Only you can say.
|
|
|
|
Re: tkprof trace analyze for recommendataion [message #504647 is a reply to message #504307] |
Wed, 27 April 2011 01:04 |
michael_bialik
Messages: 621 Registered: July 2006
|
Senior Member |
|
|
1. Your new statements does NOT belong to the trace you posted.
2. Look at TKPROF:
SELECT OPENING_BALANCE
FROM JAI_CMN_RG_PLA_TRXS
WHERE TRUNC(CREATION_DATE) >= TRUNC(:b1)
AND REGISTER_ID =
(SELECT MIN(REGISTER_ID)
FROM JAI_CMN_RG_PLA_TRXS
WHERE TRUNC(CREATION_DATE) >= TRUNC(:b1))
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 9774 14102.63 13772.09 3 53092389 0 0
Fetch 9774 1.19 1.18 2 29322 0 9774
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 19549 14103.82 13773.27 5 53121711 0 9774
Misses in library cache during parse: 1
Misses in library cache during execute: 10
Optimizer mode: ALL_ROWS
Parsing user id: 44 (APPS)
Rows Row Source Operation
-------- ---------------------------------------------------
517 TABLE ACCESS BY INDEX ROWID JAI_CMN_RG_PLA_TRXS (cr=2809907 pr=0 pw=0 time=727587754 us)
517 INDEX UNIQUE SCAN JAI_CMN_RG_PLA_TRXS_PK (cr=2809390 pr=0 pw=0 time=727562739 us)(object id 290832)
517 SORT AGGREGATE (cr=2808356 pr=0 pw=0 time=727534922 us)
41175832 TABLE ACCESS FULL JAI_CMN_RG_PLA_TRXS (cr=2808356 pr=0 pw=0 time=714651452 us)
You perform FULL table scan on JAI_CMN_RG_PLA_TRXS.
Why do you need WHERE TRUNC(CREATION_DATE) >= TRUNC(:b1)?
IMHO WHERE CREATION_DATE >= TRUNC(:b1) will work as well and will enable index usage (if such index exists).
I would create an index on (CREATION_DATE, REGISTER_ID) columns for that table (if no such index already exists).
HTH.
|
|
|
Re: tkprof trace analyze for recommendataion [message #504658 is a reply to message #504647] |
Wed, 27 April 2011 02:47 |
John Watson
Messages: 8960 Registered: January 2010 Location: Global Village
|
Senior Member |
|
|
Before attempting to tune the code or define indexes, are you certain you have the correct statements? For example, is the statement detailed above actually a problem? Each execution was (on average) less than 1.5 seconds. If this is an interactive query, that is probably OK. If it is part of a batch job, possibly not.
By the way, Is JAI an EBS financials localization? I'm not familiar with it.
|
|
|