Long execution time.
Hi,
Can anyone see a problem with the below query it is taking a long time to execute in SQL developer
select ol.sku_id, oh.order_id
from order_header oh, order_line ol
where ol.qty_tasked <= 0 or ol.qty_picked <= 0
and oh.order_id = ol.order_id
and oh.order_id = '9150391359'
and oh.client_id = ol.client_id
group by oh.order_id, ol.sku_id
order by ol.sku_id#
Regards,
Sam.
You can try something like this:
select
ol.sku_id, oh.order_id
from
(select order_id, client_id
from order_header
where order_id = '9150391359') oh,
(select order_id, client_id, skew_id
from order_line
where qty_tasked <= 0 OR qty_picked <= 0) ol
where
oh.order_id = ol.order_id AND
oh.client_id = ol.client_id
group by
oh.order_id, ol.sku_id
order by
ol.sku_idThis will reduce the number of rows before the join and may speed things up.
Similar Messages
-
Long execution times for TestStand conditional statements
I have two test stations – one here, one at the factory in China that has been operating for about a year. The test program uses TestStand 3.1 and calls primarily dll's developed using CVI. Up until a couple months ago, both test stations performed in a similar manner, then the computer at the factory died and was replaced with a new, faster computer. Now the same test sequence at the factory take three times as long to execute (30 min at the facotry, 10min here).
I have recoded the execution time at various point during the execution, and have found that the extra times seems to be occurring during the evaluation of conditional statements in TestStand (i.e. for loops, if statements, case statements). For example, one particular ‘for’ evaluation takes 30 ms on the test station here, but takes 400 ms at the test station at the factory (note: this is just the evaluation of the for condition, not the execution of the steps contained within the for loop).
The actual dll calls seem to be slightly faster with the new computer.
Also the ‘Module Times’ reported don’t seem to match the actual time for the module for the computer at the factory. For example, for the following piece of TestStand code:
Label1
Subsequence Call
Label2
I record the execution time to the report text in both Label1 and Label2. Subtracting one from the other gives me about 18 seconds. However the ‘Module Time’ recorded for ‘Subsequence Call’ is only 3.43 seconds.
Any body have any ideas why the long execution time with the new computer? I always setup the computers in exactly the same way, but maybe there is a TestStand setting somewhere that I have missed? Keep in mind, both test stations are running exactly the same revision of code.Got some more results from the factory this morning:
1) Task Manager shows that the TestExec.exe is the only thing using CPU to any significant degree. Also CPU Usage History show that the CPU Usage never reaches 100%.
2) I sent a new test program that will log test execution time in more places. Longer execution times are seen in nearly every area of the program, but one area where this is very dramatic is the time taken to return from one particular subsequence call. In this subsequence I log the time just before the <End Group> at then end of Main. There is nothing in Cleanup. I then log the time immediately after returning from this sequence. On the test system I have here this takes approximately 160 ms. On the test system at the factory this takes approximately 14.5 seconds! The program seems to be hanging here for some reason. Every time this function is called the same thing happens and for the same amount of time (and this function is called about 40 times in the test program, so this is kill me). -
Alert with event for delayed job and long execution time
Dear All,
We are planning to send alert via email in case job delayed or long execution time.
I have followed below steps:
1) Create event Raise Event when job is delayed.
2) create job chain with STEP1, Job 1 and assign event in raise event parameter.
3) Once job chain delayed it should raise events.
4) Above event should trigger custom email but I can not put the Mail_To parameter as IN parameter. And can not be recognized during
execution.
It ends with the below error.
Details:
JCS-122035: Unable to persist: JCS-102075: Mandatory parameter not set: Parameter Mail_To for job 20413
at com.redwood.scheduler.model.SchedulerSessionImpl.writeDirtyListLocal(SchedulerSessionImpl.java:805)
at com.redwood.scheduler.model.SchedulerSessionImpl.persist(SchedulerSessionImpl.java:757)
Please let us know if anybody knows how to add Mail_To parameter to script.
Any help is appreciated.
Thanks in advance.
Regards,
JiggiDear Jiggi,
where will you define execution time of particular job? because some jobs will take only 1 or 2 minutes, but some jobs normally take more than hours, so how will you decide execution time of individual jobs?
i thinks you can use P_TO Parameter for sending mail, if you want to add some output log activate spool output script.
Thanks and regards
Muhammad Asif -
Optimize long execution time due to 'db file sequential read'
Hi to all,
I have got a query that takes long execution time. Most of the time is due to 'db file sequential read'. The query is:
SELECT * FROM Table_Name
WHERE col1 = :some_value
AND col2 BETWEEN :some_range_about_2_Million
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 21 | 504 | 26125 |
| 1 | TABLE ACCESS BY INDEX ROWID| Table_Name | 21 | 504 | 26125 |
| 2 | INDEX RANGE SCAN | Index Name | 1705K| | 4100 |
The table is not partitioned having around 0.2 billion records. Record set for column 'col1' is around 1700K.
Another index is available for the col2 and col3 is not getting used.
Any suggestions to optimize it..
Regards.Perhaps a combined index (col2, col1) would work...or try "parallel" hint.
:p -
LabVIEW2012 has long execution time to write string than LabVIEW2011 on XP SP3
in for loop, each execution will output string and display it on front panel by value property.
But after upgrade to LabVIEW 2012, the execution time doubled on Chinese XP OS, I really want to know this difference between LabVIEW 2011 & LabVIEW 2012, pls advice.
"I think therefore I am"This is no way to measure the execution time. Your parallel while loop spins as fast as the computer allows, consuming all CPU it can get in the process, and starving everything else. Your code is highly flawed!
Eli: actually I add 10milliseconds delay inside both for and while loop.
In addition, get date/time in seconds is also a relatively expensive function, not to mention all these local variables! Your benchmark is completely meaningless! All it does is slow down your regular code, nothing else. How do you know in what order things start? Where is the "start time" initilized (where is the terminal?!)
Eli: I am using the states machine, and set the "start time" during the program initialization, then calculate "test time"in next case (running block).
A proper benchmark uses a three-frame flat sequence with to high resolution relative seconds timers, on in each outer frame and the code to be benchmarked in the inner frame. (here is an example). The difference between the two timers is the exection time of the inner code in seconds. Make sure to only have wires in the benchmarking code. All controls and indicators belong outside the sequence. Also make sure that no other code can run in parallel to the sequence.
Use this and you'll be surprise how fast your code actually runs.
Then you should also disabele debugging.
Please attach your actual code (including the subVI) so we can see what else you are doing wrong.
Eli: if possible, give me your mail address, then I can sent more actual code to you separately.
"I think therefore I am" -
Hi,
lately, I realized that Jubula needs extremely long for all the progresses...
For example, deleting TestResults or after execution of TestCases, the Progress "Collecting Information" and "Writing Report to Database" needs about 15-20 minutes!!
I use the embedded database and html toolkit and my project is not big at all!
I already had larger projects and never experienced that long progresses!
Any ideas/suggestions why Jubula is suddenly working that slow?
ThanksHi Nicole,
Thanks for your question! I think the problem is that the h2 database isn't designed for productive use - it doesn't scale well and will indeed get slower and slower with time (not necessarily size of the project, just time).
If you need to keep using it then you can do the following:
- stop Jubula
- perform an export all to export all of the projects
- you can also copy the database files (from your home directory under .jubula) to back them up
- delete the database files from your home directory
- connect to the database: this will recreate the database
- then you can import the projects you exported
Like I say, this isn't the preferred way of working, but the steps above should help with the current performance. Bear in mind that you should ensure that you have backups before you delete the database!
Hope that helps,
Alex -
hi,
working with 10g XE
new_header table has 9749 rows and consist of two column : itemsets and codes like that
AST:GLU:KREA:Na:IBIL, 2380. codes starts from 1 to 9749
when I run belows pl/sql codes, it takes very long time in fact it can not be complete without error
declare
cnt1 number(15) ;
cnt2 number(15) ;
itemset1 varchar(800) ;
itemset2 varchar2(800) ;
begin
select max(codes) into cnt1 from new_header ;
cnt2 := cnt1 ;
for f in 1..cnt1 loop --cnt1 loop
for l in 1..cnt2 loop --cnt2 loop
itemset1 := 'AST:GLU:KREA:Na:TBIL:IBIL' ; ---given for exeample
--select itemsets into itemset1 from new_header where codes = f ;
insert into k1
select REGEXP_SUBSTR (itemset1,'[^:]+', 1, level)
from dual
connect by level <= length(regexp_replace(itemset1 ,'[^:]*'))+1 ;
select itemsets into itemset2 from new_header where codes = l ;
insert into k2
select REGEXP_SUBSTR (itemset2,'[^:]+', 1, level)
from dual
connect by level <= length(regexp_replace(itemset2 ,'[^:]*'))+1 ;*/
check_it ;
commit ;
end loop ;
end loop ;
dbms_output.put_line(myres.count) ;
end ;
I wanto to get each part of itemset1 seperated by : k1 global temporary table has one column varchar2 will be used in check_it procudere to compare with a table values. please give me some advice urgent..what can i do. what can I use instead of regexp_substr or any idea..thanks..The regexp_substr isn't the problem.
The problem is your table has 9749 rows and you're doing this:
for f in 1..cnt1 loop --cnt1 loop
for l in 1..cnt2 loop --cnt2 loop
end loop ;
end loop ;i.e. you are trying to execute the code in the loops 9749^2 which is roughly 95 million times. And you wonder why its taking a long time.
I havn't even tried to work out what you are trying to achieve in the rest of the code - maybe you could elaborate.
I suggest you rethink your approach to the problem though. Oh, and no, it's not urgent. -
Long execution time for report MMREO050N
Hi,
I want ask a help for a report MMREO050N.
I have executed a report MMREO050N in ECC6.0, for archive 42.000 materials, but the program run a long long time, in 24 hours the report have elaborated only 254 materiel and with this performance, the program will run for months...
do you have any suggestions?
Thanks
Regards
Andrea Cioccais it the first archiving program you execute?
I am just asking this as I have seen many questions here and all started with archiving of material master while material master archiving is probably the very last step in an archving circle.
Just execute SARA, enter MM_MATNR and click the button for network.
SAP will shows you which objects should be archived prior to material master.
wrong sequence of archiving has an enormous effect on run time, because SAP executes some hundred checks for each material master. And if you have a still dependend data for an material to be archived, then SAP reads a lot data before and writes error messages in the log and does not archive the material.
Even after having archived the dependend data I am still facing about 3 minutes runtime per material. -
SQL Query + long execution time.
Dear Gurus/masters/All,
I request you all to help me in tuning the SQL query which is taking more time. DB Version : 10.2.0.4
SQL Query WHERE condition:
select column1, column2, .........
FROM
SIEBEL.S_ORG_EXT T1,
SIEBEL.S_PROD_INT T2,
SIEBEL.S_VOD T3,
SIEBEL.S_ORG_EXT T4,
SIEBEL.S_ORG_EXT T5,
SIEBEL.S_ORG_EXT_X T6,
SIEBEL.S_PROD_LN T7,
SIEBEL.S_ASSET_OM T8,
SIEBEL.S_VOD_VER T9,
SIEBEL.S_CTLG_CAT T10,
SIEBEL.S_CONTACT T11,
SIEBEL.S_PARTY T12,
SIEBEL.S_PARTY T13,
SIEBEL.S_PROD_INT T14,
SIEBEL.S_ASSET_BU T15,
SIEBEL.S_CTLG_CAT T16,
SIEBEL.S_ORG_EXT T17,
SIEBEL.S_ORG_EXT T18,
SIEBEL.S_ASSET T19,
SIEBEL.S_ADDR_PER T20,
SIEBEL.S_ORG_EXT T21,
SIEBEL.S_ASSET_X T22,
SIEBEL.S_ASSET T23
WHERE
T16.PAR_CAT_ID = T10.ROW_ID (+) AND
T14.CG_PR_CTLG_CAT_ID = T16.ROW_ID (+) AND
T3.ROW_ID = T9.VOD_ID AND
T14.CFG_MODEL_ID = T3.OBJECT_NUM AND
T23.OWNER_CON_ID = T11.ROW_ID (+) AND
T23.OWNER_ACCNT_ID = T6.PAR_ROW_ID (+) AND
T23.PER_ADDR_ID = T20.ROW_ID (+) AND
T23.PROD_ID = T14.ROW_ID AND
T23.OWNER_ACCNT_ID = T21.PAR_ROW_ID (+) AND
T14.PR_PROD_LN_ID = T7.ROW_ID (+) AND
T23.ROOT_ASSET_ID = T19.ROW_ID (+) AND
T19.PROD_ID = T2.ROW_ID (+) AND
T23.BILL_ACCNT_ID = T18.PAR_ROW_ID (+) AND
T23.RTNG_DLR_ID = T1.PAR_ROW_ID (+) AND
T23.PREF_SRV_DLR_ID = T17.PAR_ROW_ID (+) AND
T23.DLR_ID = T4.PAR_ROW_ID (+) AND
T23.ROW_ID = T22.PAR_ROW_ID (+) AND
T23.ROW_ID = T8.PAR_ROW_ID (+) AND
T23.PR_CON_ID = T12.ROW_ID (+) AND
T23.BU_ID = T15.BU_ID (+) AND T23.ROW_ID = T15.ASSET_ID (+) AND
T15.BU_ID = T13.ROW_ID (+) AND
T15.BU_ID = T5.PAR_ROW_ID (+) AND
((T23.SERIAL_NUM IS NOT NULL AND T23.PAR_ASSET_ID IS NULL OR T23.X_PHONE_NUMBER IS NOT NULL AND T23.PAR_ASSET_ID IS NOT NULL) AND
(T9.VER_NUM = :1));Query Exection Plan:
PLAN_TABLE_OUTPUT
Plan hash value: 967177145
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 54117 | 92M| 4435K (1)| 01:58:43 |
| 1 | NESTED LOOPS OUTER | | 54117 | 92M| 4435K (1)| 01:58:43 |
| 2 | NESTED LOOPS OUTER | | 54117 | 87M| 4261K (1)| 01:54:04 |
| 3 | NESTED LOOPS OUTER | | 54117 | 86M| 4154K (1)| 01:51:13 |
| 4 | NESTED LOOPS OUTER | | 54117 | 85M| 4111K (1)| 01:50:03 |
| 5 | NESTED LOOPS OUTER | | 54117 | 84M| 3980K (1)| 01:46:33 |
| 6 | NESTED LOOPS OUTER | | 54117 | 83M| 3937K (1)| 01:45:24 |
| 7 | NESTED LOOPS OUTER | | 54117 | 81M| 3763K (1)| 01:40:44 |
| 8 | NESTED LOOPS OUTER | | 54117 | 81M| 3751K (1)| 01:40:25 |
| 9 | NESTED LOOPS OUTER | | 54117 | 80M| 3621K (1)| 01:36:57 |
| 10 | NESTED LOOPS OUTER | | 54117 | 73M| 3515K (1)| 01:34:07 |
| 11 | NESTED LOOPS OUTER | | 54117 | 71M| 3410K (1)| 01:31:18 |
| 12 | NESTED LOOPS OUTER | | 54117 | 69M| 3410K (1)| 01:31:18 |
| 13 | NESTED LOOPS OUTER | | 54117 | 67M| 3410K (1)| 01:31:18 |
| 14 | NESTED LOOPS OUTER | | 54117 | 66M| 3410K (1)| 01:31:18 |
| 15 | NESTED LOOPS OUTER | | 54117 | 64M| 3324K (1)| 01:28:59 |
| 16 | NESTED LOOPS OUTER | | 54117 | 62M| 3237K (1)| 01:26:40 |
| 17 | NESTED LOOPS | | 54117 | 57M| 3106K (1)| 01:23:10 |
| 18 | NESTED LOOPS OUTER | | 71 | 43665 | 381 (2)| 00:00:01 |
| 19 | NESTED LOOPS OUTER | | 71 | 42316 | 323 (2)| 00:00:01 |
| 20 | NESTED LOOPS OUTER | | 71 | 41322 | 322 (2)| 00:00:01 |
| 21 | NESTED LOOPS | | 71 | 24708 | 265 (3)| 00:00:01 |
| 22 | NESTED LOOPS | | 77 | 2772 | 141 (4)| 00:00:01 |
|* 23 | TABLE ACCESS FULL | S_VOD_VER | 75 | 1350 | 72 (7)| 00:00:01 |
| 24 | TABLE ACCESS BY INDEX ROWID| S_VOD | 1 | 18 | 1 (0)| 00:00:01 |
|* 25 | INDEX UNIQUE SCAN | S_VOD_P1 | 1 | | 1 (0)| 00:00:01 |
| 26 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 312 | 2 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | S_PROD_INT_F9 | 1 | | 1 (0)| 00:00:01 |
| 28 | TABLE ACCESS BY INDEX ROWID | S_PROD_LN | 1 | 234 | 1 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | S_PROD_LN_P1 | 1 | | 1 (0)| 00:00:01 |
| 30 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 1 | 14 | 1 (0)| 00:00:01 |
|* 31 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 1 | | 1 (0)| 00:00:01 |
| 32 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 1 | 19 | 1 (0)| 00:00:01 |
|* 33 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 1 | | 1 (0)| 00:00:01 |
|* 34 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 760 | 375K| 43753 (1)| 00:01:11 |
|* 35 | INDEX RANGE SCAN | S_ASSET_U2 | 55873 | | 312 (3)| 00:00:01 |
| 36 | TABLE ACCESS BY INDEX ROWID | S_ASSET_OM | 1 | 94 | 2 (0)| 00:00:01 |
|* 37 | INDEX RANGE SCAN | S_ASSET_OM_U1 | 1 | | 2 (0)| 00:00:01 |
| 38 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 | 39 | 2 (0)| 00:00:01 |
|* 39 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0)| 00:00:01 |
| 40 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 1 | 29 | 2 (0)| 00:00:01 |
|* 41 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 1 | | 1 (0)| 00:00:01 |
| 42 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 1 (0)| 00:00:01 |
|* 43 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 44 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 1 (0)| 00:00:01 |
|* 45 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 46 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 32 | 1 (0)| 00:00:01 |
|* 47 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 48 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 36 | 2 (0)| 00:00:01 |
|* 49 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 50 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 139 | 2 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 1 | 16 | 2 (0)| 00:00:01 |
|* 53 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 1 | | 2 (0)| 00:00:01 |
|* 54 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | 12 | 1 (0)| 00:00:01 |
| 55 | TABLE ACCESS BY INDEX ROWID | S_ASSET_BU | 1 | 34 | 3 (0)| 00:00:01 |
|* 56 | INDEX RANGE SCAN | S_ASSET_BU_U1 | 1 | | 2 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | S_PARTY_P1 | 1 | 12 | 1 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 1 | 37 | 2 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | S_ASSET_P1 | 1 | | 2 (0)| 00:00:01 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 16 | 1 (0)| 00:00:01 |
|* 61 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 1 | | 1 (0)| 00:00:01 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_ASSET_X | 1 | 93 | 3 (0)| 00:00:01 |
|* 65 | INDEX RANGE SCAN | S_ASSET_X_U1 | 1 | | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
23 - filter("T9"."VER_NUM"=TO_NUMBER(:1))
25 - access("T3"."ROW_ID"="T9"."VOD_ID")
27 - access("T14"."CFG_MODEL_ID"="T3"."OBJECT_NUM")
29 - access("T14"."PR_PROD_LN_ID"="T7"."ROW_ID"(+))
31 - access("T14"."CG_PR_CTLG_CAT_ID"="T16"."ROW_ID"(+))
33 - access("T16"."PAR_CAT_ID"="T10"."ROW_ID"(+))
34 - filter("T23"."PAR_ASSET_ID" IS NULL AND "T23"."SERIAL_NUM" IS NOT NULL OR "T23"."X_PHONE_NUMBER" IS
NOT NULL AND "T23"."PAR_ASSET_ID" IS NOT NULL)
35 - access("T23"."PROD_ID"="T14"."ROW_ID")
37 - access("T23"."ROW_ID"="T8"."PAR_ROW_ID"(+))
39 - access("T23"."OWNER_CON_ID"="T11"."ROW_ID"(+))
41 - access("T23"."PER_ADDR_ID"="T20"."ROW_ID"(+))
43 - access("T23"."RTNG_DLR_ID"="T1"."PAR_ROW_ID"(+))
45 - access("T23"."DLR_ID"="T4"."PAR_ROW_ID"(+))
47 - access("T23"."PREF_SRV_DLR_ID"="T17"."PAR_ROW_ID"(+))
49 - access("T23"."BILL_ACCNT_ID"="T18"."PAR_ROW_ID"(+))
51 - access("T23"."OWNER_ACCNT_ID"="T21"."PAR_ROW_ID"(+))
53 - access("T23"."OWNER_ACCNT_ID"="T6"."PAR_ROW_ID"(+))
54 - access("T23"."PR_CON_ID"="T12"."ROW_ID"(+))
56 - access("T23"."ROW_ID"="T15"."ASSET_ID"(+) AND "T23"."BU_ID"="T15"."BU_ID"(+))
57 - access("T15"."BU_ID"="T13"."ROW_ID"(+))
59 - access("T23"."ROOT_ASSET_ID"="T19"."ROW_ID"(+))
61 - access("T19"."PROD_ID"="T2"."ROW_ID"(+))
63 - access("T15"."BU_ID"="T5"."PAR_ROW_ID"(+))
65 - access("T23"."ROW_ID"="T22"."PAR_ROW_ID"(+))
Note
- dynamic sampling used for this statement
105 rows selected.out put of dbms_xplan.display_cursor :
SQL> select * from table(dbms_xplan.display_cursor('xxxxxxxxxxxxxx',NULL,'iostats last'));
PLAN_TABLE_OUTPUT
SQL_ID xxxxxxxxxxxxxx, child number 0
SELECT T23.CONFLICT_ID, T23.LAST_UPD, T23.CREATED, T23.LAST_UPD_BY, T23.CREATED_BY,
T23.MODIFICATION_NUM, T23.ROW_ID, T23.ASSET_NUM, T21.LOC, T21.NAME, T23.INSTALL_DT,
T23.INVLOC_ID, T23.NAME, T23.OU_ADDR_ID, T23.OWNER_ACCNT_ID, T23.PAR_ASSET_ID, T23.PER_ADDR_ID,
T20.STATE, T23.PR_CON_ID, T23.PR_EMP_ID, T14.DESC_TEXT, T23.PROD_ID, T14.NAME,
T21.INTEGRATION_ID, T23.COST_LST_ID, T14.SERIALIZED_FLG, T23.REGISTERED_DT, T23.SERIAL_NUM,
T23.VERSION, T23.STATUS_CD, T14.PR_PROD_LN_ID, T7.NAME, T23.QTY, T23.ASSET_COND_CD,
T23.PR_ACCNT_ID, T23.OWNERSHIP_TYPE_CD, T23.XA_CLASS_ID, T23.OPER_STATUS_CD, T23.SP_NUM,
T23.BILL_ACCNT_ID, T23.SERV_ACCT_ID, T9.RELEASED_FLG, T23.CFG_TYPE_CD, T9.VER_NUM, T23.END_DT,
T23.ASSEMBLY_PORT_ID,
Plan hash value: xxxxxxxxxxxxxx
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 1 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.99 | 1236K| 460K|
| 2 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.99 | 1236K| 460K|
| 3 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.85 | 1236K| 460K|
| 4 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.69 | 1236K| 460K|
| 5 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.69 | 1236K| 460K|
| 6 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:23:58.69 | 1236K| 460K|
| 7 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.47 | 1236K| 460K|
| 8 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.47 | 1236K| 460K|
| 9 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.37 | 1236K| 460K|
| 10 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.22 | 1236K| 460K|
| 11 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.16 | 1236K| 460K|
| 12 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.16 | 1236K| 460K|
| 13 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.16 | 1236K| 460K|
| 14 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.16 | 1236K| 460K|
| 15 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:58.09 | 1236K| 460K|
| 16 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:23:57.99 | 1236K| 460K|
| 17 | NESTED LOOPS | | 1 | 11 | 10 |00:23:57.98 | 1236K| 460K|
| 18 | NESTED LOOPS OUTER | | 1 | 1 | 57 |00:00:00.02 | 828 | 0 |
| 19 | NESTED LOOPS OUTER | | 1 | 2 | 57 |00:00:00.02 | 828 | 0 |
| 20 | NESTED LOOPS OUTER | | 1 | 2 | 57 |00:00:00.02 | 828 | 0 |
| 21 | NESTED LOOPS | | 1 | 2 | 57 |00:00:00.01 | 786 | 0 |
| 22 | NESTED LOOPS | | 1 | 2 | 232 |00:00:00.01 | 493 | 0 |
|* 23 | TABLE ACCESS FULL | S_VOD_VER | 1 | 75 | 246 |00:00:00.01 | 12 | 0 |
| 24 | TABLE ACCESS BY INDEX ROWID| S_VOD | 246 | 1 | 232 |00:00:00.01 | 481 | 0 |
|* 25 | INDEX UNIQUE SCAN | S_VOD_P1 | 246 | 1 | 232 |00:00:00.01 | 249 | 0 |
| 26 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 232 | 1 | 57 |00:00:00.01 | 293 | 0 |
|* 27 | INDEX RANGE SCAN | S_PROD_INT_F9 | 232 | 1 | 57 |00:00:00.01 | 236 | 0 |
| 28 | TABLE ACCESS BY INDEX ROWID | S_PROD_LN | 57 | 1 | 39 |00:00:00.01 | 42 | 0 |
|* 29 | INDEX UNIQUE SCAN | S_PROD_LN_P1 | 57 | 1 | 39 |00:00:00.01 | 3 | 0 |
| 30 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 31 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 32 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 33 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 34 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 57 | 10 | 10 |00:23:57.97 | 1235K| 460K|
|* 35 | INDEX RANGE SCAN | S_ASSET_U2 | 57 | 734 | 627K|00:00:01.34 | 4295 | 2032 |
| 36 | TABLE ACCESS BY INDEX ROWID | S_ASSET_OM | 10 | 1 | 0 |00:00:00.01 | 26 | 2 |
|* 37 | INDEX RANGE SCAN | S_ASSET_OM_U1 | 10 | 1 | 0 |00:00:00.01 | 26 | 2 |
| 38 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 10 | 1 | 10 |00:00:00.11 | 36 | 12 |
|* 39 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 10 | 1 | 10 |00:00:00.06 | 26 | 6 |
| 40 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 10 | 1 | 10 |00:00:00.07 | 36 | 18 |
|* 41 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 10 | 1 | 10 |00:00:00.04 | 26 | 8 |
| 42 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 43 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 44 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 45 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 46 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 47 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 48 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.05 | 46 | 12 |
|* 49 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.03 | 26 | 6 |
| 50 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.15 | 55 | 23 |
|* 51 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.04 | 26 | 6 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 10 | 1 | 10 |00:00:00.10 | 40 | 12 |
|* 53 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 10 | 1 | 10 |00:00:00.05 | 30 | 6 |
|* 54 | INDEX UNIQUE SCAN | S_PARTY_P1 | 10 | 1 | 0 |00:00:00.01 | 5 | 0 |
| 55 | TABLE ACCESS BY INDEX ROWID | S_ASSET_BU | 10 | 1 | 10 |00:00:00.22 | 50 | 29 |
|* 56 | INDEX RANGE SCAN | S_ASSET_BU_U1 | 10 | 1 | 10 |00:00:00.15 | 40 | 19 |
| 57 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.01 | 36 | 0 |
|* 58 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
|* 59 | INDEX UNIQUE SCAN | S_PARTY_P1 | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_ASSET_X | 10 | 1 | 10 |00:00:00.16 | 50 | 20 |
|* 61 | INDEX RANGE SCAN | S_ASSET_X_U1 | 10 | 1 | 10 |00:00:00.09 | 40 | 10 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 10 | 1 | 10 |00:00:00.14 | 46 | 19 |
|* 63 | INDEX UNIQUE SCAN | S_ASSET_P1 | 10 | 1 | 10 |00:00:00.04 | 36 | 9 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
|* 65 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 10 | 1 | 10 |00:00:00.01 | 16 | 0 |
Predicate Information (identified by operation id):
23 - filter("T9"."VER_NUM"=:1)
25 - access("T3"."ROW_ID"="T9"."VOD_ID")
27 - access("T14"."CFG_MODEL_ID"="T3"."OBJECT_NUM")
29 - access("T14"."PR_PROD_LN_ID"="T7"."ROW_ID")
31 - access("T14"."CG_PR_CTLG_CAT_ID"="T16"."ROW_ID")
33 - access("T16"."PAR_CAT_ID"="T10"."ROW_ID")
34 - filter((("T23"."PAR_ASSET_ID" IS NULL AND "T23"."SERIAL_NUM" IS NOT NULL) OR ("T23"."X_PHONE_NUMBER" IS NOT NULL AND
"T23"."PAR_ASSET_ID" IS NOT NULL)))
35 - access("T23"."PROD_ID"="T14"."ROW_ID")
37 - access("T23"."ROW_ID"="T8"."PAR_ROW_ID")
39 - access("T23"."OWNER_CON_ID"="T11"."ROW_ID")
41 - access("T23"."PER_ADDR_ID"="T20"."ROW_ID")
43 - access("T23"."RTNG_DLR_ID"="T1"."PAR_ROW_ID")
45 - access("T23"."DLR_ID"="T4"."PAR_ROW_ID")
47 - access("T23"."PREF_SRV_DLR_ID"="T17"."PAR_ROW_ID")
49 - access("T23"."BILL_ACCNT_ID"="T18"."PAR_ROW_ID")
51 - access("T23"."OWNER_ACCNT_ID"="T21"."PAR_ROW_ID")
53 - access("T23"."OWNER_ACCNT_ID"="T6"."PAR_ROW_ID")
54 - access("T23"."PR_CON_ID"="T12"."ROW_ID")
56 - access("T23"."ROW_ID"="T15"."ASSET_ID" AND "T23"."BU_ID"="T15"."BU_ID")
58 - access("T15"."BU_ID"="T5"."PAR_ROW_ID")
59 - access("T15"."BU_ID"="T13"."ROW_ID")
61 - access("T23"."ROW_ID"="T22"."PAR_ROW_ID")
63 - access("T23"."ROOT_ASSET_ID"="T19"."ROW_ID")
65 - access("T19"."PROD_ID"="T2"."ROW_ID")
SQL_ID xxxxxxxxxxxxxx, child number 1
SELECT T23.CONFLICT_ID, T23.LAST_UPD, T23.CREATED, T23.LAST_UPD_BY, T23.CREATED_BY,
T23.MODIFICATION_NUM, T23.ROW_ID, T23.ASSET_NUM, T21.LOC, T21.NAME, T23.INSTALL_DT,
T23.INVLOC_ID, T23.NAME, T23.OU_ADDR_ID, T23.OWNER_ACCNT_ID, T23.PAR_ASSET_ID, T23.PER_ADDR_ID,
T20.STATE, T23.PR_CON_ID, T23.PR_EMP_ID, T14.DESC_TEXT, T23.PROD_ID, T14.NAME,
T21.INTEGRATION_ID, T23.COST_LST_ID, T14.SERIALIZED_FLG, T23.REGISTERED_DT, T23.SERIAL_NUM,
T23.VERSION, T23.STATUS_CD, T14.PR_PROD_LN_ID, T7.NAME, T23.QTY, T23.ASSET_COND_CD,
T23.PR_ACCNT_ID, T23.OWNERSHIP_TYPE_CD, T23.XA_CLASS_ID, T23.OPER_STATUS_CD, T23.SP_NUM,
T23.BILL_ACCNT_ID, T23.SERV_ACCT_ID, T9.RELEASED_FLG, T23.CFG_TYPE_CD, T9.VER_NUM, T23.END_DT,
T23.ASSEMBLY_PORT_ID,
Plan hash value: xxxxxxxxxxxxxx
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads |
| 1 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:15.04 | 1237K| 512K|
| 2 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:15.04 | 1237K| 512K|
| 3 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:14.92 | 1237K| 512K|
| 4 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:14.82 | 1237K| 512K|
| 5 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:14.82 | 1237K| 512K|
| 6 | NESTED LOOPS OUTER | | 1 | 10 | 10 |00:28:14.82 | 1237K| 512K|
| 7 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.64 | 1237K| 512K|
| 8 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.63 | 1237K| 512K|
| 9 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.51 | 1237K| 512K|
| 10 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.42 | 1237K| 512K|
| 11 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.33 | 1236K| 512K|
| 12 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.33 | 1236K| 512K|
| 13 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.33 | 1236K| 512K|
| 14 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.33 | 1236K| 512K|
| 15 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.23 | 1236K| 512K|
| 16 | NESTED LOOPS OUTER | | 1 | 11 | 10 |00:28:14.12 | 1236K| 512K|
| 17 | NESTED LOOPS | | 1 | 11 | 10 |00:28:14.12 | 1236K| 512K|
| 18 | NESTED LOOPS OUTER | | 1 | 1 | 57 |00:00:00.02 | 828 | 0 |
| 19 | NESTED LOOPS OUTER | | 1 | 1 | 57 |00:00:00.02 | 828 | 0 |
| 20 | NESTED LOOPS OUTER | | 1 | 1 | 57 |00:00:00.01 | 828 | 0 |
| 21 | NESTED LOOPS | | 1 | 1 | 57 |00:00:00.01 | 786 | 0 |
| 22 | NESTED LOOPS | | 1 | 2 | 232 |00:00:00.01 | 493 | 0 |
|* 23 | TABLE ACCESS FULL | S_VOD_VER | 1 | 74 | 246 |00:00:00.01 | 12 | 0 |
| 24 | TABLE ACCESS BY INDEX ROWID| S_VOD | 246 | 1 | 232 |00:00:00.01 | 481 | 0 |
|* 25 | INDEX UNIQUE SCAN | S_VOD_P1 | 246 | 1 | 232 |00:00:00.01 | 249 | 0 |
| 26 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 232 | 1 | 57 |00:00:00.01 | 293 | 0 |
|* 27 | INDEX RANGE SCAN | S_PROD_INT_F9 | 232 | 1 | 57 |00:00:00.01 | 236 | 0 |
| 28 | TABLE ACCESS BY INDEX ROWID | S_PROD_LN | 57 | 1 | 39 |00:00:00.01 | 42 | 0 |
|* 29 | INDEX UNIQUE SCAN | S_PROD_LN_P1 | 57 | 1 | 39 |00:00:00.01 | 3 | 0 |
| 30 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 31 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 32 | TABLE ACCESS BY INDEX ROWID | S_CTLG_CAT | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 33 | INDEX UNIQUE SCAN | S_CTLG_CAT_P1 | 57 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 34 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 57 | 10 | 10 |00:28:14.10 | 1236K| 512K|
|* 35 | INDEX RANGE SCAN | S_ASSET_U2 | 57 | 734 | 627K|00:00:01.26 | 4299 | 3327 |
| 36 | TABLE ACCESS BY INDEX ROWID | S_ASSET_OM | 10 | 1 | 0 |00:00:00.01 | 26 | 2 |
|* 37 | INDEX RANGE SCAN | S_ASSET_OM_U1 | 10 | 1 | 0 |00:00:00.01 | 26 | 2 |
| 38 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 10 | 1 | 10 |00:00:00.10 | 36 | 18 |
|* 39 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 10 | 1 | 10 |00:00:00.04 | 26 | 9 |
| 40 | TABLE ACCESS BY INDEX ROWID | S_ADDR_PER | 10 | 1 | 10 |00:00:00.11 | 36 | 20 |
|* 41 | INDEX UNIQUE SCAN | S_ADDR_PER_P1 | 10 | 1 | 10 |00:00:00.04 | 26 | 10 |
| 42 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 43 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 44 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 45 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 46 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
|* 47 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 0 |00:00:00.01 | 0 | 0 |
| 48 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.09 | 46 | 18 |
|* 49 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.05 | 26 | 9 |
| 50 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.09 | 55 | 32 |
|* 51 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.02 | 26 | 8 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT_X | 10 | 1 | 10 |00:00:00.13 | 40 | 18 |
|* 53 | INDEX RANGE SCAN | S_ORG_EXT_X_U1 | 10 | 1 | 10 |00:00:00.06 | 30 | 9 |
|* 54 | INDEX UNIQUE SCAN | S_PARTY_P1 | 10 | 1 | 0 |00:00:00.01 | 5 | 0 |
| 55 | TABLE ACCESS BY INDEX ROWID | S_ASSET_BU | 10 | 1 | 10 |00:00:00.18 | 50 | 29 |
|* 56 | INDEX RANGE SCAN | S_ASSET_BU_U1 | 10 | 1 | 10 |00:00:00.11 | 40 | 19 |
| 57 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 10 | 1 | 10 |00:00:00.01 | 36 | 0 |
|* 58 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
|* 59 | INDEX UNIQUE SCAN | S_PARTY_P1 | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
| 60 | TABLE ACCESS BY INDEX ROWID | S_ASSET_X | 10 | 1 | 10 |00:00:00.10 | 50 | 20 |
|* 61 | INDEX RANGE SCAN | S_ASSET_X_U1 | 10 | 1 | 10 |00:00:00.03 | 40 | 10 |
| 62 | TABLE ACCESS BY INDEX ROWID | S_ASSET | 10 | 1 | 10 |00:00:00.12 | 46 | 20 |
|* 63 | INDEX UNIQUE SCAN | S_ASSET_P1 | 10 | 1 | 10 |00:00:00.06 | 36 | 10 |
| 64 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 10 | 1 | 10 |00:00:00.01 | 26 | 0 |
|* 65 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 10 | 1 | 10 |00:00:00.01 | 16 | 0 |
Predicate Information (identified by operation id):
23 - filter("T9"."VER_NUM"=:1)
25 - access("T3"."ROW_ID"="T9"."VOD_ID")
27 - access("T14"."CFG_MODEL_ID"="T3"."OBJECT_NUM")
29 - access("T14"."PR_PROD_LN_ID"="T7"."ROW_ID")
31 - access("T14"."CG_PR_CTLG_CAT_ID"="T16"."ROW_ID")
33 - access("T16"."PAR_CAT_ID"="T10"."ROW_ID")
34 - filter((("T23"."PAR_ASSET_ID" IS NULL AND "T23"."SERIAL_NUM" IS NOT NULL) OR ("T23"."X_PHONE_NUMBER" IS NOT NULL AND
"T23"."PAR_ASSET_ID" IS NOT NULL)))
35 - access("T23"."PROD_ID"="T14"."ROW_ID")
37 - access("T23"."ROW_ID"="T8"."PAR_ROW_ID")
39 - access("T23"."OWNER_CON_ID"="T11"."ROW_ID")
41 - access("T23"."PER_ADDR_ID"="T20"."ROW_ID")
43 - access("T23"."RTNG_DLR_ID"="T1"."PAR_ROW_ID")
45 - access("T23"."DLR_ID"="T4"."PAR_ROW_ID")
47 - access("T23"."PREF_SRV_DLR_ID"="T17"."PAR_ROW_ID")
49 - access("T23"."BILL_ACCNT_ID"="T18"."PAR_ROW_ID")
51 - access("T23"."OWNER_ACCNT_ID"="T21"."PAR_ROW_ID")
53 - access("T23"."OWNER_ACCNT_ID"="T6"."PAR_ROW_ID")
54 - access("T23"."PR_CON_ID"="T12"."ROW_ID")
56 - access("T23"."ROW_ID"="T15"."ASSET_ID" AND "T23"."BU_ID"="T15"."BU_ID")
58 - access("T15"."BU_ID"="T5"."PAR_ROW_ID")
59 - access("T15"."BU_ID"="T13"."ROW_ID")
61 - access("T23"."ROW_ID"="T22"."PAR_ROW_ID")
63 - access("T23"."ROOT_ASSET_ID"="T19"."ROW_ID")
65 - access("T19"."PROD_ID"="T2"."ROW_ID")
226 rows selected.
SQL > -
BAPI performance low- taking too long execution time
Hi,
I am using BAPI "BAPI_MOSRVAPS_GETLIST2" for reading planned order details but its taking to long to execute (3-4 mins approx for 3-4 products). Please suggest me how to improve the performance of it. Input for the BAPI :
Import Parameters
Tables (Input)
PRODUCT_SELECTION
LOCATION_SELECTION
*Tables(Output)*
ORDER_HEADS
PEGGING_OUTPUT_NODES
Thanks ,
RoopeshHi,
If possible give values for locations , location types .
Please also check if you can give order ATP category.
This should give faster extraction of data.
Regards
Datta -
Execution time issues with SU01 demo script
Having worked with Scripting in a Box for a while now I wanted to try out the examples there. I read FM: SO_USER_LIST_READ or another one explaining why my attempt to narrow the returned users failed (Craig, did you find out why the functionality was removed?) and Re: Issue with "Scripting in a Box" seeing that Harry had the same problems with only ~200 users in his system. However, Craig's original post states he successfully managed with over 400 users. I'm a bit confused...
I included some simple timing stuff and found out that processing of one user in the loop takes about 1.7 seconds - little surprise then that every script times out. This seems to be due to the additional calls to GetStatus() and GetValid() - by commenting them out I get the whole list rather quickly.
Unfortunately commenting them out also means no nice icons for 'Status' and 'Valid', which is not desired. I probably could create a Z FM to deliver me the userlist with these two fields already added (which would save on rfc-calls, assuming the operation is much quicker on the server directly), but I hoped to get a solution based purely on PHP, not own ABAP coding (being aware that Craig also used a Z FM anyway, but still...)
I'm a bit unsure now how easy it is to actually create useful frontends in PHP, with such long execution times. I assume this will happen in other occasions as well, not only for user lists. Is there an alternative? Or a general way to do those things quicker?
:Frederic:Craig: you say it's easy to go from 1.7 seconds per user lookup down to a small fraction of it? Then apparently I'm lacking these skills. Could you please give me a hint what should be done there?
I though about creating a Z function, but having to write custom wrappers - possibly for about any transaction in this style - I wanted to avoid.
Bala: the two functions only take one user as input, not a list. So w/o modifying the ABAP side I can't feed the whole list in there. I wonder how much it would improve the result time anyway, so perhaps I'm trying it. It's just not a solution I'd prefer.
Paging is a good idea, the actual call to get the whole userlist is quite quick. Having like 20 users displayed at a time is manageable - still slow, but the script won't timeout anymore. I think I'll implement this today.
About AJAX: yes, I want to play around a bit with AJAX, however having the two columns valid and status removed and the information only displayed on mouseover etc is a bit like cheating. And 1.7+ seconds waiting for a hoover info is too long. So I'd like to optimize on the rfc-calling side primarily.
Craig: surely it was just a demo, and I'm just trying to get it to work for understanding it
:Frederic: -
How to reduce the execution time of this code?
Loop at porder1.
SELECT aufnr bstmg hsdat sgtxt bwart charg FROM mseg INTO
(porder-aufnr,porder-bstmg,porder-hsdat,porder-sgtxt,porder-bwart,
porder-charg)
WHERE matnr = porder1-matnr AND
aufnr = porder1-aufnr AND
werks = porder1-pwerk AND
( bwart = '101' OR
bwart = '102' ).
Endselect.
Endloop.
Regards
Praju .Hi prajwal.
I would like to suggest,
It is possible to reduce the time of execution by Increasing the number of fields in the WHERE clause as only those specific number of records are fetched which results in comparatively less execution time.
Also, SAP has designed such powerfull tools like Transactions - ST05, ST07, ST30, and many more
I would like to suggest you a couple of references relating to your case,
[SDN - Reference for Long execution time during processing of a select query|/thread/477540 [original link is broken];
[SDN - Reference for Reducing the Execution time of the program - Tools|How can i reduce time of execution;
[SDN - Reference for solutions to reduce the execution time of a program|How to reduce my query execution time?;
Hope that's usefull.
Good Luck & Regards.
Harsh Dave -
Query is taking longer exeuction time after compressing the cube
Hi,
we have compresed 15cubes at once using process chain. After Infocube compression, queries present on top of these cubes taking longer execution times at statement CL_SQL_RESULT_SET=============CP.
Please let us know how to deal with this query performance.
Thanks,
Navistry to run the query in RSRT in execute and debug mode..
see this http://forums.sdn.sap.com/thread.jspa?threadID=1713040
http://forums.sdn.sap.com/thread.jspa?threadID=1541660 -
Execution time of a simple vi too long
I'm working with LabVIEW 6.0.2 on a computer (AMD ~700MHz) under Windows 2000. The computer is connected to the instruments (eg Keithley 2400 Sourcemeter) via GPIB (NI PCI-GPIB Card). When trying to read the output of the K2400 with a very simple vi (sending the string READ? to the instrument with GPIBWrite (mode 2) and subsequently reading 100byte with GPIBRead (mode 2) from the instrument, the execution time mostly exceeds 1s (execution highlighting disabled). Sometimes, it can be much faster but this is very irreproducible. I played around with the GIPBRead and Write modes and with the number of bytes to be read from the device as well as with the hardware settings of the Keithley 2400 but nothing seemed to work. The API calls ca
ptured by NI Spy mainly (lines 8 - 160) consist of ThreadIberr() and ibwait(UD0, 0x0000).
As this problem is the main factor limiting our measurement speed, I would be grateful for any help.
Thanks a lot
Bettina WelterHello,
Thanks for contacting National Instruments. It seems like the 1 second delay that is occurring is due to the operation being called. ThreadIberr returns the value of iberr, while ibwait simply implements a wait. These two get called repeatedly while the GPIB device waits for the instrument (K2400, in your case) to finish its operation and respond back. It is quite possible that when you query the Keithley to send back 100 bytes of data, it has to gather them from its buffer (if its already been generated). And if there aren't 100 bytes of data in the buffer, the Keithley will keep the NRFD line asserted while it gathers 100 btyes of data. After the data has been gathered, the NRFD line is deasserted, at which point, ThreadIberr will detect the change in th
e ibsta status bit and read the 100 bytes.
So make sure that the 100 bytes of data that you are requesting don't take too long to be gathered, since this is where the main delay lies. Hope this information helps. Please let us know if you have further questions.
A Saha
Applications Engineering
National Instruments
Anu Saha
Academic Product Marketing Engineer
National Instruments -
"IMAQdxOpenCamera" function execution time is particularly long,why?
I install VAS2011 in CVI2010 environment, running IMAQdx the samples <Grab and AttributesSetup>, "IMAQdxOpenCamera" function execution time is particularly long, more than 7 seconds，why?
Thanks!
Solved!
Go to Solution.Thank you for your answers!
I capture video using VFW initialization faster, only use IMAQdx speed slow.
thanks!
Maybe you are looking for
-
HT1338 help, trying to up grade Mac Mini (2010) just can't get the hang of it.
Trying to get on MAC Store App. I think I need to purchase Snow Leopard.
-
My time capsule has a white strike out symbol when I try to drag & drop.
-
The problem Deficit of PU GR quantity 4 PC : P-109 1000 0020
Hi, I have finished the scenario stock transfer from plant 1000 to another plant 1100 with type UB. both are in the same company code and sales org. but why can I carry out the return sto from plant 1100 to plant 1000? plant 1100 has enough stock for
-
2012 macbook pro retina display
i am looking to buy a 2012 macbook pro retina display 13.3" core i5, 8gb ram and 126gb ssd however, have heard that the 2012 macbook retina display models have problems with them, like screen issues, over heating issues, wifi connection issues etc.
-
Billing Type is not picked up in Intercompany Invoice
Hi, The scenario is Intercompany STO. Here the flow is Purchase Order-Outbound Delivery- Invoice. No sales order. I have two billing types, proforma invoice and Intercompany invoice. Both are copy of standard types. I have maintained copy control fo