Infoset Query - Long run times
Hi All,
I was running a Bex query on top of an infoset query a few days ago with no problems and very good performance. Now, returning any number of records it runs and timesout. I know that there will be recommendations related to statistics and possibly those related to the active table of the ODS. I have checked these and they have been recently updated. In fact, when I manually update the statistics the behaviour is the same. The structure of the infoset has not changed.
We are running 3.0B on DB2.
Any ideas?
Robert Zovic
Arinso International
Hi Giridharan,
you check whether the hierarchy SIDs are updated properly, structure, to date are all fine.
check the difference between X and Y hierarchy.
Regards,
Prakasha A
Similar Messages
-
F4 on Variable Screen for a DataStore Object Produces Long Run Time
We experiencing a long run time in returning values when we select F4 for the Variable 0COMP_CODE when we process query for a DataStore. Before our upgrade to NW04S, we did not experience this issue. As background, the DataStore (ODS) has not changed, the variable has not changed, and the query has not changed.
0COMP_CODE has the following configuration in RSD1:
Query Def. Filter Value Selection Values in Master Data Table
Query Execution Filter Val. Selectn Only Posted Values for Navigation.
These settings are exactly like this in our BW 3.5 system.
In my review of the differences, I found that in BW 3.5, the runtime is short because the selection that is returned is the Company Codes in the Master Data table, but in NW04S, the selection that is returned is the Company Codes within the ODS.
Has anyone experienced this before and if so what was your resolution?
Thanks!<b>Query Execution Filter Val. Selection</b> should help you a lot in improving performance for F4.
Three options are available for the <b>Query Execution Filter Val. Selection</b> field on the BEx tab that directly affect F4 searches.
<b>The Only Posted Values for Navigation</b> setting limits an F4 search to the values related to the querys navigation state. It is the recommended setting if youre working with less savvy BW end users who may have trouble identifying applicable values or are confused when faced with long lists of characteristics. This setting yields the <b>slowest performance</b> in terms of the F4 search.
<b>Only Values in InfoProvider</b> is a better option if you need a list of characteristic values for a variable that is limited to the transactional records in the InfoProvider that a query is being executed against. This setting is ideal for restricting users to the appropriate source when data is available in different InfoProviders with different values. For example, lets say you have an InfoCube with billing data for Europe and another for the US. Each sales office will have different values, so by using this setting a variable can be restricted to the correct values.
<b>The Values in Master Data Table</b> setting allows users to list all possible characteristic values when they run F4. Recommend that you use it when you have transactional records for almost all the values across InfoProviders and users are aware of the relevance of the values for the navigation state.
While the Values in Master Data Table setting is the <b>fastest F4</b> search setting, you need to be aware of a couple of situations when using it. Users with authorization restrictions may have an F4 list returned with all the values from the master data table, but a subsequent query may not report the result. Instead it will generate an error message informing the user of the authorization restriction. Likewise, users may select values from the master data table that are not valid for the current query due to other restrictions. There may not be any records for an InfoObject in its underlying InfoProvider designed for a query, so the system returns a no applicable data found message.
<b>Important Notes for F4 - Performance -</b>
748623 Input help (F4) has a very long runtimerecommendations
661251 Filter value selection displays too few/too many values
581802 Variable dialog boxes: performance of the F4 help
581079 Performance for the F4 help of navigation attributes
626887 F4 variables and InfoObject settings.
Hope it Helps
Chetan
@CP.. -
How to set vo query at run time
Hi,
Is it possible to bind the where clause of query at run time.
N :)Hi,
Yes its possible.
To add new where clause to your query.
vo.setWhereClause(null);//If you want to remove any existing programmatically added where clause.
vo.setWhereClause("Your new query");
To bind varibales (Say there are 2 bind variables),
First way to achieve this.
setWhereClauseParam(null); //Always reset it to remove existing bindings)
setWhereClauseParam(0, "Your first paramter value"); // Second parameter "Your first paramter value" is of type object.
setWhereClauseParam(1, "Your first paramter value");
In case you use "?" styly type binding, this count in above method starts with 1 instead of 0.
Second way is to put all bind variables in an object array and pass to above method.
Vector params=new Vector(2);
params.addElement("FirstParameter");
params.addElement("SecondParameter");
Now call vo.executeQuery() to fetch the results as per new query.
Abdul Wahid -
How to get report (SQL Query) generating Run Time
There is a Standard report of Payroll which show employee transfer information on the bases of location, grade job or organization, now to get actual query which is generated by run time in report builder including whether single column parameter or lexical parameter " because currently the query in not complicate but the parameter and lexical parameter is much more due to this not quite easy to under stand just copy past it into toad or pl/sql developer,
Kindly share your experience to get such kind of query in you working time.
thanksHere i try to explain contain of query.
Parameter
P_DEPTNO = 10
P_WHERE_CLAUSE := ' AND EMPNO IS NOT NULL AND SALARY > 100'
SELECT * FROM EMP
WHERE DEPTNO = P_DEPTNO
&P_WHERE_CLAUSE
REPROT WILL GENERATE QUERY AT RUN TIME IS LIKE THAT
SELECT * FROM EMP
WHERE DEPTNO = 10
AND EMPNO IS NOT NULL AND SALARY > 100
Now i want to get this query out(Run time) by doing any oracle database feature or sth similar.
thanks -
InfoSet Query - Long Description while selecting variable values
Dear Experts,
We have an InfoSet Query on different InfoObjects like 0CUSTOMER, 0CUST_COMPC etc and the common link between these InfoObjects is CUSTOMER.
We have a variable created on this CUSTOMER. The requirement is that when this query is executed, user should be able to select a value of Customer (F4 help) and at that time, he should be able to view both Key and Long Text of Customer.
We know that if we change the CUSTOMER InfoObject --> BEx Properties tab, then we can display Long Text and Key in Query Selection Screens. However we can not do that because it would affect all queries in which this InfoObject is used.
If we go to Query Design, and choose "Long Text and Key" in properties of Customer, then system displays Long Text and Key of Customer but after the report execution is done.
We want to display the Long Text of Customer to User at the time of selection and that too without making any InfoObject level change.
If it was InfoProvider, we could have done it using "Provider specific properties of Characteristic" option. But this is InfoSet and that option does not appear here.
Please suggest the solution.
Regards
PRohit,
Are you looking to display long text for infoobject instead of short description ?
Then go tp rsd1>infoobject>display/change-->master data/texts -->text table properties -->check long text exists.
It supports a long text field with a length of 60 characters
Activate the infoobject
--Doodle
Message was edited by: Doodle -
Checking dynamic query at run time
i need to check whether the query is valid or not at run time. The query will be formed based on the column name, table name, and where clause. this query is purely a select statement. if column name and table names are diff then system should display an error msg. i have more than 10 tables and the table name will be selected from LOV. i should be allowed to enter the condition for where clause also ar run time and this condition column should also be validated.
Hi,
I think you only want to see if your select statement has compilation error or not because when you use dynamic statement it doesnt show the compilation erro if the statement has it or not. What you can do is add an item say "stmt" in your control block. change the property to multi record so that you can see multiple lines in that item and make the lenght say 2000. Now assign your statement into "stmt" for example
:control_block.stmt := 'select ' || col1
|| ','
|| col2
|| ','
|| col3
|| ' FROM '
|| table
|| ' where ' || conditionput this statement on any button on when-button-pressed trigger. When you will press the button on run time you will see the statement. Run that statement on sql*plus or toad and check if there is any problem in the statement.
Hope this helps
Ghulam -
Hi BW Experts,
Here goes my question :
There is a query which is giving runtime error as time limit exceeded. This query is based on an infoset which is based on 4 ODS's.
Is there any way we can do performance tuning for this query?
Many Thanks in advance,
Sudip.Hi Ganesh,
Thanks for your help.
Can you please tell me which option to select for the infoset query as i'm seeing a lot of options on the left hand side of the screen like master Data, Transaction data, ODS objects,PSA tables etc for the RSRV transaction?
Also to add-on from my first post...this particular query is executing for an hour after which the error message comes an "System Failue, Time limit exceeded".
Regards,
Sudip. -
BEx Query designer : Run-time error '457'
Hey,
We installed the standard query's for HR. When we try to change the query 'Average age of employees', and we try to restrict on 'Calender year/month' then we receive this error.
Run-time error '457' : This key is already associated with an element of this collection.
We're using version 3.50.
I already saw oss note 517232 but that was for version 2.0 and not intresting for my case... Anybody any idea?
Kind regards,
Tom
PS : I also saw : https://forums.sdn.sap.com/click.jspa?searchID=1049118&messageID=1649858 & https://forums.sdn.sap.com/click.jspa?searchID=1049118&messageID=2243413Hi,
Check this conditions as I haven't checked the queries ......make sure that these two conditions are not getting into picture after you make the changes to the query.
1) When we are making restricted key figures we cant use same variable to restrict to two different Characteristics in the same RKF.
2)Once a Variable used to restrict a characteristic in one RKF you cannot use it to restrict it other characteristic in other key figures i.e. You can use it to restrict that particular characteristic only in other key figures.
Hope it helps
Thanks -
How to find Query with Running time
dear frnds,
I need to find the query details and query execution time from a DB USER. am using oracle 11g. how to generate this report
please give me any idea.,
thanks.
Edited by: Velsjeya on May 14, 2012 1:07 AM
Edited by: Velsjeya on May 14, 2012 1:07 AMVelsjeya wrote:
thanks a lot,
here i need to show query running time also...( how many mins that particular query ran) ... please help mePlease do search for the question's answer. V$SQL should be able to show you what you are looking for. Asktom's thread given below discusses the same,
http://asktom.oracle.com/pls/apex/f?p=100:11:0::::P11_QUESTION_ID:912859800346801944
Aman.... -
Dashboard to BEx query call run time very slow (7-8 mins)
Hi Guys,
I am currently working on a project where BEx query is being consumed using BICS. The functional team has built a BEx which is being cached in Webi by the BO developer and then that cashed Webi is being used in Dashboard. We have many hierarchies (Fund Center, Profit Center, GL Account etc.) used in the dashboard.
BEx query > WEBi (Cached) > Dashboard
Clicking the main level in hierarchy in dashboard the data comes back in 2-3 secs as the data is cached in Webi
ISSUE: In Dashboard based on where user is on the Fund Center hierarchy there is a button called “Summary Report” on the dashboard which calls the BEx query and that second call takes roughly about 7-8 minutes. How could we reduce the run time of the second query?
The secondary query uses the same data set as the first one but as the data is cached in Webi and it uses Web services to pass data to dashboard, so any call back from dashboard to the cached webi the hierarchy information is lost and thus the secondary query call to BEx query.
Would it be possible to recommend any solution where we could bring the run time of the secondary call to less than a minute?
Thanks,
KeysFirst update to current frontend patch. many correction are included.
Further check these notes: (relavant only if Analyzer is culprit)
1160093: REPAIR MODE - Prog error/performance problems when using large workbooks
1289127: REPAIR MODE - BExAnalyzer: performance issue applying styles in Excel 2007
1293255: REPAIR MODE - BExAnalyzer: crash when repairing workbook with Excel 2007
1150242+1094799: ANA_USE_SIDGRID - Improving performance/memory in the BEx Analyzer
1179647: ANA_USE_TABLE - Performance: Network load in BEx Analyzer
1260213: ANA_USE_OPTIMIZE_STG - Performance problems during workbook opening in Excel 2007
1287179: ANA_SINGLEDPREFRESH - Single Data Provider Refresh
1286653: Performance issues while displaying hierarchy (especially in Excel 2007)
1352375: ANA_USE_SIDGRIDWBUF / ANA_USE_SIDGRIDMASS Performance improvements in a WAN (roundtrip reductions)
1373214: Workbook compression
1392745: ANA_CACHE_WORKBOOK - Workbook caching -
Long running time at system copy
Hi All,
I met a problem while performing system copy. system environment is: win server 2003 Oracle 10g
the export process runs smoothly until the 19th package be exported.
18 out of 19 package have been exported successfully.
The last package is SAPSSEXEC.XXX, I checked the log file and found it runs for long time on table IGORA, PERMISSION, REPOSRC. IGORA took 2 hours more, PERMISSION took 4 hours, and REPOSRC still havn't been completed due to it contains 20 million records, but strange is that IGORA only contains 15 entries, why it took so long? and as checked in SE11, this table doesn't contain any LONG type field.
before system export, I already updated oracle statistics.
I have read through sap note:
Note 1046103 - ORACLE DIRECT PATH LOAD SUPPORT IN R3LOAD 7.00 AND LATER
Note 936441 - Oracle settings for R3load based system copy
Note 1045847 - ORACLE DIRECT PATH LOAD SUPPORT IN R3LOAD7
But seems not helpful.
Could any expert help me?
Thank you very muchHi,
You can compare REPOSRC.log and REPOSRC.log.bck file it's copying or not.
Check the SIZE of the tables.
The Below points will use to increse the system performance while exporting.
1. Using of RowID splitting for large transparent tables (PL/SQL Script) (Table spliiting)
3. Increasing CPU/RAM in the Source hardware.
4. Editing DDLORA.TPL file for reducing index creation of import, copy parameter from DDLORA_LRG.TPL file
5. delete data from batch logs table (APQD, EDI40, TST03....)
6. Update Full statistics before export using the below br command
Brcoonect -c -u / -f stats -t all -f collect -p <number of CPU>
7. Disable archiving in database
(alter database noarchivelog)
8. PSAPTEMP adjustments , DB parameters as per the note 936441
9. for oracle slow I /O performance check the note 834343, 793113
Regards,
Ram -
How to get the name of an executing ABAP query in run time
Hi ABAP Gurus,
I need to get the ABAP query name when it's running. For example we can get the current executing ABAP program name from SY-REPID.
My tried logic - every query generates an ABAP program like AQZZUGQUERY. 'UG' stands for user-group name and the length specified for it is 12, if the length of the user-group name is less than 12, then the rest will be filled by '='. Next 'QUERY' stands for ABAP query name and the length specified for it is 14, if less, then the rest will be filled in with '=' in the right. I've tried to extract the query name by using cut and trip (offset) operations.
But somehow this logic is not working - always it's picking up the function name as checked in debug mode.
Guys - Can you please provide me the solution on this.
Thanks & regards,
Jayanta Bej.Guys,
I've cracked the issue. Instead of retrieving the query name from sy-repid, I've retrieved it from sy-cprog and the problem is resolved.
Thanks guys for your quick responses.
Thanks and regards,
Jayanta Bej. -
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 > -
Long run time with ORDER by clause
Hi,
I am having a query which is executing fine(in 2 mins) but when i am using order by clause in it, its taking around 13 mins.
Can anyone suggest what could be th reason and how to execute the same query are get the ordered record?
thanks.Sorry for not providing complet details.
Database version id 10g.
Below is the execution plan when using with order by clause.
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 1 | 118 | 1538 |
| 1 | FILTER | | | | |
| 2 | HASH JOIN | | 16657 | 1089K| 56 |
| 3 | TABLE ACCESS FULL | FILETYP | 6 | 60 | 3 |
| 4 | TABLE ACCESS FULL | FILETYPSOURCEID | 16657 | 927K| 52 |
| 5 | NESTED LOOPS | | 1 | 35 | 3 |
| 6 | TABLE ACCESS BY INDEX ROWID | FILEWAREHOUSE | 1 | 25 | 2 |
| 7 | INDEX RANGE SCAN | FILEWAREHOUSE_DX2 | 1 | | 2 |
| 8 | TABLE ACCESS BY INDEX ROWID | EXTFILE | 1 | 10 | 1 |
| 9 | INDEX UNIQUE SCAN | PK_EXTFILE | 1 | | 1 |
| 10 | SORT ORDER BY | | 1 | 118 | 1538 |
| 11 | NESTED LOOPS | | 1 | 118 | 1534 |
| 12 | NESTED LOOPS OUTER | | 1 | 100 | 1533 |
| 13 | NESTED LOOPS OUTER | | 1 | 96 | 1532 |
| 14 | NESTED LOOPS | | 1 | 88 | 1531 |
| 15 | HASH JOIN | | 5 | 360 | 1524 |
| 16 | TABLE ACCESS BY INDEX ROWID | RTXN | 1 | 22 | 1 |
| 17 | NESTED LOOPS | | 117 | 5148 | 1518 |
| 18 | VIEW | VW_SQ_1 | 20869 | 448K| 1441 |
| 19 | HASH GROUP BY | | 20869 | 427K| 1441 |
| 20 | FILTER | | | | |
| 21 | TABLE ACCESS BY INDEX ROWID| RTXNSTATHIST | 20869 | 427K| 1304 |
| 22 | INDEX RANGE SCAN | RTXNSTATHIST_DX2 | 20869 | | 29 |
| 23 | INDEX RANGE SCAN | PK_RTXN | 1 | | 1 |
| 24 | NESTED LOOPS | | 1 | 24 | 3 |
| 25 | TABLE ACCESS BY INDEX ROWID | FILEWAREHOUSE | 1 | 14 | 2 |
| 26 | INDEX RANGE SCAN | FILEWAREHOUSE_DX2 | 1 | | 2 |
| 27 | TABLE ACCESS BY INDEX ROWID | EXTFILE | 1 | 10 | 1 |
| 28 | INDEX UNIQUE SCAN | PK_EXTFILE | 1 | | 1 |
| 29 | TABLE ACCESS FULL | RTXNTYP | 1 | 28 | 5 |
| 30 | TABLE ACCESS BY INDEX ROWID | RTXNSTATHIST | 1 | 16 | 2 |
| 31 | INDEX RANGE SCAN | PK_RTXNSTATHIST | 1 | | 1 |
| 32 | TABLE ACCESS BY INDEX ROWID | NTWKNODE | 1 | 8 | 1 |
| 33 | INDEX UNIQUE SCAN | PK_NTWKNODE | 1 | | 1 |
| 34 | INDEX UNIQUE SCAN | PK_ORG | 1 | 4 | 1 |
| 35 | TABLE ACCESS BY INDEX ROWID | ACCT | 1 | 18 | 1 |
| 36 | INDEX UNIQUE SCAN | PK_ACCT | 1 | | 1 |
Below is the execution plan when running without ORDER BY clause...
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 1 | 135 | 1537 |
| 1 | FILTER | | | | |
| 2 | HASH JOIN | | 16657 | 1089K| 56 |
| 3 | TABLE ACCESS FULL | FILETYP | 6 | 60 | 3 |
| 4 | TABLE ACCESS FULL | FILETYPSOURCEID | 16657 | 927K| 52 |
| 5 | NESTED LOOPS | | 1 | 35 | 3 |
| 6 | TABLE ACCESS BY INDEX ROWID | FILEWAREHOUSE | 1 | 25 | 2 |
| 7 | INDEX RANGE SCAN | FILEWAREHOUSE_DX2 | 1 | | 2 |
| 8 | TABLE ACCESS BY INDEX ROWID | EXTFILE | 1 | 10 | 1 |
| 9 | INDEX UNIQUE SCAN | PK_EXTFILE | 1 | | 1 |
| 10 | NESTED LOOPS | | 1 | 135 | 1534 |
| 11 | NESTED LOOPS OUTER | | 1 | 117 | 1533 |
| 12 | NESTED LOOPS OUTER | | 1 | 113 | 1532 |
| 13 | NESTED LOOPS | | 1 | 105 | 1531 |
| 14 | HASH JOIN | | 5 | 445 | 1524 |
| 15 | TABLE ACCESS FULL | RTXNTYP | 1 | 28 | 5 |
| 16 | TABLE ACCESS BY INDEX ROWID | RTXN | 1 | 22 | 1 |
| 17 | NESTED LOOPS | | 117 | 7137 | 1518 |
| 18 | VIEW | VW_SQ_1 | 20869 | 794K| 1441 |
| 19 | HASH GROUP BY | | 20869 | 427K| 1441 |
| 20 | FILTER | | | | |
| 21 | TABLE ACCESS BY INDEX ROWID| RTXNSTATHIST | 20869 | 427K| 1304 |
| 22 | INDEX RANGE SCAN | RTXNSTATHIST_DX2 | 20869 | | 29 |
| 23 | INDEX RANGE SCAN | PK_RTXN | 1 | | 1 |
| 24 | NESTED LOOPS | | 1 | 24 | 3 |
| 25 | TABLE ACCESS BY INDEX ROWID | FILEWAREHOUSE | 1 | 14 | 2 |
| 26 | INDEX RANGE SCAN | FILEWAREHOUSE_DX2 | 1 | | 2 |
| 27 | TABLE ACCESS BY INDEX ROWID | EXTFILE | 1 | 10 | 1 |
| 28 | INDEX UNIQUE SCAN | PK_EXTFILE | 1 | | 1 |
| 29 | TABLE ACCESS BY INDEX ROWID | RTXNSTATHIST | 1 | 16 | 2 |
| 30 | INDEX RANGE SCAN | PK_RTXNSTATHIST | 1 | | 1 |
| 31 | TABLE ACCESS BY INDEX ROWID | NTWKNODE | 1 | 8 | 1 |
| 32 | INDEX UNIQUE SCAN | PK_NTWKNODE | 1 | | 1 |
| 33 | INDEX UNIQUE SCAN | PK_ORG | 1 | 4 | 1 |
| 34 | TABLE ACCESS BY INDEX ROWID | ACCT | 1 | 18 | 1 |
| 35 | INDEX UNIQUE SCAN | PK_ACCT | 1 | | 1 |
-------------------------------------------------------------------------------------------Edited by: user10754555 on Feb 5, 2010 6:02 PM -
Changing a Programmatic View Object's query at run-time
Hi,
I've created a programmatic View Object using the information in '35.9.3 Key Framework Methods to Override for Programmatic View Objects' in the Oracle Middleware Fusion Guide and bound it to a BarChart. This has worked fine using the following:
String myColumn = "Quant1";
protected void create() {
getViewDef().setQuery(null);
getViewDef().setSelectClause(null);
setQuery(null);
String myQuery = "SELECT Service as MyService, " + myColumn + " as MyValue FROM ColumnTestTable WHERE 1 = 1";
getViewDef().setQuery(myQuery);
setQuery(myQuery);
I also have my data updating automatically. I have public properties in my viewObjImpl class which I can set and update the value of myColumn. I then thought it would just be a case of re-calling the create() method and the SQL would be updated and my chart would auto-update using the new column to select it's values, the value of the property updates and the create method is called but the chart doesn't display any different data and stops auto-updating. Does anybody know if this is possible and if so what I may have missed?
Cheers, TomHi Timo,
I moved everything to a different public method and solved the problem by firing the execute() method which I hadn't been doing previously and the chart updates with the correct data.
However, once I execute the SQL my chart stops auto-updating with changes to the data in the database - do you know how I update the SQL query but keep my chart auto-updating? Perhaps I have to re-register for the registerDatabaseChangeListener for the query collection?
Thanks in advance, Tom
Maybe you are looking for
-
Itunes not recognising ipod / ipad
Since upgrading iTunes to 11.0.1.12 I have to shut down iTunes before connecting my ipod or ipad and then start iTunes up again. If I connect the device while iTunes is running it isn't recognised.
-
29 of 34 playlists Disappeared in iTunes for Mac. Is there a way to restore them?
Yesterday I had all 34 of my playlists in iTunes for Mac and today I only have 5 total playlists. Does anyone know how to restore iTunes playlists? Is there a way, or do I have to recreate them? I am running the latest version of iTunes (10.4.1).
-
I'm trying to install Windows XP SP2 (OEM unbranded version) through Boot Camp. No trouble creating the Boot Camp partition, and the XP files and drivers begin to load, but everything stops at "Setup is starting Windows..." I'm using a wired keyboard
-
Exit before save a Service Sheet
People, I need to control amounts before a service sheet is saved. I tested the user-exits and badis available for this situation and I can not find one that runs right before being recorded. Is There another exit besides which provides me the transa
-
We dont have a television but we run EyeTV on my Macbook Pro regularly of an evening. I'd like to take the plunge and invest in a projector that could improve our viewing experience. I'd also like one that's suitable for the odd business presentation