Query tuning during peak load

Dear all,
10.2.0.4 on solaris 10
We have a query which is running for 3 -5 seconds on normal time and on on high load on the system ,it consumes more than 10 seconds. We have a time out set to 5000Millisec . because of this the application cannot be able to read the data on high peak load time.
Any idea how to proceed with this ?
Kai

You have been asking this kind of question for more than three years here, many times I have advised you to find out 'what it is waiting for' and still you are
- too lazy
- incapable
(cross all that apply)
to do any troubleshooting on your own?
Don't you think it is about high time you stop abusing this forum?
Sybrand Bakker
Senior Oracle DBASybrand,
It will hurts to any one with these words, stop commenting. I can see here how "kais" expressing his feelings..
we can tell OP to close the threads but cannot involve much..
Kais,
COOL, Please Mention what is your findings on high load? does it by CPU consumption or some thing else.
Please close the threads in future if answered.

Similar Messages

Is there any issue in scheduling GATHER_STATS_JOB during peak load times?

Hi All,
The default DBMS_STATS job(GATHER_STATS_JOB) is running during our peak load time.
Will it have any performance impact on normal database transactions?
Is it better to reschedule that window?
What all problems can we expect during the job's run(Object locks, High I/O due to table/index reads, High CPU usage etc)?
Please help me in getting the answer. I could not find relevant information from net.
Thanks and regards
Satish

Satish V C wrote:
I am struggling to find an appropriate period to run the job as this database is active 24*7 globally.
I want to know how the activity should be measured. Should it be based on no of sessions or number of transactions or number of cursors or net I/O or a combination of all above?Satish,
if you have the AWR license you could check the AWR reports to find out when your database is most idle. In the 10g time model the most significant aspect is the DB time spent, so the period where the DB time is least might be a good candidate.
You can also check the number of logical/physical I/Os performed per second, the number of sessions, and other ratios that are shown in the top part of the AWR report (e.g. section "Load Profile").
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/

Query Execution during Data Loads (extarction)

I think BI 7.0 permitts that but I would still like to confirm from Gurus.
Can we/users continue to access data or execute queries while extraction is going on?? Can we load data during query execution?
What are the pros and cons of doing that??
Always appreciative of your help.
Suresh

Hi,
Query execution will not really hamper data loading or vice versa. But freshly loaded data would not be available for reporting before it gets activated in the infoprovider. Also in case of a cube, if the 'delete overlapping requests' step is to be performed, there could be erroneous looking data in the report till the time this step runs - that is, between the time when the new load has come in and the old request is deleted. That is why loads are best scheduled when users are not working on the system.

Query tuning request

This is my first post in this forum regarding query tuning, so my sincere apologies in advance if I have:
1) not included sufficient information,
2) included too much information,
3) not posted to the correct forum
I read through Randolf Geist's web page on instructions to post a query tuning request
and attempted to follow it as closely as possible.
I am attempting to figure out where a view I have constructed can be optimized.
It takes approx. 45 seconds to 1 minute to run; I would like to cut that down to 10 seconds if possible.
The view itself is somewhat complex; I will post the actual code if it will help you help me. Please advise.
I was under the impression that posting the code was not necessary, but if it is, let me know and I will post it.
I have been doing SQL development for a few years, but only recently in Oracle.
I have no experience in looking through the following output and being able to tell where I can improve performance,
so this will be a learning experience for me. Thanks in advance for your help - I appreciate it.
Some additional information - my view is based on tables over which I have no control - it is a third-party application
which I do reporting from. I do have the freedom to create indexes on columns within the tables if necessary.
The statement is simply
SELECT * FROM LLU_V_PRODUCTION_DETAIL_03
which is the name of my view.
here's all the information I've been able to retrieve by following Randolf's instructions:
Oracle version is 10.2.0.1.0 - 64bit
Here are optimizer parameters:
NAME TYPE VALUE
user_dump_dest string C:\ORACLE\PRODUCT\10.2.0\ADMIN
 \AXIUMPRODUCTION\UDUMP
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.1
optimizer_index_caching integer 90
optimizer_index_cost_adj integer 20
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
NAME TYPE VALUE
db_file_multiblock_read_count integer 16
NAME TYPE VALUE
db_block_size integer 8192
NAME TYPE VALUE
cursor_sharing string EXACT
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 10-29-2005 01:36
SYSSTATS_INFO DSTOP 10-29-2005 01:36
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 1298.56584
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR
13 rows selected.Here is the output of EXPLAIN PLAN:
PLAN_TABLE_OUTPUT
Plan hash value: 662813077
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 23M| 53G| | 62330 (2)| 00:12:28 |
| 1 | VIEW | LLU_V_PRODUCTION_DETAIL_03 | 23M| 53G| | 62330 (2)| 00:12:28 |
| 2 | UNION-ALL | | | | | | |
|* 3 | HASH JOIN | | 18M| 5062M| | 1525 (10)| 00:00:19 |
| 4 | VIEW | index$_join$_007 | 1725 | 25875 | | 4 (25)| 00:00:01 |
|* 5 | HASH JOIN | | | | | | |
| 6 | INDEX FAST FULL SCAN | USERS_PRIMARY | 1725 | 25875 | | 1 (0)| 00:00:01 |
| 7 | INDEX FAST FULL SCAN | USERS_PRODUCER | 1725 | 25875 | | 2 (0)| 00:00:01 |
|* 8 | HASH JOIN | | 416K| 105M| | 1399 (2)| 00:00:17 |
| 9 | TABLE ACCESS FULL | PRODUCER | 1396 | 118K| | 24 (0)| 00:00:01 |
|* 10 | HASH JOIN | | 29819 | 5183K| | 1372 (2)| 00:00:17 |
| 11 | TABLE ACCESS FULL | CLASS | 20 | 1660 | | 3 (0)| 00:00:01 |
|* 12 | TABLE ACCESS FULL | QR_PRODUCTION | 149K| 13M| | 1367 (2)| 00:00:17 |
|* 13 | FILTER | | | | | | |
|* 14 | HASH JOIN | | 16M| 5651M| | 32983 (2)| 00:06:36 |
| 15 | VIEW | index$_join$_014 | 1725 | 25875 | | 4 (25)| 00:00:01 |
|* 16 | HASH JOIN | | | | | | |
| 17 | INDEX FAST FULL SCAN | USERS_PRIMARY | 1725 | 25875 | | 1 (0)| 00:00:01 |
| 18 | INDEX FAST FULL SCAN | USERS_PRODUCER | 1725 | 25875 | | 2 (0)| 00:00:01 |
|* 19 | HASH JOIN | | 149K| 49M| | 32874 (1)| 00:06:35 |
| 20 | TABLE ACCESS FULL | CLASS | 20 | 1660 | | 3 (0)| 00:00:01 |
|* 21 | HASH JOIN | | 149K| 37M| | 32870 (1)| 00:06:35 |
| 22 | TABLE ACCESS FULL | PRODUCER | 1396 | 118K| | 24 (0)| 00:00:01 |
|* 23 | HASH JOIN | | 222K| 37M| 12M| 32844 (1)| 00:06:35 |
| 24 | TABLE ACCESS FULL | PATIENT | 188K| 10M| | 6979 (1)| 00:01:24 |
|* 25 | HASH JOIN | | 222K| 24M| | 23860 (2)| 00:04:47 |
|* 26 | TABLE ACCESS FULL | PROCEDUR | 888 | 44400 | | 11 (0)| 00:00:01 |
|* 27 | TABLE ACCESS FULL | TRX | 442K| 28M| | 23845 (2)| 00:04:47 |
|* 28 | TABLE ACCESS FULL | USERS | 1 | 11 | | 55 (0)| 00:00:01 |
| 29 | NESTED LOOPS | | 1 | 473 | | 25798 (1)| 00:05:10 |
| 30 | NESTED LOOPS | | 1 | 413 | | 25797 (1)| 00:05:10 |
| 31 | NESTED LOOPS | | 1 | 398 | | 25796 (1)| 00:05:10 |
| 32 | NESTED LOOPS | | 1 | 390 | | 25795 (1)| 00:05:10 |
|* 33 | HASH JOIN | | 1 | 303 | | 25794 (1)| 00:05:10 |
| 34 | TABLE ACCESS FULL | LLU_EVALUATION_DESCRIPTIONS | 95 | 6175 | | 3 (0)| 00:00:01 |
|* 35 | HASH JOIN | | 4630 | 1076K| | 25791 (1)| 00:05:10 |
|* 36 | HASH JOIN | | 9607 | 1623K| | 23834 (1)| 00:04:47 |
| 37 | MERGE JOIN | | 888 | 91464 | | 13 (8)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | CLASS | 20 | 1660 | | 1 (0)| 00:00:01 |
| 39 | INDEX FULL SCAN | CLASS_PRIMARY | 20 | | | 1 (0)| 00:00:01 |
|* 40 | SORT JOIN | | 888 | 17760 | | 12 (9)| 00:00:01 |
|* 41 | TABLE ACCESS FULL | PROCEDUR | 888 | 17760 | | 11 (0)| 00:00:01 |
|* 42 | TABLE ACCESS FULL | TRX | 19125 | 1307K| | 23820 (1)| 00:04:46 |
|* 43 | TABLE ACCESS FULL | GRADITEM | 655K| 40M| | 1952 (1)| 00:00:24 |
| 44 | TABLE ACCESS BY INDEX ROWID | PRODUCER | 1 | 87 | | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | PRODUCER_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
|* 46 | TABLE ACCESS BY INDEX ROWID | GRADING | 1 | 8 | | 1 (0)| 00:00:01 |
|* 47 | INDEX UNIQUE SCAN | GRADING_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 48 | TABLE ACCESS BY INDEX ROWID | USERS | 221 | 3315 | | 1 (0)| 00:00:01 |
|* 49 | INDEX RANGE SCAN | USERS_PRODUCER | 1 | | | 1 (0)| 00:00:01 |
| 50 | TABLE ACCESS BY INDEX ROWID | PATIENT | 1 | 60 | | 1 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | PATIENT_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | USERS | 109 | 1635 | | 1 (0)| 00:00:01 |
| 53 | NESTED LOOPS | | 1 | 438 | | 2023 (1)| 00:00:25 |
| 54 | NESTED LOOPS | | 1 | 423 | | 2022 (1)| 00:00:25 |
| 55 | NESTED LOOPS | | 1 | 363 | | 2021 (1)| 00:00:25 |
| 56 | NESTED LOOPS | | 1 | 276 | | 2020 (1)| 00:00:25 |
| 57 | NESTED LOOPS | | 1 | 193 | | 2019 (1)| 00:00:25 |
| 58 | NESTED LOOPS | | 1 | 185 | | 2018 (1)| 00:00:25 |
| 59 | NESTED LOOPS | | 1 | 173 | | 2017 (1)| 00:00:25 |
| 60 | NESTED LOOPS | | 1 | 140 | | 2016 (1)| 00:00:25 |
|* 61 | TABLE ACCESS FULL | GRADITEM | 317 | 23141 | | 1953 (2)| 00:00:24 |
|* 62 | TABLE ACCESS BY INDEX ROWID| TRX | 1 | 67 | | 1 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | TRX_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
|* 64 | TABLE ACCESS BY INDEX ROWID | TRX | 1 | 33 | | 1 (0)| 00:00:01 |
|* 65 | INDEX UNIQUE SCAN | TRX_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
|* 66 | TABLE ACCESS BY INDEX ROWID | GRADITEM | 1 | 12 | | 1 (0)| 00:00:01 |
|* 67 | INDEX RANGE SCAN | GRADITEM_ID | 19 | | | 1 (0)| 00:00:01 |
|* 68 | TABLE ACCESS BY INDEX ROWID | GRADING | 1 | 8 | | 1 (0)| 00:00:01 |
|* 69 | INDEX UNIQUE SCAN | GRADING_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 70 | TABLE ACCESS BY INDEX ROWID | CLASS | 1 | 83 | | 1 (0)| 00:00:01 |
|* 71 | INDEX UNIQUE SCAN | CLASS_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 72 | TABLE ACCESS BY INDEX ROWID | PRODUCER | 1 | 87 | | 1 (0)| 00:00:01 |
|* 73 | INDEX UNIQUE SCAN | PRODUCER_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
| 74 | TABLE ACCESS BY INDEX ROWID | PATIENT | 1 | 60 | | 1 (0)| 00:00:01 |
|* 75 | INDEX UNIQUE SCAN | PATIENT_PRIMARY | 1 | | | 1 (0)| 00:00:01 |
|* 76 | INDEX RANGE SCAN | USERS_PRODUCER | 1 | | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
 3 - access("QRP"."ProviderID"="U1"."Producer")
 5 - access(ROWID=ROWID)
 8 - access(TRIM("QRP"."ProviderID")=TRIM("P"."Producer"))
10 - access(TRIM("QRP"."axiUm_Discipline")=TRIM("CLASS"."Class"))
12 - filter("QRP"."ProviderID" IS NOT NULL AND "QRP"."Location"<'9990' AND "QRP"."ProcedureID"<>185 AND
 "QRP"."PatientFirstName"<>'NON-PATIENT' AND ("QRP"."PatientFirstName"<>'TED' OR "QRP"."PatientLastName" NOT LIKE
 'CAVENDER%'))
13 - filter( NOT EXISTS (SELECT 0 FROM AXIUM."USERS" "USERS" WHERE "Custom3"='YES' AND LNNVL("User"<>:B1)) OR
 TO_CHAR(INTERNAL_FUNCTION("P"."EndDate"),'YYYY')<'2011' OR TRIM(TO_CHAR(INTERNAL_FUNCTION("P"."EndDate"),'YYYY')) IS
 NULL OR "TRX"."Procedure"='A0021' OR "TRX"."Procedure"='A0022')
14 - access("TRX"."Producer"="U1"."Producer")
16 - access(ROWID=ROWID)
19 - access("PROC"."Discipline"="CLASS"."Class")
21 - access("TRX"."Producer"="P"."Producer")
23 - access("TRX"."Patient"="PAT"."Patient")
25 - access("TRX"."Procedure"="PROC"."Procedure")
26 - filter("PROC"."Discipline" IS NOT NULL)
27 - filter("TRX"."Deleted"=0 AND "TRX"."Status"='C' AND "TRX"."Procedure" NOT LIKE 'D0149%' AND
 "TRX"."Procedure"<>'D5001C')
28 - filter("Custom3"='YES' AND LNNVL("User"<>:B1))
33 - access(TRIM(UPPER("GI"."QuestionText"))=TRIM(UPPER("LLU"."GRADITEM_QuestionText")) AND
 TRIM(UPPER("GI"."Text"))=TRIM(UPPER("LLU"."GRADITEM_Text")) AND TRIM("TRX"."Procedure")=TRIM("LLU"."ProcedureCode"))
35 - access("TRX"."Type"="GI"."Type" AND "TRX"."Id"="GI"."Id" AND "TRX"."Treatment"="GI"."Treatment")
36 - access("TRX"."Procedure"="PROC"."Procedure")
40 - access("PROC"."Discipline"="CLASS"."Class")
 filter("PROC"."Discipline"="CLASS"."Class")
41 - filter("PROC"."Discipline" IS NOT NULL)
42 - filter("TRX"."Grading"<>0 AND "TRX"."Deleted"=0 AND "TRX"."Status"='C')
43 - filter("GI"."Grading"<>0)
45 - access("TRX"."Producer"="P"."Producer")
46 - filter("G"."Deleted"=0)
47 - access("TRX"."Grading"="G"."Grading")
 filter("G"."Grading"<>0 AND "G"."Grading"="GI"."Grading")
49 - access("TRX"."Producer"="U1"."Producer")
51 - access("TRX"."Patient"="PAT"."Patient")
61 - filter("GI"."IsHeading"=3 AND TRIM("GI"."QuestionText")='Comments' AND "GI"."Grading"<>0)
62 - filter("TRX"."Grading"<>0 AND "TRX"."Deleted"=0 AND "TRX"."Status"='C' AND ("TRX"."Procedure"='G1002' OR
 "TRX"."Procedure"='G1003'))
63 - access("GI"."Type"="TRX"."Type" AND "GI"."Id"="TRX"."Id" AND "GI"."Treatment"="TRX"."Treatment")
64 - filter("TRX"."Grading"<>0 AND "TRX"."Deleted"=0 AND "TRX"."Status"='C' AND ("TRX"."Procedure"='G1002' OR
 "TRX"."Procedure"='G1003') AND "TRX"."Grading"="TRX"."Grading")
65 - access("TRX"."Type"="TRX"."Type" AND "TRX"."Id"="TRX"."Id" AND "TRX"."Treatment"="TRX"."Treatment")
66 - filter("GI"."RelValue"<>0 AND "TRX"."Type"="GI"."Type" AND "TRX"."Treatment"="GI"."Treatment")
67 - access("TRX"."Id"="GI"."Id")
68 - filter("G"."Deleted"=0)
69 - access("TRX"."Grading"="G"."Grading")
 filter("G"."Grading"<>0 AND "GI"."Grading"="G"."Grading")
71 - access("TRX"."Discipline"="CLASS"."Class")
73 - access("TRX"."Producer"="P"."Producer")
75 - access("TRX"."Patient"="PAT"."Patient")
76 - access("TRX"."Producer"="U1"."Producer")
138 rows selected.
Elapsed: 00:00:00.62
631015 rows selected.
Elapsed: 00:01:49.13Output from AUTOTRACE (I think)
NOTE: this post was too long for the forum, so I have removed a number of lines in the following output which appeared to be duplicating the above section (EXPLAIN PLAN).
Statistics
 2657 recursive calls
 0 db block gets
 12734113 consistent gets
 13499 physical reads
 0 redo size
103697740 bytes sent via SQL*Net to client
 69744 bytes received via SQL*Net from client
 6312 SQL*Net roundtrips to/from client
 76 sorts (memory)
 0 sorts (disk)
 631015 rows processedThe TKPROF output
select * from llu_v_production_detail_03
call count cpu elapsed disk query current rows
Parse 1 0.51 0.51 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 6312 88.09 98.01 13490 12733584 0 631015
total 6314 88.60 98.52 13490 12733584 0 631015
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 57
Rows Row Source Operation
631015 VIEW LLU_V_PRODUCTION_DETAIL_03 (cr=12733584 pr=13490 pw=0 time=92145592 us)
631015 UNION-ALL (cr=12733584 pr=13490 pw=0 time=91514573 us)
125485 HASH JOIN (cr=8099 pr=6396 pw=0 time=1523326 us)
 1725 VIEW index$_join$_007 (cr=24 pr=0 pw=0 time=4777 us)
 1725 HASH JOIN (cr=24 pr=0 pw=0 time=3051 us)
 1725 INDEX FAST FULL SCAN USERS_PRIMARY (cr=7 pr=0 pw=0 time=50 us)(object id 55023)
 1725 INDEX FAST FULL SCAN USERS_PRODUCER (cr=17 pr=0 pw=0 time=16 us)(object id 55024)
144513 HASH JOIN (cr=8075 pr=6396 pw=0 time=2326445 us)
 1396 TABLE ACCESS FULL PRODUCER (cr=107 pr=0 pw=0 time=29 us)
144513 HASH JOIN (cr=7968 pr=6396 pw=0 time=2035684 us)
 20 TABLE ACCESS FULL CLASS (cr=7 pr=0 pw=0 time=71 us)
151043 TABLE ACCESS FULL QR_PRODUCTION (cr=7961 pr=6396 pw=0 time=313553 us)
462685 FILTER (cr=10755862 pr=7094 pw=0 time=58570941 us)
466790 HASH JOIN (cr=145247 pr=7094 pw=0 time=11007301 us)
 1725 VIEW index$_join$_014 (cr=24 pr=0 pw=0 time=6817 us)
 1725 HASH JOIN (cr=24 pr=0 pw=0 time=5091 us)
 1725 INDEX FAST FULL SCAN USERS_PRIMARY (cr=7 pr=0 pw=0 time=35 us)(object id 55023)
 1725 INDEX FAST FULL SCAN USERS_PRODUCER (cr=17 pr=0 pw=0 time=19 us)(object id 55024)
485205 HASH JOIN (cr=145223 pr=7094 pw=0 time=10945107 us)
 20 TABLE ACCESS FULL CLASS (cr=7 pr=0 pw=0 time=105 us)
507772 HASH JOIN (cr=145216 pr=7094 pw=0 time=11947534 us)
 1396 TABLE ACCESS FULL PRODUCER (cr=107 pr=0 pw=0 time=18 us)
507772 HASH JOIN (cr=145109 pr=7094 pw=0 time=10924473 us)
188967 TABLE ACCESS FULL PATIENT (cr=31792 pr=0 pw=0 time=188998 us)
507772 HASH JOIN (cr=113317 pr=7094 pw=0 time=9652037 us)
 895 TABLE ACCESS FULL PROCEDUR (cr=46 pr=0 pw=0 time=65 us)
509321 TABLE ACCESS FULL TRX (cr=113271 pr=7094 pw=0 time=5604567 us)
 8548 TABLE ACCESS FULL USERS (cr=10610615 pr=0 pw=0 time=39053120 us)
42669 NESTED LOOPS (cr=507317 pr=0 pw=0 time=3686506 us)
42669 NESTED LOOPS (cr=421535 pr=0 pw=0 time=3217140 us)
45269 NESTED LOOPS (cr=301155 pr=0 pw=0 time=2449542 us)
45323 NESTED LOOPS (cr=210131 pr=0 pw=0 time=2134056 us)
45323 HASH JOIN (cr=119056 pr=0 pw=0 time=1635472 us)
 95 TABLE ACCESS FULL LLU_EVALUATION_DESCRIPTIONS (cr=7 pr=0 pw=0 time=118 us)
98272 HASH JOIN (cr=119049 pr=0 pw=0 time=1446703 us)
46996 HASH JOIN (cr=109018 pr=0 pw=0 time=944857 us)
 786 MERGE JOIN (cr=50 pr=0 pw=0 time=1528 us)
 20 TABLE ACCESS BY INDEX ROWID CLASS (cr=4 pr=0 pw=0 time=99 us)
 20 INDEX FULL SCAN CLASS_PRIMARY (cr=1 pr=0 pw=0 time=10 us)(object id 53850)
 786 SORT JOIN (cr=46 pr=0 pw=0 time=750 us)
 895 TABLE ACCESS FULL PROCEDUR (cr=46 pr=0 pw=0 time=18 us)
47196 TABLE ACCESS FULL TRX (cr=108968 pr=0 pw=0 time=805137 us)
696300 TABLE ACCESS FULL GRADITEM (cr=10031 pr=0 pw=0 time=277 us)
45323 TABLE ACCESS BY INDEX ROWID PRODUCER (cr=91075 pr=0 pw=0 time=414937 us)
45323 INDEX UNIQUE SCAN PRODUCER_PRIMARY (cr=45752 pr=0 pw=0 time=198709 us)(object id 54581)
45269 TABLE ACCESS BY INDEX ROWID GRADING (cr=91024 pr=0 pw=0 time=353081 us)
45270 INDEX UNIQUE SCAN GRADING_PRIMARY (cr=45753 pr=0 pw=0 time=173185 us)(object id 54088)
42669 TABLE ACCESS BY INDEX ROWID USERS (cr=120380 pr=0 pw=0 time=703786 us)
42669 INDEX RANGE SCAN USERS_PRODUCER (cr=46127 pr=0 pw=0 time=249186 us)(object id 55024)
42669 TABLE ACCESS BY INDEX ROWID PATIENT (cr=85782 pr=0 pw=0 time=407452 us)
42669 INDEX UNIQUE SCAN PATIENT_PRIMARY (cr=43098 pr=0 pw=0 time=198477 us)(object id 54370)
 176 TABLE ACCESS BY INDEX ROWID USERS (cr=49426 pr=0 pw=0 time=1783886 us)
 367 NESTED LOOPS (cr=49149 pr=0 pw=0 time=6159428 us)
 190 NESTED LOOPS (cr=48953 pr=0 pw=0 time=409391 us)
 190 NESTED LOOPS (cr=48569 pr=0 pw=0 time=407105 us)
 190 NESTED LOOPS (cr=48185 pr=0 pw=0 time=404820 us)
 191 NESTED LOOPS (cr=47991 pr=0 pw=0 time=410291 us)
 193 NESTED LOOPS (cr=47603 pr=0 pw=0 time=422507 us)
 193 NESTED LOOPS (cr=46979 pr=0 pw=0 time=416890 us)
 193 NESTED LOOPS (cr=46396 pr=0 pw=0 time=414374 us)
14285 TABLE ACCESS FULL GRADITEM (cr=9602 pr=0 pw=0 time=85793 us)
 193 TABLE ACCESS BY INDEX ROWID TRX (cr=36794 pr=0 pw=0 time=128427 us)
 8218 INDEX UNIQUE SCAN TRX_PRIMARY (cr=28576 pr=0 pw=0 time=64353 us)(object id 54930)
 193 TABLE ACCESS BY INDEX ROWID TRX (cr=583 pr=0 pw=0 time=2169 us)
 193 INDEX UNIQUE SCAN TRX_PRIMARY (cr=390 pr=0 pw=0 time=918 us)(object id 54930)
 193 TABLE ACCESS BY INDEX ROWID GRADITEM (cr=624 pr=0 pw=0 time=4840 us)
 1547 INDEX RANGE SCAN GRADITEM_ID (cr=395 pr=0 pw=0 time=2910 us)(object id 54093)
 191 TABLE ACCESS BY INDEX ROWID GRADING (cr=388 pr=0 pw=0 time=1887 us)
 191 INDEX UNIQUE SCAN GRADING_PRIMARY (cr=197 pr=0 pw=0 time=943 us)(object id 54088)
 190 TABLE ACCESS BY INDEX ROWID CLASS (cr=194 pr=0 pw=0 time=1306 us)
 190 INDEX UNIQUE SCAN CLASS_PRIMARY (cr=4 pr=0 pw=0 time=551 us)(object id 53850)
 190 TABLE ACCESS BY INDEX ROWID PRODUCER (cr=384 pr=0 pw=0 time=1617 us)
 190 INDEX UNIQUE SCAN PRODUCER_PRIMARY (cr=194 pr=0 pw=0 time=715 us)(object id 54581)
 190 TABLE ACCESS BY INDEX ROWID PATIENT (cr=384 pr=0 pw=0 time=1941 us)
 190 INDEX UNIQUE SCAN PATIENT_PRIMARY (cr=194 pr=0 pw=0 time=939 us)(object id 54370)
 176 INDEX RANGE SCAN USERS_PRODUCER (cr=196 pr=0 pw=0 time=1389 us)(object id 55024)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 6312 0.00 0.00
db file scattered read 1614 0.02 2.08
SQL*Net message from client 6312 0.00 10.11
SQL*Net more data to client 48662 0.00 0.70
db file sequential read 4645 0.02 7.11
latch: shared pool 7 0.00 0.00
latch: cache buffers chains 1 0.00 0.00
********************************************************************************Again, I apologize if this is way more information than is necessary.
All advice/suggestions/assistance will be gratefully accepted.
Carl

Hi Rob,
Thank you for replying. Here is the view definition . . . it looks pretty convoluted, I know.
I am reporting from a database which I have no control over other than to add indexes where needed.
For reporting purposes, I am needing to create the dataset from a number of different tables; hence all the UNION clauses.
-- CODE FOLLOWS
CREATE OR REPLACE VIEW LLU_V_PRODUCTION_DETAIL_03
AS
SELECT
'QR' AS "Source",
U1."User" AS "UserID",
QRP."ProviderID" AS "ProviderID",
P."LastName" AS "ProviderLastName",
P."FirstName" AS "ProviderFirstName",
TO_CHAR(P."EndDate",'YYYY') AS "GraduationYear",
P."PGroup",
QRP."PatientID",
QRP."ChartNumber",
QRP."PatientLastName",
QRP."PatientFirstName",
QRP."ProcedureID" || '-' || QRP."ProcedureSuffix" AS "Procedure",
QRP."ProcedureDescription",
QRP."Tooth" AS "Site",
QRP."Surface",
QRP."axiUm_Discipline" AS "Discipline",
"CLASS"."Rank" AS "DisciplineSorter",
"CLASS"."Name" AS "DisciplineName",
QRP."Points",
0 AS "Hours",
QRP."ServiceDate",
0 AS "Id",
QRP."UniqueID" AS "Grading",
0 AS "LastSort",
QRP."CategoryID",
'' AS "CPAR comments"
FROM QR_PRODUCTION QRP
INNER JOIN PRODUCER P
ON TRIM(QRP."ProviderID") = TRIM(P."Producer")
INNER JOIN CLASS
ON TRIM(QRP."axiUm_Discipline") = TRIM(CLASS."Class")
INNER JOIN USERS U1
ON QRP."ProviderID" = U1."Producer"
WHERE (QRP."Location" < '9990')
AND (QRP."ProviderID" IS NOT NULL)
AND (QRP."ProcedureID" <> 185)
-- skip the Cavender family - training patients
AND NOT (QRP."PatientLastName" LIKE 'CAVENDER%' AND QRP."PatientFirstName" = 'TED')
AND QRP."PatientFirstName" <> 'NON-PATIENT'
--ORDER BY QRP."ProcedureID"
UNION ALL
SELECT
'axiUm TRX' AS "Source",
U1."User" AS "UserID",
TRX."Producer" AS "ProviderID",
P."LastName",
P."FirstName",
TO_CHAR(P."EndDate",'YYYY') AS "GraduationYear",
P."PGroup",
PAT."Patient",
PAT."Chart",
PAT."Last" AS "PatientLastName",
PAT."First" AS "PatientFirstName",
TRX."Procedure",
PROC."Description",
TRX."Site",
TRX."Surface",
TRIM(PROC."Discipline") AS "Discipline",
"CLASS"."Rank" AS "DisciplineSorter",
"CLASS"."Name",
CASE WHEN
 ((TRX."Procedure" IN ('A0013','A0019','A0020','A0021','A0023','A0024','A0025','A0026','A0027','A0028','A0029','A0030','O179'))
 OR
 -- no points are to be awarded for any procedures performed on typodonts
 (EXISTS (SELECT 1 FROM PTTYPES PTT WHERE PTT."Patient" = PAT."Patient" and PTT."PatType" = 'TYPO' and PTT."Deleted" = 0)))
 AND -- except for the following procedures
 (TRX."Procedure" NOT IN ('A0015','A0016','A0018','D0210'))
 THEN 0 ELSE PROC."RelValue" END AS "Points",
CASE WHEN TRX."Procedure" IN ('A0013','A0019','A0020','A0021','A0023','A0024','A0025','A0026','A0027','A0028','A0029','A0030','O179')
 THEN PROC."RelValue" ELSE 0 END AS "Hours",
TRX."TreatmentDate",
TRX."Id",
TRX."Grading",
-1 AS "LastSort",
-- additional link conditions added and table name changed on 1 July 2009 - cji
SELECT "CategoryID" FROM LLU_CATEGORIES_X_PROCEDURES_03 LLU
WHERE TRX."Procedure" = LLU."ProcedureID"
AND TO_CHAR(P."EndDate",'YYYY') = LLU."GraduationYear"
AND SUBSTR(TRX."Producer",1,1) = LLU."ProviderType"
AND LLU."CategoryID" NOT IN (82)
) AS "CategoryID",
'' AS "CPAR comments"
FROM TRX
INNER JOIN PATIENT PAT
ON TRX."Patient" = PAT."Patient"
INNER JOIN USERS U1
ON TRX."Producer" = U1."Producer"
INNER JOIN PROCEDUR PROC
ON TRX."Procedure" = PROC."Procedure"
INNER JOIN CLASS
ON PROC."Discipline" = CLASS."Class"
INNER JOIN PRODUCER P
ON TRX."Producer" = P."Producer"
WHERE (TRX."Status" = 'C')
AND (TRX."Deleted" = 0)
--AND (TRX."Grading" = 0)
AND (TRX."Procedure" NOT LIKE 'D0149%')
AND (TRX."Procedure" <> 'D5001C')
-- exclude all procedures approved by Peds faculty ONLY FOR CLASS OF 2011 AND LATER
-- EXCEPT FOR the Peds Block code (A0021 and A0022) - always include those
AND NOT
TRX."AppUser" IN (SELECT "User" FROM USERS WHERE "Custom3" = 'YES') -- Peds faculty
AND
TO_CHAR(P."EndDate",'YYYY') >= '2011'
AND
TRIM(TO_CHAR(P."EndDate",'YYYY')) IS NOT NULL
AND
TRX."Procedure" NOT IN ('A0021','A0022')
UNION ALL
SELECT
'axiUm GRADING' AS "Source",
U1."User" AS "UserID",
TRX."Producer" AS "ProviderID",
P."LastName",
P."FirstName",
TO_CHAR(P."EndDate",'YYYY'), -- Graduation year
P."PGroup",
PAT."Patient",
PAT."Chart",
PAT."Last" AS "PatientLastName",
PAT."First" AS "PatientFirstName",
TRX."Procedure",
LLU."Description",
TRX."Site",
TRX."Surface",
TRIM(PROC."Discipline") AS "Discipline",
"CLASS"."Rank" AS "DisciplineSorter",
"CLASS"."Name",
LLU."Points", --LLU_POINTS_FROM_EVALUATIONS(TRX."Procedure", nvl(GI."Text",0)),
0 AS "Hours",
TRX."TreatmentDate",
GI."Id",
GI."Grading",
GI."Row" AS "LastSort",
LLU."CategoryID",
'' AS "CPAR comments"
FROM TRX
INNER JOIN PATIENT PAT
ON TRX."Patient" = PAT."Patient"
INNER JOIN PRODUCER P
ON TRX."Producer" = P."Producer"
INNER JOIN GRADING G
ON TRX."Grading" = G."Grading"
INNER JOIN GRADITEM GI
ON G."Grading" = GI."Grading"
AND TRX."Type" = GI."Type"
AND TRX."Id" = GI."Id"
AND TRX."Treatment" = GI."Treatment"
INNER JOIN PROCEDUR PROC
ON TRX."Procedure" = PROC."Procedure"
INNER JOIN CLASS
ON PROC."Discipline" = CLASS."Class"
INNER JOIN LLU_EVALUATION_DESCRIPTIONS LLU
ON (TRIM(UPPER(GI."QuestionText")) = TRIM(UPPER(LLU."GRADITEM_QuestionText")))
AND (TRIM(UPPER(GI."Text")) = TRIM(UPPER(LLU."GRADITEM_Text")))
AND (TRIM(TRX."Procedure") = TRIM(LLU."ProcedureCode"))
INNER JOIN USERS U1
ON TRX."Producer" = U1."Producer"
WHERE (TRX."Status" = 'C')
AND (TRX."Deleted" = 0)
AND (TRX."Grading" <> 0)
AND (G."Deleted" = 0)
UNION ALL
SELECT 'ClinPtsAdj',
U1."User" AS "UserID",
TRX."Producer",
P."LastName", P."FirstName",
TO_CHAR(P."EndDate",'YYYY'), -- Graduation year
P."PGroup", PAT."Patient", PAT."Chart", PAT."Last", PAT."First",
TRX."Procedure",
'Clinic points adjustment',
'' AS "Site",
'' AS "Surface",
TRIM(TRX."Discipline"),
"CLASS"."Rank",
"CLASS"."Name",
DERIVED."Points",
0 AS "Hours",
GI."Date",
GI."Id",
GI."Grading",
GI."Row",
NULL AS "CategoryID",
TRIM(REPLACE(GI."Note", CHR(13) || CHR(10), ' '))
FROM TRX
INNER JOIN PATIENT PAT
ON (TRX."Patient" = PAT."Patient")
INNER JOIN PRODUCER P
ON (TRX."Producer" = P."Producer")
INNER JOIN CLASS
ON (TRX."Discipline" = CLASS."Class")
INNER JOIN GRADING G
ON (TRX."Grading" = G."Grading")
INNER JOIN GRADITEM GI
ON (GI."Grading" = G."Grading")
AND (GI."Type" = TRX."Type")
AND (GI."Id" = TRX."Id")
AND (GI."Treatment" = TRX."Treatment")
INNER JOIN USERS U1
ON TRX."Producer" = U1."Producer"
INNER JOIN
SELECT TRX."Type", TRX."Id", TRX."Treatment", TRX."Grading",
 CASE WHEN TRX."Procedure" = 'G1003' THEN GI."RelValue" * -1 ELSE "RelValue" END AS "Points"
FROM TRX, GRADITEM GI
WHERE (TRX."Type" = GI."Type")
AND (TRX."Id" = GI."Id")
AND (TRX."Treatment" = GI."Treatment")
AND (TRX."Procedure" IN ('G1002','G1003'))
AND (TRX."Status" = 'C')
AND (TRX."Deleted" = 0)
AND (TRX."Grading" <> 0)
AND (GI."RelValue" <> 0)
) DERIVED
ON (TRX."Type" = DERIVED."Type")
AND (TRX."Id" = DERIVED."Id")
AND (TRX."Treatment" = DERIVED."Treatment")
AND (TRX."Grading" = DERIVED."Grading")
WHERE (TRX."Status" = 'C')
AND (TRX."Deleted" = 0)
AND (TRX."Grading" <> 0)
AND (G."Deleted" = 0)
AND (TRX."Procedure" IN ('G1002','G1003'))
AND (GI."IsHeading" = 3)
AND (TRIM(GI."QuestionText") = 'Comments')
--ORDER BY "ProviderID", "DisciplineSorter", "Id", "Grading", "Site", "LastSort";A couple of additional points:
The table USERS already had an index on column "Producer"; I added an index on column "Custom3" but it did not seem to make any difference.
Table USERS has 1,725 rows
Table PRODUCER (aliased as P) has 1,396 rows
Table TRX has 1,443,764 rows.
Any additional information you need I will be glad to provide.
Thanks a bunch; it may not be too late to teach an old dog new tricks.
And thank you all for the kind words about the posting; about the only thing I can do well is follow directions.
Carl

Complex SQL query Tuning

Hi Fellas,
I am new to query tuning. I have a big query with a TKPROF details. It is just fetching 34 records and taking approx 30 mins.
The TKPROF detail will follow after the query.
SELECT /*+ NO_INDEX(A, RA_CUSTOMER_TRX_N11 ) USE_NL(TYPES,A) */ a.customer_trx_id CUSTOMER_TRX_ID ,
a.trx_number TRX_NUMBER ,
A . INTERFACE_HEADER_ATTRIBUTE5 BILLING_STAGE ,
A . INTERFACE_HEADER_CONTEXT PBRR_TYPE ,
A . INTERFACE_HEADER_ATTRIBUTE11 BILLING_TERM ,
NVL ( TL . SEQUENCE_NUM , 1 ) TERM_SEQUENCE_NUMBER ,
types.type TRX_TYPE ,
l_types.meaning TRX_TYPE_NAME ,
TYPES . ACCOUNTING_AFFECT_FLAG OPEN_RECEIVABLE_FLAG ,
a.trx_date TRX_DATE , SHIP_TO_CUSTOMER_ID SHIP_TO_CUSTOMER_ID ,
SHIP_TO_CONTACT_ID SHIP_TO_CONTACT_ID ,
REMIT_TO_ADDRESS_ID REMIT_TO_ADDRESS_ID ,
A . PRIMARY_SALESREP_ID PRIMARY_SALESREP_ID ,
B . ACCOUNT_NUMBER CUSTOMER_NUMBER ,
A . INTERNAL_NOTES INTERNAL_NOTES ,
A . COMMENTS TRX_COMMENTS ,
PREVIOUS_CUSTOMER_TRX_ID PREVIOUS_CUSTOMER_TRX_ID ,
SHIP_TO_SITE_USE_ID SHIP_TO_SITE_USE_ID ,
NVL ( PRINTING_COUNT , 0 ) PRINTING_COUNT ,
PRINTING_ORIGINAL_DATE PRINTING_ORIGINAL_DATE ,
PRINTING_LAST_PRINTED PRINTING_LAST_PRINTED ,
PRINTING_PENDING PRINTING_PENDING ,
LAST_PRINTED_SEQUENCE_NUM LAST_PRINTED_SEQUENCE_NUMBER ,
START_DATE_COMMITMENT START_DATE_COMMITMENT ,
END_DATE_COMMITMENT END_DATE_COMMITMENT ,
INITIAL_CUSTOMER_TRX_ID INITIAL_CUSTOMER_TRX_ID ,
A . INVOICE_CURRENCY_CODE INVOICE_CURRENCY_CODE ,
A . REASON_CODE CREDIT_HEADER_REASON_CODE_CSTM ,
A . TERM_ID TERM_ID ,
A . SHIP_DATE_ACTUAL SHIP_DATE_ACTUAL ,
A . SHIP_VIA SHIP_VIA ,
A . WAYBILL_NUMBER WAYBILL_NUMBER ,
A . PURCHASE_ORDER PURCHASE_ORDER_NUMBER ,
A . PURCHASE_ORDER_REVISION PURCHASE_ORDER_REVISION ,
A . PURCHASE_ORDER_DATE PURCHASE_ORDER_DATE ,
A . CREATED_BY ORDER_CREATED_BY_CSTM ,
P . DUE_DATE TERM_DUE_DATE_FROM_PS ,
NVL ( TL . RELATIVE_AMOUNT , 100 ) * ( 100 / NVL ( T . BASE_AMOUNT , 100 ) ) TERM_RELATIVE_AMOUNT ,
T . NAME TERM_NAME ,
A . BILL_TO_CUSTOMER_ID BILL_TO_CUSTOMER_ID ,
A . BILL_TO_CONTACT_ID BILL_TO_CONTACT_ID ,
A . BILL_TO_SITE_USE_ID BILL_TO_SITE_USE_ID ,
U_BILL . LOCATION BILL_TO_LOCATION ,
SUBSTRB ( PARTY . PARTY_NAME , 1 , 50 ) BILL_CUST_NAME ,
RTRIM ( RPAD ( LOC . ADDRESS1 , 40 ) ) BILL_ADDRESS1 ,
RTRIM ( RPAD ( LOC . ADDRESS2 , 40 ) ) BILL_ADDRESS2 ,
RTRIM ( RPAD ( LOC . ADDRESS3 , 40 ) ) BILL_ADDRESS3 ,
RTRIM ( RPAD ( LOC . ADDRESS4 , 40 ) ) BILL_ADDRESS4 ,
LOC . CITY BILL_CITY , NVL ( LOC . STATE ,
LOC . PROVINCE ) BILL_STATE ,
LOC . POSTAL_CODE BILL_POSTAL_CODE ,
LOC . COUNTRY BILL_COUNTRY ,
U_BILL . TAX_REFERENCE BILL_SITE_TAX_REFERENCE ,
PARTY . TAX_REFERENCE BILL_CUST_TAX_REFERENCE ,
nvl(amount_line_items_original + decode(a.initial_customer_trx_id, '', 0, nvl(com_adj.amount,0)), to_number(null)) TRX_LINE_AMOUNT ,
nvl(tax_original, to_number(null)) TRX_TAX_AMOUNT ,
nvl(freight_original, to_number(null)) TRX_FREIGHT_AMOUNT ,
p.amount_due_original + decode(a.initial_customer_trx_id, '', 0, nvl(com_adj.amount,0)) TRX_ALL_AMOUNT ,
DECODE ( : P_ORDER_BY , 'TRX_NUMBER' , A . TRX_NUMBER , 'ADJUSTMENT_NUMBER' , A.TRX_NUMBER , 'CUSTOMER' , SUBSTRB ( PARTY . PARTY_NAME , 1 , 50 ) , 'POSTAL_CODE' , LOC . POSTAL_CODE , A . TRX_NUMBER ) ORDER_BY ,
LOC . ADDRESS1 BILL_TO_ADDRESS1 ,
LOC . ADDRESS2 BILL_TO_ADDRESS2 ,
LOC . ADDRESS3 BILL_TO_ADDRESS3 ,
LOC . ADDRESS4 BILL_TO_ADDRESS4 ,
LOC . STATE BILL_TO_STATE ,
LOC . PROVINCE BILL_TO_PROVINCE ,
T . description Term_Description ,
a . org_id ,
a . created_from
FROM
AR_ADJUSTMENTS COM_ADJ,
AR_PAYMENT_SCHEDULES P,
RA_CUST_TRX_LINE_GL_DIST REC,
RA_CUSTOMER_TRX A,
HZ_CUST_ACCOUNTS B,
RA_TERMS T,
RA_TERMS_LINES TL,
RA_CUST_TRX_TYPES TYPES,
AR_LOOKUPS L_TYPES,
HZ_PARTIES PARTY,
HZ_CUST_ACCT_SITES A_BILL,
HZ_PARTY_SITES PARTY_SITE,
HZ_LOCATIONS LOC,
HZ_CUST_SITE_USES U_BILL
WHERE
A.BILL_TO_CUSTOMER_ID = B.CUST_ACCOUNT_ID AND
REC.CUSTOMER_TRX_ID = A.CUSTOMER_TRX_ID AND
REC.LATEST_REC_FLAG = 'Y' AND
REC.ACCOUNT_CLASS = 'REC' AND
P.PAYMENT_SCHEDULE_ID + DECODE ( P.CLASS , 'INV' , 0 , '' ) = COM_ADJ.PAYMENT_SCHEDULE_ID (+) AND
COM_ADJ.SUBSEQUENT_TRX_ID IS NULL AND 'C' = COM_ADJ.ADJUSTMENT_TYPE (+) AND
A.COMPLETE_FLAG = 'Y' AND
A.CUST_TRX_TYPE_ID = TYPES.CUST_TRX_TYPE_ID AND
L_TYPES.LOOKUP_TYPE = 'INV/CM/ADJ' AND
A.PRINTING_OPTION IN ( 'PRI' , 'REP' ) AND
L_TYPES.LOOKUP_CODE = DECODE ( TYPES.TYPE , 'DEP' , 'INV' , TYPES.TYPE ) AND
NVL ( P.TERMS_SEQUENCE_NUMBER , nvl ( TL.SEQUENCE_NUM , 0 ) ) = nvl ( TL.SEQUENCE_NUM , nvl ( p.terms_sequence_number , 0 ) ) AND
DECODE ( P.PAYMENT_SCHEDULE_ID , '' , 0 , NVL ( T.PRINTING_LEAD_DAYS , 0 ) ) = 0 AND
A.BILL_TO_SITE_USE_ID = U_BILL.SITE_USE_ID AND
U_BILL.CUST_ACCT_SITE_ID = A_BILL.CUST_ACCT_SITE_ID AND
A_BILL.party_site_id = party_site.party_site_id AND
B.PARTY_ID = PARTY.PARTY_ID AND
loc.location_id = party_site.location_id AND
NVL ( P.AMOUNT_DUE_REMAINING , 0 ) <> 0 AND
A.CUST_TRX_TYPE_ID = 2526 AND
TYPES.TYPE = 'INV' AND
A.TERM_ID = TL.TERM_ID (+) AND
A.TERM_ID = T.TERM_ID (+) AND
A.CUSTOMER_TRX_ID = P.CUSTOMER_TRX_ID (+) AND
A.PRINTING_PENDING = 'Y' AND
NVL ( TL.SEQUENCE_NUM , 1 ) > NVL ( A.LAST_PRINTED_SEQUENCE_NUM , 0 ) and 1 = 1 AND
NOT EXISTS ( SELECT 'X' from ECE_TP_DETAILS ETD ,
 ECE_TP_HEADERS ETH
WHERE
ETH.TP_HEADER_ID = A_BILL.TP_HEADER_ID AND
ETD.TP_HEADER_ID = ETH.TP_HEADER_ID AND
ETD.EDI_FLAG = 'Y' AND
ETD.DOCUMENT_ID = 'INO' AND
ETD.DOCUMENT_TYPE = DECODE ( TYPES.TYPE , 'CM' , DECODE ( A.PREVIOUS_CUSTOMER_TRX_ID , NULL , 'OACM' , 'CM' ) , TYPES.TYPE ) ) AND
A.PRINTING_OPTION IN ( 'PRI' , 'REP' ) AND
T.NAME not like 'PB%' AND
1 = 1 AND
MIT_AR.GE_AR_COAKLEY_ELIGIBLE ( 'NEW' , P.CUSTOMER_TRX_ID , A.ORG_ID ) = 0 AND
A.org_id = TYPES.org_id UNION SELECT /*+ NO_INDEX(A, RA_CUSTOMER_TRX_N11 ) USE_NL(TYPES,A) */
a.customer_trx_id , a.trx_number ,
A . INTERFACE_HEADER_ATTRIBUTE5 ,
A . INTERFACE_HEADER_CONTEXT ,
A . INTERFACE_HEADER_ATTRIBUTE11 ,
NVL ( P . TERMS_SEQUENCE_NUMBER , 1 ) ,
types.type , l_types.meaning ,
TYPES . ACCOUNTING_AFFECT_FLAG ,
a.trx_date ,
A . SHIP_TO_CUSTOMER_ID ,
A . SHIP_TO_CONTACT_ID ,
A . REMIT_TO_ADDRESS_ID ,
A . PRIMARY_SALESREP_ID ,
B . ACCOUNT_NUMBER ,
A . INTERNAL_NOTES ,
A . COMMENTS ,
PREVIOUS_CUSTOMER_TRX_ID ,
SHIP_TO_SITE_USE_ID ,
NVL ( PRINTING_COUNT , 0 ) ,
PRINTING_ORIGINAL_DATE ,
PRINTING_LAST_PRINTED ,
PRINTING_PENDING ,
LAST_PRINTED_SEQUENCE_NUM ,
START_DATE_COMMITMENT ,
END_DATE_COMMITMENT ,
INITIAL_CUSTOMER_TRX_ID ,
A . INVOICE_CURRENCY_CODE ,
A . REASON_CODE ,
A . TERM_ID ,
A . SHIP_DATE_ACTUAL ,
A . SHIP_VIA ,
A . WAYBILL_NUMBER ,
A . PURCHASE_ORDER ,
A . PURCHASE_ORDER_REVISION ,
A . PURCHASE_ORDER_DATE ,
A . CREATED_BY ,
P . DUE_DATE ,
NVL ( TL . RELATIVE_AMOUNT , 100 ) * ( 100 / NVL ( T . BASE_AMOUNT , 100 ) ) ,
T . NAME , A . BILL_TO_CUSTOMER_ID ,
A . BILL_TO_CONTACT_ID ,
A . BILL_TO_SITE_USE_ID ,
U_BILL . LOCATION BILL_TO_LOCATION ,
SUBSTRB ( PARTY . PARTY_NAME , 1 , 50 ) BILL_CUST_NAME ,
RTRIM ( RPAD ( LOC . ADDRESS1 , 40 ) ) ,
RTRIM ( RPAD ( LOC . ADDRESS2 , 40 ) ) ,
RTRIM ( RPAD ( LOC . ADDRESS3 , 40 ) ) ,
RTRIM ( RPAD ( LOC . ADDRESS4 , 40 ) ) ,
LOC . CITY ,
NVL ( LOC . STATE , LOC . PROVINCE ) ,
LOC . POSTAL_CODE ,
LOC . COUNTRY ,
U_BILL . TAX_REFERENCE ,
PARTY . TAX_REFERENCE ,
nvl(amount_line_items_original + decode(a.initial_customer_trx_id, '', 0, nvl(com_adj.amount,0)), to_number(null)) ,
nvl(tax_original, to_number(null)) ,
nvl(freight_original, to_number(null)) ,
p.amount_due_original + decode(a.initial_customer_trx_id, '', 0, nvl(com_adj.amount,0)) ,
DECODE ( : P_ORDER_BY , 'TRX_NUMBER' ,
A . TRX_NUMBER , 'ADJUSTMENT_NUMBER' ,
A.TRX_NUMBER , 'CUSTOMER' ,
SUBSTRB ( PARTY . PARTY_NAME , 1 , 50 ) , 'POSTAL_CODE' ,
LOC . POSTAL_CODE , A . TRX_NUMBER ) ORDER_BY ,
LOC . ADDRESS1 ,
LOC . ADDRESS2 ,
LOC . ADDRESS3 ,
LOC . ADDRESS4 ,
LOC . STATE ,
LOC . PROVINCE ,
T . description ,
a . org_id ,
a . created_from
FROM
RA_TERMS_LINES TL,
RA_CUST_TRX_TYPES TYPES,
AR_LOOKUPS L_TYPES,
 HZ_CUST_ACCOUNTS B,
HZ_PARTIES PARTY,
HZ_CUST_SITE_USES U_BILL,
HZ_CUST_ACCT_SITES A_BILL,
HZ_PARTY_SITES PARTY_SITE,
HZ_LOCATIONS LOC,
AR_ADJUSTMENTS COM_ADJ,
RA_CUSTOMER_TRX A,
AR_PAYMENT_SCHEDULES P,
RA_TERMS T
WHERE
A.BILL_TO_CUSTOMER_ID = B.CUST_ACCOUNT_ID
AND P.PAYMENT_SCHEDULE_ID + DECODE ( P.CLASS , 'INV' , 0 , '' ) = COM_ADJ.PAYMENT_SCHEDULE_ID (+) AND
COM_ADJ.SUBSEQUENT_TRX_ID IS NULL AND
'C' = COM_ADJ.ADJUSTMENT_TYPE (+) AND
A.COMPLETE_FLAG = 'Y' AND
A.CUSTOMER_TRX_ID = P.CUSTOMER_TRX_ID AND
A.CUST_TRX_TYPE_ID = TYPES.CUST_TRX_TYPE_ID AND
L_TYPES.LOOKUP_TYPE = 'INV/CM/ADJ' AND
A.PRINTING_OPTION IN ( 'PRI' , 'REP' ) AND
L_TYPES.LOOKUP_CODE = DECODE ( TYPES.TYPE , 'DEP' , 'INV' , TYPES.TYPE ) AND
NVL ( T.PRINTING_LEAD_DAYS , 0 ) > 0 AND
A.BILL_TO_SITE_USE_ID = U_BILL.SITE_USE_ID AND
U_BILL.CUST_ACCT_SITE_ID = A_BILL.CUST_ACCT_SITE_ID AND
A_BILL.PARTY_SITE_ID = PARTY_SITE.PARTY_SITE_ID AND
B.PARTY_ID = PARTY.PARTY_ID AND
LOC.LOCATION_ID = PARTY_SITE.LOCATION_ID AND
NVL ( P.TERMS_SEQUENCE_NUMBER , TL.SEQUENCE_NUM ) = TL.SEQUENCE_NUM AND
NVL ( P.AMOUNT_DUE_REMAINING , 0 ) <> 0 AND
A.CUST_TRX_TYPE_ID = 2526 AND
TYPES.TYPE = 'INV' AND
T.TERM_ID = P.TERM_ID AND
TL.TERM_ID (+) = T.TERM_ID AND
A.PRINTING_PENDING = 'Y' AND
P.TERMS_SEQUENCE_NUMBER > NVL ( A.LAST_PRINTED_SEQUENCE_NUM , 0 ) and 1 = 1 AND
NOT EXISTS ( SELECT 'X' from
ECE_TP_DETAILS ETD ,
ECE_TP_HEADERS ETH
WHERE
ETH.TP_HEADER_ID = A_BILL.TP_HEADER_ID AND
ETD.TP_HEADER_ID = ETH.TP_HEADER_ID AND
ETD.EDI_FLAG = 'Y' AND
ETD.DOCUMENT_ID = 'INO' AND
ETD.DOCUMENT_TYPE = DECODE ( TYPES.TYPE , 'CM' , DECODE ( A.PREVIOUS_CUSTOMER_TRX_ID , NULL , 'OACM' , 'CM' ) , TYPES.TYPE ) ) AND
NVL ( A.PRINTING_OPTION , 'REP' ) IN ( 'PRI' , 'REP' ) AND
T.NAME not like 'PB%' AND 1 = 1 AND
MIT_AR.GE_AR_COAKLEY_ELIGIBLE ( 'NEW' , P.CUSTOMER_TRX_ID , A.ORG_ID ) = 0 AND
A.org_id = TYPES.org_id
ORDER BY 60 ASC,68 ASC,2 ASC,3 ASC,4 ASC,5 ASC,44 ASC
call count cpu elapsed disk query current rows
Parse 1 0.06 0.08 0 364 0 0
Execute 1 5.11 4.98 0 0 0 0
Fetch 18 81.35 1375.73 203636 357435 0 34
total 20 86.52 1380.80 203636 357799 0 34
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 25
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
34 34 34 SORT UNIQUE (cr=569992 pr=227554 pw=0 time=1658548772 us)
34 34 34 UNION-ALL (cr=569992 pr=227554 pw=0 time=773822949 us)
34 34 34 FILTER (cr=228022 pr=107808 pw=0 time=773820837 us)
34 34 34 FILTER (cr=228022 pr=107808 pw=0 time=773820394 us)
34 34 34 NESTED LOOPS OUTER (cr=228022 pr=107808 pw=0 time=771070499 us)
34 34 34 NESTED LOOPS (cr=227986 pr=107806 pw=0 time=773799735 us)
34 34 34 NESTED LOOPS (cr=227882 pr=107806 pw=0 time=773742298 us)
34 34 34 NESTED LOOPS (cr=227812 pr=107806 pw=0 time=773688021 us)
34 34 34 NESTED LOOPS (cr=227708 pr=107806 pw=0 time=773636699 us)
34 34 34 FILTER (cr=227638 pr=107806 pw=0 time=773566978 us)
4616 4616 4616 NESTED LOOPS OUTER (cr=220679 pr=106836 pw=0 time=823009777 us)
4610 4610 4610 NESTED LOOPS (cr=206836 pr=102712 pw=0 time=623651066 us)
4610 4610 4610 NESTED LOOPS (cr=188367 pr=96450 pw=0 time=531982352 us)
4610 4610 4610 NESTED LOOPS (cr=179145 pr=96449 pw=0 time=530980660 us)
4610 4610 4610 FILTER (cr=165290 pr=96448 pw=0 time=529149297 us)
4610 4610 4610 NESTED LOOPS OUTER (cr=165290 pr=96448 pw=0 time=530066499 us)
4607 4607 4607 NESTED LOOPS (cr=156074 pr=96442 pw=0 time=762671095 us)
4615 4615 4615 NESTED LOOPS (cr=146842 pr=96441 pw=0 time=751255741 us)
4615 4615 4615 NESTED LOOPS (cr=137610 pr=96435 pw=0 time=751144978 us)
4615 4615 4615 NESTED LOOPS (cr=123763 pr=96435 pw=0 time=750949543 us)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUSTOMER_TRX_ALL (cr=114531 pr=96435 pw=0 time=750675597 us)
*329687 329687 329687 INDEX RANGE SCAN RA_CUSTOMER_TRX_N17 (cr=6232 pr=6046 pw=0 time=31982795 us)(object id 4788)* 4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUST_TRX_TYPES_ALL (cr=9232 pr=0 pw=0 time=239450 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_CUST_TRX_TYPES_U1 (cr=4617 pr=0 pw=0 time=160139 us)(object id 55731)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=13847 pr=0 pw=0 time=180337 us)
4615 4615 4615 INDEX UNIQUE SCAN FND_LOOKUP_VALUES_U1 (cr=9232 pr=0 pw=0 time=135717 us)(object id 491822)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_TERMS_B (cr=9232 pr=6 pw=0 time=155074 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_TERMS_B_U1 (cr=4617 pr=0 pw=0 time=60566 us)(object id 55734)
4607 4607 4607 TABLE ACCESS BY INDEX ROWID RA_TERMS_TL (cr=9232 pr=1 pw=0 time=181115 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_TERMS_TL_U1 (cr=4617 pr=1 pw=0 time=82153 us)(object id 55755)
4610 4610 4610 TABLE ACCESS BY INDEX ROWID RA_TERMS_LINES (cr=9216 pr=6 pw=0 time=259864 us)
4610 4610 4610 INDEX RANGE SCAN RA_TERMS_LINES_U1 (cr=4609 pr=1 pw=0 time=104110 us)(object id 6703)
4610 4610 4610 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=13855 pr=1 pw=0 time=1350357 us)
4610 4610 4610 INDEX UNIQUE SCAN HZ_CUST_SITE_USES_U1 (cr=9222 pr=1 pw=0 time=434079 us)(object id 44870)
4610 4610 4610 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL (cr=9222 pr=1 pw=0 time=1024466 us)
4610 4610 4610 INDEX UNIQUE SCAN HZ_CUST_ACCT_SITES_U1 (cr=4612 pr=1 pw=0 time=337477 us)(object id 46883)
4610 4610 4610 TABLE ACCESS BY INDEX ROWID RA_CUST_TRX_LINE_GL_DIST_ALL (cr=18469 pr=6262 pw=0 time=86754686 us)
4610 4610 4610 INDEX RANGE SCAN RA_CUST_TRX_LINE_GL_DIST_N6 (cr=13836 pr=4061 pw=0 time=55844483 us)(object id 1510967)
4616 4616 4616 TABLE ACCESS BY INDEX ROWID AR_PAYMENT_SCHEDULES_ALL (cr=13843 pr=4124 pw=0 time=50689789 us)
4616 4616 4616 INDEX RANGE SCAN AR_PAYMENT_SCHEDULES_N2 (cr=9233 pr=1494 pw=0 time=15169412 us)(object id 4877)
34 34 34 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS (cr=70 pr=0 pw=0 time=24450 us)
34 34 34 INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U1 (cr=36 pr=0 pw=0 time=5962 us)(object id 85278)
34 34 34 TABLE ACCESS BY INDEX ROWID HZ_PARTY_SITES (cr=104 pr=0 pw=0 time=58609 us)
34 34 34 INDEX UNIQUE SCAN HZ_PARTY_SITES_U1 (cr=70 pr=0 pw=0 time=31189 us)(object id 45527)
34 34 34 TABLE ACCESS BY INDEX ROWID HZ_LOCATIONS (cr=70 pr=0 pw=0 time=52502 us)
34 34 34 INDEX UNIQUE SCAN HZ_LOCATIONS_U1 (cr=36 pr=0 pw=0 time=23883 us)(object id 45692)
34 34 34 TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=104 pr=0 pw=0 time=49042 us)
34 34 34 INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=70 pr=0 pw=0 time=22106 us)(object id 757879)
0 0 0 TABLE ACCESS BY INDEX ROWID AR_ADJUSTMENTS_ALL (cr=36 pr=2 pw=0 time=19638 us)
0 0 0 INDEX RANGE SCAN AR_ADJUSTMENTS_N3 (cr=36 pr=2 pw=0 time=19271 us)(object id 5473)
0 0 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=9 us)
0 0 0 INDEX UNIQUE SCAN ECE_TP_HEADERS_U1 (cr=0 pr=0 pw=0 time=7 us)(object id 46119)
0 0 0 TABLE ACCESS BY INDEX ROWID ECE_TP_DETAILS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN ECE_TP_DETAILS_U2 (cr=0 pr=0 pw=0 time=0 us)(object id 6271)
0 0 0 FILTER (cr=341970 pr=119746 pw=0 time=883424760 us)
0 0 0 FILTER (cr=341970 pr=119746 pw=0 time=883424758 us)
0 0 0 NESTED LOOPS OUTER (cr=341970 pr=119746 pw=0 time=883424757 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424752 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424749 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424742 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424740 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424735 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424731 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424726 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424724 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424721 us)
0 0 0 NESTED LOOPS (cr=341970 pr=119746 pw=0 time=883424715 us)
34 34 34 NESTED LOOPS (cr=341900 pr=119746 pw=0 time=882400482 us)
4615 4615 4615 NESTED LOOPS (cr=123763 pr=93484 pw=0 time=674293279 us)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUSTOMER_TRX_ALL (cr=114531 pr=93484 pw=0 time=674030164 us)
329687 329687 329687 INDEX RANGE SCAN RA_CUSTOMER_TRX_N17 (cr=6232 pr=6130 pw=0 time=36621510 us)(object id 4788)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUST_TRX_TYPES_ALL (cr=9232 pr=0 pw=0 time=249893 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_CUST_TRX_TYPES_U1 (cr=4617 pr=0 pw=0 time=169485 us)(object id 55731)
34 34 34 TABLE ACCESS BY INDEX ROWID AR_PAYMENT_SCHEDULES_ALL (cr=218137 pr=26262 pw=0 time=310068873 us)
3304 3304 3304 INDEX RANGE SCAN AR_PAYMENT_SCHEDULES_N2 (cr=214841 pr=24355 pw=0 time=283359418 us)(object id 4877)
0 0 0 TABLE ACCESS BY INDEX ROWID RA_TERMS_B (cr=70 pr=0 pw=0 time=829 us)
34 34 34 INDEX UNIQUE SCAN RA_TERMS_B_U1 (cr=36 pr=0 pw=0 time=527 us)(object id 55734)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_CUST_SITE_USES_ALL (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_CUST_SITE_USES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 44870)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCT_SITES_ALL (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_CUST_ACCT_SITES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 46883)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_CUST_ACCOUNTS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_CUST_ACCOUNTS_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 85278)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_PARTIES (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_PARTIES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 757879)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_PARTY_SITES (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_PARTY_SITES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 45527)
0 0 0 TABLE ACCESS BY INDEX ROWID HZ_LOCATIONS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN HZ_LOCATIONS_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 45692)
0 0 0 TABLE ACCESS BY INDEX ROWID RA_TERMS_TL (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN RA_TERMS_TL_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 55755)
0 0 0 TABLE ACCESS BY INDEX ROWID RA_TERMS_LINES (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX RANGE SCAN RA_TERMS_LINES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 6703)
0 0 0 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN FND_LOOKUP_VALUES_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 491822)
0 0 0 TABLE ACCESS BY INDEX ROWID AR_ADJUSTMENTS_ALL (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX RANGE SCAN AR_ADJUSTMENTS_N3 (cr=0 pr=0 pw=0 time=0 us)(object id 5473)
0 0 0 NESTED LOOPS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN ECE_TP_HEADERS_U1 (cr=0 pr=0 pw=0 time=0 us)(object id 46119)
0 0 0 TABLE ACCESS BY INDEX ROWID ECE_TP_DETAILS (cr=0 pr=0 pw=0 time=0 us)
0 0 0 INDEX UNIQUE SCAN ECE_TP_DETAILS_U2 (cr=0 pr=0 pw=0 time=0 us)(object id 6271)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
row cache lock 6 0.00 0.00
SQL*Net message to client 18 0.00 0.00
SQL*Net more data to client 2 0.00 0.00
gc current block 2-way 5375 0.02 3.76
gc cr grant 2-way 49175 0.05 24.09
db file sequential read 203636 0.51 1289.70
gcs drm freeze in enter server mode 7 0.28 1.30
latch: KCL gc element parent latch 4 0.00 0.00
gc remaster 2 0.07 0.12
latch: gcs resource hash 26 0.00 0.00
latch free 1 0.00 0.00
gc cr block 2-way 9 0.00 0.00
latch: cache buffers chains 1 0.00 0.00
SQL*Net message from client 18 0.00 0.00
Thanks in Advance..

Hi,
it looks like your problem stems from the wrong choice of the driving table:
4615 4615 4615 NESTED LOOPS (cr=123763 pr=96435 pw=0 time=750949543 us)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUSTOMER_TRX_ALL (cr=114531 pr=96435 pw=0 time=750675597 us)
329687 329687 329687 INDEX RANGE SCAN RA_CUSTOMER_TRX_N17 (cr=6232 pr=6046 pw=0 time=31982795 us)(object id 4788) 4615 4615 4615 TABLE ACCESS BY INDEX ROWID RA_CUST_TRX_TYPES_ALL (cr=9232 pr=0 pw=0 time=239450 us)
4615 4615 4615 INDEX UNIQUE SCAN RA_CUST_TRX_TYPES_U1 (cr=4617 pr=0 pw=0 time=160139 us)(object id 55731)
4615 4615 4615 TABLE ACCESS BY INDEX ROWID FND_LOOKUP_VALUES (cr=13847 pr=0 pw=0 time=180337 us)Here, you are spending 750 seconds retriveing 329k rows, 98% of which are rejected on the next step. And the reason this is happening is because the optimizer underestimates the cardinatlity of this step by a factor of x50 (6.2k estimated, 329k actual value). Find out why this is happening or post relevant diagnostic information here (predicates, columns stats etc.), and fix this -- this should make your query twice as fast.
The second half is coming from the SORT UNIQUE step. This looks weird: why on Earth it would take over 800 seconds to sort 34 rows?! Maybe there is something in the plan that I'm missing -- it's really hard to read because it's not formatted. Please obtain a plan with rowsource stats using dbms_xplan.display_cursor and post it here (google dbms_xplan.display_cursor allstats last if not sure how to do that).
Best regards,
Nikolay

Server hangs or freezes during heavy load

During peak times of the day, especially during heavy load on the Calendar Server,
the application seems to hang. The client side application will not respond on
the user's desktop, and uni* commands on the server itself respond considerably
slow.

There are two parameters in the server configuration file that are strongly
believed to be a trigger of server hangs or freezes in large deployments and/or
busy servers. Here is a description of the problem:

Large deployments tend to be 3000+ users per node. This could be a single or
multi-node environment.

A lock manager fix was implemented in 4.0 to correct a problem that was
found in 3.51 where the server would hang. At that time, the parameters called
read/writelocktimeouts
were introduced as a failover mechanism in case the
database was not available, which would then trigger the client process to
disconnect rather than hang the whole server.

These timeouts effectively will terminate a process whose read or write exceeds
the specified periods. The default of 20 seconds is quite a large amount of time;
however, it is not totally unlikely that such a value could be met on a
very busy system. If this is the case, and there is some relation between a
process being terminated by one of these timeouts and subsequent system
instability, then the "solution" would not be to extend the values of the
timeouts but rather to exclude them. This way, it will ensure that no process is
terminated this way and therefore the process would be allowed to continue until
it had completed its job.

The timeouts were not removed from the product, but under normal circumstances
they probably won't be needed anymore anyhow. It seems that on a busy calendar
server, setting the db timeout alarms may actually trigger the server to freeze.
Below are some examples of errors that appear in the log files which show
that the database is no longer accepting client requests:

db_VISTA ERROR -920 -> cst_d_open: d_open
db_SchedBaseOpen: unable to open database
probable cause: unilckd is down or "/users/unison/tmp/unisonlckm"
was removed
uniengd: database lock timeout
ITEM: "NA,NA" <0,0>
CLIENT: "unises", "A.02.80"
INET-NAME:
INET-ADDR:
CALL: "SessionsInfoGet"

To make the fix:
<OL>
<LI>Using your favorite editor, edit the /users/unison/misc/unison.ini file.
In the following section you will see these two parameters:

[ENG]
writelocktimeout = 20
readlocktimeout = 20

<LI>Place a "#" sign (or the appropriate comment symbol for your OS) in front of
these two lines and save the file.

<LI>The server will now have to be restarted in order for the changes to take
effect.
</OL>

This looks similar to what I'm seeing.
DPM 2010, there's one backup set (for me a file server disk) that every time I try to run the initial replica on it the server hangs and needs to be rebooted by iLO. It doesn't just die suddenly, first the data stream on the backup stops then the OS becomes
less responsive but there is no resource issue. trying to open event view will cause a few things to lock up then over a few mins the server is complete froze. like the disk drives have been locked.
Suspecting McAfee, I added in all the exclusions, that didn't help so I added the process exclusions which are done by setting dpmra and csc to low risk and that didn't help either. I could reproduce it just by kicking off a backup for this one file servers
drive so it's easy to test with.
Tonight, I had some permissions in EPO to let me stop the scanning completely and disable the on-access scan and for the first time it worked!
There is definitely an issue between DPM and McAfee beyond what is on MS's web page for AV checks.
I don't have a workaround yet other than stopping the AV completely... Something to follow up on next week. For the moment I made some progress though.

Query Tuning - Response time Statistics collection

Our Application is Load tested for a period of 1 hour with peak load.
For this specific period of time, say thousands of queries gets executed in the database,
What we need is say for one particular query " select XYZ from ABC" within this span of 1 hour, we need statistics like
Number of times Executed
Average Response time
Maximum response time
minimum response time
90th percentile response time ( sorted in ascending order, 90th percentile guy)
All these statistics are possible if i can get all the response times for that particular query for that period of 1 hour....
I tried using sql trace and TKPROF but unable to get all these statistics...
Application uses connection pooling, so connections are taken as and when needed...
Any thoughts on this?
Appreciate your help.

I don't think v$sqlarea can help me out with the exact stats i needed, but certainly it has lot of other stats to take. B/w there is no dictionary view called v$sqlstats.
There are other applications which share the same database where i am trying to capture for my application, so flushing cache which currently has 30K rows is not feasible solution.
Any more thoughts on this?

How to set default date of 3 weeks(21 days) from today's date during page load?

I want to show the default date as 3 weeks from today's date during page load.
For example ,i have given as adf.CurrentDate + 21 in EO for the attribute 'DueDate'. But it is showing me the date as 9.7.2013. 3 weeks default date is not getting set.If i give adf.currentDate also ,it not giving me today's date,it showing the 9.7.2013 only.Kindly provide your suggestions to set the default date as 3 weeks from today's date during page load.Thanks in advance.

Hi,
when you set the value on the entity level then you don't want to show it during page load but when the field is empty ? Correct? if so then the use case is a different one. The easiest way to implement this would be to create a Rowimpl class (Java option) and then in the get method of the entity attribute check if the value is null and if it is, set it to the current date + 21 days. This way all rows will be set with the 3 weeks due date but fields are not overridden each time the row is queried
Frank

Slow Internet during Peak Times

Hi I am actually a Sky customer but because of living in a rural area everything is done through the BT lines.
I'v known for awhile that if you are downloading or using p2p programms through peak times, your internet is slowed during peak times intentionally by BT, which I have no problem with, and since I am a Sky customer but working through the BT lines this also effects me.
However...
The internet is getting slowed down even though no downloads are occuring during peak times, I am the only one in my house that uses downloads (parents just use facebook), whenever I do download it is for games on steam, but now I just do them at another house because...
1) 10mb internet isn't all that great for downloading large files I would rather not leave my PC on for 2 nights just to download a game
2) I can go to a friends house and use theirs and not be effected by the peak time limit, and download at a very high speed
My step brother uploads videos to youtube, and when he does them, its usually about 12AM before he goes to sleep, and never during the peak times, that is the upmost most stress that happens in terms of our internet traffic.
The internet slows down at exactly 5:15PM to 11:15PM, every single day, and during this time the internet is pretty much unusable, even to browse web pages, watching videos on youtube(in lowest quality 240p) or playing xbox/pc/ps3 is stictly a nono.
This is a quote from a rather basic forum page
"Total time taken to generate the page: 61.17250 seconds"
Even google takes an abnormally long time to load.
I phoned Sky and they said they cannot do anything as it is BT owns the lines and I should expect a call from BT soon, they did phone, but I was not in, and have never had a phone call again.
I am just wondering how can I resolve this issue.
Thanks
Stefan

you can check here to see if anything shown as a problem at your exchange http://usertools.plus.net/exchanges/mso.php
http://usertools.plus.net/exchanges/?
http://btbusiness.custhelp.com/app/service_status
http://bt.custhelp.com/app/answers/detail/a_id/15036
If you like a post, or want to say thanks for a helpful answer, please click on the Ratings star on the left-hand side of the post.
If someone answers your question correctly please let other members know by clicking on ’Mark as Accepted Solution’.

Massive speed drop during peak time!!

Hi,
I recently switched over to BT broadband (3/11/2014) and unfortunately I have been having some major issues with download speeds during peak times. Off peak times I usually register download speeds of around 12-14Mbps, which is great, but during peak hours (11:00-14:00 and 18:00-22:00) my download speed drops to anywhere between 0.01-1.0Mbps, even on a wired connection. I fully expect speeds to drop during these hours (even though BT claimed on their website that they wouldn’t) but in no way should they even be this slow surely. The internet is completely unusable when the speeds drop as pages can take several minutes to load and I am currently paying for Netflix and Amazon Prime subscriptions that I simply can’t use because videos or streams will not load, they just constantly buffer!
I have been in contact with the online help chat with this issue and they simply recommended that I reset my router, and whilst this temporarily fixed the issue for a few hours, my problem soon returned. Since then I have not touched the router in over 10 days in the hope that the speeds would start to settle, and whilst off-peak times have improved, peak times are no better than before, and in some cases worse.
I have been patient and given the router and provider 3 weeks to settle down, but I am seeing absolutely no signs of improvement. As I said, I understand that speeds may drop during peak hours, but as it stands I’m basically losing my internet during this time. I’m starting to wonder what it is I’m paying for. I had no such trouble with my previous provider during peak hours, so I’m not sure why there is suddenly a problem.
I am using the Home Hub 4, and here are my ADSL Stats and my test results from Sunday evening (23/11/14):
13:58:12, 23 Nov. ( 81.290000) DSL noise margin: 5.60 dB upstream, 6.10 dB downstream
13:58:11, 23 Nov. ( 80.240000) DSL line rate: 1152 Kbps upstream, 15576 Kbps downstream
18:55:08, 23 Nov. ( 81.160000) DSL noise margin: 6.50 dB upstream, 6.10 dB downstream
18:55:07, 23 Nov. ( 80.100000) DSL line rate: 1104 Kbps upstream, 15288 Kbps downstream
After a network test on my xbox one (wired connection) I got the following:
7.05pm
Download speed: 0.34Mbps
Upload speed: 0.88 Mbps
7.20pm
Download speed: 0.05Mbps
Upload speed: 0.87 Mbps
Speedtest result:
I have tried to get a result from the BT Speed checker, but my internet won’t even load it as of around 7-8pm
During the week I have been browsing the forums in an attempt to locate a possible solution and I came across this thread in which the original poster describes a problem very similar to mine. It seems that switching their line at the exchange to a less congested one seemed to alleviate the problem?
https://community.bt.com/t5/ADSL-Copper-Broadband-Speed/Slow-Peak-time-broadband/m-p/1111272/highlig...
Anyway, hopefully someone can help address and solve these issues as I’m starting to get a bit frustrated and beginning to regret my decision to switch providers.
Thanks in advance for any help,
Ben
Solved!
Go to Solution.

Is anything showing here for your exchange http://usertools.plus.net/exchanges/mso.php
http://usertools.plus.net/exchanges/?
http://btbusiness.custhelp.com/app/service_status
http://bt.custhelp.com/app/answers/detail/a_id/15036
If you want to say thanks for a helpful answer,please click on the Ratings star on the left-hand side If the reply answers your question then please mark as ’Mark as Accepted Solution’

Slow internet during peak hrs NEPA

For the past few weeks I have been experiencing slow internet downloads and youtube here in northeast PA , especially during peak hours. here is my traceroute and scroll down for transciever stats : btw, my speed is 3mbps/768
news.giganews.com
traceroute to , 30 hops max, 60 byte packets
1 gw1-g-vlan201.dca.giganews.com (216.196.98.4) 0 ms 0 ms 0 ms
2 te0-0-0-7.mpd22.iad02.atlas.cogentco.com (38.122.67.49) 0 ms te0-7-0-9.mpd22.iad02.atlas.cogentco.com (38.122.62.193) 1 ms te0-0-0-7.mpd22.iad02.atlas.cogentco.com (38.122.67.49) 0 ms
3 te0-2-0-0.ccr21.iad02.atlas.cogentco.com (154.54.31.101) 0 ms 0 ms te0-0-0-4.ccr21.iad02.atlas.cogentco.com (154.54.31.105) 0 ms
4 * * *
5 xe-1-0-2-0.NWRK-BB-RTR1.verizon-gni.net (130.81.17.74) 12 ms 12 ms xe-3-1-2-0.NWRK-BB-RTR1.verizon-gni.net (130.81.23.206) 10 ms
6 P12-0-0.SCTNPA-LCR-01.verizon-gni.net (130.81.22.13) 16 ms 15 ms G14-0-0.SCTNPA-LCR-01.verizon-gni.net (130.81.209.195) 14 ms
7 P10-0.SCTNPA-HZTNPAHZ-ERXG01.verizon-gni.net (130.81.136.43) 17 ms 19 ms 18 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * * Max number of unresponsive hops reached (firewall or filter?)
news-europe.giganews.com
traceroute to, 30 hops max, 60 byte packets
1 vl201.gw1.ams.giganews.com (216.196.110.3) 0 ms 0 ms 0 ms
2 te7-7.ccr01.ams05.atlas.cogentco.com (149.11.104.9) 0 ms 0 ms 0 ms
3 te0-5-0-1.mpd21.ams03.atlas.cogentco.com (154.54.72.46) 0 ms te0-5-0-1.mpd22.ams03.atlas.cogentco.com (154.54.72.54) 0 ms te0-5-0-1.mpd21.ams03.atlas.cogentco.com (154.54.72.46) 0 ms
4 te0-1-0-0.mpd22.lon13.atlas.cogentco.com (130.117.0.198) 87 ms te0-5-0-7.ccr22.lpl01.atlas.cogentco.com (130.117.50.85) 10 ms te0-3-0-7.ccr22.lpl01.atlas.cogentco.com (154.54.37.130) 10 ms
5 te0-7-0-9.ccr22.bos01.atlas.cogentco.com (154.54.85.221) 76 ms te0-0-0-3.ccr21.lpl01.atlas.cogentco.com (154.54.37.141) 85 ms te0-7-0-3.ccr21.bos01.atlas.cogentco.com (154.54.31.169) 76 ms
6 te0-0-0-18.mpd22.jfk02.atlas.cogentco.com (154.54.44.29) 82 ms te0-7-0-18.mpd22.jfk02.atlas.cogentco.com (154.54.44.33) 81 ms te0-2-0-1.ccr21.ymq02.atlas.cogentco.com (154.54.87.62) 85 ms
7 te0-2-0-6.ccr21.jfk05.atlas.cogentco.com (154.54.3.98) 82 ms te0-1-0-6.ccr21.jfk05.atlas.cogentco.com (154.54.3.166) 81 ms te0-2-0-6.ccr21.jfk05.atlas.cogentco.com (154.54.3.98) 82 ms
8 xe-4-1-4-0.NY5030-BB-RTR2.verizon-gni.net (130.81.17.123) 87 ms 0.xe-10-3-0.BR2.NYC4.ALTER.NET (204.255.168.113) 81 ms 82 ms
9 xe-4-1-4-0.NY5030-BB-RTR2.verizon-gni.net (130.81.17.123) 81 ms 0.so-5-0-0.NY5030-BB-RTR2.ALTER.NET (152.63.10.46) 79 ms 79 ms
10 P12-0-0.SCTNPA-LCR-02.verizon-gni.net (130.81.22.15) 93 ms 93 ms 0.xe-10-3-0.BR2.NYC4.ALTER.NET (204.255.168.113) 85 ms
11 P9-0.SCTNPA-HZTNPAHZ-ERXG01.verizon-gni.net (130.81.33.39) 100 ms 98 ms 100 ms
12 * * *
13 * P9-0.SCTNPA-HZTNPAHZ-ERXG01.verizon-gni.net (130.81.33.39) 103 ms *
14 * * *
15 * * *
16 * * *
17 * * Max number of unresponsive hops reached (firewall or filter?)
And here is the transciever stats:
Transceiver Statistics
Transceiver Revision:
7.2.3.0
Vendor ID Code:
4
Line Mode:
G.DMT Mode
Data Path:
Fast
Transceiver Information
Downstream Path
Upstream Path
DSL Speed (Kbits/Sec)
3360
864
Margin (dB)
23.5
11.0
Line Attenuation (dB)
17.5
9.0
Transmit Power (dBm)
9.6
11.8
Solved!
Go to Solution.

#1 An original or very old style NID with a spark gap and ground wire can even get spiders in it that could cause an issue. Inspect the NID first before thinking of changes or wiring.
http://en.wikipedia.org/wiki/Network_interface_device
http://en.wikipedia.org/wiki/Demarcation_point
Running a good quality wire CAT5, no need for CAT6, directly to the NID for the DSL modem jack may help. That is what I had done with mine. Depending on the number of loads or amount of wire in the house could also cause issues. But if the user's signal quality is not being pulled low due to a wiring issues, it would usually indicate a problem elsewhere. Unless there was noise being picked up on the premises wiring. Wire DSL directly to the NID and install a filter there for all other in house wiring may help. There used to be available what was called a NID Filter, and I am sure you can still get them.
Ideal Connection if house wiring is an issue, or very old, and lengthy. Install a filter / splitter at the NID.
Run CAT5 directly to the NID location, and install a dedicated jack for the DSL modem.
Remove all in house wiring from the NID.
Connect piece of CAT5 from the NID to the filter / splitter input
Connect all existing phone lines to the phone side of the filter output.
Connect the new DSL CAT5 directly to the NID before the filter / splitter, or to the DSL side of the filter / splitter, depending on the device purchased.
This will take all the existing premises wiring out of the picture unless there is a short circuit or excessive load somewhere in the house.
At this point all the single filters could be removed because the DSL is filtered at the NID.
http://www.homephonewiring.com/dsl.html
#2 You can test outbound to Giganews. But giganews has/had a test that will check your inbound connection from their servers to you.
I heard from another user that
    Giganews is being watched very closely because of multipart binaries, and pirated material. MP3s and Video Content. 7 years ago you could get 10-20 MP3 albums in a single day, and that was with a 15/5 fios connection. So they started providing an encrypted connection service for an added fee. I have not messed with news groups for a very long time. Now with deep packet inspection, and other enforcement, I would not even think of it. No news I want there. But there may be content that people want? They may even be checking and limiting speed from that domain. Never tested. But let me see. It looks as if reverse trace routes and speed tests are being blocked by Verizon from Giganews to my router.
        Reverse Traceroute
        Tool news.giganews.com
        traceroute to *.*.*.*, 30 hops max, 60 byte packets
        1 gw1-g-vlan201.dca.giganews.com (216.196.98.4) 0 ms 0 ms 0 ms
        2 te0-0-0-7.mpd22.iad02.atlas.cogentco.com (38.122.67.49) 0 ms 0 ms te0-7-0-9.mpd22.iad02.atlas.cogentco.com (38.122.62.193) 0 ms
        3 te0-0-0-4.ccr21.iad02.atlas.cogentco.com (154.54.31.105) 0 ms 0 ms te0-2-0-0.ccr21.iad02.atlas.cogentco.com (154.54.31.101) 0 ms
        4 uunet.iad01.atlas.cogentco.com (154.54.13.138) 28 ms verizon.iad01.atlas.cogentco.com (154.54.10.226) 40 ms uunet.iad01.atlas.cogentco.com (154.54.13.138) 28 ms
        5 0.ae1.RES-BB-RTR2.verizon-gni.net (152.63.32.157) 41 ms 41 ms 0.ae2.RES-BB-RTR1.verizon-gni.net (152.63.34.22) 13 ms
        6 * * *
        7 * * *
        8 * * *
        9 * * *
        10 * * *
        11 * * *
        12 * * *
        13 * * *
        14 * * *
        15 * * *
        16 * * Max number of unresponsive hops reached (firewall or filter?)
#3 Have the provider run a local loop test to see if any problems are indicated. If there are, then they could run the test with everything in the house disconnected, except the new DSL modem connection. If issues are still indicated, then the DSL provider needs to make connections on the local loop. Another user told me that they had issues when it rained, and it was because construction had left a splice box open on a line somewhere.
If you are the original poster (OP) and your issue is solved, please remember to click the "Solution?" button so that others can more easily find it. If anyone has been helpful to you, please show your appreciation by clicking the "Kudos" button.

Extremely poor performance to various websites during peak hours - peering issue?

Since approximately 26 Jan 2015, we have been experiencing extremely poor performance to several specific websites during peak hours, 9pm-11pm. Page loads take many minutes (or never complete), etc. Many other sites are perfectly fine, and if I connect to the same sites at the same time through my work VPN, they perform extremly well (under 1sec). There is no correlation between OS or browser and the poor performance (tested on Windows, OSX, Linux) and speedtest typically reports over 80/80.
I've not caught any packet loss using periodic pings. Traceroutes indicate a bunch of different routes being used (I assume this is expected for CDNs), but here's one example of an obviously bad single traceroute:
$ traceroute images.dailykos.com
traceroute to fallback.global-ssl.fastly.net (23.235.46.185), 64 hops max
1 10.1.1.1 0.464ms 0.364ms 0.298ms
2 173.48.161.1 5.223ms 4.793ms 4.904ms
3 130.81.191.250 7.387ms 7.466ms 7.366ms
4 130.81.151.76 4.909ms 4.905ms 4.932ms
5 152.63.20.117 12.441ms 12.433ms 12.434ms
6 152.63.4.141 12.373ms 12.468ms 12.370ms
7 152.179.220.126 14.989ms 14.937ms 14.872ms
8 68.86.84.249 12.505ms 12.259ms 14.988ms
9 68.86.85.25 22.409ms 22.433ms 22.519ms
10 68.86.85.1 19.817ms 19.894ms 19.919ms
11 68.86.83.74 17.389ms 19.870ms 22.460ms
12 4.53.116.18 24.815ms 25.080ms 24.851ms
13 * 208.122.44.198 2849.473ms 29.832ms
14 173.231.134.18 22.430ms * 2026.736ms
The sites in question use the Fastly CDN - my theory is that the VZ-Fastly connection is under provisioned or is broken, but I'm out of my depth at this point.

"This is a nationwide peering/routing issue that was intentionally created by Verizon to create congestion and (1) extract priority fees from the likes of Netflix and (2) get customers to subscribe to higher speed tiers. This has been acknowledged by the FCC. Verizon is building new interconnections to remedy the problem, but it will persist for at least another 6 months."

Help for query tuning

hello all
my one of query is returning result in 1-2 mins only for 1 lakh record but i am not sure if it showed me complete rows or not because when I an trying to get count of result ..its taking lot of time .when I am using this query on plsql code ..code is running slow so just wanted to confirm on query tuning point of view if its fine or not ..please look onto it and let me know if query is fine or not by explain plan .my oracle version is 11g
this is my query
SELECT ROWNUM , TRUNC(rownum/5000) + 20000 ,'FOR_UPDATE', sku_org.NAME ,
acct_promo_sku.src_num , acct_promo_sku.sub_type ,
promo_actual.sku_actual_pos
FROM siebel.s_src acct_promo_hdr,
siebel.s_src acct_title_format,
siebel.s_src acct_promo_sku,
siebel.s_src_x acct_promo_hdrx,
siebel.s_src_x acct_promo_skux,
siebel.s_prod_int prod,
siebel.s_bu promo_hdr_org,
siebel.s_bu sku_org,
siebelwb.stg_sbl_acct_promo_actuals2 promo_actual
WHERE acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
AND acct_promo_hdr.row_id = acct_title_format.par_src_id
AND acct_title_format.sub_type = 'PLAN_ACCT_PROMOTION_CATEGORY'
AND acct_title_format.row_id = acct_promo_sku.par_src_id
AND acct_promo_sku.sub_type = 'PLAN_ACCOUNT_PROMOTION_PRODUCT'
AND acct_promo_hdr.row_id = acct_promo_hdrx.par_row_id
AND acct_promo_sku.row_id = acct_promo_skux.par_row_id(+)
AND acct_promo_sku.prod_id = prod.row_id
AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
AND acct_promo_sku.bu_id = sku_org.row_id
AND prod.x_prod_material_num = promo_actual.material_number
and prod.X_PROD_SALES_ORG=promo_actual.sales_org
AND acct_promo_hdr.row_id = promo_actual.acct_promo_id
and nvl(acct_promo_hdr.pr_accnt_id,0)=nvl(promo_actual.acct_siebel_rowid,0)
and nvl(acct_promo_hdr.x_indirect_id,0)=nvl(promo_actual.indirect_acct_siebel_rowid,0)
AND promo_actual.load_date >= TRUNC(SYSDATE)
AND promo_actual.load_date < TRUNC(SYSDATE + 1)
explain plan
PLAN_TABLE_OUTPUT
Plan hash value: 3864590768
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 298 | 2300 (1)| 00:00:28 |
| 1 | COUNT | | | | | |
|* 2 | FILTER | | | | | |
| 3 | NESTED LOOPS | | | | | |
| 4 | NESTED LOOPS | | 1 | 298 | 2300 (1)| 00:00:28 |
| 5 | NESTED LOOPS OUTER | | 1 | 273 | 2298 (1)| 00:00:28 |
| 6 | NESTED LOOPS | | 1 | 263 | 2296 (1)| 00:00:28 |
| 7 | NESTED LOOPS | | 1 | 236 | 2295 (1)| 00:00:28 |
| 8 | NESTED LOOPS | | 1 | 165 | 2292 (1)| 00:00:28 |
| 9 | NESTED LOOPS | | 1 | 117 | 2289 (1)| 00:00:28 |
| 10 | NESTED LOOPS | | 1 | 109 | 2289 (1)| 00:00:28 |
| 11 | NESTED LOOPS | | 1 | 99 | 2287 (1)| 00:00:28 |
|* 12 | TABLE ACCESS FULL | STG_SBL_ACCT_PROMO_ACTUALS2 | 1 | 49 | 2285 (1)| 00:0
|* 13 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 50 | 2 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 | | 1 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | S_SRC_X_U1 | 1 | 10 | 2 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | S_BU_P1 | 1 | 8 | 0 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 48 | 3 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | S_SRC_F2 | 2 | | 2 (0)| 00:00:01 |
|* 19 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 71 | 3 (0)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | S_SRC_F2 | 2 | | 2 (0)| 00:00:01 |
| 21 | TABLE ACCESS BY INDEX ROWID | S_BU | 1 | 27 | 1 (0)| 00:00:01 |
|* 22 | INDEX UNIQUE SCAN | S_BU_P1 | 1 | | 0 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | S_SRC_X_U1 | 1 | 10 | 2 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
|* 25 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 25 | 2 (0)| 00:00:
Predicate Information (identified by operation id):
2 - filter(TRUNC(SYSDATE@!)<TRUNC(SYSDATE@!+1))
12 - filter("PROMO_ACTUAL"."LOAD_DATE">=TRUNC(SYSDATE@!) AND "PROMO_ACTUAL"."LOAD_DATE"<TRUNC(SYSD
13 - filter("ACCT_PROMO_HDR"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION' AND
NVL("ACCT_PROMO_HDR"."PR_ACCNT_ID",'0')=NVL("PROMO_ACTUAL"."ACCT_SIEBEL_ROWID",'0') AND
NVL("ACCT_PROMO_HDR"."X_INDIRECT_ID",'0')=NVL("PROMO_ACTUAL"."INDIRECT_ACCT_SIEBEL_ROWID",'0'
14 - access("ACCT_PROMO_HDR"."ROW_ID"="PROMO_ACTUAL"."ACCT_PROMO_ID")
15 - access("ACCT_PROMO_HDR"."ROW_ID"="ACCT_PROMO_HDRX"."PAR_ROW_ID")
16 - access("ACCT_PROMO_HDR"."BU_ID"="PROMO_HDR_ORG"."ROW_ID")
17 - filter("ACCT_TITLE_FORMAT"."SUB_TYPE"='PLAN_ACCT_PROMOTION_CATEGORY')
18 - access("ACCT_PROMO_HDR"."ROW_ID"="ACCT_TITLE_FORMAT"."PAR_SRC_ID")
19 - filter("ACCT_PROMO_SKU"."PROD_ID" IS NOT NULL AND
"ACCT_PROMO_SKU"."SUB_TYPE"='PLAN_ACCOUNT_PROMOTION_PRODUCT')
20 - access("ACCT_TITLE_FORMAT"."ROW_ID"="ACCT_PROMO_SKU"."PAR_SRC_ID")
22 - access("ACCT_PROMO_SKU"."BU_ID"="SKU_ORG"."ROW_ID")
23 - access("ACCT_PROMO_SKU"."ROW_ID"="ACCT_PROMO_SKUX"."PAR_ROW_ID"(+))
24 - access("ACCT_PROMO_SKU"."PROD_ID"="PROD"."ROW_ID")
25 - filter("PROD"."X_PROD_MATERIAL_NUM" IS NOT NULL AND
"PROD"."X_PROD_MATERIAL_NUM"="PROMO_ACTUAL"."MATERIAL_NUMBER" AND
"PROD"."X_PROD_SALES_ORG"="PROMO_ACTUAL"."SALES_ORG")
55 rows selected.
thanks

Hi,
the plan you posted has the cost of 2300, i.e. 2300 single-block reads or equivalent number f multi-block reads. Even if none of the blocks is found in cache, 2300 reas shouldn't take more than a couple of minutes, beacause for most of the hard drives available today a disk read is typically within 5-10 ms.
This means that if there is a problem, we will never find out about it by looking in the plan. And it's quite likely that there is, in fact, a problem, because the plan contains a bunch of nested joins, and the cost of each nested join is directly proportional to the cardinality of the previous nested loop. I.e. it suffices to make one bad mistake in estimating the number of rows coming fom one of the nested rows to screw up the entire plan and get all remaining estimates (including the total cost of the query) completely wrong.
In order for us to be able to tell more, we need to see the plan with rowsource statistics, and please don't forget to use tags to preserve formatting (use the preview tab to make sure the posted plan is actually readable).
Best regards,
Nikolay

Adobe Premiere Elements 7.0 hangs while exporting and during peak file generation.

I have Adobe Premiere Elements 7.0 (PRE7). I have a project which is using a single clip from a Mini-DV that was captured with Nero 8. Nero 8 was used because it was captured prior to installing PRE7. The file is 12GB and is on a USB disk drive because I don't have the space on my main hard drive (I have about 11GB free). My project doesn't do too much that's fancy. It merely uses about 20 minutes of the 60 minute Mini-DV captured AVI, and it uses simple transitions between each scene. I also have very simple titles at start and end. No themes or anything else.
I've seen two problems. 1) While editing the project, seemingly (but I'm not positive it's related) while the peek file was being generated, PRE7 would get into a state of using about 40% to 50% CPU, and it would not let me do anything else. The other problem, 2) While using "Share" to export the video to WMA for playback on PC (about 180MB estimated file size according to Adobe), the file is exported to about the last remaining 5 seconds, but then PRE7 goes into that mode of hanging with 40% to 50% CPU usage.
One time when it had this 50% CPU issue, I let it sit overnight, and the export was finished in the morning. The export that time was to a 90MB FLV for posting to the "web" according to the Share wizard. But when I was doing the above (issue #2), it went into the 50% CPU usage but didn't finish after waiting around 2 hours. Even if I were to let it sit that time, and it were to finish, it seems like something's wrong and that this is unacceptable.
When this happens, and PRE7 goes into 50% CPU utilization, there is no pacifier or percentage bar advancing. It usually happens near 100% finished. Only one time did it complete successfully after leaving it unattended at 90% complete for an extraordinary amount of time.
To recap:
C:\ hard drive ---> PRE7, my project.
E:\ USB drive ---> 12GB source AVI file and destination for export.
I saw elsewhere on this forum that someone imported a mini-dv captured AVI into Window Movie Maker and then exported it to Mini-DV from that app. This solved that person's problem with hanging during peak file creation. I had the 50% hang issue during peak file generation but I'm not sure it was related to peak file generation. A peak file was generated in a project which, when exported with share as mentioned above, still did the hang 50% CPU issue. Regardless, I will try the import/export/movemaker thing and report back but I've been trying enough things that I wanted to take a second to ask for assistance.
Does anyone have this issue, and is there a patch or fix?
I might be able to provide a user mode dump of the 50% CPU adobe process. There is some call stack information and I'm wondering if developers would want this info if they don't already have a solution/fix to this bug.
Thanks for any help.

I have some more info on the hang which I've been experiencing during export/share of a project which uses an AVI as its one main clip. Adobe Premiere Elements 7 (PRE7) appears to be hanging because it's looping endlessly in ImporterAVI.prm. I'm wondering if this info can be passed onto Adobe developers and/or if I can submit this information elsewhere for such processing. I also have a process dump file which might be helpful, not to mention the original project files.
I used Process Monitor to help analyze this situation, and prior to PRE7 getting into the endless loop, it appears to be reading from the AVI file little by little, and WMEncodingHelper.exe is writing out little by little to the destination file, both of which I would expect. When PRE7 gets to the end of the import/export, Process Monitor appears to show all the aforementioned disk activity ceasing. I see neither process reading or writing. This would be normal if the share/export procedure had completed. But PRE7 is not complete. It is hung and is operating at 50% CPU utilization.
Far below in this post are technical details which may be helpful to an Adobe developer determine why the importer could get into this endless loop. In those details, there is a jump instruction, "jb ImporterAVI!xImportEntry+0xf32", which will always jump if a particular compare always turns out a certain way. But in my review of the counters being compared, it never will get to a point of exiting. When I modify a flag (the carry flag) to be 0, the loop exits. When I did this, my export/share of my project completed successfully. So it was done, but for some reason, PRE7 was looping and looping in its AVI importor instead of completing the export (aka "Share").
I cannot say that this certainly indicates a bug with PRE7, but it seems to me that there's enough data for Adobe to be at least investigating this particular issue. I'm not the only person who has seen this as there was at least one other message describing the same problem which the user resolved by effectively re-creating the AVI file via a no-op import/export into and out of MovieMaker. My AVI also goes through MovieMaker, import/export, without a hitch.
In a sense, I view PRE7's "share" as essentially an import, processing of imported information (i.e., effects and transitions), and an export. It's an import of all clips into the project at the right times, a processing of all effects, and finally an export to a destination. I realize this is simplistic, but the point I'm making is I have a simple project with a single AVI, and it appears that the "import" portion of PRE7's Share option is choking on the only clip used by this project. I also don't have much but simple transitions and a beginning/ending title on the project, so I'm not thinking this use of PRE7 is much more than what I'm doing with MovieMaker when importing/exporting this AVI.
I fully agree that optimum hardware can be either required or critical for certain types of video editing, but PRE7 is a consumer program and I'm not using anything extensive about it and the symptoms are that PRE7 is looping on its import of a file other programs don't have a problem with. I already tried purchasing a 1TB external, which I'm glad I did, but I really think Adobe developers should look at this issue. There may be a problem with handling certain AVI clips used in a project when those clips come from certain sources. If there is an issue, perhaps it could warrant a fix that would make PRE7 more compatible with these other clips.
Does Adobe have a procedure for people to upload (or mail) projects and files to it so that they can troubleshoot why the importer gets into this state? I also mentioned earlier that I have a full user-mode dump of the process which may be of value to a dev. Can I submit this information anywhere?
Here are textual technical details:
Plug-in which loops: C:\Program Files\Adobe\Adobe Premiere Elements 7.0\Plug-ins\en_US\ImporterAVI.prm
The following are the instructions at the "bottom" of the loop which never ends. Below, I put "***" at the jump instruction I mentioned earler. If I force the carry flag to be 0 at that point, and the jump is skipped, the export completed successfully. Additionally, notice that [esp-0x1c] is 0x2000, and that both eax and edi are 0. When I see it loop, eax stays at 0 and never reaches 0x2000. I wonder if something about the AVI is causing values used by this importer to be such that it causes this endless loop, and if that's the case, and if such values are valid/good, I'm wondering if the importer can be fixed by being able to detect such values so as to not choke (if in fact it's an importer issue).
1239dda2 50 push eax
1239dda3 ffd1 call ecx
1239dda5 8b442424 mov eax,dword ptr [esp+24h]
1239dda9 015c2428 add dword ptr [esp+28h],ebx
1239ddad 03c7 add eax,edi
1239ddaf 83c410 add esp,10h
1239ddb2 3b44241c cmp eax,dword ptr [esp+1Ch]
1239ddb6 89442414 mov dword ptr [esp+14h],eax
; *** This is where it loops around and around.
1239ddba 0f82f2feffff jb ImporterAVI!xImportEntry+0xf32 (1239dcb2)
ImporterAVI!xImportEntry+0x1040:
1239ddc0 8b542420 mov edx,dword ptr [esp+20h]
1239ddc4 52 push edx
1239ddc5 e810d40000 call ImporterAVI!xImportEntry+0xe45a (123ab1da)
1239ddca 83c404 add esp,4
ImporterAVI!xImportEntry+0x104d:
1239ddcd 5f pop edi
1239ddce 5e pop esi
1239ddcf 5d pop ebp
1239ddd0 33c0 xor eax,eax
1239ddd2 5b pop ebx
1239ddd3 83c428 add esp,28h
1239ddd6 c3 ret
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
3195d9b8 12387545 10590f9c 27c53e00 06b35ff6 ImporterAVI!xImportEntry+0x103a
3195d9ec 1239ea10 06b35ff6 00000000 27ad8a60 ImporterAVI+0x7545
3195da1c 1238aa31 06b3554b 00000000 7fdf0000 ImporterAVI!xImportEntry+0x1c90
00000000 00000000 00000000 00000000 00000000 ImporterAVI+0xaa31
[esp-1Ch]: 3195d9a0 00002000
eax=00000000 ebx=00000000 ecx=3195dbcc edx=00000000 esi=27ad8a60 edi=00000000
eip=1239ddba esp=3195d984 ebp=3c7ba50b iopl=0 nv up ei ng nz na pe cy
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000287
ImporterAVI!xImportEntry+0x103a:
1239ddba 0f82f2feffff jb ImporterAVI!xImportEntry+0xf32 (1239dcb2) [br=1]

Here we go again! MEGA slow speeds during peak hou...

Hi folks,
I have noticed that during PEAK hours, my XBox Live sessions lag like a [insert expletive here]!
WHY, oh why do BT insist on throttling, nay, strangling their network to the point where it is totally unusable for anything more than basic browsing or sending/receiving emails?!?
I work reasonably long hours and only get two days off per week, so when I have free time, I'd like to game in a relatively lag-free environment, but right now, this isn't happening! Just tonight, in a game of MW2, I was experiencing such bad lag that shot registration was all but extinct!
I know that BT throttle P2P, but I don't use it and wonder why http and other protocols are being throttled as well!
A speedtest.net result:
And one from BT's own speedtester:
Come on, BT! This is NOT the service that I'm paying for and if it continues this way, I'm out of here when my contract ends!

Rottie wrote:
borley wrote:
Totaly agree with you mine has dropped more than 50% , you say your out of here soon as the contract ends i`m sure BT are breaking their contract so i`m sure you have rights to finish it early. BBC Watchdog here we come lol
Hi there,
Thanks for your reply.
As I understand it, BT are only in breach if the speed falls below the "acceptable speed" threshold in your profile, which in my case, is 12000kbps. Even then, I'm almost certain that BT would offer the *cough* "solution" of changing you from FTTC to ADSL.
Personally speaking, I think the issue lies with contention in the network, either locally or at a centralised point. Unfortunately, the only solution for this (other than throttling speeds to the point of being unusable) is to buy in more bandwidth from BT Wholesale, but that of course, would cut too deeply into BT's profits and in turn see us all paying more for next years' service.
What is the purpose in selling/supplying FTTC when the network infrastructure is clearly unable to meet demand? Using marketing ploys to create this artificial/false perception of what FTTC is, a "superfast fibre service" (partial fibre) then once bought by the consumer only to be told that there are restrictions to be applied is merely lying. Even though there is a FUP many of the constraints once the contract is agreed to, are hidden from the customer. Then again this is the case with most companies.

Query tuning during peak load

Similar Messages

Maybe you are looking for