Unable to Execute Explain Plan for the selected SQL
When working with several SQL statements in one SQL Worksheet you execute the specific statement by selecting it and pressing F9.
The same is not possible for the explain plan though.
If you select the first SQL statement and press F6, the explain plan is executed correctly. If you try the same for any other statement, all you get is 'No SQL statement entered.' on the status bar.
Maciej
It is available.
Type this in.
create table xx (yy number(10));
create table zz (aa number(10));
select * from xx;
select * from zz;Run all these statements by pressing f5.
Place the cursor on 'select * from xx;'.
Press f6 gives you a plan.
Place the cursor on 'select * from zz;'
press f6 gives you a different plan.
The problem seems to be that F6 is still suffering from a statement selection bug which is already fixed for f9. That is selecting a whole statement results in failure to recognise a statement and the 'No statement entered' message.
Similar Messages
-
Different execution plans for the same sql
Hi,
Im testing our new 10gR2 database on Linux and I can't understand why the same query use different plan.
Here are the details.
Table name: invoice_detail
Records: About 10,670,900
Columns:
No
seq (the primary key is No+Seq). Each invoices contains +/- 10 invoice_details.
category ( <- 10 different values )
State ( <- 3 different values )
Basically, I have an index on the primary key and another index on Category + State.
My request:
select *
from invoice_detail
where no=123456 <- Best index to use
and state <> 'CANCEL'
and category = 'INVOICE'
If i run this query from Toad or sql+, that's fine.
The same query (i'm watching it from EM) executed via Forms use the category+state index.
When I first import the database, the last thing I do is to run DBMS_STATS.GATHER_DATABASE_STATS.
At this point, Forms use the right index.
The day after (after the database has been analyzed with the predefined job via EM) Forms use the wrong index.
I re-analyzed everything with exec DBMS_STATS.GATHER_DATABASE_STATS but the problem is still there.
Thanks in advanceI'm already using bind variables.
I changed the "Estimated Percentage" to 100% in "Gather Optimizer Statistics Default Options" and now it seems to use the correct index. I'm stressed because I dont understand why it chooses different plan for the same sql.
Actually, my users test the migration 1 day after I load all the data (drop schema-create schema-load data-analyze database) and at this point everythings go fine. After the second analyze of the database, the DB choose the wrong indexes.
I really cannot migrate until I understand why it happens.
Any ideas?
TIA -
Multiple Executions Plans for the same SQL statement
Dear experts,
awrsqrpt.sql is showing multiple executions plans for a single SQL statement. How is it possible that one SQL statement will have multiple Executions Plans within the same AWR report.
Below is the awrsqrpt's output for your reference.
WORKLOAD REPOSITORY SQL Report
Snapshot Period Summary
DB Name DB Id Instance Inst Num Release RAC Host
TESTDB 2157605839 TESTDB1 1 10.2.0.3.0 YES testhost1
Snap Id Snap Time Sessions Curs/Sess
Begin Snap: 32541 11-Oct-08 21:00:13 248 141.1
End Snap: 32542 11-Oct-08 21:15:06 245 143.4
Elapsed: 14.88 (mins)
DB Time: 12.18 (mins)
SQL Summary DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
Elapsed
SQL Id Time (ms)
51szt7b736bmg 25,131
Module: SQL*Plus
UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(ACCT_DR_BAL,
0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND TEST_ACC_NB = ACCT_ACC_NB(+)) WHERE
TEST_BATCH_DT = (:B1 )
SQL ID: 51szt7b736bmg DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> 1st Capture and Last Capture Snap IDs
refer to Snapshot IDs witin the snapshot range
-> UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL,0) + NVL(AC...
Plan Hash Total Elapsed 1st Capture Last Capture
# Value Time(ms) Executions Snap ID Snap ID
1 2960830398 25,131 1 32542 32542
2 3834848140 0 0 32542 32542
Plan 1(PHV: 2960830398)
Plan Statistics DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100
Stat Name Statement Per Execution % Snap
Elapsed Time (ms) 25,131 25,130.7 3.4
CPU Time (ms) 23,270 23,270.2 3.9
Executions 1 N/A N/A
Buffer Gets 2,626,166 2,626,166.0 14.6
Disk Reads 305 305.0 0.3
Parse Calls 1 1.0 0.0
Rows 371,735 371,735.0 N/A
User I/O Wait Time (ms) 564 N/A N/A
Cluster Wait Time (ms) 0 N/A N/A
Application Wait Time (ms) 0 N/A N/A
Concurrency Wait Time (ms) 0 N/A N/A
Invalidations 0 N/A N/A
Version Count 2 N/A N/A
Sharable Mem(KB) 26 N/A N/A
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | | | 1110 (100)| |
| 1 | UPDATE | TEST | | | | |
| 2 | TABLE ACCESS FULL | TEST | 116K| 2740K| 1110 (2)| 00:00:14 |
| 3 | TABLE ACCESS BY INDEX ROWID| ACCT | 1 | 26 | 5 (0)| 00:00:01 |
| 4 | INDEX RANGE SCAN | ACCT_DT_ACC_IDX | 1 | | 4 (0)| 00:00:01 |
Plan 2(PHV: 3834848140)
Plan Statistics DB/Inst: TESTDB/TESTDB1 Snaps: 32541-32542
-> % Total DB Time is the Elapsed Time of the SQL statement divided
into the Total Database Time multiplied by 100
Stat Name Statement Per Execution % Snap
Elapsed Time (ms) 0 N/A 0.0
CPU Time (ms) 0 N/A 0.0
Executions 0 N/A N/A
Buffer Gets 0 N/A 0.0
Disk Reads 0 N/A 0.0
Parse Calls 0 N/A 0.0
Rows 0 N/A N/A
User I/O Wait Time (ms) 0 N/A N/A
Cluster Wait Time (ms) 0 N/A N/A
Application Wait Time (ms) 0 N/A N/A
Concurrency Wait Time (ms) 0 N/A N/A
Invalidations 0 N/A N/A
Version Count 2 N/A N/A
Sharable Mem(KB) 26 N/A N/A
Execution Plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | | | 2 (100)| |
| 1 | UPDATE | TEST | | | | |
| 2 | TABLE ACCESS BY INDEX ROWID| TEST | 1 | 28 | 2 (0)| 00:00:01 |
| 3 | INDEX RANGE SCAN | TEST_DT_IND | 1 | | 1 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| ACCT | 1 | 26 | 4 (0)| 00:00:01 |
| 5 | INDEX RANGE SCAN | INDX_ACCT_DT | 1 | | 3 (0)| 00:00:01 |
Full SQL Text
SQL ID SQL Text
51szt7b736bm UPDATE TEST SET TEST_TRN_DAY_CL = (SELECT (NVL(ACCT_CR_BAL, 0) +
NVL(ACCT_DR_BAL, 0)) FROM ACCT WHERE ACCT_TRN_DT = (:B1 ) AND PB
RN_ACC_NB = ACCT_ACC_NB(+)) WHERE TEST_BATCH_DT = (:B1 )Your input is highly appreciated.
Thanks for taking your time in answering my question.
RegardsOracle Lover3 wrote:
Dear experts,
awrsqrpt.sql is showing multiple executions plans for a single SQL statement. How is it possible that one SQL statement will have multiple Executions Plans within the same AWR report.If you're using bind variables and you've histograms on your columns which can be created by default in 10g due to the "SIZE AUTO" default "method_opt" parameter of DBMS_STATS.GATHER__STATS it is quite normal that you get different execution plans for the same SQL statement. Depending on the values passed when the statement is hard parsed (this feature is called "bind variable peeking" and enabled by default since 9i) an execution plan is determined and re-used for all further executions of the same "shared" SQL statement.
If now your statement ages out of the shared pool or is invalidated due to some DDL or statistics gathering activity it will be re-parsed and again the values passed in that particular moment will determine the execution plan. If you have skewed data distribution and a histogram in place that reflects that skewness you might get different execution plans depending on the actual values used.
Since this "flip-flop" behaviour can sometimes be counter-productive if you're unlucky and the values used to hard parse the statement leading to a plan that is unsuitable for the majority of values used afterwards, 11g introduced the "adaptive" cursor sharing that attempts to detect such a situation and can automatically re-evaluate the execution plan of the statement.
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/ -
Hi ,
We have no.of packages to check for explain plan.
Is there any tool to which we can feed the packages and get the expalin plan result of all the queries.
Please advice
thanks
MaanasaHi Maanasa
Two things…
1) I’m not aware of any tool that does what you are looking for.
2) Do you use bind variables in your SQL statements. If yes, there is no way to accurately get the execution plans without executing them. In fact the query optimizer requires the bind variable values to produce an execution plan…
Hence, the advice of enabling SQL trace (either through the SQL_TRACE parameter or the DBMS_MONITOR package) is the best one.
HTH
Chris Antognini
Troubleshooting Oracle Performance, Apress 2008
http://top.antognini.ch -
Different execution plans for the same SQL query
Good afternoon,
My customer is sending an SQL query that goes slower after some time.
He has verified the exection plan, and this seems to change after some time.
At first (when the database has just been restarted), it looks like this:
Rows Row Source Operation
3 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE1> PARTITION: 1 1
22 NESTED LOOPS
3 VIEW
3 MINUS
14215 SORT UNIQUE
14215 NESTED LOOPS
14215 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
14215 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE2> PARTITION: 1 1
14215 INDEX UNIQUE SCAN <INDEX2> (object id 26024)
14212 SORT UNIQUE
14212 REMOTE
18 INDEX RANGE SCAN <INDEX1> (object id 25911)
After a while, this becomes:
Rows Row Source Operation
8 NESTED LOOPS
14218 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
8 VIEW
113744 MINUS
202151524 SORT UNIQUE
14218 NESTED LOOPS
14218 TABLE ACCESS FULL <TABLE1> PARTITION: 1 1
14218 TABLE ACCESS BY GLOBAL INDEX ROWID <TABLE2> PARTITION: 1 1
14218 INDEX UNIQUE SCAN <INDEX_2> (object id 26024)
202037780 SORT UNIQUE
14210 REMOTE
At regular intervals a "coalesce" of the <INDEX2> is scheduled.
Do you have any idea what might cause this different plans? (it's heavily impacting performance, because the second execution plan takes 5 times more time)
Thanks
Dominique
Edited by: scampsd on May 17, 2011 1:42 PMscampsd wrote:
Good afternoon,
My customer is sending an SQL query that goes slower after some time.
He has verified the exection plan, and this seems to change after some time.
At first (when the database has just been restarted), it looks like this:
At regular intervals a "coalesce" of the <INDEX2> is scheduled.
Do you have any idea what might cause this different plans? (it's heavily impacting performance, because the second execution plan takes 5 times more time)Something on your system is changing. Unfortunately if finding out what were easy you would have done it already
You have isolated a couple of things. What happends of you disable the index maintenance?
It is odd that performance as you described it degrands merely because of time the database has been up -
How to change the explain plan for currently running query?
Hi All,
I am using Oracle enterprise 9i edition. I have a query which frames dynamically and running in the database. I noticed a table with 31147758 rows
in the query which has no indexes and taking more time to process. I tried to create an INdex on that table. I know the query is already running with a FULL table scan. Is it possible to change the explain plan for the current running query to consider the INDEX?
[code]
SELECT /*+ USE_HASH (c,e,b,a) */
d.att_fcc extrt_prod_dim_id,
d.att_fcc compr_prod_dim_id,
a.glbl_uniq_id glbl_uniq_id,
to_date(c.dit_code,'RRRRMMDD')STRT_DT,
(to_date(c.dit_code,'RRRRMMDD')+150)END_DT,
a.pat_nbr pat_id,
a.rxer_id rxer_id,
e.rxer_geog_id rxer_geog_id,
a.pharmy_id pharmy_id,
a.pscr_pack_id pscr_pack_id,
a.dspnsd_pack_id dspnsd_pack_id,
DENSE_RANK () OVER (PARTITION BY a.pat_nbr ORDER BY c.dit_code) daterank,
COUNT( DISTINCT d.att_fcc ) OVER (PARTITION BY a.pat_nbr, c.dit_code) event_cnt
DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
d.att_fcc
ORDER BY c.dit_code) prodrank,
DENSE_RANK () OVER (PARTITION BY a.pat_nbr,
d.att_fcc
ORDER BY c.dit_code DESC) stoprank
FROM
pd_dimitems c,
pd_pack_attribs d ,
lrx_tmp_rxer_geog e,
lrx_tmp_pat_daterank p,
lrx_tmp_valid_fact_link a
WHERE c.dit_id = a.tm_id
AND e.rxer_id = a.rxer_id
AND a.glbl_uniq_id = p.glbl_uniq_id
AND p.daterank > 1
AND a.pscr_pack_id = d.att_dit_id
[/code]
The table lrx_tmp_pat_daterank is having that 31147758 rows. So I am wondering how to make the query to use the newly created index on the table?Why do you think using Indexes will improve the performance of the query? How many rows this query is returning? Optimizer might chose a Full table scan when it finds out that Index plan might not be useful. Why are you using /*+ USE_HASH (c,e,b,a) */ hint? This Hint will force oracle to use Full table scan instead of using the index. Try removing it and see if the plan changes.
Regards, -
How to find Explain Plan for a large querry which has multiple sub querries
Hi All,
I have a Package which has many procedures and one of the procedure has a cursor which is like 2000 lines. This cursor has a main select statement which again has many select statements in it.
Now how do I do the explain plan for the main select statement?
If it can be done easier way in toad(or SQLPLUS), please tell me...When your query takes too long ...
-
Explain plan for Query performance
Hi Gurus,
I need to improve the performance of a procedure. The procedure has the below QUery. I dont have Idea on how to imrpove the perf by seeing the explain plan. Can anyone please help me to explain where I need to change the code.
The below are the code and Explain plan for the same.
-----------Code----------------------------
SELECT IV_STORECODE AS STORECODE,
TO_CHAR(RD.ITEMCODE) AS ITEMCODE,
C.ITEMCATEGORYNAME,
ISUB.ITEMSUBCATEGORY1NAME
FROM RECEIPTS R
INNER JOIN RECEIPTDETAILS RD
ON R.RECEIPTID = RD.RECEIPTID
INNER JOIN ITEMCOMPANY IC
ON IC.ITEMCODE = RD.ITEMCODE
INNER JOIN ITEMCATEGORY C
ON IC.ITEMCATEGORY = C.ITEMCATEGORYID
LEFT OUTER JOIN ITEMSUBCATEGORY1 ISUB
ON ISUB.ITEMSUBCATEGORY1ID = IC.ITEMSUBCATEGORY1
AND ISUB.ITEMSUBCATEGORY1ID IN
(SELECT ITEMSUBCATEGORY1ID
FROM ITEMSUBCATEGORY1
WHERE ITEMCATEGORYID = IV_ITEMCATEGORY)
INNER JOIN STORE SE
ON SE.STORECODE = R.STORECODE
WHERE R.STORECODE = IV_STORECODE
AND SE.HOSPITALID = IV_HOSPITALID
AND TRUNC(R.CREATEDDATE) BETWEEN V_FROMDATE AND
V_TODATE
AND R.STATUSID NOT IN (99, 5)
AND
(IV_DRUGTYPE IS NULL OR
IC.DRUGTYPECATEGORYID = IV_DRUGTYPE)
UNION
SELECT IV_STORECODE AS STORECODE,
TO_CHAR(STD.ITEMCODE) AS ITEMCODE,
C.ITEMCATEGORYNAME,
ISUB.ITEMSUBCATEGORY1NAME
FROM STOCKTRANSACTION ST
INNER JOIN STOCKTRANSACTIONDETAILS STD
ON ST.STOCKTRANSACTIONID = STD.STOCKTRANSACTIONID
INNER JOIN ITEMCOMPANY IC
ON IC.ITEMCODE = STD.ITEMCODE
INNER JOIN ITEMCATEGORY C
ON IC.ITEMCATEGORY = C.ITEMCATEGORYID
LEFT OUTER JOIN ITEMSUBCATEGORY1 ISUB
ON ISUB.ITEMSUBCATEGORY1ID = IC.ITEMSUBCATEGORY1
AND ISUB.ITEMSUBCATEGORY1ID IN
(SELECT ITEMSUBCATEGORY1ID
FROM ITEMSUBCATEGORY1
WHERE ITEMCATEGORYID = IV_ITEMCATEGORY)
INNER JOIN STORE SE
ON SE.STORECODE = ST.STORECODE
WHERE ST.STORECODE = IV_STORECODE
AND SE.HOSPITALID = IV_HOSPITALID
AND TRUNC(ST.CREATEDDATE) BETWEEN V_FROMDATE AND
V_TODATE
AND ST.STATUS <> 99
AND STD.ITEMCODE NOT LIKE '%#%'
AND
(IV_DRUGTYPE IS NULL OR
IC.DRUGTYPECATEGORYID = IV_DRUGTYPE)
UNION
SELECT D.STORECODE,
TO_CHAR(D.ITEMCODE) AS ITEMCODE,
C.ITEMCATEGORYNAME,
ISUB.ITEMSUBCATEGORY1NAME
FROM DAILYINVENTORY D
INNER JOIN ITEMCOMPANY IC
ON IC.ITEMCODE = D.ITEMCODE
INNER JOIN ITEMCATEGORY C
ON IC.ITEMCATEGORY = C.ITEMCATEGORYID
LEFT OUTER JOIN ITEMSUBCATEGORY1 ISUB
ON ISUB.ITEMSUBCATEGORY1ID = IC.ITEMSUBCATEGORY1
AND ISUB.ITEMSUBCATEGORY1ID IN
(SELECT ITEMSUBCATEGORY1ID
FROM ITEMSUBCATEGORY1
WHERE ITEMCATEGORYID = IV_ITEMCATEGORY)
INNER JOIN STORE SE
ON SE.STORECODE = D.STORECODE
WHERE D.STORECODE = IV_STORECODE
AND SE.HOSPITALID = IV_HOSPITALID
AND TRUNC(D.UPDATEDDATE) <= V_TODATE
AND D.QTY > 0
AND D.ITEMCODE NOT LIKE '%#%'
AND C.ITEMCATEGORYID = IV_ITEMCATEGORY
AND (IV_DRUGTYPE IS NULL OR
IC.DRUGTYPECATEGORYID = IV_DRUGTYPE)
AND (IV_SUBITEMCATEGORY IS NULL OR
ISUB.ITEMSUBCATEGORY1ID = IV_SUBITEMCATEGORY) Will post the explain plan ..
Thanks in advance..Ensure you also include all the other information people will need to help you, e.g. database version, table structures/relationships and cardinalities, row counts etc.
See the two threads linked to in the FAQ: {message:id=9360003} -
Hi,
For getting the explain plan for a query, we use the statement
"explain plan for " + Query
Similarly, to get an explain plan for a procedure, do we have any way like
"explain plan for " + "Execute " + Procedure
How do we get an explain plan for a procedure that is executed
Thanks in Advance.teckfreak wrote:
Hi Robert,
I am working on an utility application which will execute the procedure and show the explain plan to the user for him to analyze the explain plan and take necessary steps for optimization. I am showing the Procedure inputs to the user, allowing him to enter values and taking them and executing the procedure. I am setting the trace and extracting the explain plan for the procedure using TKPROF utility and showing it to the user.
While doing so, the trace file is stored in udump folder. I am accessing the trace file from TKPROF utility. I am able to run the TKPROF from the command prompt. But if I try automating the TKPROF command in a .NET application using Process.Start, it says "Not able to access the file.". I tried giving full permissions to Everyone and it still throws the error. Kindly guide me how to proceed.. A different approach that you might want to consider (as indicated by William):
- Flush the shared pool and use a unique MODULE description for each execution of your procedure (e.g. using DBMS_APPLICATION_INFO.SET_MODULE), e.g. using a logon trigger
- Query V$SQL for your unique MODULE description and run DBMS_XPLAN.DISPLAY_CURSOR for each corresponding child cursor found (SQL_ID + CHILD_NUMBER) in the shared pool. This plan generation could be automated using a procedure
The result of this approach corresponds to the tracing using TKPROF since it will provide the actual execution plans used at runtime rather than separate EXPLAIN PLAN results which might differ from the actual plans.
This assumes that your shared pool is sufficiently large to hold all the child cursor created by your procedure without aging them out while the procedure is running. It's probably also only applicable to an environment where not too much work is being done while running this test and the recommended flushing of the shared pool.
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/ -
Explain plan left the building
Hello guys, i have interesting problem, at least it seemed to me like that.
I am on 10.2.0.4.0 and for every statement i do explain plan i get the same plan ???.
Propably very known issue to some, but i didn't exeperienced that till now, so if somene have some advice, please share.
E.g.
SQL> explain plan for select user from dual;
Explained.
SQL> select * from table(dbms_xplan.display);
Plan hash value: 3995103059
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |
| 0 | SELECT STATEMENT REMOTE | | 1 | 96 | 97591 (5)| 00:05:07 | |
| 1 | SORT ORDER BY | | 1 | 96 | 97591 (5)| 00:05:07 | |
|* 2 | TABLE ACCESS BY INDEX ROWID| CCONTACT_ALL | 1 | 54 | 3 (0)| 00:00:01 | VIPBS~ |
| 3 | NESTED LOOPS | | 1 | 96 | 97590 (5)| 00:05:07 | |
|* 4 | TABLE ACCESS FULL | CUSTOMER_ALL | 1 | 42 | 97587 (5)| 00:05:07 | VIPBS~ |
|* 5 | INDEX RANGE SCAN | PKCCONTACT_ALL | 1 | | 2 (0)| 00:00:01 | VIPBS~ |
Predicate Information (identified by operation id):
2 - filter("A1"."CCCONTRACT"='X')
4 - filter((TO_NUMBER("A2"."CSCOMPTAXNO")=3007943362918 OR
TO_NUMBER("A2"."PASSPORTNO")=0109965330447) AND (TO_NUMBER("A2"."CSLEVEL")=10 OR
TO_NUMBER("A2"."CSLEVEL")=20 AND "A2"."TMCODE"<>59 AND "A2"."TMCODE"<>42 AND "A2"."TMCODE"<>61
AND "A2"."TMCODE"<>11 AND "A2"."TMCODE"<>19) AND "A2"."CSTYPE"='a' AND "A2"."PAYMNTRESP"='X')
5 - access("A1"."CUSTOMER_ID"="A2"."CUSTOMER_ID")
filter("A1"."CUSTOMER_ID"<>0)
Note
- 'PLAN_TABLE' is old version
- fully remote statement
28 rows selected....so, it looks like i am doing all that just with select user from dual .... : ) ... ok
SQL> explain plan for
2 SELECT param_value
3 FROM ncis.cis_case_script_vars
4 WHERE case_id = 296645706 AND seq = 1 AND param_name = 'OHOPNAMT';
Explained.
SQL> select * from table(dbms_xplan.display);
Plan hash value: 3995103059
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |
| 0 | SELECT STATEMENT REMOTE | | 1 | 96 | 97591 (5)| 00:05:07 | |
| 1 | SORT ORDER BY | | 1 | 96 | 97591 (5)| 00:05:07 | |
|* 2 | TABLE ACCESS BY INDEX ROWID| CCONTACT_ALL | 1 | 54 | 3 (0)| 00:00:01 | VIPBS~ |
| 3 | NESTED LOOPS | | 1 | 96 | 97590 (5)| 00:05:07 | |
|* 4 | TABLE ACCESS FULL | CUSTOMER_ALL | 1 | 42 | 97587 (5)| 00:05:07 | VIPBS~ |
|* 5 | INDEX RANGE SCAN | PKCCONTACT_ALL | 1 | | 2 (0)| 00:00:01 | VIPBS~ |
Predicate Information (identified by operation id):
2 - filter("A1"."CCCONTRACT"='X')
4 - filter((TO_NUMBER("A2"."CSCOMPTAXNO")=3007943362918 OR
TO_NUMBER("A2"."PASSPORTNO")=0109965330447) AND (TO_NUMBER("A2"."CSLEVEL")=10 OR
TO_NUMBER("A2"."CSLEVEL")=20 AND "A2"."TMCODE"<>59 AND "A2"."TMCODE"<>42 AND "A2"."TMCODE"<>61
AND "A2"."TMCODE"<>11 AND "A2"."TMCODE"<>19) AND "A2"."CSTYPE"='a' AND "A2"."PAYMNTRESP"='X')
5 - access("A1"."CUSTOMER_ID"="A2"."CUSTOMER_ID")
filter("A1"."CUSTOMER_ID"<>0)
Note
- 'PLAN_TABLE' is old version
- fully remote statement
28 rows selected.
SQL>..same plan for different sql...
..and now, i am trying to explain plan for several easy sqls but look...
SQL> explain plan for select * from all_objects where rownum < 2;
explain plan for select * from all_objects where rownum < 2
ERROR at line 1:
ORA-01039: insufficient privileges on underlying objects of the view
SQL> explain plan for select * from user_tables ;
explain plan for select * from user_tables
ERROR at line 1:
ORA-01039: insufficient privileges on underlying objects of the view
SQL> desc all_objects
Name Null? Type
OWNER NOT NULL VARCHAR2(30)
OBJECT_NAME NOT NULL VARCHAR2(30)
SUBOBJECT_NAME VARCHAR2(30)
OBJECT_ID NOT NULL NUMBER
DATA_OBJECT_ID NUMBER
OBJECT_TYPE VARCHAR2(19)
CREATED NOT NULL DATE
LAST_DDL_TIME NOT NULL DATE
TIMESTAMP VARCHAR2(19)
STATUS VARCHAR2(7)
TEMPORARY VARCHAR2(1)
GENERATED VARCHAR2(1)
SECONDARY VARCHAR2(1)...i can't figure this out... maybe i have to flush 'explain plan' ? it's ok if it sounds funny,im off with ideas..
then i tried to explain this sql:
SQL> explain plan for
2 SELECT param_value
3 FROM ncis.cis_case_script_vars
4 WHERE case_id = 296645706 AND seq = 1 AND param_name = 'OHOPNAMT';
Explained.
SQL> select * from table(dbms_xplan.display);
Plan hash value: 3995103059
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |
| 0 | SELECT STATEMENT REMOTE | | 1 | 96 | 97591 (5)| 00:05:07 | |
| 1 | SORT ORDER BY | | 1 | 96 | 97591 (5)| 00:05:07 | |
|* 2 | TABLE ACCESS BY INDEX ROWID| CCONTACT_ALL | 1 | 54 | 3 (0)| 00:00:01 | VIPBS~ |
| 3 | NESTED LOOPS | | 1 | 96 | 97590 (5)| 00:05:07 | |
|* 4 | TABLE ACCESS FULL | CUSTOMER_ALL | 1 | 42 | 97587 (5)| 00:05:07 | VIPBS~ |
|* 5 | INDEX RANGE SCAN | PKCCONTACT_ALL | 1 | | 2 (0)| 00:00:01 | VIPBS~ |
Predicate Information (identified by operation id):
2 - filter("A1"."CCCONTRACT"='X')
4 - filter((TO_NUMBER("A2"."CSCOMPTAXNO")=3007943362918 OR
TO_NUMBER("A2"."PASSPORTNO")=0109965330447) AND (TO_NUMBER("A2"."CSLEVEL")=10 OR
TO_NUMBER("A2"."CSLEVEL")=20 AND "A2"."TMCODE"<>59 AND "A2"."TMCODE"<>42 AND "A2"."TMCODE"<>61
AND "A2"."TMCODE"<>11 AND "A2"."TMCODE"<>19) AND "A2"."CSTYPE"='a' AND "A2"."PAYMNTRESP"='X')
5 - access("A1"."CUSTOMER_ID"="A2"."CUSTOMER_ID")
filter("A1"."CUSTOMER_ID"<>0)
Note
- 'PLAN_TABLE' is old version
- fully remote statement
28 rows selected.
SQL>..and got the same plan again....
anyone with suggestons, anyone encountered this behaviour ?Vili Dialis wrote:
Is there some way to force usage of one of them explicitly, how can i know which one is currently used ?
So what happend here ?
I am using what plan table of the above, and why that table generates always the same plan ?
*/To bypass the problem (probably), and to see how it happened (possibly) see http://jonathanlewis.wordpress.com/2010/01/25/old-plan_table/
Not sure why you keep getting the same plan, but dbms_xplan does a 'select where plan_id = (select max(plan_id) ..) so perhaps the plan_table(s) you keep using have an artificially high plan_id which is always getting selected. (You could try doing: delete from plan_table ; commit; )
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
A general reminder about "Forum Etiquette / Reward Points": http://forums.oracle.com/forums/ann.jspa?annID=718
If you never mark your questions as answered people will eventually decide that it's not worth trying to answer you because they will never know whether or not their answer has been of any use, or whether you even bothered to read it.
It is also important to mark answers that you thought helpful - again it lets other people know that you appreciate their help, but it also acts as a pointer for other people when they are researching the same question, moreover it means that when you mark a bad or wrong answer as helpful someone may be prompted to tell you (and the rest of the forum) what's so bad or wrong about the answer you found helpful. -
How Explain Plan Calculates the Bytes
Hi All,
I am using Oracle 10g edition 10.2.0.3.0.
Here I have a table and an explain plan. Explain plan shows Bytes = 50, Cost = 1 and %CPU = 0. I would like to know,
1) How bytes are calculcated?
2) What "Cost = 1" means?
3) What "%CPU = 0 means?
SQL> desc t_pdur_insulin_prof
Name
SAK_RECIP NOT NULL NUMBER(9)
SAK_CLAIM NOT NULL NUMBER(9)
SAK_DRUG NOT NULL NUMBER(9)
DTE_DISPENSE NOT NULL NUMBER(8)
CDE_PROF_TYPE NOT NULL CHAR(1)
SQL> explain plan for
2 select * from t_pdur_insulin_prof
3 where sak_recip = 10013819;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 438947110
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 50 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_PDUR_INSULIN_PROF | 2 | 50 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("SAK_RECIP"=10013819)
13 rows selected.
Thanks!user2081225 wrote:
Hi All,
I am using Oracle 10g edition 10.2.0.3.0.
Here I have a table and an explain plan. Explain plan shows Bytes = 50, Cost = 1 and %CPU = 0. I would like to know,
1) How bytes are calculcated?
2) What "Cost = 1" means?
3) What "%CPU = 0 means?
SQL> desc t_pdur_insulin_prof
Name
SAK_RECIP NOT NULL NUMBER(9)
SAK_CLAIM NOT NULL NUMBER(9)
SAK_DRUG NOT NULL NUMBER(9)
DTE_DISPENSE NOT NULL NUMBER(8)
CDE_PROF_TYPE NOT NULL CHAR(1)
SQL> explain plan for
2 select * from t_pdur_insulin_prof
3 where sak_recip = 10013819;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 438947110
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 50 | 1 (0)| 00:00:01 |
|* 1 | INDEX RANGE SCAN| I_PDUR_INSULIN_PROF | 2 | 50 | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("SAK_RECIP"=10013819)
13 rows selected.
Thanks!consider Reading The Fine Manual
http://docs.oracle.com/cd/E11882_01/server.112/e16638/optimops.htm#sthref981 -
Quick way to look at explain plan for executing a package?
I can look at explain plans for queries without any problem. But i'm troubleshooting the performance of executing a package and i'm wondering if there is a way to look at what's happening without using EM tools? i.e. command lines.
for queries, i've used set autotrace on or explain plan for query...
but how do you do this for the execution of a package?Thanks for the reply..i've tried sql_trace=TRUE but somehow i don't get the execution plan..i only see the number of parses, executes and fetches...
e.g. in my tkprof output, i have:
one of the select statements is here
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 6 0 0
total 3 0.00 0.00 0 6 0 0
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 58 (recursive depth: 1)
But there is no execution plan..i've never done this when executing a package...what am i missing? this works fine for query statements..but not for packages.. -
Explain plan changing for the same sql
Hi All,
In a E Business suite application, we have the 10.2.0.4 Database.
One of the program is running a select stmt which is using different explain plan one in a month which is causing issue in the program running for longer time.
Ex : When it uses the index A, it is running fine. When it uses the index B, it is running for longer time.
Can you please advice on the possible reasons for the same sql to choose index B instead of index A some times.
Thanks,
RakeshIt could be that the SQL is question got aged out of the shared pool and when it came to be reparsed - the values in the bind variables were such that access via index b was more attractive than access via index a.
Could you please send the query and the good and bad plans and all other information that might help diagnose the problem..
Note: we had a similiar case where plans suddenly changed for no apperant reason (on 10.2.0.2) - we found that under certain circumstances the optimizer would not peek into the bind varaibles to derive the execution path. -
Hi,
I have a sql which is recently having a performance problems in Production. I have generated a explain plan for it trying to find out what it is doing but plan itself is close to 1000 lines. I want to check if there is any efficient way to go through big plan like this one and quickly find the damaging areas..
2) I also wanted to know if there is way to generate explain plans in HTML format which executed in past and have entry in dba_hist_sqltext.
3) I also have two sql_monitor reports which I want to compare. is there any efficient way to do it as well?
Please share your thoughts!
Thanks in advance!
Regards,
Suman-Hi,
I suggest you can try running sql advisor on the query maybe something fruitful comes up
http://www.oracle-base.com/articles/11g/sql-access-advisor-11gr1.php
I am not sure about the explain plan being printed in html format but
You may also want to try the sqlhistory.sql query from below page
http://evdbt.com/scripts/
I have used it many times to check on executions and explain plans which may have changed over the period
I have faced it many times , the query picks up a bad explain plan and performs poorly -
CBO generating different plans for the same data in similar Environments
Hi All
I have been trying to compare an SQL from 2 different but similar environments build of the same hardware specs .The issue I am facing is environment A, the query executes in less than 2 minutes with plan mostly showing full table scans and hash join whereas in environment B(problematic), it times out after 2 hours with an error of unable to extend table space . The statistics are up to date in both environments for both tables and indexes . System parameters are exactly similar(default oracle for except for multiblock_read_count ).
Both Environment have same db parameter for db_file_multiblock_read_count(16), optimizer(refer below),hash_area_size (131072),pga_aggregate_target(1G),db_block_size(8192) etc . SREADTIM, MREADTIM, CPUSPEED, MBRC are all null in aux_stats in both environment because workload was never collected i believe.
Attached is details about the SQL with table stats, SQL and index stats my main concern is CBO generating different plans for the similar data and statistics and same hardware and software specs. Is there any thing else I should consider .I generally see environment B being very slow and always plans tend to nested loops and index scan whereas what we really need is a sensible FTS in many cases. One of the very surprising thing is METER_CONFIG_HEADER below which has just 80 blocks of data is being asked for index scan.
show parameter optimizer
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
**Environment**
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for Solaris: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production
Note: : There are slight difference in the no of records in the attached sheet.However, I wanted to tell that i have tested with exact same data and was getting similar results but I couldn't retain the data untill collecting the details in the attachment
TEST1 COMPARE TABLE LEVE STATS used by CBO
ENVIRONMENT A
TABLE_NAME NUM_ROWS BLOCKS LAST_ANALYZED
ASSET 3607425 167760 5/02/2013 22:11
METER_CONFIG_HEADER 3658 80 5/01/2013 0:07
METER_CONFIG_ITEM 32310 496 5/01/2013 0:07
NMI 1899024 33557 18/02/2013 10:55
REGISTER 4830153 101504 18/02/2013 9:57
SDP_LOGICAL_ASSET 1607456 19137 18/02/2013 15:48
SDP_LOGICAL_REGISTER 5110781 78691 18/02/2013 9:56
SERVICE_DELIVERY_POINT 1425890 42468 18/02/2013 13:54
ENVIRONMENT B
TABLE_NAME NUM_ROWS BLOCKS LAST_ANALYZED
ASSET 4133939 198570 16/02/2013 10:02
METER_CONFIG_HEADER 3779 80 16/02/2013 10:55
METER_CONFIG_ITEM 33720 510 16/02/2013 10:55
NMI 1969000 33113 16/02/2013 10:58
REGISTER 5837874 120104 16/02/2013 11:05
SDP_LOGICAL_ASSET 1788152 22325 16/02/2013 11:06
SDP_LOGICAL_REGISTER 6101934 91088 16/02/2013 11:07
SERVICE_DELIVERY_POINT 1447589 43804 16/02/2013 11:11
TEST ITEM 2 COMPARE INDEX STATS used by CBO
ENVIRONMENT A
TABLE_NAME INDEX_NAME UNIQUENESS BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR NUM_ROWS
ASSET IDX_AST_DEVICE_CATEGORY_SK NONUNIQUE 2 9878 67 147 12982 869801 3553095
ASSET IDX_A_SAPINTLOGDEV_SK NONUNIQUE 2 7291 2747 2 639 1755977 3597916
ASSET SYS_C00102592 UNIQUE 2 12488 3733831 1 1 3726639 3733831
METER_CONFIG_HEADER SYS_C0092052 UNIQUE 1 12 3670 1 1 3590 3670
METER_CONFIG_ITEM SYS_C0092074 UNIQUE 1 104 32310 1 1 32132 32310
NMI IDX_NMI_ID NONUNIQUE 2 6298 844853 1 2 1964769 1965029
NMI IDX_NMI_ID_NK NONUNIQUE 2 6701 1923072 1 1 1922831 1923084
NMI IDX_NMI_STATS NONUNIQUE 1 106 4 26 52 211 211
REGISTER REG_EFFECTIVE_DTM NONUNIQUE 2 12498 795 15 2899 2304831 4711808
REGISTER SYS_C00102653 UNIQUE 2 16942 5065660 1 1 5056855 5065660
SDP_LOGICAL_ASSET IDX_SLA_SAPINTLOGDEV_SK NONUNIQUE 2 3667 1607968 1 1 1607689 1607982
SDP_LOGICAL_ASSET IDX_SLA_SDP_SK NONUNIQUE 2 3811 668727 1 2 1606204 1607982
SDP_LOGICAL_ASSET SYS_C00102665 UNIQUE 2 5116 1529606 1 1 1528136 1529606
SDP_LOGICAL_REGISTER SYS_C00102677 UNIQUE 2 17370 5193638 1 1 5193623 5193638
SERVICE_DELIVERY_POINT IDX_SDP_NMI_SK NONUNIQUE 2 4406 676523 1 2 1423247 1425890
SERVICE_DELIVERY_POINT IDX_SDP_SAP_INT_NMI_SK NONUNIQUE 2 7374 676523 1 2 1458238 1461108
SERVICE_DELIVERY_POINT SYS_C00102687 UNIQUE 2 4737 1416207 1 1 1415022 1416207
ENVIRONMENT B
TABLE_NAME INDEX_NAME UNIQUENESS BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR NUM_ROWS
ASSET IDX_AST_DEVICE_CATEGORY_SK NONUNIQUE 2 8606 121 71 16428 1987833 4162257
ASSET IDX_A_SAPINTLOGDEV_SK NONUNIQUE 2 8432 1780146 1 1 2048170 4162257
ASSET SYS_C00116157 UNIQUE 2 13597 4162263 1 1 4158759 4162263
METER_CONFIG_HEADER SYS_C00116570 UNIQUE 1 12 3779 1 1 3734 3779
METER_CONFIG_ITEM SYS_C00116592 UNIQUE 1 107 33720 1 1 33459 33720
NMI IDX_NMI_ID NONUNIQUE 2 6319 683370 1 2 1970460 1971313
NMI IDX_NMI_ID_NK NONUNIQUE 2 6597 1971293 1 1 1970771 1971313
NMI IDX_NMI_STATS NONUNIQUE 1 98 48 2 4 196 196
REGISTER REG_EFFECTIVE_DTM NONUNIQUE 2 15615 1273 12 2109 2685924 5886582
REGISTER SYS_C00116748 UNIQUE 2 19533 5886582 1 1 5845565 5886582
SDP_LOGICAL_ASSET IDX_SLA_SAPINTLOGDEV_SK NONUNIQUE 2 4111 1795084 1 1 1758441 1795130
SDP_LOGICAL_ASSET IDX_SLA_SDP_SK NONUNIQUE 2 4003 674249 1 2 1787987 1795130
SDP_LOGICAL_ASSET SYS_C004520 UNIQUE 2 5864 1795130 1 1 1782147 1795130
SDP_LOGICAL_REGISTER SYS_C004539 UNIQUE 2 20413 6152850 1 1 6073059 6152850
SERVICE_DELIVERY_POINT IDX_SDP_NMI_SK NONUNIQUE 2 3227 660649 1 2 1422572 1447803
SERVICE_DELIVERY_POINT IDX_SDP_SAP_INT_NMI_SK NONUNIQUE 2 6399 646257 1 2 1346948 1349993
SERVICE_DELIVERY_POINT SYS_C00128706 UNIQUE 2 4643 1447946 1 1 1442796 1447946
TEST ITEM 3 COMPARE PLANS
ENVIRONMENT A
Plan hash value: 4109575732
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 13 | 2067 | | 135K (2)| 00:27:05 |
| 1 | HASH UNIQUE | | 13 | 2067 | | 135K (2)| 00:27:05 |
|* 2 | HASH JOIN | | 13 | 2067 | | 135K (2)| 00:27:05 |
|* 3 | HASH JOIN | | 6 | 900 | | 135K (2)| 00:27:04 |
|* 4 | HASH JOIN ANTI | | 1 | 137 | | 135K (2)| 00:27:03 |
|* 5 | TABLE ACCESS BY INDEX ROWID| NMI | 1 | 22 | | 5 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 131 | | 95137 (2)| 00:19:02 |
|* 7 | HASH JOIN | | 1 | 109 | | 95132 (2)| 00:19:02 |
|* 8 | TABLE ACCESS FULL | ASSET | 36074 | 1021K| | 38553 (2)| 00:07:43 |
|* 9 | HASH JOIN | | 90361 | 7059K| 4040K| 56578 (2)| 00:11:19 |
|* 10 | HASH JOIN | | 52977 | 3414K| 2248K| 50654 (2)| 00:10:08 |
|* 11 | HASH JOIN | | 39674 | 1782K| | 40101 (2)| 00:08:02 |
|* 12 | TABLE ACCESS FULL | REGISTER | 39439 | 1232K| | 22584 (2)| 00:04:32 |
|* 13 | TABLE ACCESS FULL | SDP_LOGICAL_REGISTER | 4206K| 56M| | 17490 (2)| 00:03:30 |
|* 14 | TABLE ACCESS FULL | SERVICE_DELIVERY_POINT | 675K| 12M| | 9412 (2)| 00:01:53 |
|* 15 | TABLE ACCESS FULL | SDP_LOGICAL_ASSET | 1178K| 15M| | 4262 (2)| 00:00:52 |
|* 16 | INDEX RANGE SCAN | IDX_NMI_ID_NK | 2 | | | 2 (0)| 00:00:01 |
| 17 | VIEW | | 39674 | 232K| | 40101 (2)| 00:08:02 |
|* 18 | HASH JOIN | | 39674 | 1046K| | 40101 (2)| 00:08:02 |
|* 19 | TABLE ACCESS FULL | REGISTER | 39439 | 500K| | 22584 (2)| 00:04:32 |
|* 20 | TABLE ACCESS FULL | SDP_LOGICAL_REGISTER | 4206K| 56M| | 17490 (2)| 00:03:30 |
|* 21 | TABLE ACCESS FULL | METER_CONFIG_HEADER | 3658 | 47554 | | 19 (0)| 00:00:01 |
|* 22 | TABLE ACCESS FULL | METER_CONFIG_ITEM | 7590 | 68310 | | 112 (2)| 00:00:02 |
Predicate Information (identified by operation id):
2 - access("METER_CONFIG_HEADER_SK"="METER_CONFIG_HEADER_SK")
3 - access("NETWORK_TARIFF_CD"="NETWORK_TARIFF_CD")
4 - access("SERVICE_DELIVERY_POINT_SK"="TMP"."SERVICE_DELIVERY_POINT_SK")
5 - filter("ROW_CURRENT_IND"='Y' AND ("NMI_STATUS_CD"='A' OR "NMI_STATUS_CD"='D'))
7 - access("ASSET_CD"="EQUIP_CD" AND "SAP_INT_LOG_DEVICE_SK"="SAP_INT_LOG_DEVICE_SK")
8 - filter("ROW_CURRENT_IND"='Y')
9 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")
10 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")
11 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")
12 - filter("REGISTER_TYPE_CD"='C' AND (SUBSTR("REGISTER_ID_CD",1,1)='4' OR
SUBSTR("REGISTER_ID_CD",1,1)='5' OR SUBSTR("REGISTER_ID_CD",1,1)='6') AND "ROW_CURRENT_IND"='Y')
13 - filter("ROW_CURRENT_IND"='Y')
14 - filter("ROW_CURRENT_IND"='Y')
15 - filter("ROW_CURRENT_IND"='Y')
16 - access("NMI_SK"="NMI_SK")
18 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")
19 - filter("REGISTER_TYPE_CD"='C' AND (SUBSTR("REGISTER_ID_CD",1,1)='1' OR
SUBSTR("REGISTER_ID_CD",1,1)='2' OR SUBSTR("REGISTER_ID_CD",1,1)='3') AND "ROW_CURRENT_IND"='Y')
20 - filter("ROW_CURRENT_IND"='Y')
21 - filter("ROW_CURRENT_IND"='Y')
22 - filter("ROW_CURRENT_IND"='Y' AND "CONROL_REGISTER"='X')
ENVIRONMENT B
Plan hash value: 2826260434
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 181 | 103K (2)| 00:20:47 |
| 1 | HASH UNIQUE | | 1 | 181 | 103K (2)| 00:20:47 |
|* 2 | HASH JOIN ANTI | | 1 | 181 | 103K (2)| 00:20:47 |
|* 3 | HASH JOIN | | 1 | 176 | 56855 (2)| 00:11:23 |
|* 4 | HASH JOIN | | 1 | 163 | 36577 (2)| 00:07:19 |
|* 5 | TABLE ACCESS BY INDEX ROWID | ASSET | 1 | 44 | 4 (0)| 00:00:01 |
| 6 | NESTED LOOPS | | 1 | 131 | 9834 (2)| 00:01:59 |
| 7 | NESTED LOOPS | | 1 | 87 | 9830 (2)| 00:01:58 |
| 8 | NESTED LOOPS | | 1 | 74 | 9825 (2)| 00:01:58 |
|* 9 | HASH JOIN | | 1 | 52 | 9820 (2)| 00:01:58 |
|* 10 | TABLE ACCESS BY INDEX ROWID| METER_CONFIG_HEADER | 1 | 14 | 1 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 33 | 116 (2)| 00:00:02 |
|* 12 | TABLE ACCESS FULL | METER_CONFIG_ITEM | 1 | 19 | 115 (2)| 00:00:02 |
|* 13 | INDEX RANGE SCAN | SYS_C00116570 | 1 | | 1 (0)| 00:00:01 |
|* 14 | TABLE ACCESS FULL | SERVICE_DELIVERY_POINT | 723K| 13M| 9699 (2)| 00:01:57 |
|* 15 | TABLE ACCESS BY INDEX ROWID | NMI | 1 | 22 | 5 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | IDX_NMI_ID_NK | 2 | | 2 (0)| 00:00:01 |
|* 17 | TABLE ACCESS BY INDEX ROWID | SDP_LOGICAL_ASSET | 1 | 13 | 5 (0)| 00:00:01 |
|* 18 | INDEX RANGE SCAN | IDX_SLA_SDP_SK | 2 | | 2 (0)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | IDX_A_SAPINTLOGDEV_SK | 2 | | 2 (0)| 00:00:01 |
|* 20 | TABLE ACCESS FULL | REGISTER | 76113 | 2378K| 26743 (2)| 00:05:21 |
|* 21 | TABLE ACCESS FULL | SDP_LOGICAL_REGISTER | 5095K| 63M| 20245 (2)| 00:04:03 |
| 22 | VIEW | | 90889 | 443K| 47021 (2)| 00:09:25 |
|* 23 | HASH JOIN | | 90889 | 2307K| 47021 (2)| 00:09:25 |
|* 24 | TABLE ACCESS FULL | REGISTER | 76113 | 966K| 26743 (2)| 00:05:21 |
|* 25 | TABLE ACCESS FULL | SDP_LOGICAL_REGISTER | 5095K| 63M| 20245 (2)| 00:04:03 |
Predicate Information (identified by operation id):
2 - access("SERVICE_DELIVERY_POINT_SK"="TMP"."SERVICE_DELIVERY_POINT_SK")
3 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK" AND
"SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")
4 - access("ASSET_CD"="EQUIP_CD")
5 - filter("ROW_CURRENT_IND"='Y')
9 - access("NETWORK_TARIFF_CD"="NETWORK_TARIFF_CD")
10 - filter("ROW_CURRENT_IND"='Y')
12 - filter("ROW_CURRENT_IND"='Y' AND "CONROL_REGISTER"='X')
13 - access("METER_CONFIG_HEADER_SK"="METER_CONFIG_HEADER_SK")
14 - filter("ROW_CURRENT_IND"='Y')
15 - filter("ROW_CURRENT_IND"='Y' AND ("NMI_STATUS_CD"='A' OR "NMI_STATUS_CD"='D'))
16 - access("NMI_SK"="NMI_SK")
17 - filter("ROW_CURRENT_IND"='Y')
18 - access("SERVICE_DELIVERY_POINT_SK"="SERVICE_DELIVERY_POINT_SK")
19 - access("SAP_INT_LOG_DEVICE_SK"="SAP_INT_LOG_DEVICE_SK")
20 - filter((SUBSTR("REGISTER_ID_CD",1,1)='4' OR SUBSTR("REGISTER_ID_CD",1,1)='5' OR
SUBSTR("REGISTER_ID_CD",1,1)='6') AND "REGISTER_TYPE_CD"='C' AND "ROW_CURRENT_IND"='Y')
21 - filter("ROW_CURRENT_IND"='Y')
23 - access("SAP_INT_LOGICAL_REGISTER_SK"="SAP_INT_LOGICAL_REGISTER_SK")
24 - filter((SUBSTR("REGISTER_ID_CD",1,1)='1' OR SUBSTR("REGISTER_ID_CD",1,1)='2' OR
SUBSTR("REGISTER_ID_CD",1,1)='3') AND "REGISTER_TYPE_CD"='C' AND "ROW_CURRENT_IND"='Y')
25 - filter("ROW_CURRENT_IND"='Y')Edited by: abhilash173 on Feb 24, 2013 9:16 PM
Edited by: abhilash173 on Feb 24, 2013 9:18 PMHi Paul,
I misread your question initially .The system stats are outdated in both ( same result as seen from aux_stats) .I am not a DBA and do not have access to gather system stats fresh.
select * from sys.aux_stats$
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS NULL COMPLETED
SYSSTATS_INFO DSTART NULL 02-16-2011 15:24
SYSSTATS_INFO DSTOP NULL 02-16-2011 15:24
SYSSTATS_INFO FLAGS 1 NULL
SYSSTATS_MAIN CPUSPEEDNW 1321.20523 NULL
SYSSTATS_MAIN IOSEEKTIM 10 NULL
SYSSTATS_MAIN IOTFRSPEED 4096 NULL
SYSSTATS_MAIN SREADTIM NULL NULL
SYSSTATS_MAIN MREADTIM NULL NULL
SYSSTATS_MAIN CPUSPEED NULL NULL
SYSSTATS_MAIN MBRC NULL NULL
SYSSTATS_MAIN MAXTHR NULL NULL
SYSSTATS_MAIN SLAVETHR NULL NULL
Maybe you are looking for
-
Hi I have java packet with code that connects to a Oracle database (jdbc connection) which failes using BPM 10g studio. Executing this as a java main program from prompt (using same libs and same jre as in STUDIO), works Code looks like.. SolutionOff
-
I was wondering if I could use iweb to set up a web site, but I want the address to be just a basic ".com" address. (without the .mac// stuff) Can I do this with a .mac account, or do I need to use a different web hosting company?
-
Efficient method to save data to disk in RT?
What options are available to read data from a buffer and save it to the hard disk drive in RT? What method requires the least processor overhead...or perhaps can be set to run in the background without any processor intervention at all?
-
My install of maverick failed as disk is damaged and cannot repaired. I tried to erase disk but got error disk cannot be unmounted. Please help. What can i do? Thank you very much.
-
Hi All I have written a RFC. I have a input as a char(25). I would like to raise an exception with <error message> + <input> for instance ERROR IN THE STRING <INPUT STRING> How can I do ? Thanks for your help Jerome