Query plan shows Cost: 0 Bytes: 851 Cardinality: 1

Hi,
Customer running 10.2.0.4 on linux 64 bit.
Explain plan shows:
SELECT STATEMENT ALL_ROWS Cost: 0 Bytes: 851 Cardinality: 1
8 FILTER
7 SORT ORDER BY Bytes: 851 Cardinality: 1
6 HASH JOIN OUTER Cost: 2,873,137 Bytes: 5,047,622,251 Cardinality: 5,931,401
4 HASH JOIN Cost: 1,696,501 Bytes: 4,567,178,770 Cardinality: 5,931,401
1 TABLE ACCESS FULL TABLE LIVE.INSTRUMENT Cost: 212,073 Bytes: 679,589,280 Cardinality: 1,595,280
3 PARTITION RANGE ALL Cost: 764,856 Bytes: 2,040,401,944 Cardinality: 5,931,401 Partition #: 6 Partitions accessed #1 - #27
2 TABLE ACCESS FULL TABLE LIVE.DEALTRANS Cost: 764,856 Bytes: 2,040,401,944 Cardinality: 5,931,401 Partition #: 6 Partitions accessed #1 - #27
5 TABLE ACCESS FULL TABLE LIVE.SMDBINSTRUMENT Cost: 1,169 Bytes: 4,958,172 Cardinality: 61,212
I understand that explain plans can be unreliable but:
1) why does cost show as 0? Its obviously much higher. Is there just not enough room?
2) why a cardinality of 1?
Thanks in advance,
Steve

Hi Someoneelse,
Not sure, i have a query into the client.
Thanks for responding.
Steve

Similar Messages

Benefits: Health plans show costs with bi-weekly rates in Enrollment screen

Hello,
I have created 2 new health plans. During testing, I noticed when trying to enroll employees via the Enrollment screen, the plan options show costs with bi-weekly rates rather than monthly rates. For these health plans, I had set the cost variants and costs rules to "Monthly." Is there another setting somewhere that I am missing? Please advise- thanks

The benefit payment model assignment is configured in view V_T74HE (note VARGU is getting from feature MODDE). You can check this payment model through view V_T549W to see what period parameter it's set to (PERMO). It's probably currently set to 'bi-weekly' instead of 'Monthly' in your system.
Rgds.

Query plan shows larg amount of time

I ran explain plan for the query below and it takes a long time:
update table docs d
set d.mismatch = 'Y'
where exists (select 1 from diff a where a.versions > 1 and a.ed_id = d.ed_id)
diff is a view with 1069493 rows
docs is a table with 1527012 rows.
Any idea on improving performance. Please!

I'm running 10g. Please see the plan output below:
PLAN_TABLE_OUTPUT
Plan hash value: 2669996443
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | UPDATE STATEMENT | | 76351 | 3131K| | 115K (2)| 00:39:49 |
| 1 | UPDATE | DOC | | | | | |
|* 2 | HASH JOIN | | 76351 | 3131K| | 115K (2)| 00:39:49 |
| 3 | SORT UNIQUE | | 53475 | 1201K| | 80731 (1)| 00:27:49 |
| 4 | VIEW | DIFF | 53475 | 1201K| | 80731 (1)| 00:27:49 |
|* 5 | FILTER | | | | | | |
PLAN_TABLE_OUTPUT
| 6 | SORT GROUP BY | | 53475 | 1566K| | 80731 (1)| 00:27:49 |
| 7 | VIEW | | 1527K| 43M| | 80731 (1)| 00:27:49 |
| 8 | SORT GROUP BY | | 1527K| 249M| 581M| 80731 (1)| 00:27:49 |
| 9 | TABLE ACCESS FULL| DOC | 1527K| 249M| | 34009 (1)| 00:11:44 |
| 10 | TABLE ACCESS FULL | DOC | 1527K| 27M| | 34494 (3)| 00:11:54 |
Predicate Information (identified by operation id):
2 - access("A"."EDV_ED_ID"="D"."EDV_ED_ID")
PLAN_TABLE_OUTPUT
5 - filter(COUNT(*)>1)

Explain about the cost, bytes & cardinality calculation in oracle9i

Hi All,
Any one can explain about the cost, bytes & cardinality calculation in oracle 9i.
Actually I want to understand the behaviour of execution plan taken by oracle.
Here is one example.
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=51 Card=1 Bytes=424)
1 0 SORT (GROUP BY) (Cost=51 Card=1 Bytes=424)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'NBFC_ADDRESS_M'
3 2 NESTED LOOPS (Cost=43 Card=1 Bytes=424)
4 3 NESTED LOOPS (Cost=43 Card=1 Bytes=350)
5 4 NESTED LOOPS (Cost=43 Card=1 Bytes=296)
6 5 NESTED LOOPS (Cost=40 Card=1 Bytes=242)
7 6 NESTED LOOPS (Cost=15 Card=1 Bytes=193)
8 7 NESTED LOOPS (Cost=13 Card=1 Bytes=164)
9 8 NESTED LOOPS (Cost=10 Card=1 Bytes=138)
10 9 NESTED LOOPS (Cost=9 Card=1 Bytes=125)
11 10 NESTED LOOPS (Cost=7 Card=1 Bytes=57)
12 11 TABLE ACCESS (BY INDEX ROWID) OF 'NBFC_BRANCH_M' (Cost=2 Card=1 Bytes=20)
13 12 INDEX (UNIQUE SCAN) OF 'NBFC_BRANCH_M_PK' (UNIQUE) (Cost=1 Card=1)
14 11 TABLE ACCESS (BY INDEX ROWID) OF 'CS_ALLOCATION_HDR' (Cost=5 Card=1 Bytes=37)
15 14 INDEX (RANGE SCAN) OF 'CS_ALLOCATION_QUEING' (NON-UNIQUE) (Cost=2 Card=2)
16 10 TABLE ACCESS (BY INDEX ROWID) OF 'LEA_AGREEMENT_DTL' (Cost=2 Card=1 Bytes=68)
17 16 INDEX (UNIQUE SCAN) OF 'LEA_AGREEMENT_DTL_UQ' (UNIQUE) (Cost=1 Card=1)
18 9 INDEX (UNIQUE SCAN) OF 'SYS_C0016578' (UNIQUE) (Cost=1 Card=1 Bytes=13)
19 8 TABLE ACCESS (BY INDEX ROWID) OF 'LEA_ASSET_M' (Cost=3 Card=1 Bytes=26)
20 19 INDEX (RANGE SCAN) OF 'LEA_ASSET_M_CDX1'(NON-UNIQUE) (Cost=2 Card=1)
21 7 TABLE ACCESS (BY INDEX ROWID) OF 'NBFC_CUSTOMER_M' (Cost=2 Card=1 Bytes=29)
22 21 INDEX (UNIQUE SCAN) OF 'NBFC_CUSTOMER_M_PK' (UNIQUE) (Cost=1 Card=1)
23 6 TABLE ACCESS (BY INDEX ROWID) OF 'NBFC_CHEQUE_DTL' (Cost=25 Card=1 Bytes=49)
24 23 INDEX (RANGE SCAN) OF 'NBFC_CHEQUE_DTL_IDX1'(NON-UNIQUE) (Cost=3 Card=23)
25 5 TABLE ACCESS (BY INDEX ROWID) OF 'NBFC_ADDRESS_M' (Cost=3 Card=1 Bytes=54)
26 25 INDEX (RANGE SCAN) OF 'UK_BPID_BPTYPE_ADDTYPE'(NON-UNIQUE) (Cost=2 Card=1)
27 4 TABLE ACCESS (BY INDEX ROWID) OF 'NBFC_ADDRESS_M'
28 27 INDEX (RANGE SCAN) OF 'NBFC_ADDRESS_M_CDX1' (NON-UNIQUE) (Cost=2 Card=2)
29 3 INDEX (RANGE SCAN) OF 'NBFC_ADDRESS_M_CDX1' (NON-UNIQUE) (Cost=2 Card=2)
Statistics
1 recursive calls
0 db block gets
117 consistent gets
108 physical reads
0 redo size
2181 bytes sent via SQL*Net to client
1185 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
Actully I don't know how to post the thread in proper format so example is not formatted.
Thanx.. Ratan

Cardinality is the number of rows.
Cost -- think that is relative.
Bytes -- the amount of data?
Tom Kyte has a really nice explanation of this in Effective Oracle by Design -- but I left it at work.

Query to show component cost of production order

Need help writing a query to show the component cost of a production order, using moving average valuation method.
I understand the table oinm has all history for an item and its calculated price.
would like to query a production order to show the cost of components at the time of receipt of that production order.
ideas?

I have created this query that will work:
SELECT t0.docdate,t0.appobjtype as [Prod/Comp],t0.itemcode,t0.dscription,t0.outqty,t0.calcprice,(t0.outqty*t0.calcprice) as [Trans Value],t0.warehouse,t0.appobjabs as [Production Order] FROM OINM T0 WHERE t0.transtype='59' and T0.[AppObjAbs] =[%0] order by t0.transnum
The prompt is where you enter the production order document number. It will show the calculated cost of components at the time of receipt.
Thanks for the guidance.
Rich

Planning query donu2019t show current data

Hello,
I have an input ready query over an aggregation level of a real time cube. Whenever the yellow request is closed and a new request is opened, the input ready query does not show the old data. And sometimes it shows incorrect data. We found that the issue is with the Cache.
In RSRT when opening the input ready query in debug mode with "Do not use cache setting", the query returns correct data. But the surprise thing is that, the input ready query has Cache setting as inactive (0) in RSRT. So we had to generate the Delta buffer query <infoprovider>/!!1<infoprovider> in RSRT where <infoprovider> is the name of the real time cube.
This solved our problem and the query brought in correct data. But again when I close the second request, the input ready query again shows me no data or shows me wrong data. So again we need to generate the delta buffer query in RSRT <infoprovider>/!!1<infoprovider>.
This is very annoying when considering the fact that you have to generate the delta buffer query every time the request is closed. This could be a overhead in maintenance and will not go well with people.
Does anybody have any solutions for solving this issue. Is there any setting by which we can turn off cache altogether or delete cache when a request is closed etc? or worst conditions how to automate the generation of delta buffer queries every time the request is closed?
Any help is really appreciated.
Regards,
Anand

please check the below;
Delta buffer query in RSRT for BI-IP ("<infoprovider>/!!1<infoprovider>)
Planning query donu2019t show the current data
Edited by: Hymavathi Yanamadala on Sep 9, 2009 5:47 AM

Merge cartesian join in query plan

Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.

user8650395 wrote:
Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.Interesting.
There was a a thread a day or two ago about when dynamic sampling does not work. You can search OTN for it if you like. Also check the docs to make sure that dynamic sampling works with GTTS
One problem with GTTS is getting accurate statistics. Have you considered using DBMS_STATISTICS to set the statistics on the table to adjust the cardinality?
Your cardinality of 1 sounds incorrect. In theory a cartesian join against one row should be painelss; unfortunately your cardinality figure seems to be off! Sometimes in cases like yours the cost-based optimizer will choose a Cartesian join even when the table joins are properly specified.

Explain Plan shows Nested Loops, Is it good or bad?

Hi All,
I have a doubt in the explain plan, I would like to know if the Nested Loops , will it degrade the query performance?
Note: I have pasted only few output that I had taken from the expalin plan.
Do let me know if there is any article I could read to get clear understanding about the same.
17 NESTED LOOPS ANTI Cost: 125 Bytes: 186 Cardinality: 1
15 NESTED LOOPS ANTI Cost: 124 Bytes: 166 Cardinality: 1
12 NESTED LOOPS Cost: 122 Bytes: 140 Cardinality: 1
     9 NESTED LOOPS Cost: 121 Bytes: 117 Cardinality: 1
Thanks

Hi,
there is absolutely nothing wrong about nested loops (NL). It's a very efficient way of combining data from two rowsources. It works pretty much like a regular loop: it takes all rows from one rowsource (the "outer" one) and for each of them it looks up a row matching the join condition in the other rowsource (the "inner" one).
Note that there are not so many alternatives in Oracle: there are only 3 ways to join data in Oracle, and one of them is used in rather special circumstances (merge join). So normally the choice is between a NL and a hash join. Hash join (HJ) takes the smaller dataset and builds an in-memory lookup table using a hash function on join column(s). Then it goes through the other dataset and as it goes, it applies the hashing function to join column(s) and picks the matching rows from the smaller dataset.
Actually, hash joins and nested loops are not all that different. The basic mechanism is same: you go through one datasource and as you go, you pick matching rows from the other and do the join. The main difference is that a HJ requires some preparation work (it costs resources to build the in-memory table) and thus HJ are typically associated with less-selective queries and full table scans.
In your particular case it's nor possible to tell whether or not NL is in order based on just a few rows from the explain plan. We need to know the structure of your tables (the DDL), what kind of data they hold (optimizer stats) and what query you are running to be able to tell.
Best regards,
Nikolay

Query plan and negative value in where

I have a question about this query:
select g.col1,
g.col2
from tab1 g,
tab2 part
where part.col3 <> 0
and g.col4 = 'PRO3'
and g.col2 = part.col5
and g.cod7 = -1
This is the execution plan:
SELECT STATEMENT, GOAL = ALL_ROWS
HASH JOIN
INDEX FAST FULL SCAN     SYS_C00254422     14     22453     516419
TABLE ACCESS FULL     TAB2     920     67458     1079328
If I change the select in this way:
select g.col1,
g.col2
from tab1 g,
tab2 part
where part.col3 <> 0
and g.col4 = 'PRO3'
and g.col2 = part.col5
and -g.cod7 = 1
I have a new query plan:
SELECT STATEMENT, GOAL = ALL_ROWS
NESTED LOOPS
INDEX FAST FULL SCAN     SYS_C00254422
TABLE ACCESS BY INDEX ROWID          TAB2
INDEX UNIQUE SCAN          SYS_C00254336
Oralce use a nested loop and the index of the table TAB1 and doesn't do the hash join.
Why?
I use oracle 10g
Message was edited by:
user613483
Message was edited by:
user613483

SQL> desc TAB1
Name Null? Type
COL1 NOT NULL VARCHAR2(5)
COL4 NOT NULL VARCHAR2(5)
COL2 NOT NULL VARCHAR2(15)
COL7 NOT NULL NUMBER(3)
DTCOL8 NOT NULL DATE
DRcol9 DATE
LEVcol10 NUMBER(3)
COL11 VARCHAR2(30)
COD12 VARCHAR2(15)
LEV13 NUMBER(3)
COD14 VARCHAR2(15)
LEV15 NUMBER(3)
COD16 VARCHAR2(15)
LEVN17 NUMBER(3)
COD18 VARCHAR2(15)
LEV19 NUMBER(3)
CODNOD20 VARCHAR2(15)
LEVNO21 NUMBER(3)
CODNOD22 VARCHAR2(15)
LEVN23 NUMBER(3)
COD24 VARCHAR2(15)
LEV25 NUMBER(3)
CODNOD26 VARCHAR2(15)
L27 NUMBER(3)
CODN28 VARCHAR2(15)
LEV28 NUMBER(3)
D30 DATE
SQL> desc tab2
Name Null? Type
COL5 NOT NULL VARCHAR2(15)
DESY1 VARCHAR2(60)
DESPA VARCHAR2(60)
CODS VARCHAR2(5)
CODNI VARCHAR2(5)
CODZO VARCHAR2(10)
CODC VARCHAR2(5)
CDFIS VARCHAR2(30)
CO VARCHAR2(30)
CODVATI VARCHAR2(30)
COT1 VARCHAR2(15)
COT2 VARCHAR2(15)
DCAT3 VARCHAR2(15)
CAT4 VARCHAR2(15)
COD VARCHAR2(15)
COU VARCHAR2(5)
FLG NOT NULL NUMBER(1)
COT VARCHAR2(20)
FLGCUSTD NOT NULL NUMBER(1)
CODMOE VARCHAR2(5)
FLG NOT NULL NUMBER(1)
FLGC NOT NULL NUMBER(1)
CODMOP VARCHAR2(5)
CODC VARCHAR2(15)
COELIV VARCHAR2(15)
CONC VARCHAR2(15)
COGMT VARCHAR2(10)
COR VARCHAR2(5)
COOUP VARCHAR2(15)
VALDIT NUMBER(14,2)
DTREDIT DATE
DTRE DATE
DTD DATE
DST DATE
DK DATE
COCK VARCHAR2(5)
CMOD VARCHAR2(5)
FNN NOT NULL NUMBER(1)
PGDCL VARCHAR2(60)
PDB VARCHAR2(60)
CXTEL VARCHAR2(15)
ILCK VARCHAR2(15)
DTTART DATE
PVERY NUMBER(9)
FLTUAL NOT NULL NUMBER(1)
DVER DATE
RIFE_INTERNO VARCHAR2(15)
DATADATE
ESENZIONE DATE
NMSENZIONE VARCHAR2(15)
VSED NUMBER(14,2)
EORD NOT NULL NUMBER(1)
EM VARCHAR2(30)
COTER VARCHAR2(15)
COUST VARCHAR2(15)
CORINT VARCHAR2(15)
TURFACE NUMBER(6)
ODSURFACE NUMBER(6)
ALINDEXPOT NUMBER(6)
SSE NUMBER(6)
NUSEATTR NUMBER(6)
NUETTI NUMBER(6)
CORTY VARCHAR2(15)
DESEC VARCHAR2(60)
QTEARI NUMBER(6)
TOFACE NUMBER(6)
COD VARCHAR2(30)
FLGCI NUMBER(1)
FLGC NUMBER(1)
COL3 NUMBER(1)
FLGCOL33 NUMBER(1)
Query plan of the original select:
1     SQL_ID 51kgr2x36h3y4, child number 0
2     -------------------------------------
3     select g.col1, g.col2 from tab1 g, tab2 part
4     where part.col3 <> 0 and g.col4 = 'PRO3' and g.col2 =
5     part.col5 and g.col7 = -1
6
7     Plan hash value: 2145701647
8
9     ---------------------------------------------------------------------------------------
10     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
11     ---------------------------------------------------------------------------------------
12     | 0 | SELECT STATEMENT | | | | 938 (100)| |
13     |* 1 | HASH JOIN | | 22485 | 856K| 938 (17)| 00:00:05 |
14     |* 2 | INDEX FAST FULL SCAN| SYS_C00254422 | 22453 | 504K| 14 (8)| 00:00:01 |
15     |* 3 | TABLE ACCESS FULL | TAB2 | 67458 | 1054K| 920 (16)| 00:00:05 |
16     ---------------------------------------------------------------------------------------
17
18     Predicate Information (identified by operation id):
19     ---------------------------------------------------
20
21     1 - access("G"."COL2"="PART"."COL5")
22     2 - filter(("G"."COL7"=(-1) AND "G"."COL4"='PRO3'))
23     3 - filter("PART"."COL3"<>0)
24
Sql plan of the second quesry:
1     SQL_ID g1hc2xj88sc7x, child number 0
2     -------------------------------------
3     select g.col1, g.col2 from tab1 g, tab2 part where
4     part.col3 <> 0 and g.col4 = 'PRO3' and g.col2 = part.col5
5     and -g.col7 = 1
6
7     Plan hash value: 601419963
8
9     ----------------------------------------------------------------------------------------------
10     | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
11     ----------------------------------------------------------------------------------------------
12     | 0 | SELECT STATEMENT | | | | 512 (100)| |
13     | 1 | NESTED LOOPS | | 249 | 9711 | 512 (1)| 00:00:03 |
14     |* 2 | INDEX FAST FULL SCAN | SYS_C00254422 | 248 | 5704 | 15 (14)| 00:00:01 |
15     |* 3 | TABLE ACCESS BY INDEX ROWID| TAB2 | 1 | 16 | 2 (0)| 00:00:01 |
16     |* 4 | INDEX UNIQUE SCAN | SYS_C00254336 | 1 | | 1 (0)| 00:00:01 |
17     ----------------------------------------------------------------------------------------------
18
19     Predicate Information (identified by operation id):
20     ---------------------------------------------------
21
22     2 - filter(((-"G"."COL7")=1 AND "G"."COL4"='PRO3'))
23     3 - filter("PART"."COL3"<>0)
24     4 - access("G"."COL2"="PART"."COL5")
25
Index used:
Primary key on tab2 SYS_C00254336:
alter table TAB2
add primary key (COL5)
using index
tablespace name_tablespace;
Primary key on tab1 SYS_C00254422;
alter table TAB1
add primary key (COL1, COL4, COL2, COL7, DTCOL8 )
using index
tablespace name_tablespace;
Message was edited by:
user613483
Message was edited by:
user613483

Can users see the query plan of a SQL query in Oracle?

Hi,
I wonder for a given sql query, after the system optimization, can I see the query plan in oracle? If yes, how to do that? thank you.
Xing

You can use explain plan in SQLPlus
SQL> explain plan for select * from user_tables;
Explained.
Elapsed: 00:00:01.63
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
Plan hash value: 806004009
| Id | Operation                       | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |          | 2014 | 1123K|   507   (6)| 00:00:07 |
|* 1 | HASH JOIN RIGHT OUTER          |          | 2014 | 1123K|   507   (6)| 00:00:07 |
|   2 |   TABLE ACCESS FULL             | SEG$     | 4809 |   206K|    34   (3)| 00:00:01 |
|* 3 |   HASH JOIN RIGHT OUTER         |          | 1697 |   873K|   472   (6)| 00:00:06 |
|   4 |    TABLE ACCESS FULL            | USER$    |    74 | 1036 |     3   (0)| 00:00:01 |
|* 5 |    HASH JOIN OUTER              |          | 1697 |   850K|   468   (6)| 00:00:06 |
|   6 |     NESTED LOOPS OUTER          |          | 1697 |   836K|   315   (6)| 00:00:04 |
|* 7 |      HASH JOIN                  |          | 1697 |   787K|   226   (8)| 00:00:03 |
|   8 |       TABLE ACCESS FULL         | TS$      |    13 |   221 |     5   (0)| 00:00:01 |
|   9 |       NESTED LOOPS              |          | 1697 |   759K|   221   (8)| 00:00:03 |
| 10 |        MERGE JOIN CARTESIAN     |          | 1697 |   599K|   162 (10)| 00:00:02 |
|* 11 |         HASH JOIN               |          |     1 |   326 |     1 (100)| 00:00:01 |
|* 12 |          FIXED TABLE FULL       | X$KSPPI |     1 |    55 |     0   (0)| 00:00:01 |
| 13 |          FIXED TABLE FULL       | X$KSPPCV |   100 | 27100 |     0   (0)| 00:00:01 |
| 14 |         BUFFER SORT             |          | 1697 | 61092 |   162 (10)| 00:00:02 |
|* 15 |          TABLE ACCESS FULL      | OBJ$     | 1697 | 61092 |   161 (10)| 00:00:02 |
|* 16 |        TABLE ACCESS CLUSTER     | TAB$     |     1 |    96 |     1   (0)| 00:00:01 |
|* 17 |         INDEX UNIQUE SCAN       | I_OBJ#   |     1 |       |     0   (0)| 00:00:01 |
| 18 |      TABLE ACCESS BY INDEX ROWID| OBJ$     |     1 |    30 |     1   (0)| 00:00:01 |
|* 19 |       INDEX UNIQUE SCAN         | I_OBJ1   |     1 |       |     0   (0)| 00:00:01 |
| 20 |     TABLE ACCESS FULL           | OBJ$     | 52728 |   411K|   151   (4)| 00:00:02 |
Predicate Information (identified by operation id):
   1 - access("T"."FILE#"="S"."FILE#"(+) AND "T"."BLOCK#"="S"."BLOCK#"(+) AND
              "T"."TS#"="S"."TS#"(+))
   3 - access("CX"."OWNER#"="CU"."USER#"(+))
   5 - access("T"."DATAOBJ#"="CX"."OBJ#"(+))
   7 - access("T"."TS#"="TS"."TS#")
11 - access("KSPPI"."INDX"="KSPPCV"."INDX")
12 - filter("KSPPI"."KSPPINM"='_dml_monitoring_enabled')
15 - filter("O"."OWNER#"=USERENV('SCHEMAID') AND BITAND("O"."FLAGS",128)=0)
16 - filter(BITAND("T"."PROPERTY",1)=0)
17 - access("O"."OBJ#"="T"."OBJ#")
19 - access("T"."BOBJ#"="CO"."OBJ#"(+))
42 rows selected.
Elapsed: 00:00:03.61
SQL> If your plan table does not exist, execute the script $ORACLE_HOME/RDBMS/ADMIN/utlxplan.sql to create the table.

Slow running query, plan attached

Oracle Database 10g Release 10.2.0.1.0
A particular query is taking a rather long time to run. This was something which used to run rather quick until a couple of days back.
Indexes seem to be used and nothing else seem to have changed muck. The 5.38 sec cpu time is what i am trying to trace down.
Does the attached plan show anything that indicates an underlying issue?
SELECT NVL(SUM(NVL(TCR.EMPLOYEEHOURSWORKED, 0) + NVL(TCR.EMPLOYEEOTHOURSWORKED,0)), 0)
FROM   TYPE TYP, EQUIPMENT EQ, TIMECARD TC, TIMECARDRESOURCE TCR
WHERE TYP.TYPEID =   EQ.TYPEID
AND    TCR.EQUIPMENTID = EQ.EQUIPMENTID
AND    EQ.TYPEID = :B2
AND    TCR.EMPLOYEEID = :B1
AND    TCR.TIMECARDID = TC.TIMECARDID
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute    218      0.05       0.04          0          0          0           0
Fetch      218      5.33       5.23          0    2176948          0         218
total      438      5.38       5.28          0    2176948          0         218
Misses in library cache during parse: 1
Misses in library cache during execute: 2
Optimizer mode: ALL_ROWS
Parsing user id: 91     (recursive depth: 1)
Rows     Row Source Operation
     68 SORT AGGREGATE (cr=679048 pr=0 pw=0 time=1580234 us)
     56   TABLE ACCESS BY INDEX ROWID TIMECARDRESOURCE (cr=679048 pr=0 pw=0 time=1479170 us)
743036    NESTED LOOPS (cr=9656 pr=0 pw=0 time=1507400 us)
   2788     TABLE ACCESS BY INDEX ROWID EQUIPMENT (cr=1972 pr=0 pw=0 time=15059 us)
   2788      INDEX RANGE SCAN IDX_EQP_TYPEID (cr=204 pr=0 pw=0 time=6075 us)(object id 193877)
740180     INDEX RANGE SCAN IDX_TCR_EQPID (cr=7684 pr=0 pw=0 time=848397 us)(object id 193878)
********************************************************************************

997026 wrote:
Oracle Database 10g Release 10.2.0.1.0
A particular query is taking a rather long time to run. This was something which used to run rather quick until a couple of days back.
Indexes seem to be used and nothing else seem to have changed muck. The 5.38 sec cpu time is what i am trying to trace down.
Does the attached plan show anything that indicates an underlying issue?
SELECT NVL(SUM(NVL(TCR.EMPLOYEEHOURSWORKED, 0) + NVL(TCR.EMPLOYEEOTHOURSWORKED,0)), 0)
FROM   TYPE TYP, EQUIPMENT EQ, TIMECARD TC, TIMECARDRESOURCE TCR
WHERE TYP.TYPEID =   EQ.TYPEID
AND    TCR.EQUIPMENTID = EQ.EQUIPMENTID
AND    EQ.TYPEID = :B2
AND    TCR.EMPLOYEEID = :B1
AND    TCR.TIMECARDID = TC.TIMECARDID
call     count       cpu    elapsed       disk      query    current        rows
Parse        2      0.00       0.00          0          0          0           0
Execute    218      0.05       0.04          0          0          0           0
Fetch      218      5.33       5.23          0    2176948          0         218
total      438      5.38       5.28          0    2176948          0         218
Misses in library cache during parse: 1
Misses in library cache during execute: 2
Optimizer mode: ALL_ROWS
Parsing user id: 91     (recursive depth: 1)
Rows     Row Source Operation
68 SORT AGGREGATE (cr=679048 pr=0 pw=0 time=1580234 us)
56   TABLE ACCESS BY INDEX ROWID TIMECARDRESOURCE (cr=679048 pr=0 pw=0 time=1479170 us)
743036    NESTED LOOPS (cr=9656 pr=0 pw=0 time=1507400 us)
2788     TABLE ACCESS BY INDEX ROWID EQUIPMENT (cr=1972 pr=0 pw=0 time=15059 us)
2788      INDEX RANGE SCAN IDX_EQP_TYPEID (cr=204 pr=0 pw=0 time=6075 us)(object id 193877)
740180     INDEX RANGE SCAN IDX_TCR_EQPID (cr=7684 pr=0 pw=0 time=848397 us)(object id 193878)
Notice how smart the optimizer has been - you've written a query with 4 tables in it, but the optimizer has recognised that it can eliminate two of the tables because of the primary key and referential integrity constraints.
From the remaining two tables, you have a query that looks as if it is inherently NON-SCALABLE. You select all timecardresources for a given employee, and all pieces of equiplment of a given type, and join them on the equipment id.
I am going to guess that the number of timecardresources for an employee will always grow with time - which means the volume of work you need to do will grow with time; moreover that on some regular basis you add rows to timecardresources, which means the number of random block visits per employeeid will grow with time.
It's possible that hash join that you've engineered in your current solution was the original path, but the optimizer reached the breakpoint where the cost of random visits by employeeid became too great and the decided to use a nested loop from the equipment. (These things happen). However, the point may come when you current solution is also too expensive and the optimizer may then decide to do a tablescan on the timecradresources table.
This is a fairly classic type of problem - a (relatively) small result set arising from a join with a single predicate on each of the joined tables.
If my assumptions are correct, you need to find a way to do one of three things
a) reduce the cost of finding all the timecardresources for an employee - recreating the table as an IOT (index organized table) may be an appropriate mechanism
b) restructure you indexes to minimise random visits to tables - eliminating data as early as possible.
c) re-engineer your indexes and SQL so that you don't do random visits to tables unless you need the rows that you're going to find (Here's a link to my blog which let's you access a video made a couple of years ago of a presentation I did on the topic: https://jonathanlewis.wordpress.com/2011/06/23/video/ )
A couple of other notes:
a) Christian Antognini's book is probably the best practical book available at present on Oracle Tuning
b) The index you've dropped in your solution looks like it might be an index created to protect a foreign key constraint from the "foreign key locking" problem.
Keep an eye open for enqueue waits of type TM, and TM deadlocks.
Regards
Jonathan Lewis

Reg: query plan -

Hi Experts,
I was playing/experimenting with query plans but got stuck up with the below. I guess, I'm overlooking something.
ranit@XE11GR2>> create table t
2 as
3 select * from all_objects;
Table created.
ranit@XE11GR2>> exec dbms_stats.gather_table_stats('rb1','t');
PL/SQL procedure successfully completed.
ranit@XE11GR2>> create index t_uidx
2 on
3 t(owner, object_type, object_name);
Index created.
ranit@XE11GR2>> select * from t
2 where owner = 'SYS';
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 1601196873
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 1642 |   144K|    67   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T    | 1642 |   144K|    67   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("OWNER"='SYS')
ranit@XE11GR2>> select count(*) from t
2 where owner = 'SYS';
Elapsed: 00:00:00.00
Execution Plan
Plan hash value: 1979783846
| Id | Operation         | Name   | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |        |     1 |     7 |    11   (0)| 00:00:01 |
|   1 | SORT AGGREGATE   |        |     1 |     7 |            |          |
|* 2 |   INDEX RANGE SCAN| T_UIDX | 1642 | 11494 |    11   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("OWNER"='SYS')
Doubt: Why does the first query have a FTS while the second query (with COUNT(*)) does an Index scan?
ranit@XE11GR2>> select owner, object_name, namespace from t
2 where owner = 'SYS';
Elapsed: 00:00:00.05
Execution Plan
Plan hash value: 1601196873
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      | 1642 | 47618 |    67   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T    | 1642 | 47618 |    67   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("OWNER"='SYS')
Also, in the above I'm seeing that if I add a non-indexed column in SELECT clause (like column 'namespace') it goes for a FTS. How does column in SELECT clause affect the use of Indexes?
Any pointers if highly appreciated.
Thanks,
Ranit

The second query doesn't have to visit the table - all the required data is in the index- and Oracle thinks that a range scan will only have to go through a small number of leaf blocks to find all the SYS entries. The first query needs data which can only be found in the table, and Oracle thinks the 1642 rows it need to find will be spread across so many blocks that it's quicker to do the tablescan than jump to each one separately after doing an index range scan.
If you want to see how much work Oracle thinks it would take to use an indexed access path into the table, you could test by adding a hint to the query.
Regards
Jonathan Lewis
Now on twitter: @jloracle

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

SQL 2012 SP1 - How to determine a query that causes Error 8623 in SQL Log: The query processor ran out of internal resources and could not produce a query plan. This is a rare event...

We are getting multiple 8623 Errors in SQL Log while running Vendor's software.
How can you catch which Query causes the error?
I tried to catch it using SQL Profiler Trace but it doesn't show which Query/Sp is the one causing an error.
I also tried to use Extended Event session to catch it, but it doesn't create any output either.
Error:
The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that
reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.
Extended Event Session that I used;
CREATE EVENT SESSION
overly_complex_queries
ON SERVER
ADD EVENT sqlserver.error_reported
ACTION (sqlserver.sql_text, sqlserver.tsql_stack, sqlserver.database_id, sqlserver.username)
WHERE ([severity] = 16
AND [error_number] = 8623)
ADD TARGET package0.asynchronous_file_target
(SET filename = 'E:\SQLServer2012\MSSQL11.MSSQLSERVER\MSSQL\Log\XE\overly_complex_queries.xel' ,
metadatafile = 'E:\SQLServer2012\MSSQL11.MSSQLSERVER\MSSQL\Log\XE\overly_complex_queries.xem',
max_file_size = 10,
max_rollover_files = 5)
WITH (MAX_DISPATCH_LATENCY = 5SECONDS)
GO
-- Start the session
ALTER EVENT SESSION overly_complex_queries
ON SERVER STATE = START
GO
It creates only .xel file, but not .xem
Any help/advice is greatly appreciated

Hi VK_DBA,
According to your error message, about which query statement may fail with error message 8623, as other post, you can use trace flag 4102 & 4118 for overcoming this error. Another way is looking for queries with very long IN lists, a large number of
UNIONs, or a large number of nested sub-queries. These are the most common causes of this particular error message.
The error 8623 occurs when attempting to select records through a query with a large number of entries in the "IN" clause (> 10,000). For avoiding this error, I suggest that you could apply the latest Cumulative Updates media for SQL Server 2012 Service
Pack 1, then simplify the query. You may try divide and conquer approach to get part of the query working (as temp table) and then add extra joins / conditions. Or You could try to run the query using the hint option (force order), option (hash join), option
(merge join) with a plan guide.
For more information about error 8623, you can review the following article.
http://blogs.technet.com/b/mdegre/archive/2012/03/13/8623-the-query-processor-ran-out-of-internal-resources-and-could-not-produce-a-query-plan.aspx
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

How to setup a query plan in effective at any time for SP or SQL query?

I have a SP which include a group by SQL statement. It retrieve data from a couple of tables which are over 1G size,
When I run this SP at first time, it take more than 5 minutes to get the result. then I run it again and again, Finally, it become very quick, I can get the result within second.
Not sure why. I guess it is because of query plan.
How to make it running at first time to get result within second? How to force a better best query plan in effective at first time to run the query?
If the engine has better plan in memory, could it be lost at some point? because I have the complain from end user said some times it is fast, sometime it is very slow.
How to resolve this problem?

thanks, kevin. Here is the pesudo query( I modify table name as business rule from my company). you are right, mytab3 is a lookup table.
Select d.stock,i.description,c.categoryname,
Round(IsNull(Sum(d.qty),0),2) AS qty,
From mytab1 d,mytab2 s,invent i,mytab3 c
Where
d.stock != 'param1'
And d.id1 = s.id1    --id1: univarchar(11)
And i.code = c.code   --code:univarchar(2)
And d.stock = i.stock --stock: univarchar(12)
And i.code2 = d.code2 --code2: univarchar(2)
And d.code2 = 'param2'
And s.id2 = 'param3'   --id2: univarchar(6)
Group By c.categoryname,d.stock,i.description
Order By d.stock
here is the query plan when run this query:
The command completed with no results returned
QUERY PLAN FOR STATEMENT 1 (at line 1).
Executed in parallel by coordinating process and 4 worker processes.
    STEP 1
        The type of query is SELECT (into Worktable1).
        GROUP BY
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Executed in parallel by coordinating process and 4 worker processes.
        FROM TABLE
            mytab2
            s
        Nested iteration.
        Index : ind_mytab2 _id2
        Forward scan.
        Positioning by key.
        Keys are:
            id2 ASC
        Executed in parallel with a 4-way hash scan.
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            mytab1
            d
        Nested iteration.
        Index : ind_det_inv
        Forward scan.
        Positioning by key.
        Keys are:
            id1 ASC
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            invent
            i
        Nested iteration.
        Using Clustered Index.
        Index : invent_pk
        Forward scan.
        Positioning by key.
        Keys are:
            stock ASC
            code2 ASC
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            mytab3
            c
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.
        Parallel work table merge.
    STEP 2
        The type of query is INSERT.
        The update mode is direct.
        Executed by coordinating process.
        Worktable2 created, in allpages locking mode, for ORDER BY.
        FROM TABLE
            Worktable1.
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 8 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable2.
    STEP 3
        The type of query is SELECT.
        Executed by coordinating process.
        This step involves sorting.
        FROM TABLE
            Worktable2.
        Using GETSORTED
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 8 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
Total estimated I/O cost for statement 1 (at line 1): 1409882.
The sort for Worktable2 is done in Serial

Query plan shows Cost: 0 Bytes: 851 Cardinality: 1

Similar Messages

Maybe you are looking for