Subquery Unnesting issue
select *from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - ProductionSQL
DELETE FROM A
WHERE TR_STATUS IN ('C', 'R')
OR A.TAX_AUDIT_RECORD_ID IN ( SELECT B.TAX_AUDIT_RECORD_ID FROM B WHERE A.TAX_AUDIT_RECORD_ID = B.TAX_AUDIT_RECORD_ID);Current execution plan
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | DELETE STATEMENT | | 5639K| 123M| 14156 (1)| 00:02:50 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ20002 | 5639K| 123M| 14156 (1)| 00:02:50 | | | Q2,02 | P->S | QC (RAND) |
| 3 | INDEX MAINTENANCE | A | | | | | | | Q2,02 | PCWP | |
| 4 | PX RECEIVE | | 5639K| 123M| 14156 (1)| 00:02:50 | | | Q2,02 | PCWP | |
| 5 | PX SEND RANGE | :TQ20001 | 5639K| 123M| 14156 (1)| 00:02:50 | | | Q2,01 | P->P | RANGE |
| 6 | DELETE | A | | | | | | | Q2,01 | PCWP | |
| 7 | BUFFER SORT | | | | | | | | Q2,01 | PCWC | |
| 8 | PX RECEIVE | | 5639K| 123M| 14156 (1)| 00:02:50 | | | Q2,01 | PCWP | |
| 9 | PX SEND HASH (BLOCK ADDRESS)| :TQ20000 | 5639K| 123M| 14156 (1)| 00:02:50 | | | | S->P | HASH (BLOCK|
|* 10 | FILTER | | | | | | | | | | |
| 11 | PX COORDINATOR | | | | | | | | | | |
| 12 | PX SEND QC (RANDOM) | :TQ10000 | 5639K| 123M| 14156 (1)| 00:02:50 | | | Q1,00 | P->S | QC (RAND) |
| 13 | PX BLOCK ITERATOR | | 5639K| 123M| 14156 (1)| 00:02:50 | 1 | 32 | Q1,00 | PCWC | |
| 14 | TABLE ACCESS FULL | B | 5639K| 123M| 14156 (1)| 00:02:50 | 1 | 32 | Q1,00 | PCWP | |
| 15 | PARTITION RANGE ALL | | 1 | 21 | 3 (0)| 00:00:01 | 1 | 8 | | | |
|* 16 | INDEX RANGE SCAN | PK_B | 1 | 21 | 3 (0)| 00:00:01 | 1 | 8 | | | |
Predicate Information (identified by operation id):
10 - filter("A"."TR_STATUS"='C' OR "A"."TR_STATUS"='R' OR EXISTS (SELECT 0 FROM "B" WHERE
"B"."TAX_AUDIT_RECORD_ID"=:B1))
16 - access("B"."TAX_AUDIT_RECORD_ID"=:B1)There is no relationship (pk/fk) between both of these tables. PK are being populated by an oracle sequence in both the tables. There are lot of matching ids in both the tables though (1Million).
I dont know why Oracle is using FILTER instead of using join methods. I tried using USE_HASH, USE_NL, USE_SJ, but no luck.
Join column (TAX_AUDIT_RECORD_ID) is NOT NULL in both table definition.
I even tried UNNEST hint in sub-query, but again, i did not get any success.
Thanks very much Jonathan for your pointer. (I am regular reader of your blog and wondering how come i missed this one !)
I am getting below error while using LNNVL function:
explain plan for
DELETE FROM A tars where rowid in
(select rowid from A where TR_STATUS IN ('C', 'R')
union all
select rowid from A tars where exists
(SELECT null FROM B taxar WHERE B.TAX_AUDIT_RECORD_ID = A.TAX_AUDIT_RECORD_ID)
and lnnvl(A.TR_STATUS IN ('C', 'R')));
ORA-13207: incorrect use of the [LNNVL] operatorWould i expect same result(row count) with/without this function ?
However, If i remove LNNVL,i get below plan :
Plan hash value: 1196139345
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | DELETE STATEMENT | | 513G| 21T| 1434K (77)| 04:46:49 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10006 | 513G| 21T| 1434K (77)| 04:46:49 | | | Q1,06 | P->S | QC (RAND) |
| 3 | INDEX MAINTENANCE | A | | | | | | Q1,06 | PCWP | | |
| 4 | PX RECEIVE | | 513G| 21T| 1434K (77)| 04:46:49 | | | Q1,06 | PCWP | |
| 5 | PX SEND RANGE | :TQ10005 | 513G| 21T| 1434K (77)| 04:46:49 | | | Q1,05 | P->P | RANGE |
| 6 | DELETE | A | | | | | | | Q1,05 | PCWP | |
| 7 | PX RECEIVE | | 513G| 21T| 1434K (77)| 04:46:49 | | | Q1,05 | PCWP | |
| 8 | PX SEND HASH (BLOCK ADDRESS) | :TQ10004 | 513G| 21T| 1434K (77)| 04:46:49 | | | Q1,04 | P->P | HASH (BLOCK|
|* 9 | HASH JOIN BUFFERED | | 513G| 21T| 1434K (77)| 04:46:49 | | | Q1,04 | PCWP | |
| 10 | PX RECEIVE | | 5069K| 159M| 17222 (1)| 00:03:27 | | | Q1,04 | PCWP | |
| 11 | PX SEND HASH | :TQ10002 | 5069K| 159M| 17222 (1)| 00:03:27 | | | Q1,02 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 5069K| 159M| 17222 (1)| 00:03:27 | 1 | 32 | Q1,02 | PCWC | |
| 13 | TABLE ACCESS FULL | A | 5069K| 159M| 17222 (1)| 00:03:27 | 1 | 32 | Q1,02 | PCWP | |
| 14 | PX RECEIVE | | 10M| 116M| 322K (3)| 01:04:35 | | | Q1,04 | PCWP | |
| 15 | PX SEND HASH | :TQ10003 | 10M| 116M| 322K (3)| 01:04:35 | | | Q1,03 | P->P | HASH |
| 16 | VIEW | VW_NSO_1 | 10M| 116M| 322K (3)| 01:04:35 | | | Q1,03 | PCWP | |
| 17 | SORT UNIQUE | | 10M| 338M| 322K (95)| 01:04:35 | | | Q1,03 | PCWP | |
| 18 | PX RECEIVE | | | | | | | | Q1,03 | PCWP | |
| 19 | PX SEND HASH | :TQ10001 | | | | | | | Q1,01 | P->P | HASH |
| 20 | BUFFER SORT | | 513G| 21T| | | | | Q1,01 | PCWP | |
| 21 | UNION-ALL | | | | | | | | Q1,01 | PCWP | |
| 22 | PX BLOCK ITERATOR | | 5069K| 67M| 17275 (1)| 00:03:28 | 1 | 32 | Q1,01 | PCWC | |
|* 23 | TABLE ACCESS FULL | A | 5069K| 67M| 17275 (1)| 00:03:28 | 1 | 32 | Q1,01 | PCWP | |
|* 24 | HASH JOIN SEMI | | 5069K| 270M| 305K (4)| 01:01:08 | | | Q1,01 | PCWP | |
| 25 | PX BLOCK ITERATOR | | 5069K| 169M| 17275 (1)| 00:03:28 | 1 | 32 | Q1,01 | PCWC | |
|* 26 | TABLE ACCESS FULL | A | 5069K| 169M| 17275 (1)| 00:03:28 | 1 | 32 | Q1,01 | PCWP | |
| 27 | BUFFER SORT | | | | | | | | Q1,01 | PCWC | |
| 28 | PX RECEIVE | | 276M| 5547M| 287K (4)| 00:57:34 | | | Q1,01 | PCWP | |
| 29 | PX SEND BROADCAST LOCAL| :TQ10000 | 276M| 5547M| 287K (4)| 00:57:34 | | | Q1,00 | P->P | BCST LOCAL |
| 30 | PX BLOCK ITERATOR | | 276M| 5547M| 287K (4)| 00:57:34 | 1 | 8 | Q1,00 | PCWC | |
| 31 | TABLE ACCESS FULL | B | 276M| 5547M| 287K (4)| 00:57:34 | 1 | 8 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
9 - access(ROWID="ROWID")
23 - filter("A"."TR_STATUS"='C' OR "A"."TR_STATUS"='R')
24 - access("B"."TAX_AUDIT_RECORD_ID"="A"."TAX_AUDIT_RECORD_ID")
26 - filter("A"."TR_STATUS"='C' OR "A"."TR_STATUS"='R')
Similar Messages
-
Whenever oracle make a hard parse ,will consider subquery unnest and view merge during query merge ,but what are subquery Unnesting Restrictions,when oracle can't make subquery unnest ???
I am not sure that I understand the question.
In general, Oracle cannot unnest a subquery if doing so would change (or would potentially change) the results. The classic example here is when the subquery contains something like the ROWNUM function or some sort of aggregate. If you have
SELECT e.empno, d.deptno, d.rn
FROM (SELECT deptno, dname, rownum rn
FROM dept) d,
emp e
WHERE e.deptno = d.deptnothe subquery cannot be unnested because you only want the ROWNUM pseudocolumn evaluated for the rows in the subquery, not all the rows that the entire query would return.
Justin -
[oracle 10.2.0.4] My view is not merged
Hi,
I have a view which is not merged by the CBO. I mean the CBO decides to apply the filter predicate after the execution of the view.
Here is the definition of the view
CREATE OR REPLACE VIEW VUNSCP AS
SELECT X.DASFM,X.COINT,X.NUCPT,X.RGCOD,X.RGCID,X.CODEV,X.CTDEV,X.CDVRF,X.TXCHJ,X.MTNLV,X.MTVDP,
LEAD(X.MTNLV+X.MTVDP,1) OVER (PARTITION BY X.COINT,X.NUCPT,X.CDVRF,X.CTDEV,X.CODEV,X.RGCOD,X.RGCID ORDER BY X.DASFM DESC),
SUM(X.MTNLV) OVER (PARTITION BY X.COINT,X.CODEV,X.RGCOD)
FROM SFMCPT XThe query is:
explain plan for
select * from VUNSCP where dasfm='30-apr-10';
select * from table(dbms_xplan.display);
Plan hash value: 2545326530
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 13M| 1529M| | 195K (1)| 00:39:11 |
|* 1 | VIEW | VUNSCP | 13M| 1529M| | 195K (1)| 00:39:11 |
| 2 | WINDOW SORT | | 13M| 646M| 1996M| 195K (1)| 00:39:11 |
| 3 | TABLE ACCESS FULL| SFMCPT | 13M| 646M| | 27991 (4)| 00:05:36 |
Predicate Information (identified by operation id):
1 - filter("DASFM"='30-apr-10')You can see that a FTS is performed on SFMCPT (>1 million of rows) and that the filter predicate is applied only after the view has been instantiated.
So the index on DASFM can't be used.
This query is returning about 30 000 rows. We see on the plan that the CBO is mistaken beacause it reckons that there's going to be 13M of rows.
If I add the filter predicate directly on the view'script I get the correct plan:
explain plan for
SELECT X.DASFM,X.COINT,X.NUCPT,X.RGCOD,X.RGCID,X.CODEV,X.CTDEV,X.CDVRF,X.TXCHJ,X.MTNLV,X.MTVDP,
LEAD(X.MTNLV+X.MTVDP,1) OVER (PARTITION BY X.COINT,X.NUCPT,X.CDVRF,X.CTDEV,X.CODEV,X.RGCOD,X.RGCID ORDER BY X.DASFM DESC),
SUM(X.MTNLV) OVER (PARTITION BY X.COINT,X.CODEV,X.RGCOD)
FROM SFMCPT X where dasfm='30-apr-10';
select * from table(dbms_xplan.display);
Plan hash value: 1865390099
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 14357 | 729K| 13271 (1)| 00:02:40 |
| 1 | WINDOW SORT | | 14357 | 729K| 13271 (1)| 00:02:40 |
| 2 | TABLE ACCESS BY INDEX ROWID| SFMCPT | 14357 | 729K| 13269 (1)| 00:02:40 |
|* 3 | INDEX RANGE SCAN | SFMCPT1 | 14357 | | 67 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - access("DASFM"='30-apr-10')The index is now used and the rows estimated seem closer to the actual rows.
I tried several things:
- disabling the "OPTIMZER_COST_BASED_TRANSFORMATION" hidden parameter
- use the MERGE hint
- alter session set optimizer_features_enable = '9.2.0.8';
All these workarounds don't work => I'm still getting the bad execution plan.
According to Jonathan LEWIS' s book the 9i optimzer always merge views But here even if I set the optimizer_features_enable parameter to 9i the view is not merged.
It's sure that the issue is due to the analytical functions but why ?
Can please someone help me to understand what is going on ?
Edited by: Ahmed AANGOUR on 5 mai 2010 08:41here is the 10053 trace file:
/oracle/app/oracle/admin/UBIXPROD/udump/ubixprod_ora_24971_10053_optimizer_trace.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/app/oracle/10.2.0
System name: Linux
Node name: lin-ubi-test1.ubitrade.com
Release: 2.6.9-78.0.1.ELsmp
Version: #1 SMP Tue Jul 22 18:01:05 EDT 2008
Machine: x86_64
Instance name: UBIXPROD
Redo thread mounted by this instance: 1
Oracle process number: 26
*** 2010-05-04 12:14:51.450
*** ACTION NAME:() 2010-05-04 12:14:51.450
*** MODULE NAME:([email protected] (TNS V1-V3)) 2010-05-04 12:14:51.450
*** SERVICE NAME:(SYS$USERS) 2010-05-04 12:14:51.450
*** SESSION ID:(135.1512) 2010-05-04 12:14:51.450
Registered qb: SEL$1 0xa9e139a8 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=5 objn=297481 hint_alias="VUNSCP"@"SEL$1"
Registered qb: SEL$2 0xa9e0bdd0 (PARSER)
signature (): qb_name=SEL$2 nbfros=1 flg=0
fro(0): flg=4 objn=265023 hint_alias="X"@"SEL$2"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 3xakq94fcx4td.
CVM: Considering view merge in query block SEL$1 (#0)
CVM: Checking validity of merging SEL$2 (#0)
CVM: Considering view merge in query block SEL$2 (#0)
CVM: CVM bypassed: Window functions in this view
CBQT: Validity checks failed for 3xakq94fcx4td.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$2 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
PM: Passed validity checks.
FPD: Considering simple filter push in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
"VUNSCP"."DASFM"='30-apr-10'
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: "VUNSCP"."DASFM"='30-apr-10'
after transitive predicate generation: "VUNSCP"."DASFM"='30-apr-10'
finally: "VUNSCP"."DASFM"='30-apr-10'
JPPD: JPPD bypassed: View not on right-side of outer join
FPD: Considering simple filter push in SEL$2 (#0)
FPD: Current where clause predicates in SEL$2 (#0) :
apadrv-start: call(in-use=2936, alloc=16344), compile(in-use=38784, alloc=44568)
kkoqbc-start
: call(in-use=2936, alloc=16344), compile(in-use=40472, alloc=44568)
kkoqbc-subheap (create addr=0x2a9740c1f0)
Current SQL statement for this session:
EXPLAIN PLAN FOR select * from VUNSCP where dasfm='30-apr-10'
Peeked values of the binds in SQL statement
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
_pga_max_size = 262140 KB
cursor_sharing = similar
_optimizer_cost_based_transformation = off
Column Usage Monitoring is ON: tracking level = 1
QUERY BLOCK TEXT
EXPLAIN PLAN FOR select * from VUNSCP where dasfm='30-apr-10'
QUERY BLOCK SIGNATURE
qb name was generated
signature (optimizer): qb_name=SEL$2 nbfros=1 flg=0
fro(0): flg=0 objn=265023 hint_alias="X"@"SEL$2"
SYSTEM STATISTICS INFORMATION
Using NOWORKLOAD Stats
CPUSPEED: 2503 millions instruction/sec
IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
IOSEEKTIM: 10 milliseconds (default is 10)
BASE STATISTICAL INFORMATION
Table Stats::
Table: SFMCPT Alias: X
#Rows: 13036040 #Blks: 122880 AvgRowLen: 358.00
Index Stats::
Index: SFMCPT1 Col#: 2 3 4 8 5 7 118
LVLS: 2 #LB: 58758 #DK: 13013072 LB/K: 1.00 DB/K: 1.00 CLUF: 11983641.00
Index: SFMCPT2 Col#: 1
LVLS: 2 #LB: 30031 #DK: 13483987 LB/K: 1.00 DB/K: 1.00 CLUF: 2410599.00
Index: SFMCPT3 Col#: 3 4 8 5 7 2 118
LVLS: 2 #LB: 39065 #DK: 13013072 LB/K: 1.00 DB/K: 1.00 CLUF: 12583891.00
SINGLE TABLE ACCESS PATH
BEGIN Single Table Cardinality Estimation
Table: SFMCPT Alias: X
Card: Original: 13036040 Rounded: 13036040 Computed: 13036040.00 Non Adjusted: 13036040.00
END Single Table Cardinality Estimation
Access Path: TableScan
Cost: 27991.05 Resp: 27991.05 Degree: 0
Cost_io: 26881.00 Cost_cpu: 33334822147
Resp_io: 26881.00 Resp_cpu: 33334822147
Best:: AccessPath: TableScan
Cost: 27991.05 Degree: 1 Resp: 27991.05 Card: 13036040.00 Bytes: 0
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Considering cardinality-based initial join order.
Permutations for Starting Table :0
Join order[1]: SFMCPT[X]#0
WiF sort
SORT resource Sort statistics
Sort width: 766 Area size: 1048576 Max Area size: 134215680
Degree: 1
Blocks to Sort: 108528 Row size: 68 Total Rows: 13036040
Initial runs: 7 Merge passes: 1 IO Cost / pass: 58786
Total IO sort cost: 167314 Total CPU sort cost: 16584848017
Total Temp space used: 2093966000
Best so far: Table#: 0 cost: 195857.3183 card: 13036040.0000 bytes: 677874080
(newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:80000
Number of join permutations tried: 1
SORT resource Sort statistics
Sort width: 766 Area size: 1048576 Max Area size: 134215680
Degree: 1
Blocks to Sort: 108528 Row size: 68 Total Rows: 13036040
Initial runs: 7 Merge passes: 1 IO Cost / pass: 58786
Total IO sort cost: 167314 Total CPU sort cost: 16584848017
Total Temp space used: 2093966000
Final - All Rows Plan: Best join order: 1
Cost: 195857.3183 Degree: 1 Card: 13036040.0000 Bytes: 677874080
Resc: 195857.3183 Resc_io: 194195.0000 Resc_cpu: 49919670164
Resp: 195857.3183 Resp_io: 194195.0000 Resc_cpu: 49919670164
kkoipt: Query block SEL$2 (#0)
******* UNPARSED QUERY IS *******
SELECT "X"."DASFM" "DASFM","X"."COINT" "COINT","X"."NUCPT" "NUCPT","X"."RGCOD" "RGCOD","X"."RGCID" "RGCID","X"."CODEV" "CODEV","X"."CTDEV" "CTDEV","X"."CDVRF" "CDVRF","X"."TXCHJ" "TXCHJ","X"."MTNLV" "MTNLV","X"."MTVDP" "MTVDP",DECODE(COUNT(*) OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD","X"."CTDEV","X"."NUCPT","X"."CDVRF","X"."RGCID" ORDER BY "X"."DASFM" DESC ROWS BETWEEN 1 FOLLOWING AND 1 FOLLOWING ),1,FIRST_VALUE("X"."MTNLV"+"X"."MTVDP") OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD","X"."CTDEV","X"."NUCPT","X"."CDVRF","X"."RGCID" ORDER BY "X"."DASFM" DESC ROWS BETWEEN 1 FOLLOWING AND 1 FOLLOWING ),NULL) "MTUNS",SUM("X"."MTNLV") OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD") "MTNLI" FROM "SFMCPT" "X"
kkoqbc-subheap (delete addr=0x2a9740c1f0, in-use=11856, alloc=12408)
kkoqbc-end
: call(in-use=57760, alloc=81816), compile(in-use=41096, alloc=44568)
kkoqbc-start
: call(in-use=57760, alloc=81816), compile(in-use=41184, alloc=44568)
kkoqbc-subheap (create addr=0x2a9746b058)
QUERY BLOCK TEXT
select * from VUNSCP where dasfm='30-apr-10'
QUERY BLOCK SIGNATURE
qb name was generated
signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=1 objn=297481 hint_alias="VUNSCP"@"SEL$1"
SYSTEM STATISTICS INFORMATION
Using NOWORKLOAD Stats
CPUSPEED: 2503 millions instruction/sec
IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
IOSEEKTIM: 10 milliseconds (default is 10)
BASE STATISTICAL INFORMATION
Table Stats::
Table: VUNSCP Alias: VUNSCP (NOT ANALYZED)
#Rows: 0 #Blks: 0 AvgRowLen: 0.00
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Considering cardinality-based initial join order.
Permutations for Starting Table :
Join order[1]: VUNSCP[VUNSCP]#0
Best so far: Table#: 0 cost: 195857.3183 card: 13036040.0000 bytes: 1603432920
(newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:80000
Number of join permutations tried: 1
Final - All Rows Plan: Best join order: 1
Cost: 195857.3183 Degree: 1 Card: 13036040.0000 Bytes: 1603432920
Resc: 195857.3183 Resc_io: 194195.0000 Resc_cpu: 49919670164
Resp: 195857.3183 Resp_io: 194195.0000 Resc_cpu: 49919670164
kkoipt: Query block SEL$1 (#0)
******* UNPARSED QUERY IS *******
SELECT "VUNSCP"."DASFM" "DASFM","VUNSCP"."COINT" "COINT","VUNSCP"."NUCPT" "NUCPT","VUNSCP"."RGCOD" "RGCOD","VUNSCP"."RGCID" "RGCID","VUNSCP"."CODEV" "CODEV","VUNSCP"."CTDEV" "CTDEV","VUNSCP"."CDVRF" "CDVRF","VUNSCP"."TXCHJ" "TXCHJ","VUNSCP"."MTNLV" "MTNLV","VUNSCP"."MTVDP" "MTVDP","VUNSCP"."MTUNS" "MTUNS","VUNSCP"."MTNLI" "MTNLI" FROM (SELECT "X"."DASFM" "DASFM","X"."COINT" "COINT","X"."NUCPT" "NUCPT","X"."RGCOD" "RGCOD","X"."RGCID" "RGCID","X"."CODEV" "CODEV","X"."CTDEV" "CTDEV","X"."CDVRF" "CDVRF","X"."TXCHJ" "TXCHJ","X"."MTNLV" "MTNLV","X"."MTVDP" "MTVDP",DECODE(COUNT(*) OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD","X"."CTDEV","X"."NUCPT","X"."CDVRF","X"."RGCID" ORDER BY "X"."DASFM" DESC ROWS BETWEEN 1 FOLLOWING AND 1 FOLLOWING ),1,FIRST_VALUE("X"."MTNLV"+"X"."MTVDP") OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD","X"."CTDEV","X"."NUCPT","X"."CDVRF","X"."RGCID" ORDER BY "X"."DASFM" DESC ROWS BETWEEN 1 FOLLOWING AND 1 FOLLOWING ),NULL) "MTUNS",SUM("X"."MTNLV") OVER ( PARTITION BY "X"."COINT","X"."CODEV","X"."RGCOD") "MTNLI" FROM "SFMCPT" "X") "VUNSCP" WHERE "VUNSCP"."DASFM"='30-apr-10'
kkoqbc-subheap (delete addr=0x2a9746b058, in-use=11544, alloc=12408)
kkoqbc-end
: call(in-use=63208, alloc=81816), compile(in-use=41688, alloc=44568)
apadrv-end: call(in-use=63208, alloc=81816), compile(in-use=42872, alloc=44568)
sql_id=3xakq94fcx4td.
Current SQL statement for this session:
EXPLAIN PLAN FOR select * from VUNSCP where dasfm='30-apr-10'
============
Plan Table
============
---------------------------------------+-----------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time |
---------------------------------------+-----------------------------------+
| 0 | SELECT STATEMENT | | | | 191K | |
| 1 | VIEW | VUNSCP | 12M | 1529M | 191K | 00:39:11 |
| 2 | WINDOW SORT | | 12M | 646M | 191K | 00:39:11 |
| 3 | TABLE ACCESS FULL | SFMCPT | 12M | 646M | 27K | 00:06:36 |
---------------------------------------+-----------------------------------+
Predicate Information:
1 - filter("DASFM"='30-apr-10')Edited by: Ahmed AANGOUR on 5 mai 2010 08:43 -
Do we need to know if failover and loadbalancing is implemented to plan for DB upgrade from 9i to 10gR2? If so why?
Hi,
Issues when upgrading from Oracle 9i :
1. Hash Group by aggregation which allows a hash algorithm to process group by statements. You have to use for sorts ORDER BY.
2. 10g CBO has been added costed subquery unnesting and view merging functionality.
a. Symptoms might range from high parse times to wrong results
3.The CONNECT Role has been changed since 10g R2
4. Parse times may increase after upgrade/migration
Hope it helps....
Thanks
LaserSoft -
How to improve the query performance or tune query from Explain Plan
Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
21 FILTER
16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
1 recursive calls
0 db block gets
0 consistent gets
0 physical reads
0 redo size
243 bytes sent via SQL*Net to client
349 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
SID
310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME VALUE
DB time 9247
DB CPU 9247
background elapsed time 0
background cpu time 0
sequence load elapsed time 0
parse time elapsed 6374
hard parse elapsed time 5997
sql execute elapsed time 2939
connection management call elapsed 1660
failed parse elapsed time 0
failed parse (out of shared memory) 0
hard parse (sharing criteria) elaps 0
hard parse (bind mismatch) elapsed 0
PL/SQL execution elapsed time 95
inbound PL/SQL rpc elapsed time 0
PL/SQL compilation elapsed time 0
Java execution elapsed time 0
repeated bind elapsed time 48
RMAN cpu time (backup/restore) 0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
VALUE
163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID CHILD_NUMBER
04mpgrzhsv72w 0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
Please verify value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
PM: PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
: call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc. -
Virtual column partitioning - explain plan takes lot of time.
I have some problem with table with partitioning based on virtual column.
Explain plan generates for some simple select 2-5 minutes,
but the same select but without part of where clausule generate in secounds.
In both query there is the same explain plan.
Could someone explain why?
Table:
CREATE TABLE "SUBSCRIPTION"
"CUSTOMER_ID" VARCHAR2(100 BYTE),
"IDENT_SOURCE_ID" VARCHAR2(20 BYTE),
"ACCOUNT_ID" VARCHAR2(100 BYTE),
"MSISDN" VARCHAR2(500 BYTE),
"IMSI" VARCHAR2(500 BYTE),
"SIM" VARCHAR2(500 BYTE),
"IMEI" VARCHAR2(500 BYTE),
"MEID" VARCHAR2(15 BYTE),
"EMAIL" VARCHAR2(100 BYTE),
"TELCOOP" VARCHAR2(1000 BYTE),
"MSISDN_TYPE" VARCHAR2(20 BYTE),
"GSM" NUMBER(1,0),
"CDMA" NUMBER(1,0),
"VALID_FROM" DATE,
"VALID_TO" DATE,
"MSISDN_HASH" NUMBER(3,0) GENERATED ALWAYS AS (MOD(TO_NUMBER(NVL2(RTRIM(TRANSLATE(NVL(SUBSTR("MSISDN",-3),NVL("MSISDN",'err')),'123456789','000000000'),'0'),'-1',NVL(SUBSTR("MSISDN",-3),"MSISDN"))),125)) VIRTUAL VISIBLE, --generali mod from 3 last digits of msisdn
) PARTITION BY LIST ( "MSISDN_HASH" )
PARTITION "PCHR" VALUES ( -1 )
PARTITION "P000" VALUES ( 0 )
PARTITION "P001" VALUES ( 1 )
... and so on till...
PARTITION "P124" VALUES (124)
PARALLEL 4;
Slow select:
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from dbident2.subscription
where MSISDN = '600489461'
AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Fast select:
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from dbident2.subscription
where MSISDN = '600489461'
AND MSISDN_HASH = 86--Slower select trace:
Registered qb: SEL$1 0xf4ea2a20 (PARSER)
QUERY BLOCK SIGNATURE
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
SPM: statement not found in SMB
SPM: statement not a candidate for auto-capture
Dynamic sampling level auto-adjusted from 6 to 6
Automatic degree of parallelism (ADOP)
Automatic degree of parallelism is disabled: Parameter.
PM: Considering predicate move-around in query block SEL$1 (#0)
Predicate Move-Around (PM)
OPTIMIZER INFORMATION
----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Legend
The following abbreviations are used by optimizer trace.
CBQT - cost-based query transformation
JPPD - join predicate push-down
OJPPD - old-style (non-cost-based) JPPD
FPD - filter push-down
PM - predicate move-around
CVM - complex view merging
SPJ - select-project-join
SJC - set join conversion
SU - subquery unnesting
OBYE - order by elimination
OST - old style star transformation
ST - new (cbqt) star transformation
CNT - count(col) to count(*) transformation
JE - Join Elimination
JF - join factorization
SLP - select list pruning
DP - distinct placement
qb - query block
LB - leaf blocks
DK - distinct keys
LB/K - average number of leaf blocks per key
DB/K - average number of data blocks per key
CLUF - clustering factor
NDV - number of distinct values
Resp - response cost
Card - cardinality
Resc - resource cost
NL - nested loops (join)
SM - sort merge (join)
HA - hash (join)
CPUSPEED - CPU Speed
IOTFRSPEED - I/O transfer speed
IOSEEKTIM - I/O seek time
SREADTIM - average single block read time
MREADTIM - average multiblock read time
MBRC - average multiblock read count
MAXTHR - maximum I/O system throughput
SLAVETHR - average slave I/O throughput
dmeth - distribution method
1: no partitioning required
2: value partitioned
4: right is random (round-robin)
128: left is random (round-robin)
8: broadcast right and partition left
16: broadcast left and partition right
32: partition left using partitioning of right
64: partition right using partitioning of left
256: run the join in serial
0: invalid distribution method
sel - selectivity
ptn - partition
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
Compilation Environment Dump
pgamax_size = 1258280 KB
parallel_query_default_dop = 32
db_file_multiblock_read_count = 16
Bug Fix Control Environment
PARAMETERS IN OPT_PARAM HINT
Column Usage Monitoring is ON: tracking level = 1
Considering Query Transformations on query block SEL$1 (#0)
Query transformations (QT)
JF: Checking validity of join factorization for query block SEL$1 (#0)
JF: Bypassed: not a UNION or UNION-ALL query block.
ST: not valid since star transformation parameter is FALSE
TE: Checking validity of table expansion for query block SEL$1 (#0)
TE: Bypassed: No relevant table found.
CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
CBQT: Validity checks failed for afjvvjmx6tqgr.
CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
Common Subexpression elimination (CSE)
CSE: CSE not performed on query block SEL$1 (#0).
OBYE: Considering Order-by Elimination from view SEL$1 (#0)
Order-by elimination (OBYE)
OBYE: OBYE bypassed: no order by to eliminate.
CVM: Considering view merge in query block SEL$1 (#0)
query block SEL$1 (#0) unchanged
Considering Query Transformations on query block SEL$1 (#0)
Query transformations (QT)
JF: Checking validity of join factorization for query block SEL$1 (#0)
JF: Bypassed: not a UNION or UNION-ALL query block.
ST: not valid since star transformation parameter is FALSE
TE: Checking validity of table expansion for query block SEL$1 (#0)
TE: Bypassed: No relevant table found.
CBQT bypassed for query block SEL$1 (#0): no complex view, sub-queries or UNION (ALL) queries.
CBQT: Validity checks failed for afjvvjmx6tqgr.
CSE: Considering common sub-expression elimination in query block SEL$1 (#0)
Common Subexpression elimination (CSE)
CSE: CSE not performed on query block SEL$1 (#0).
SU: Considering subquery unnesting in query block SEL$1 (#0)
Subquery Unnest (SU)
SJC: Considering set-join conversion in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: not performed
PM: Considering predicate move-around in query block SEL$1 (#0)
Predicate Move-Around (PM)
PM: PM bypassed: Outer query contains no views.
PM: PM bypassed: Outer query contains no views.
query block SEL$1 (#0) unchanged
FPD: Considering simple filter push in query block SEL$1 (#0)
"SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
try to generate transitive predicate from check constraints for query block SEL$1 (#0)
finally: "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
apadrv-start sqlid=12053738773107497463
call(in-use=8176, alloc=32712), compile(in-use=114912, alloc=116848), execution(in-use=175432, alloc=178928)
Peeked values of the binds in SQL statement
Final query after transformations:******* UNPARSED QUERY IS *******
SELECT "SUBSCRIPTION"."CUSTOMER_ID" "CUSTOMER_ID","SUBSCRIPTION"."IDENT_SOURCE_ID" "IDENT_SOURCE_ID","SUBSCRIPTION"."ACCOUNT_ID" "ACCOUNT_ID","SUBSCRIPTION"."MSISDN" "MSISDN","SUBSCRIPTION"."IMSI" "IMSI","SUBSCRIPTION"."SIM" "SIM","SUBSCRIPTION"."IMEI" "IMEI","SUBSCRIPTION"."MEID" "MEID","SUBSCRIPTION"."EMAIL" "EMAIL","SUBSCRIPTION"."TELCOOP" "TELCOOP" FROM "DBIDENT2"."SUBSCRIPTION" "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."MSISDN_HASH"=86 AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
kkoqbc: optimizing query block SEL$1 (#0)
call(in-use=8320, alloc=32712), compile(in-use=115880, alloc=116848), execution(in-use=175432, alloc=178928)
kkoqbc-subheap (create addr=0x2b24ebece950)
QUERY BLOCK TEXT
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
QUERY BLOCK SIGNATURE
signature (optimizer): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=0 objn=848731 hint_alias="SUBSCRIPTION"@"SEL$1"
SYSTEM STATISTICS INFORMATION
Using NOWORKLOAD Stats
CPUSPEEDNW: 714 millions instructions/sec (default is 100)
IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
IOSEEKTIM: 10 milliseconds (default is 10)
MBRC: -1 blocks (default is 16)
BASE STATISTICAL INFORMATION
Table Stats::
Table: SUBSCRIPTION Alias: SUBSCRIPTION Partition [87]
#Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
#Rows: 218104 #Blks: 11008 AvgRowLen: 129.00 ChainCnt: 0.00
Index Stats::
Index: SUBSCRIPTION_NDX_ACCID Col#: 3
LVLS: 3 #LB: 121036 #DK: 9767936 LB/K: 1.00 DB/K: 1.00 CLUF: 13921256.00
Index: SUBSCRIPTION_NDX_CUSID Col#: 1 2 18
LVLS: 3 #LB: 142123 #DK: 24665396 LB/K: 1.00 DB/K: 1.00 CLUF: 24842146.00
Index: SUBSCRIPTION_NDX_EMAIL Col#: 9
LVLS: 2 #LB: 8365 #DK: 1361827 LB/K: 1.00 DB/K: 1.00 CLUF: 1361798.00
Index: SUBSCRIPTION_NDX_EXT1 Col#: 19
LVLS: 2 #LB: 65756 #DK: 67792 LB/K: 1.00 DB/K: 80.00 CLUF: 5446485.00
Index: SUBSCRIPTION_NDX_IMEI Col#: 7
LVLS: 2 #LB: 44539 #DK: 9199616 LB/K: 1.00 DB/K: 1.00 CLUF: 10413439.00
Index: SUBSCRIPTION_NDX_IMSI Col#: 5
LVLS: 3 #LB: 92914 #DK: 12846080 LB/K: 1.00 DB/K: 1.00 CLUF: 23472821.00
Index: SUBSCRIPTION_NDX_MEID Col#: 8
LVLS: 1 #LB: 132 #DK: 12585 LB/K: 1.00 DB/K: 1.00 CLUF: 18419.00
Index: SUBSCRIPTION_NDX_MSISDN Col#: 4 PARTITION [87]
LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
LVLS: 2 #LB: 1092 #DK: 74848 LB/K: 1.00 DB/K: 2.00 CLUF: 191920.00
Index: SUBSCRIPTION_NDX_SIM Col#: 6
LVLS: 2 #LB: 88153 #DK: 13169664 LB/K: 1.00 DB/K: 1.00 CLUF: 24727298.00
Index: SUBSCRIPTION_NDX_SRCID Col#: 2 17
LVLS: 2 #LB: 81729 #DK: 4 LB/K: 20432.00 DB/K: 257314.00 CLUF: 1029257.00
Access path analysis for SUBSCRIPTION
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
*** 2012-06-12 12:34:53.283
** Performing dynamic sampling initial checks. **
Column (#14):
NewDensity:0.000020, OldDensity:0.000366 BktCnt:254, PopBktCnt:22, PopValCnt:1, NDV:46252
Column (#14):
NewDensity:0.000163, OldDensity:0.000378 BktCnt:254, PopBktCnt:12, PopValCnt:1, NDV:5852
Column (#14): VALID_FROM( Part#: 87
AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
Column (#14): VALID_FROM(
AvgLen: 8 NDV: 5852 Nulls: 2 Density: 0.000163 Min: 2450364 Max: 2456082
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 244
Column (#4):
NewDensity:0.000000, OldDensity:0.000000 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:9730048
Column (#4):
NewDensity:0.000013, OldDensity:0.000033 BktCnt:254, PopBktCnt:0, PopValCnt:0, NDV:74848
Column (#4): MSISDN( Part#: 87
AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
Column (#4): MSISDN(
AvgLen: 10 NDV: 74848 Nulls: 0 Density: 0.000013
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 255
** Dynamic sampling initial checks returning TRUE (level = 6).
*** 2012-06-12 12:34:53.284
** Generated dynamic sampling query:
query text :
SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false') NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */ NVL(SUM(C1),0), NVL(SUM(C2),0) FROM (SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("SUBSCRIPTION") FULL("SUBSCRIPTION") NO_PARALLEL_INDEX("SUBSCRIPTION") */ 1 AS C1, CASE WHEN "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss') THEN 1 ELSE 0 END AS C2 FROM "DBIDENT2"."SUBSCRIPTION" SAMPLE BLOCK (1.153706 , 1) SEED (1) "SUBSCRIPTION" WHERE "SUBSCRIPTION"."MSISDN"='600600600' AND "SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) SAMPLESUB
*** 2012-06-12 12:36:44.452
** Executed dynamic sampling query:
level : 6
sample pct. : 1.153706
total partitions : 1
partitions for sampling : 1
actual sample size : 342182
filtered sample card. : 0
orig. card. : 218104
block cnt. table stat. : 11008
block cnt. for sampling: 11008
max. sample block cnt. : 128
sample block cnt. : 127
min. sel. est. : 0.00001260
** Not using dynamic sampling for single table sel. or cardinality.
DS Failed for : ----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
Column (#21):
NewDensity:0.002912, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:126, NDV:126
Column (#21): MSISDN_HASH( Part#: 87
AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
Column (#21): MSISDN_HASH(
AvgLen: 3 NDV: 1 Nulls: 0 Density: 0.000002 Min: 86 Max: 86
Histogram: Freq #Bkts: 1 UncompBkts: 13365 EndPtVals: 1
Column (#1):
NewDensity:0.000000, OldDensity:0.000241 BktCnt:254, PopBktCnt:31, PopValCnt:2, NDV:9768960
Column (#1):
NewDensity:0.000009, OldDensity:0.000250 BktCnt:254, PopBktCnt:36, PopValCnt:3, NDV:99208
Column (#1): CUSTOMER_ID( Part#: 87
AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
Column (#1): CUSTOMER_ID(
AvgLen: 11 NDV: 99208 Nulls: 0 Density: 0.000009
Histogram: HtBal #Bkts: 254 UncompBkts: 254 EndPtVals: 222
Column (#2):
NewDensity:0.000639, OldDensity:0.000000 BktCnt:14078, PopBktCnt:14078, PopValCnt:3, NDV:3
Column (#2):
NewDensity:0.000786, OldDensity:0.000002 BktCnt:13365, PopBktCnt:13365, PopValCnt:3, NDV:3
Column (#2): IDENT_SOURCE_ID( Part#: 87
AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
Column (#2): IDENT_SOURCE_ID(
AvgLen: 5 NDV: 3 Nulls: 0 Density: 0.000786
Histogram: Freq #Bkts: 3 UncompBkts: 13365 EndPtVals: 3
ColGroup (#1, Index) SUBSCRIPTION_NDX_CUSID
Col#: 1 2 18 CorStregth: -1.00
ColGroup (#2, Index) SUBSCRIPTION_NDX_SRCID
Col#: 2 17 CorStregth: -1.00
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Table: SUBSCRIPTION Alias: SUBSCRIPTION
Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
Access Path: TableScan
Cost: 2420.71 Resp: 672.42 Degree: 0
Cost_io: 2409.00 Cost_cpu: 100334308
Resp_io: 669.17 Resp_cpu: 27870641
kkofmx: index filter:"SUBSCRIPTION"."MSISDN_HASH"=86
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Access Path: index (AllEqRange)
Index: SUBSCRIPTION_NDX_MSISDN
resc_io: 6.00 resc_cpu: 36840
ix_sel: 0.000013 ix_sel_with_filters: 0.000013
***** Logdef predicate Adjustment ******
Final IO cst 0.00 , CPU cst 2300.00
***** End Logdef Adjustment ******
Cost: 6.01 Resp: 6.01 Degree: 1
Best:: AccessPath: IndexRange
Index: SUBSCRIPTION_NDX_MSISDN
Cost: 6.01 Degree: 1 Resp: 6.01 Card: 2.75 Bytes: 0
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Considering cardinality-based initial join order.
Permutations for Starting Table :0
Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
Best so far: Table#: 0 cost: 6.0051 card: 2.7487 bytes: 291
****** Recost for parallel table scan *******
Access path analysis for SUBSCRIPTION
SINGLE TABLE ACCESS PATH
Single Table Cardinality Estimation for SUBSCRIPTION[SUBSCRIPTION]
*** 2012-06-12 12:36:44.454
** Performing dynamic sampling initial checks. **
** TABLE SUBSCRIPTION Alias: SUBSCRIPTION : reused cached dynamic sampling result (failure).
ColGroup Usage:: PredCnt: 2 Matches Full: Partial:
***** Virtual column Adjustment ******
Column name MSISDN_HASH
cost_cpu 2300.00
cost_io 179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368.00
***** End virtual column Adjustment ******
Table: SUBSCRIPTION Alias: SUBSCRIPTION
Card: Original: 218104.000000 Rounded: 3 Computed: 2.75 Non Adjusted: 2.75
Access Path: TableScan
Cost: 2420.71 Resp: 672.42 Degree: 0
Cost_io: 2409.00 Cost_cpu: 100334308
Resp_io: 669.17 Resp_cpu: 27870641
Best:: AccessPath: TableScan
Cost: 672.42 Degree: 4 Resp: 672.42 Card: 2.75 Bytes: 97
Join order[1]: SUBSCRIPTION[SUBSCRIPTION]#0
Join order aborted: cost > best plan cost
(newjo-stop-1) k:0, spcnt:0, perm:1, maxperm:2000
Number of join permutations tried: 1
Enumerating distribution method (advanced)
Trying or-Expansion on query block SEL$1 (#0)
Transfer Optimizer annotations for query block SEL$1 (#0)
id=0 frofkks[i] (index start key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
id=0 frofkke[i] (index stop key) predicate="SUBSCRIPTION"."MSISDN"='600600600'
id=0 frofand predicate="SUBSCRIPTION"."VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss')
Final cost for query block SEL$1 (#0) - All Rows Plan:
Best join order: 1
Cost: 6.0051 Degree: 1 Card: 3.0000 Bytes: 291
Resc: 6.0051 Resc_io: 6.0000 Resc_cpu: 43740
Resp: 6.0051 Resp_io: 6.0000 Resc_cpu: 43740
kkoqbc-subheap (delete addr=0x2b24ebece950, in-use=21280, alloc=32840)
kkoqbc-end:
call(in-use=252920, alloc=343912), compile(in-use=129048, alloc=133000), execution(in-use=192248, alloc=195240)
kkoqbc: finish optimizing query block SEL$1 (#0)
apadrv-end
call(in-use=252920, alloc=343912), compile(in-use=129960, alloc=133000), execution(in-use=192248, alloc=195240)
Starting SQL statement dump
user_id=115 user_name=xxx module=SQL*Plus action=
sql_id=afjvvjmx6tqgr plan_hash_value=1672204165 problem_type=3
----- Current SQL Statement for this session (sql_id=afjvvjmx6tqgr) -----
explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
sql_text_length=266
sql=explain plan for
select CUSTOMER_ID, IDENT_SOURCE_ID, ACCOUNT_ID, MSISDN, IMSI, SIM, IMEI, MEID, EMAIL, TELCOOP
from subscription
where MSISDN = '600600600' AND MSISDN_HASH = 86
AND VALID_FROM <=TO_DATE('2012-02-10 00:00:00', 'YYYY-MM-DD HH2
sql=4:MI:SS')
----- Explain Plan Dump -----
----- Plan Table -----
============
Plan Table
============
-----------------------------------------------------------------------------------------------------------------------+
| Id | Operation | Name | Rows | Bytes | Cost | Time | Pstart| Pstop |
-----------------------------------------------------------------------------------------------------------------------+
| 0 | SELECT STATEMENT | | | | 6 | | | |
| 1 | PARTITION LIST SINGLE | | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID | SUBSCRIPTION | 3 | 291 | 6 | 00:00:01 | 88 | 88 |
| 3 | INDEX RANGE SCAN | SUBSCRIPTION_NDX_MSISDN| 3 | | 3 | 00:00:01 | 88 | 88 |
-----------------------------------------------------------------------------------------------------------------------+
Predicate Information:
2 - filter("VALID_FROM"<=TO_DATE(' 2012-02-10 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
3 - access("MSISDN"='600600600')
Content of other_xml column
===========================
nodeid/pflags: 1 1 db_version : 11.2.0.2
parse_schema : xxx
plan_hash : 1672204165
plan_hash_2 : 1960934971
Outline Data:
/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('11.2.0.2')
DB_VERSION('11.2.0.2')
OPT_PARAM('optimizer_dynamic_sampling' 6)
ALL_ROWS
OUTLINE_LEAF(@"SEL$1")
INDEX_RS_ASC(@"SEL$1" "SUBSCRIPTION"@"SEL$1" ("SUBSCRIPTION"."MSISDN"))
END_OUTLINE_DATA
Query Block Registry:
SEL$1 0xf4ea2a20 (PARSER) [FINAL]
call(in-use=259392, alloc=343912), compile(in-use=170344, alloc=270888), execution(in-use=344120, alloc=346656)
End of Optimizer State Dump
Dumping Hints
=============
====================== END SQL Statement Dump ======================
Edited by: user3754081 on 2012-06-12 08:07 -
I have a DATA table which consists of Minutely data. For every unique filename, solar_id, year, day there is a unique processing stage that can exist and to find the highest processing stage we select the MAX(date_stamp) for that particular day since it will be the latest touched stage.
So for any given day we can have 1440minutes x (5processing stages on average) = ~7k records.
If I have a query that wants to look at the highest processing stage that exists each day over a TIME FRAME, how can I improve it's performance?
SELECT DISTINCT s.NAME NAME, s.climate_id climate_id, a.solar_id solar_id,
a.processing_stage processing_stage, a.YEAR YEAR, a.DAY DAY,
TO_CHAR (a.date_stamp, 'YYYY-MM-DD HH24:MI:SS') date_stamp, a.user_id
FROM solar_station s, DATA a
WHERE a.solar_id = '636'
AND s.solar_id = '636'
AND s.climate_id = '611KBE0'
AND a.solar_id = s.solar_id
AND a.time_stamp BETWEEN TO_DATE ('2004-9-8', 'YYYY-MM-DD')
AND TO_DATE ('2004-9-20', 'YYYY-MM-DD')
AND (a.solar_id, a.filename, a.YEAR, a.DAY, a.date_stamp) IN (
SELECT b.solar_id, b.filename, b.YEAR, b.DAY, MAX (b.date_stamp)
FROM DATA b
WHERE b.solar_id = '636'
AND b.solar_id = s.solar_id
AND b.time_stamp BETWEEN TO_DATE ('2004-9-8', 'YYYY-MM-DD')
AND TO_DATE ('2004-9-20', 'YYYY-MM-DD')
GROUP BY b.solar_id, b.filename, b.YEAR, b.DAY)
ORDER BY s.NAME, a.YEAR, a.DAY;The data table is partioned by YEAR and sub-partioned by solar_id.Hmm, still a full table scan on data. This is
probably caused by the unnecessary line
AND b.solar_id = s.solar_idWhat happens if you remove this line?
Regards,
Rob.
SELECT DISTINCT s.NAME NAME, s.climate_id climate_id, a.solar_id solar_id,
a.processing_stage processing_stage, a.YEAR YEAR, a.DAY DAY,
TO_CHAR (a.date_stamp, 'YYYY-MM-DD HH24:MI:SS') date_stamp, a.user_id
FROM solar_station s, DATA a
WHERE a.solar_id = '636'
AND s.solar_id = '636'
AND s.climate_id = '611KBE0'
--AND a.solar_id = s.solar_id
and year between 2004 and 2004
AND a.time_stamp BETWEEN TO_DATE ('2004-9-8', 'YYYY-MM-DD')
AND TO_DATE ('2004-12-20', 'YYYY-MM-DD')
AND (a.solar_id, a.filename, a.YEAR, a.DAY, a.date_stamp) IN (
SELECT b.solar_id, b.filename, b.YEAR, b.DAY, MAX (b.date_stamp)
FROM DATA b
WHERE b.solar_id = '636'
--AND b.solar_id = s.solar_id
and year between 2004 and 2004
AND b.time_stamp BETWEEN TO_DATE ('2004-9-8', 'YYYY-MM-DD')
AND TO_DATE ('2004-12-20', 'YYYY-MM-DD')
GROUP BY b.solar_id, b.filename, b.YEAR, b.DAY)
ORDER BY s.NAME, a.YEAR, a.DAY;
PLAN_TABLE_OUTPUT
Plan hash value: 4121458178
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 156 | 19500 | 30539 (4)| 00:06:07 | | |
| 1 | SORT ORDER BY | | 156 | 19500 | 30539 (4)| 00:06:07 | | |
| 2 | HASH UNIQUE | | 156 | 19500 | 30538 (4)| 00:06:07 | | |
|* 3 | HASH JOIN | | 156 | 19500 | 30537 (4)| 00:06:07 | | |
| 4 | NESTED LOOPS | | 1401 | 95268 | 15279 (4)| 00:03:04 | | |
|* 5 | TABLE ACCESS BY INDEX ROWID| SOLAR_STATION | 1 | 27 | 1 (0)| 00:00:01 | | |
|* 6 | INDEX UNIQUE SCAN | SOLAR_STATION_PK | 1 | | 0 (0)| 00:00:01 | | |
| 7 | VIEW | VW_NSO_1 | 1401 | 57441 | 15278 (4)| 00:03:04 | | |
| 8 | SORT GROUP BY | | 1401 | 82659 | 15278 (4)| 00:03:04 | | |
| 9 | PARTITION RANGE ITERATOR | | 272K| 15M| 15245 (3)| 00:03:03 | 10 | 11 |
| 10 | PARTITION HASH SINGLE | | 272K| 15M| 15245 (3)| 00:03:03 | 1 | 1 |
|* 11 | TABLE ACCESS FULL | DATA | 272K| 15M| 15245 (3)| 00:03:03 | | |
| 12 | PARTITION RANGE ITERATOR | | 272K| 14M| 15254 (4)| 00:03:04 | 10 | 11 |
| 13 | PARTITION HASH SINGLE | | 272K| 14M| 15254 (4)| 00:03:04 | 1 | 1 |
|* 14 | TABLE ACCESS FULL | DATA | 272K| 14M| 15254 (4)| 00:03:04 | | |
Predicate Information (identified by operation id):
3 - access("A"."SOLAR_ID"="$nso_col_1" AND "A"."FILENAME"="$nso_col_2" AND "A"."YEAR"="$nso_col_3" AND
"A"."DAY"="$nso_col_4" AND "A"."DATE_STAMP"="$nso_col_5")
5 - filter("S"."CLIMATE_ID"='611KBE0')
6 - access("S"."SOLAR_ID"='636')
11 - filter("B"."TIME_STAMP">=TO_DATE('2004-09-08 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "YEAR"=2004 AND
"B"."SOLAR_ID"='636' AND "B"."TIME_STAMP"<=TO_DATE('2004-12-20 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))
14 - filter("A"."TIME_STAMP">=TO_DATE('2004-09-08 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "YEAR"=2004 AND
"A"."SOLAR_ID"='636' AND "A"."TIME_STAMP"<=TO_DATE('2004-12-20 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))>
Message was edited by:
Rob van Wijk
ddition questions:
What is the outcome of:
select count(*)
from ( SELECT s.NAME NAME
, s.climate_id climate_id
, a.solar_id solar_id
, a.processing_stage processing_stage
, a.YEAR YEAR
, a.DAY DAY
, TO_CHAR (a.date_stamp, 'YYYY-MM-DD HH24:MI:SS')
date_stamp
, a.user_id
, max(a.date_stamp) over (partition by a.solar_id,
a.file_name, a.year, a.day) max_date_stamp
FROM solar_station s
, DATA a
WHERE a.solar_id = '636'
AND s.solar_id = '636'
AND s.climate_id = '611KBE0'
AND a.solar_id = s.solar_id
AND year between 2004 and 2004
AND a.time_stamp BETWEEN TO_DATE ('2004-9-8',
'YYYY-MM-DD') AND TO_DATE ('2004-12-20',
'YYYY-MM-DD')
Here we get:
COUNT(*)
1266111
1 row selected.
You might remove the subquery by issuing:
select distinct *
from ( SELECT s.NAME NAME
, s.climate_id climate_id
, a.solar_id solar_id
, a.processing_stage processing_stage
, a.YEAR YEAR
, a.DAY DAY
, TO_CHAR (a.date_stamp, 'YYYY-MM-DD HH24:MI:SS')
date_stamp
, a.user_id
, max(a.date_stamp) over (partition by a.solar_id,
a.file_name, a.year, a.day) max_date_stamp
FROM solar_station s
, DATA a
WHERE a.solar_id = '636'
AND s.solar_id = '636'
AND s.climate_id = '611KBE0'
AND a.solar_id = s.solar_id
AND year between 2004 and 2004
AND a.time_stamp BETWEEN TO_DATE ('2004-9-8',
'YYYY-MM-DD') AND TO_DATE ('2004-12-20',
'YYYY-MM-DD')
date_stamp = max_date_stamp
ORDER BY s.NAME
, a.YEAR
, a.DAY
select distinct *
from ( SELECT s.NAME NAME
, s.climate_id climate_id
, a.solar_id solar_id
, a.processing_stage processing_stage
, a.YEAR YEAR
, a.DAY DAY
, TO_CHAR (a.date_stamp, 'YYYY-MM-DD HH24:MI:SS') date_stamp
, a.user_id
, max(a.date_stamp) over (partition by a.solar_id, a.filename, a.year, a.day) max_date_stamp
FROM solar_station s
, DATA a
WHERE a.solar_id = '636'
AND s.solar_id = '636'
AND s.climate_id = '611KBE0'
AND a.solar_id = s.solar_id
AND year between 2004 and 2004
AND a.time_stamp BETWEEN TO_DATE ('2004-9-8', 'YYYY-MM-DD') AND TO_DATE ('2004-12-20', 'YYYY-MM-DD')
where date_stamp = max_date_stamp
ORDER BY NAME
, YEAR
, DAY;
PLAN_TABLE_OUTPUT
Plan hash value: 3043498213
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 14702 | 990K| | 20550 (3)| 00:04:07 | | |
| 1 | SORT UNIQUE | | 14702 | 990K| 9608K| 19862 (3)| 00:03:59 | | |
|* 2 | VIEW | | 90794 | 6117K| | 18372 (3)| 00:03:41 | | |
| 3 | WINDOW SORT | | 90794 | 13M| 33M| 18372 (3)| 00:03:41 | | |
|* 4 | HASH JOIN | | 90794 | 13M| | 15251 (3)| 00:03:04 | | |
|* 5 | TABLE ACCESS BY INDEX ROWID| SOLAR_STATION | 1 | 78 | | 1 (0)| 00:00:01 | | |
|* 6 | INDEX UNIQUE SCAN | SOLAR_STATION_PK | 1 | | | 0 (0)| 00:00:01 | | |
| 7 | PARTITION RANGE ITERATOR | | 272K| 20M| | 15245 (3)| 00:03:03 | 10 | 11 |
| 8 | PARTITION HASH SINGLE | | 272K| 20M| | 15245 (3)| 00:03:03 | 1 | 1 |
|* 9 | TABLE ACCESS FULL | DATA | 272K| 20M| | 15245 (3)| 00:03:03 | | |
Predicate Information (identified by operation id):
2 - filter("MAX_DATE_STAMP"=TO_TIMESTAMP("DATE_STAMP"))
4 - access("A"."SOLAR_ID"="S"."SOLAR_ID")
5 - filter("S"."CLIMATE_ID"='611KBE0')
6 - access("S"."SOLAR_ID"='636')
9 - filter("A"."TIME_STAMP">=TO_DATE('2004-09-08 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "YEAR"=2004 AND
"A"."SOLAR_ID"='636' AND "A"."TIME_STAMP"<=TO_DATE('2004-12-20 00:00:00', 'yyyy-mm-dd hh24:mi:ss'))The result was an error:
Error at line 0
ORA-01843: not a valid month -
Oracle Lite, optimizer?
Hi all!
I'm in Oracle lite 10.3...what type of optimizer use Olite?
I've some mysterious results in a select, only i change the order in the where conditions and the results are distincts...Hey Anastasia,
Do you mean for the client or for MGP? I am assuming you want to unnest the subquery within the COMPOSE phase. Correct?
Here is the only reference to unnesting on the client in the documentation:
Example 5
In this example, the "ordered" hint selects the EMP table as the outermost table in the join ordering. The optimizer still attempts to pick the best possible indexes to use for execution. All other optimizations, such as view replacement and subquery unnesting are still attempted.
Select //ordered// Eno, Ename, Loc from Emp, Dept
where Dept.DeptNo = Emp.DeptNo and Emp.Sal > 50000;
But if this is your MGP that you are inquiring about, just alter the publication select statement with:
SELECT /*+ UNNEST */ * FROM SOMESCHEMA.SOMETABLE WHERE BLAH, BLAH, BLAH -
CBO - Wrong Cardinality Estimate
Hello,
Version 10.2.0.3
I am trying to understand the figures in the Explain Plan. I am not able to explain the cardinality of 70 on step 4.
The query takes very long to execute (about 400 secs). I would expect HASH JOIN SEMI instead of NESTED LOOPS SEMI.
I have tried to provide as much information as possible. I have just requested the 10053 trace, dont have it now.
There is a primary key on ORDERS.ORDER_ID (NUMBER) column. However, we are forced to use to_char(order_id) to accomodate for COT_EXTERNAL_ID being VARCHAR2 field.
1 select cdw.* from cdw_orders cdw where cdw.cot_external_id in
2 (
3 select to_char(order_id) from orders o where o.status_id in (12,16,22)
4* )
SQL> /
Execution Plan
Plan hash value: 733167152
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 280 | 326 (1)| 00:00:04 |
| 1 | NESTED LOOPS SEMI | | 2 | 280 | 326 (1)| 00:00:04 |
| 2 | TABLE ACCESS FULL | CDW_ORDERS | 3362 | 433K| 293 (1)| 00:00:04 |
| 3 | INLIST ITERATOR | | | | | |
|* 4 | TABLE ACCESS BY INDEX ROWID| ORDERS | 70 | 560 | 1 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | ORDERS_STATUS_ID_IDX | 2 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
5 - access("O"."STATUS_ID"=12 OR "O"."STATUS_ID"=16 OR "O"."STATUS_ID"=22)Here is some of the details on the table columns and data.
SQL> select column_name,num_distinct,density,num_nulls,num_buckets from all_tab_columns where table_name = 'ORDERS'
2 and column_name in ('STATUS_ID','ORDER_ID');
COLUMN_NAME NUM_DISTINCT DENSITY NUM_NULLS NUM_BUCKETS
ORDER_ID 177951 .00000561952447584 0 254
STATUS_ID 23 .00000275335899280 0 23
SQL> select num_rows from all_tables where table_name = 'ORDERS';
NUM_ROWS
177951
SQL> select index_name,distinct_keys,clustering_factor,num_rows,sample_size from all_indexes where index_name = 'ORDERS_STATUS_ID_IDX'
2 /
INDEX_NAME DISTINCT_KEYS CLUSTERING_FACTOR NUM_ROWS SAMPLE_SIZE
ORDERS_STATUS_ID_IDX 25 35893 177951 177951Histograms on column STATUS_ID
SQL> select * from (
2 select column_name,endpoint_value,endpoint_number- nvl(lag(endpoint_number) over (order by endpoint_value),0) count
3 from all_tab_histograms where column_name = 'STATUS_ID' and table_name = 'ORDERS'
4 ) where endpoint_value in (12,16,22);
COLUMN_NAME ENDPOINT_VALUE COUNT
STATUS_ID 12 494
STATUS_ID 16 24
STATUS_ID 22 3064
SQL> select max(endpoint_number) from all_tab_histograms where column_name = 'STATUS_ID' and table_name = 'ORDERS' ;
MAX(ENDPOINT_NUMBER)
5641I tried to run the query for individual values instead of inlist to check the numbers.
1 select cdw.* from cdw_orders cdw where cdw.cot_external_id in
2 (
3 select to_char(order_id) from orders o where o.status_id = 12
4* )
SQL> /
Execution Plan
Plan hash value: 3178043291
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 280 | 33 (19)| 00:00:01 |
| 1 | MERGE JOIN SEMI | | 2 | 280 | 33 (19)| 00:00:01 |
| 2 | TABLE ACCESS BY INDEX ROWID| CDW_ORDERS | 3362 | 433K| 21 (0)| 00:00:01 |
| 3 | INDEX FULL SCAN | CDW_ORD_COT_EXT_ID | 3362 | | 2 (0)| 00:00:01 |
|* 4 | SORT UNIQUE | | 15584 | 121K| 11 (46)| 00:00:01 |
|* 5 | VIEW | index$_join$_002 | 15584 | 121K| 9 (34)| 00:00:01 |
|* 6 | HASH JOIN | | | | | |
|* 7 | INDEX RANGE SCAN | ORDERS_STATUS_ID_IDX | 15584 | 121K| 1 (0)| 00:00:01 |
| 8 | INDEX FAST FULL SCAN | PK_ORDERS | 15584 | 121K| 5 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - access("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
5 - filter("O"."STATUS_ID"=12)
6 - access(ROWID=ROWID)
7 - access("O"."STATUS_ID"=12)For status_id = 12, the cardinality on step 7 for orders_status_id_idx is 15584 which is inline with the expectation ie., (494/5641)*177951 = 15583.7 ~ 15584.
Now, I continue the same with status_is = 16
1 select cdw.* from cdw_orders cdw where cdw.cot_external_id in
2 (
3 select to_char(order_id) from orders o where o.status_id = 16
4* )
SQL> /
Execution Plan
Plan hash value: 43581000
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1363 | 186K| 10 (10)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID | CDW_ORDERS | 2 | 264 | 1 (0)| 00:00:01 |
| 2 | NESTED LOOPS | | 1363 | 186K| 10 (10)| 00:00:01 |
| 3 | SORT UNIQUE | | 757 | 6056 | 2 (0)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID| ORDERS | 757 | 6056 | 2 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | ORDERS_STATUS_ID_IDX | 757 | | 1 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | CDW_ORD_COT_EXT_ID | 2 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
5 - access("O"."STATUS_ID"=16)
6 - access("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))Here also the cardinality on step 5 for orders_status_id_idx is as expected ie., (24/5641)*177951 = 757.1 ~ 757
Finally, running the same for status_id = 22 surprises me
1 select cdw.* from cdw_orders cdw where cdw.cot_external_id in
2 (
3 select to_char(order_id) from orders o where o.status_id = 22
4* )
SQL> /
Execution Plan
Plan hash value: 3496542905
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 280 | 326 (1)| 00:00:04 |
| 1 | NESTED LOOPS SEMI | | 2 | 280 | 326 (1)| 00:00:04 |
| 2 | TABLE ACCESS FULL | CDW_ORDERS | 3362 | 433K| 293 (1)| 00:00:04 |
|* 3 | TABLE ACCESS BY INDEX ROWID| ORDERS | 60 | 480 | 1 (0)| 00:00:01 |
|* 4 | INDEX RANGE SCAN | ORDERS_STATUS_ID_IDX | 2 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter("CDW"."COT_EXTERNAL_ID"=TO_CHAR("ORDER_ID"))
4 - access("O"."STATUS_ID"=22)Like the ones for 12 and 16, I would have expected the cardinality on step 4 to be (3064/5641)*177951 = 96657, but I see only 2.
This is where my doubt is. Is this got to do with 22 being a popular value ? Can someone explain this behaviour ?
As a solution I am thinking of creating an index on to_char(order_id) - function based, hoping that the step 3 CDW.COT_EXTERNAL_ID = TO_CHAR(ORDER_ID) changes
to access instead of filter. Let me know your thoughts on the index creation as well.
Thanks,
Rgds,
Gokul
Edited by: Gokul Gopal on 24-May-2012 02:40Hello Jonathan,
Apologies, I was wrong about optimizer_index_cost_adj value to be set to 100. I gather from DBA the value is set to currently set to 1.
I have pasted the 10053 trace file for value 22. I was not able to figure out the "jsel=min(1, 6.1094e-04)" bit.
/dborafiles/COTP/bycota2/udump/bycota2_ora_2147_values_22.trc
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
ORACLE_HOME = /dboracle/orabase/product/10.2.0
System name: Linux
Node name: byl945d002
Release: 2.6.9-55.ELsmp
Version: #1 SMP Fri Apr 20 16:36:54 EDT 2007
Machine: x86_64
Instance name: bycota2
Redo thread mounted by this instance: 2
Oracle process number: 37
Unix process pid: 2147, image: oracle@byl945d002 (TNS V1-V3)
*** 2012-05-28 14:00:59.737
*** ACTION NAME:() 2012-05-28 14:00:59.737
*** MODULE NAME:(SQL*Plus) 2012-05-28 14:00:59.737
*** SERVICE NAME:(SYS$USERS) 2012-05-28 14:00:59.737
*** SESSION ID:(713.51629) 2012-05-28 14:00:59.737
Registered qb: SEL$1 0x973e5458 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
fro(0): flg=4 objn=51893 hint_alias="CDW"@"SEL$1"
Registered qb: SEL$2 0x973e6058 (PARSER)
signature (): qb_name=SEL$2 nbfros=1 flg=0
fro(0): flg=4 objn=51782 hint_alias="O"@"SEL$2"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM: Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks passed for 5r4bhr2yrt5gz.
apadrv-start: call(in-use=704, alloc=16344), compile(in-use=60840, alloc=63984)
Current SQL statement for this session:
select cdw.* from cdw_orders cdw where cdw.cot_external_id in (select to_char(o.order_id) from orders o where status_id = 22)
Legend
The following abbreviations are used by optimizer trace.
CBQT - cost-based query transformation
JPPD - join predicate push-down
FPD - filter push-down
PM - predicate move-around
CVM - complex view merging
SPJ - select-project-join
SJC - set join conversion
SU - subquery unnesting
OBYE - order by elimination
ST - star transformation
qb - query block
LB - leaf blocks
DK - distinct keys
LB/K - average number of leaf blocks per key
DB/K - average number of data blocks per key
CLUF - clustering factor
NDV - number of distinct values
Resp - response cost
Card - cardinality
Resc - resource cost
NL - nested loops (join)
SM - sort merge (join)
HA - hash (join)
CPUCSPEED - CPU Speed
IOTFRSPEED - I/O transfer speed
IOSEEKTIM - I/O seek time
SREADTIM - average single block read time
MREADTIM - average multiblock read time
MBRC - average multiblock read count
MAXTHR - maximum I/O system throughput
SLAVETHR - average slave I/O throughput
dmeth - distribution method
1: no partitioning required
2: value partitioned
4: right is random (round-robin)
512: left is random (round-robin)
8: broadcast right and partition left
16: broadcast left and partition right
32: partition left using partitioning of right
64: partition right using partitioning of left
128: use hash partitioning dimension
256: use range partitioning dimension
2048: use list partitioning dimension
1024: run the join in serial
0: invalid distribution method
sel - selectivity
ptn - partition
Peeked values of the binds in SQL statement
PARAMETERS USED BY THE OPTIMIZER
PARAMETERS WITH ALTERED VALUES
sort_area_retained_size = 65535
optimizer_mode = first_rows_100
optimizer_index_cost_adj = 25
optimizer_index_caching = 100
Bug Fix Control Environment
fix 4611850 = enabled
fix 4663804 = enabled
fix 4663698 = enabled
fix 4545833 = enabled
fix 3499674 = disabled
fix 4584065 = enabled
fix 4602374 = enabled
fix 4569940 = enabled
fix 4631959 = enabled
fix 4519340 = enabled
fix 4550003 = enabled
fix 4488689 = enabled
fix 3118776 = enabled
fix 4519016 = enabled
fix 4487253 = enabled
fix 4556762 = 15
fix 4728348 = enabled
fix 4723244 = enabled
fix 4554846 = enabled
fix 4175830 = enabled
fix 4722900 = enabled
fix 5094217 = enabled
fix 4904890 = enabled
fix 4483286 = disabled
fix 4969880 = disabled
fix 4711525 = enabled
fix 4717546 = enabled
fix 4904838 = enabled
fix 5005866 = enabled
fix 4600710 = enabled
fix 5129233 = enabled
fix 5195882 = enabled
fix 5084239 = enabled
fix 4595987 = enabled
fix 4134994 = enabled
fix 5104624 = enabled
fix 4908162 = enabled
fix 5015557 = enabled
PARAMETERS WITH DEFAULT VALUES
optimizer_mode_hinted = false
optimizer_features_hinted = 0.0.0
parallel_execution_enabled = true
parallel_query_forced_dop = 0
parallel_dml_forced_dop = 0
parallel_ddl_forced_degree = 0
parallel_ddl_forced_instances = 0
_query_rewrite_fudge = 90
optimizer_features_enable = 10.2.0.3
_optimizer_search_limit = 5
cpu_count = 8
active_instance_count = 2
parallel_threads_per_cpu = 2
hash_area_size = 131072
bitmap_merge_area_size = 1048576
sort_area_size = 65536
_sort_elimination_cost_ratio = 0
_optimizer_block_size = 8192
_sort_multiblock_read_count = 2
_hash_multiblock_io_count = 0
_db_file_optimizer_read_count = 32
_optimizer_max_permutations = 2000
pga_aggregate_target = 602112 KB
_pga_max_size = 204800 KB
_query_rewrite_maxdisjunct = 257
_smm_auto_min_io_size = 56 KB
_smm_auto_max_io_size = 248 KB
_smm_min_size = 602 KB
_smm_max_size = 102400 KB
_smm_px_max_size = 301056 KB
_cpu_to_io = 0
_optimizer_undo_cost_change = 10.2.0.3
parallel_query_mode = enabled
parallel_dml_mode = disabled
parallel_ddl_mode = enabled
sqlstat_enabled = false
_optimizer_percent_parallel = 101
_always_anti_join = choose
_always_semi_join = choose
_optimizer_mode_force = true
_partition_view_enabled = true
_always_star_transformation = false
_query_rewrite_or_error = false
_hash_join_enabled = true
cursor_sharing = exact
_b_tree_bitmap_plans = true
star_transformation_enabled = false
_optimizer_cost_model = choose
_new_sort_cost_estimate = true
_complex_view_merging = true
_unnest_subquery = true
_eliminate_common_subexpr = true
_pred_move_around = true
_convert_set_to_join = false
_push_join_predicate = true
_push_join_union_view = true
_fast_full_scan_enabled = true
_optim_enhance_nnull_detection = true
_parallel_broadcast_enabled = true
_px_broadcast_fudge_factor = 100
_ordered_nested_loop = true
_no_or_expansion = false
_system_index_caching = 0
_disable_datalayer_sampling = false
query_rewrite_enabled = true
query_rewrite_integrity = enforced
_query_cost_rewrite = true
_query_rewrite_2 = true
_query_rewrite_1 = true
_query_rewrite_expression = true
_query_rewrite_jgmigrate = true
_query_rewrite_fpc = true
_query_rewrite_drj = true
_full_pwise_join_enabled = true
_partial_pwise_join_enabled = true
_left_nested_loops_random = true
_improved_row_length_enabled = true
_index_join_enabled = true
_enable_type_dep_selectivity = true
_improved_outerjoin_card = true
_optimizer_adjust_for_nulls = true
_optimizer_degree = 0
_use_column_stats_for_function = true
_subquery_pruning_enabled = true
_subquery_pruning_mv_enabled = false
_or_expand_nvl_predicate = true
_like_with_bind_as_equality = false
_table_scan_cost_plus_one = true
_cost_equality_semi_join = true
_default_non_equality_sel_check = true
_new_initial_join_orders = true
_oneside_colstat_for_equijoins = true
_optim_peek_user_binds = true
_minimal_stats_aggregation = true
_force_temptables_for_gsets = false
workarea_size_policy = auto
_smm_auto_cost_enabled = true
_gs_anti_semi_join_allowed = true
_optim_new_default_join_sel = true
optimizer_dynamic_sampling = 2
_pre_rewrite_push_pred = true
_optimizer_new_join_card_computation = true
_union_rewrite_for_gs = yes_gset_mvs
_generalized_pruning_enabled = true
_optim_adjust_for_part_skews = true
_force_datefold_trunc = false
statistics_level = typical
_optimizer_system_stats_usage = true
skip_unusable_indexes = true
_remove_aggr_subquery = true
_optimizer_push_down_distinct = 0
_dml_monitoring_enabled = true
_optimizer_undo_changes = false
_predicate_elimination_enabled = true
_nested_loop_fudge = 100
_project_view_columns = true
_local_communication_costing_enabled = true
_local_communication_ratio = 50
_query_rewrite_vop_cleanup = true
_slave_mapping_enabled = true
_optimizer_cost_based_transformation = linear
_optimizer_mjc_enabled = true
_right_outer_hash_enable = true
_spr_push_pred_refspr = true
_optimizer_cache_stats = false
_optimizer_cbqt_factor = 50
_optimizer_squ_bottomup = true
_fic_area_size = 131072
_optimizer_skip_scan_enabled = true
_optimizer_cost_filter_pred = false
_optimizer_sortmerge_join_enabled = true
_optimizer_join_sel_sanity_check = true
_mmv_query_rewrite_enabled = true
_bt_mmv_query_rewrite_enabled = true
_add_stale_mv_to_dependency_list = true
_distinct_view_unnesting = false
_optimizer_dim_subq_join_sel = true
_optimizer_disable_strans_sanity_checks = 0
_optimizer_compute_index_stats = true
_push_join_union_view2 = true
_optimizer_ignore_hints = false
_optimizer_random_plan = 0
_query_rewrite_setopgrw_enable = true
_optimizer_correct_sq_selectivity = true
_disable_function_based_index = false
_optimizer_join_order_control = 3
_optimizer_cartesian_enabled = true
_optimizer_starplan_enabled = true
_extended_pruning_enabled = true
_optimizer_push_pred_cost_based = true
_sql_model_unfold_forloops = run_time
_enable_dml_lock_escalation = false
_bloom_filter_enabled = true
_update_bji_ipdml_enabled = 0
_optimizer_extended_cursor_sharing = udo
_dm_max_shared_pool_pct = 1
_optimizer_cost_hjsmj_multimatch = true
_optimizer_transitivity_retain = true
_px_pwg_enabled = true
optimizer_secure_view_merging = true
_optimizer_join_elimination_enabled = true
flashback_table_rpi = non_fbt
_optimizer_cbqt_no_size_restriction = true
_optimizer_enhanced_filter_push = true
_optimizer_filter_pred_pullup = true
_rowsrc_trace_level = 0
_simple_view_merging = true
_optimizer_rownum_pred_based_fkr = true
_optimizer_better_inlist_costing = all
_optimizer_self_induced_cache_cost = false
_optimizer_min_cache_blocks = 10
_optimizer_or_expansion = depth
_optimizer_order_by_elimination_enabled = true
_optimizer_outer_to_anti_enabled = true
_selfjoin_mv_duplicates = true
_dimension_skip_null = true
_force_rewrite_enable = false
_optimizer_star_tran_in_with_clause = true
_optimizer_complex_pred_selectivity = true
_optimizer_connect_by_cost_based = true
_gby_hash_aggregation_enabled = true
_globalindex_pnum_filter_enabled = true
_fix_control_key = 0
_optimizer_skip_scan_guess = false
_enable_row_shipping = false
_row_shipping_threshold = 80
_row_shipping_explain = false
_optimizer_rownum_bind_default = 10
_first_k_rows_dynamic_proration = true
_optimizer_native_full_outer_join = off
Bug Fix Control Environment
fix 4611850 = enabled
fix 4663804 = enabled
fix 4663698 = enabled
fix 4545833 = enabled
fix 3499674 = disabled
fix 4584065 = enabled
fix 4602374 = enabled
fix 4569940 = enabled
fix 4631959 = enabled
fix 4519340 = enabled
fix 4550003 = enabled
fix 4488689 = enabled
fix 3118776 = enabled
fix 4519016 = enabled
fix 4487253 = enabled
fix 4556762 = 15
fix 4728348 = enabled
fix 4723244 = enabled
fix 4554846 = enabled
fix 4175830 = enabled
fix 4722900 = enabled
fix 5094217 = enabled
fix 4904890 = enabled
fix 4483286 = disabled
fix 4969880 = disabled
fix 4711525 = enabled
fix 4717546 = enabled
fix 4904838 = enabled
fix 5005866 = enabled
fix 4600710 = enabled
fix 5129233 = enabled
fix 5195882 = enabled
fix 5084239 = enabled
fix 4595987 = enabled
fix 4134994 = enabled
fix 5104624 = enabled
fix 4908162 = enabled
fix 5015557 = enabled
PARAMETERS IN OPT_PARAM HINT
Column Usage Monitoring is ON: tracking level = 1
COST-BASED QUERY TRANSFORMATIONS
FPD: Considering simple filter push (pre rewrite) in SEL$1 (#0)
FPD: Current where clause predicates in SEL$1 (#0) :
"CDW"."COT_EXTERNAL_ID"=ANY (SELECT TO_CHAR("O"."ORDER_ID") FROM "ORDERS" "O")
Registered qb: SEL$1 0x974658b0 (COPY SEL$1)
signature(): NULL
Registered qb: SEL$2 0x9745e408 (COPY SEL$2)
signature(): NULL
Cost-Based Subquery Unnesting
SU: No subqueries to consider in query block SEL$2 (#2).
SU: Considering subquery unnesting in query block SEL$1 (#1)
SU: Performing unnesting that does not require costing.
SU: Considering subquery unnest on SEL$1 (#1).
SU: Checking validity of unnesting subquery SEL$2 (#2)
SU: Passed validity checks.
SU: Transforming ANY subquery to a join.
Registered qb: SEL$5DA710D3 0x974658b0 (SUBQUERY UNNEST SEL$1; SEL$2)
signature (): qb_name=SEL$5DA710D3 nbfros=2 flg=0
fro(0): flg=0 objn=51893 hint_alias="CDW"@"SEL$1"
fro(1): flg=0 objn=51782 hint_alias="O"@"SEL$2"
Cost-Based Complex View Merging
CVM: Finding query blocks in SEL$5DA710D3 (#1) that are valid to merge.
SU: Transforming ANY subquery to a join.
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$5DA710D3 (#1).
Query block (0x2a973e5458) before join elimination:
SQL:******* UNPARSED QUERY IS *******
SELECT "CDW".* FROM "COT_PLUS"."ORDERS" "O","COT_PLUS"."CDW_ORDERS" "CDW" WHERE "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
Query block (0x2a973e5458) unchanged
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$5DA710D3 (#1).
PM: Checking validity of predicate move-around in SEL$5DA710D3 (#1).
PM: PM bypassed: Outer query contains no views.
JPPD: Applying transformation directives
JPPD: Checking validity of push-down in query block SEL$5DA710D3 (#1)
JPPD: No view found to push predicate into.
FPD: Considering simple filter push in SEL$5DA710D3 (#1)
FPD: Current where clause predicates in SEL$5DA710D3 (#1) :
"CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
kkogcp: try to generate transitive predicate from check constraints for SEL$5DA710D3 (#1)
predicates with check contraints: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
after transitive predicate generation: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
finally: "CDW"."COT_EXTERNAL_ID"=TO_CHAR("O"."ORDER_ID") AND "O"."STATUS_ID"=22
First K Rows: Setup begin
kkoqbc-start
: call(in-use=1592, alloc=16344), compile(in-use=101000, alloc=134224)
QUERY BLOCK TEXT
select cdw.* from cdw_orders cdw where cdw.cot_external_id in (select to_char(o.order_id) from orders o where status_id = 22)
QUERY BLOCK SIGNATURE
qb name was generated
signature (optimizer): qb_name=SEL$5DA710D3 nbfros=2 flg=0
fro(0): flg=0 objn=51893 hint_alias="CDW"@"SEL$1"
fro(1): flg=0 objn=51782 hint_alias="O"@"SEL$2"
SYSTEM STATISTICS INFORMATION
Using NOWORKLOAD Stats
CPUSPEED: 714 millions instruction/sec
IOTFRSPEED: 4096 bytes per millisecond (default is 4096)
IOSEEKTIM: 10 milliseconds (default is 10)
BASE STATISTICAL INFORMATION
Table Stats::
Table: CDW_ORDERS Alias: CDW
#Rows: 3375 #Blks: 1504 AvgRowLen: 132.00
Index Stats::
Index: CDW_ORD_COT_EXT_ID Col#: 10
LVLS: 1 #LB: 232 #DK: 1878 LB/K: 1.00 DB/K: 1.00 CLUF: 1899.00
Index: CDW_ORD_REFERENCE_IDX Col#: 13
LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00
Index: COMMITTED_IDX Col#: 12
LVLS: 1 #LB: 171 #DK: 1673 LB/K: 1.00 DB/K: 1.00 CLUF: 1657.00
Index: OBJID_IDX Col#: 16 17
LVLS: 2 #LB: 318 #DK: 3372 LB/K: 1.00 DB/K: 1.00 CLUF: 1901.00
Index: ORDID_IDX Col#: 14
LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00
Table Stats::
Table: ORDERS Alias: O
#Rows: 178253 #Blks: 7300 AvgRowLen: 282.00
Index Stats::
Index: IDX_ORDERS_CONFIG Col#: 80
LVLS: 1 #LB: 215 #DK: 452 LB/K: 1.00 DB/K: 130.00 CLUF: 59161.00
Index: IDX_ORDERS_REFRENCE_NUMBER Col#: 6
LVLS: 1 #LB: 428 #DK: 68698 LB/K: 1.00 DB/K: 1.00 CLUF: 115830.00
Index: ORDERS_BILLING_SI_IDX Col#: 13
LVLS: 1 #LB: 84 #DK: 3049 LB/K: 1.00 DB/K: 8.00 CLUF: 27006.00
Index: ORDERS_LATEST_ORD_IDX Col#: 3
LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00
Index: ORDERS_ORDER_TYPE_IDX Col#: 4
LVLS: 2 #LB: 984 #DK: 64 LB/K: 15.00 DB/K: 932.00 CLUF: 59702.00
Index: ORDERS_ORD_MINOR__IDX Col#: 43 5
LVLS: 2 #LB: 784 #DK: 112 LB/K: 7.00 DB/K: 375.00 CLUF: 42012.00
Index: ORDERS_OWNING_ORG_IDX Col#: 37
LVLS: 0 #LB: 0 #DK: 0 LB/K: 0.00 DB/K: 0.00 CLUF: 0.00
Index: ORDERS_PARENT_ORD_IDX Col#: 2
LVLS: 1 #LB: 206 #DK: 37492 LB/K: 1.00 DB/K: 1.00 CLUF: 58051.00
Index: ORDERS_SD_CONFIG__IDX Col#: 42
LVLS: 2 #LB: 604 #DK: 10 LB/K: 60.00 DB/K: 3638.00 CLUF: 36389.00
Index: ORDERS_SPECIAL_OR_IDX Col#: 36
LVLS: 1 #LB: 63 #DK: 2 LB/K: 31.00 DB/K: 556.00 CLUF: 1113.00
Index: ORDERS_STATUS_ID_IDX Col#: 5
LVLS: 2 #LB: 635 #DK: 25 LB/K: 25.00 DB/K: 1440.00 CLUF: 36015.00
Index: PK_ORDERS Col#: 1
LVLS: 1 #LB: 408 #DK: 178253 LB/K: 1.00 DB/K: 1.00 CLUF: 131025.00
SINGLE TABLE ACCESS PATH
Column (#5): STATUS_ID(NUMBER)
AvgLen: 3.00 NDV: 20 Nulls: 0 Density: 2.7653e-06 Min: 2 Max: 33
Histogram: Freq #Bkts: 20 UncompBkts: 5567 EndPtVals: 20
Table: ORDERS Alias: O
Card: Original: 178253 Rounded: 95450 Computed: 95450.37 Non Adjusted: 95450.37
Access Path: TableScan
Cost: 1419.89 Resp: 1419.89 Degree: 0
Cost_io: 1408.00 Cost_cpu: 101897352
Resp_io: 1408.00 Resp_cpu: 101897352
kkofmx: index filter:"O"."STATUS_ID"=22
Access Path: index (skip-scan)
SS sel: 0.53548 ANDV (#skips): 60
SS io: 419.81 vs. table scan io: 1408.00
Skip Scan chosen
Access Path: index (SkipScan)
Index: ORDERS_ORD_MINOR__IDX
resc_io: 22918.81 resc_cpu: 204258888
ix_sel: 0.53548 ix_sel_with_filters: 0.53548
Cost: 5735.66 Resp: 5735.66 Degree: 1
Access Path: index (AllEqRange)
Index: ORDERS_STATUS_ID_IDX
resc_io: 19629.00 resc_cpu: 180830676
ix_sel: 0.53548 ix_sel_with_filters: 0.53548
Cost: 4912.53 Resp: 4912.53 Degree: 1
****** trying bitmap/domain indexes ******
Best:: AccessPath: TableScan
Cost: 1419.89 Degree: 1 Resp: 1419.89 Card: 95450.37 Bytes: 0
SINGLE TABLE ACCESS PATH
Table: CDW_ORDERS Alias: CDW
Card: Original: 3375 Rounded: 3375 Computed: 3375.00 Non Adjusted: 3375.00
Access Path: TableScan
Cost: 292.51 Resp: 292.51 Degree: 0
Cost_io: 291.00 Cost_cpu: 12971896
Resp_io: 291.00 Resp_cpu: 12971896
Best:: AccessPath: TableScan
Cost: 292.51 Degree: 1 Resp: 292.51 Card: 3375.00 Bytes: 0
OPTIMIZER STATISTICS AND COMPUTATIONS
GENERAL PLANS
Considering cardinality-based initial join order.
Permutations for Starting Table :0
Join order[1]: CDW_ORDERS[CDW]#0 ORDERS[O]#1
Now joining: ORDERS[O]#1
NL Join
Outer table: Card: 3375.00 Cost: 292.51 Resp: 292.51 Degree: 1 Bytes: 132
Inner table: ORDERS Alias: O
Access Path: TableScan
NL Join: Cost: 4788284.86 Resp: 4788284.86 Degree: 0
Cost_io: 4748144.00 Cost_cpu: 343916534896
Resp_io: 4748144.00 Resp_cpu: 343916534896
kkofmx: index filter:"O"."STATUS_ID"=22
OPTIMIZER PERCENT INDEX CACHING = 100
Access Path: index (FullScan)
Index: ORDERS_ORD_MINOR__IDX
resc_io: 22497.00 resc_cpu: 217815366
ix_sel: 1 ix_sel_with_filters: 0.53548
NL Join: Cost: 19004464.41 Resp: 19004464.41 Degree: 1
Cost_io: 18982134.75 Cost_cpu: 191314735126
Resp_io: 18982134.75 Resp_cpu: 191314735126
OPTIMIZER PERCENT INDEX CACHING = 100
Access Path: index (AllEqJoin)
Index: ORDERS_STATUS_ID_IDX
resc_io: 1.00 resc_cpu: 7981
ix_sel: 1.0477e-05 ix_sel_with_filters: 1.0477e-05
NL Join: Cost: 1137.05 Resp: 1137.05 Degree: 1
Cost_io: 1134.75 Cost_cpu: 19706236
Resp_io: 1134.75 Resp_cpu: 19706236
****** trying bitmap/domain indexes ******
Best NL cost: 1137.05
resc: 1137.05 resc_io: 1134.75 resc_cpu: 19706236
resp: 1137.05 resp_io: 1134.75 resp_cpu: 19706236
adjusting AJ/SJ sel based on min/max ranges: jsel=min(1, 6.1094e-04)Semi Join Card: 2.06 = outer (3375.00) * sel (6.1094e-04)
Join Card - Rounded: 2 Computed: 2.06
SM Join
Outer table:
resc: 292.51 card 3375.00 bytes: 132 deg: 1 resp: 292.51
Inner table: ORDERS Alias: O
resc: 1419.89 card: 95450.37 bytes: 8 deg: 1 resp: 1419.89
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 598 Area size: 616448 Max Area size: 104857600
Degree: 1
Blocks to Sort: 65 Row size: 156 Total Rows: 3375
Initial runs: 1 Merge passes: 0 IO Cost / pass: 0
Total IO sort cost: 0 Total CPU sort cost: 10349977
Total Temp space used: 0
SORT resource Sort statistics
Sort width: 598 Area size: 616448 Max Area size: 104857600
Degree: 1
Blocks to Sort: 223 Row size: 19 Total Rows: 95450
Initial runs: 2 Merge passes: 1 IO Cost / pass: 122
Total IO sort cost: 345 Total CPU sort cost: 85199490
Total Temp space used: 3089000
SM join: Resc: 2068.56 Resp: 2068.56 [multiMatchCost=0.00]
SM cost: 2068.56
resc: 2068.56 resc_io: 2044.00 resc_cpu: 210418716
resp: 2068.56 resp_io: 2044.00 resp_cpu: 210418716
SM Join (with index on outer)
Access Path: index (FullScan)
Index: CDW_ORD_COT_EXT_ID
resc_io: 2132.00 resc_cpu: 18119160
ix_sel: 1 ix_sel_with_filters: 1
Cost: 533.53 Resp: 533.53 Degree: 1
Outer table:
resc: 533.53 card 3375.00 bytes: 132 deg: 1 resp: 533.53
Inner table: ORDERS Alias: O
resc: 1419.89 card: 95450.37 bytes: 8 deg: 1 resp: 1419.89
using dmeth: 2 #groups: 1
SORT resource Sort statistics
Sort width: 598 Area size: 616448 Max Area size: 104857600
Degree: 1
Blocks to Sort: 223 Row size: 19 Total Rows: 95450
Initial runs: 2 Merge passes: 1 IO Cost / pass: 122
Total IO sort cost: 345 Total CPU sort cost: 85199490
Total Temp space used: 3089000
SM join: Resc: 2308.37 Resp: 2308.37 [multiMatchCost=0.00]
HA Join
Outer table:
resc: 292.51 card 3375.00 bytes: 132 deg: 1 resp: 292.51
Inner table: ORDERS Alias: O
resc: 1419.89 card: 95450.37 bytes: 8 deg: 1 resp: 1419.89
using dmeth: 2 #groups: 1
Cost per ptn: 1.67 #ptns: 1
hash_area: 151 (max=25600) Hash join: Resc: 1714.08 Resp: 1714.08 [multiMatchCost=0.00]
HA cost: 1714.08
resc: 1714.08 resc_io: 1699.00 resc_cpu: 129204369
resp: 1714.08 resp_io: 1699.00 resp_cpu: 129204369
Best:: JoinMethod: NestedLoopSemi
Cost: 1137.05 Degree: 1 Resp: 1137.05 Card: 2.06 Bytes: 140
Best so far: Table#: 0 cost: 292.5140 card: 3375.0000 bytes: 445500
Table#: 1 cost: 1137.0501 card: 2.0619 bytes: 280
Number of join permutations tried: 1
(newjo-save) [0 1 ]
Final - All Rows Plan: Best join order: 1
Cost: 1137.0501 Degree: 1 Card: 2.0000 Bytes: 280
Resc: 1137.0501 Resc_io: 1134.7500 Resc_cpu: 19706236
Resp: 1137.0501 Resp_io: 1134.7500 Resc_cpu: 19706236
kkoipt: Query block SEL$5DA710D3 (#1)
kkoqbc-end
: call(in-use=156048, alloc=164408), compile(in-use=103696, alloc=134224)
First K Rows: Setup end
*********************** -
Report Issue - A subquery filter may not reference the current report
Hi,
I a, trying to create a drill down report - I am getting below error when I drill down from summary report to detail -
A subquery filter may not reference the current report (or contain a circular reference to any report).
Error Details
Error Codes: S6C66RYK:WIF3IYGO
Recursion limit exceeded in Xml Expression Visitor
The issue is I have a budget report which will drill down to display amount by each period -
Jan-10 Feb-10 Mar-10
1223 123 10
Now I am trying to display detail GL transactions by clicking the amount field.
This means summary report should pass period along with amount to display detail GL transactions.
Please help me to resolve this issue.
Thanks,
PoojakExplain exactly how you create your 2 reports.
The second one must have "is prompted" filters if you want it to use the values of the first one. -
Hi All,
Oracle v11.2.0.2
I have a SELECT query which executes in less than a second and selects few records.
Now, if I put this SELECT query in IN clause of a DELETE command, that takes ages (even when DELETE is done using its primary key).
See below query and execution plan.
Here is the SELECT query
SQL> SELECT ITEM_ID
2 FROM APP_OWNER.TABLE1
3 WHERE COLUMN1 = 'SomeValue1234'
4 OR (COLUMN1 LIKE 'SomeValue1234%'
5 AND REGEXP_LIKE (
6 COLUMN1,
7 '^SomeValue1234[A-Z]{3}[0-9]{5}$'
8 ));
ITEM_ID
74206192
1 row selected.
Elapsed: 00:00:40.87
Execution Plan
Plan hash value: 3153606419
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 2 | 38 | 7 (0)| 00:00:01 |
| 1 | CONCATENATION | | | | | |
|* 2 | INDEX RANGE SCAN | PK_TABLE1 | 1 | 19 | 4 (0)| 00:00:01 |
|* 3 | INDEX UNIQUE SCAN| PK_TABLE1 | 1 | 19 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - access("COLUMN1" LIKE 'SomeValue1234%')
filter("COLUMN1" LIKE 'SomeValue1234%' AND REGEXP_LIKE
("COLUMN1",'^SomeValue1234[A-Z]{3}[0-9]{5}$'))
3 - access("COLUMN1"='SomeValue1234')
filter(LNNVL("COLUMN1" LIKE 'SomeValue1234%') OR LNNVL(
REGEXP_LIKE ("COLUMN1",'^SomeValue1234[A-Z]{3}[0-9]{5}$')))
Statistics
0 recursive calls
0 db block gets
8 consistent gets
0 physical reads
0 redo size
348 bytes sent via SQL*Net to client
360 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processedNow see the DELETE command. ITEM_ID is the primary key for TABLE2
SQL> delete from TABLE2 where ITEM_ID in (
2 SELECT ITEM_ID
3 FROM APP_OWNER.TABLE1
4 WHERE COLUMN1 = 'SomeValue1234'
5 OR (COLUMN1 LIKE 'SomeValue1234%'
6 AND REGEXP_LIKE (
7 COLUMN1,
8 '^SomeValue1234[A-Z]{3}[0-9]{5}$'
9 ))
10 );
1 row deleted.
Elapsed: 00:02:12.98
Execution Plan
Plan hash value: 173781921
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | DELETE STATEMENT | | 4 | 228 | 63490 (2)| 00:12:42 |
| 1 | DELETE | TABLE2 | | | | |
| 2 | NESTED LOOPS | | 4 | 228 | 63490 (2)| 00:12:42 |
| 3 | SORT UNIQUE | | 1 | 19 | 63487 (2)| 00:12:42 |
|* 4 | INDEX FAST FULL SCAN| I_TABLE1_3 | 1 | 19 | 63487 (2)| 00:12:42 |
|* 5 | INDEX RANGE SCAN | PK_TABLE2 | 7 | 266 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter("COLUMN1"='SomeValue1234' OR "COLUMN1" LIKE 'SomeValue1234%' AND
REGEXP_LIKE ("COLUMN1",'^SomeValue1234[A-Z]{3}[0-9]{5}$'))
5 - access("ITEM_ID"="ITEM_ID")
Statistics
1 recursive calls
5 db block gets
227145 consistent gets
167023 physical reads
752 redo size
765 bytes sent via SQL*Net to client
1255 bytes received via SQL*Net from client
4 SQL*Net roundtrips to/from client
3 sorts (memory)
0 sorts (disk)
1 rows processedWhat can be the issue here?
I tried NO_UNNEST hint, which made difference, but still the DELETE was taking around a minute (instead of 2 minutes), but that is way more than that sub-second response.
Thanks in advancerahulras wrote:
SQL> delete from TABLE2 where ITEM_ID in (
2 SELECT ITEM_ID
3 FROM APP_OWNER.TABLE1
4 WHERE COLUMN1 = 'SomeValue1234'
5 OR (COLUMN1 LIKE 'SomeValue1234%'
6 AND REGEXP_LIKE (
7 COLUMN1,
8 '^SomeValue1234[A-Z]{3}[0-9]{5}$'
9 ))
10 );
The optimizer will transform this delete statement into something like:
delete from table2 where rowid in (
select t2.rowid
from
table2 t2,
table1 t1
where
t1.itemid = t2.itemid
and (t1.column1 = etc.... )
)With the standalone subquery against t1 the optimizer has been a little clever with the concatenation operation, but it looks as if there is something about this transformed join that makes it impossible for the concatenation mechanism to be used. I'd also have to guess that something about the way the transformation has happened has made Oracle "lose" the PK index. As I said in another thread a few minutes ago, I don't usually look at 10053 trace files to solve optimizer problems - but this is the second one today where I'd start looking at the trace if it were my problem.
You could try rewriting the query in this explicit join and select rowid form - that way you could always force the optimizer into the right path through table1. It's probably also possible to hint the original to make the expected path appear, but since the thing you hint and the thing that Oracle optimises are so different it might turn out to be a little difficult. I'd suggest raising an SR with Oracle.
Regards
Jonathan Lewis -
SELECT m_label, (SELECT COUNT(c_id) FROM tbl_count WHERE tbl_main_fk = m_id) AS totalCount
FROM tbl_main
It's a simple subquery code to get the total count of the related table, and the result return perfectly when I click test, but it will fail in control panel, how to solve the problem?It's definitely a bug in Dreamweaver. I have created a couple of tables using your structure, and it works fine in both phpMyAdmin and the Test panel of the Recordset dialog box. However, it triggers a MySQL error in the Bindings panel.
I have done some testing, and discovered that the query is being corrupted somehow. What is actually being submitted to the database by the Bindings panel is this:
SELECT a.*, (SELECT p.p_img FROM tbl_photos p
WHERE 0 = 1
I also tried your query without the table aliases like this:
SELECT tbl_album.*, (SELECT p_img FROM tbl_photos
WHERE tbl_album_fk = tbl_album.a_id AND p_cover = 1 LIMIT 0, 1)
AS coverImg FROM tbl_album
This resulted in the same problem:
SELECT tbl_album.*, (SELECT p_img FROM tbl_photos
WHERE 0 = 1
So, for some reason, it's being truncated after the table name in the subquery. I have no idea why.
I'm in touch with Dreamweaver engineers, and will raise this issue with them, but I doubt if there will be a rapid solution to this problem. -
Inner Subquery Issue....
Hi All,
I have a query as under:
Select calendar_date, man_days_demand
from (
select calendar_date,
( --Man_days_demand calculation
select count(fsr)
from t1,t2,t3,(select region_id from t4
union
select region_id from t3 ) TAB1
where tab1.region_id = '®ion_id'
) Man_days_demand
from calendar_fiscal_viewI am facing the problem with TAB1 inner subquery. the region that i am getting from TAB1 is compared to input of region_id but it is not working. It may be because inner subquery is executed first and hence any region i am inputting is not getting compared to region_id extracted from TAB1..
can anybody suggest alternate query or resolution to thsi issue as i need to compare the region coming from TAB1 to my input region.
Thanks,
JPHi,
I am posting my actual query:
SELECT calendar_date timeperiod,
man_days_demand demand
FROM (
SELECT cal.calendar_date calendar_date,
(-- in line column qry to count the service reqs falling on that specific day
-- DEMAND
SELECT decode(nvl(sum(count(ssrj.field_service_rep)),0),0,0,1)
FROM sop_service_request_job ssrj, sop_service_request ssr,
sop_service_user ssu, sop_user_map smp1 /*(\*select distinct region_id, ssu.sso_id sso_id
from sop_user_map smp,sop_service_user ssu
where smp.sso_id = ssu.sso_id and role_id = 1 *\
select region_id, sso_id
from sop_user_map smp
where role_id = 1
and upper(nvl(smp.region_id, 'test')) like
upper(nvl('%®ion_id%', 'test'))
union
select region_id, to_number(field_service_rep)
from sop_service_request_job ssrj, sop_service_request ssr
where ssr.service_request_id = ssrj.service_request_id
and field_service_rep is not null
and region_id is not null
and region_id != '~'
and upper(nvl(ssr.region_id, 'test')) like
upper(nvl('%®ion_id%', 'test'))
\*and ssrj.job_status = 'ASSIGNED'*\
and ssr.workflow_status in ('SUBMITTED','APPROVED','PARTIAL ASSIGNMENT','ASSIGNED','PENDING REVIEW','CLOSED')
) tab1*/
WHERE (((cal.calendar_date between ssrj.scheduled_start_date AND
get_end_date(ssrj.scheduled_start_date,
ssrj.expected_service_hours,
ssrj.weekend)))
OR
(cal.calendar_date < ssrj.scheduled_start_date and
cal.calendar_date > get_end_date(ssrj.scheduled_start_date,
ssrj.expected_service_hours,
ssrj.weekend)))
and ssrj.service_request_id = ssr.service_request_id
and smp1.sso_id = ssu.sso_id
and smp1.sso_id = ssrj.field_service_rep
and ssrj.field_service_rep is not null
/*and ssrj.job_status = 'ASSIGNED'*/
and ssr.workflow_status in ('SUBMITTED','APPROVED','PARTIAL ASSIGNMENT','ASSIGNED','PENDING REVIEW','CLOSED')
and ssu.sso_id = ssrj.field_service_rep
and nvl(ssu.sso_id,0) like nvl('%&ssoid%',0)
--and ssu.sso_id = tab1.sso_id
and smp1.region_id in (
select region_id
from sop_user_map smp
where role_id = 1
and upper(nvl(smp.region_id, 'test')) like
upper(nvl('%®ion_id%', 'test'))
union
select region_id
from sop_service_request_job ssrj, sop_service_request ssr
where ssr.service_request_id = ssrj.service_request_id
and field_service_rep is not null
and region_id is not null
and region_id != '~'
and upper(nvl(ssr.region_id, 'test')) like
upper(nvl('%®ion_id%', 'test'))
--and ssrj.job_status = 'ASSIGNED'
and ssr.workflow_status in ('SUBMITTED','APPROVED','PARTIAL ASSIGNMENT','ASSIGNED','PENDING REVIEW','CLOSED')
and upper(nvl(ssu.qualification,'test')) like upper(nvl('%&qualification%','test'))
and upper(nvl(ssr.platform_type,'test')) like upper(nvl('%&platform_name%','test'))
and upper(nvl(ssu.country,'test')) like upper(nvl('%&country%','test'))
--and upper(nvl(tab1.region_id,'test')) like upper(nvl('%®ion_id%','test'))
-- and upper(nvl(tab1.region_id,'test')) like upper(nvl('%®ion_id%','test'))
and upper(nvl(ssrj.weekend,'test')) like upper(nvl('%&weekend%','test'))
and upper(nvl(ssu.state,'test')) like upper(nvl('%&state%','test'))
GROUP BY calendar_date
) Man_Days_demand
from sop_fiscal_calendar_v cal
WHERE
calendar_date BETWEEN trunc(to_date('&date_range_start_date','mm/dd/yyyy'))
AND trunc(to_date('&date_range_end_date','mm/dd/yyyy'))
)This is also not working.. I need to filter by region...
Thanks,
JP -
XML Unnesting and In Memory issue
I have a source table in oracle that contains a column (Nclob) that have XML messages and my target is BW data souce
I build my job like that
Source Table------Quey1 (to convert to varchar)-------------Query2(Unnest XML using extract_xml)-----------------BW Target
I successfully running the job with small test data in source (About 100,000 records) takes about 30 minutes
But when I running with the actual table contains about 140000000 it takes so long time my be more than 12 hours and never ending and it is affect the job server so I decide to kill the job
I checked the log I found that the job running in im memory mode instead of peagable because it is nested schema
I need help to enhance this job and let running successfullyDo you mean that I need to remove Query transform that do extract_xml from the column and instead of it use XML_Pipeline?
I tried but I found XML_pipeline only accept files not database -
Subquery Factoring -Performance Issue
Hi experts,
Oracle 10G
select
a.colums,
b.columns
from
( select
Colums
from
F ,
(select
columns
from
bigtable
where
<condition with recdate and modified date with timezone convertions Given as in end of this qury)
) a,
( select
Colums
from
tables,
(select
columns
from
bigtable
where
<condition with recdate and modified date with timezone convertions Given as in end of this qury)
) b
(TO_DATE(TO_CHAR(FROM_TZ(CAST(CF.RECDT as timestamp),'GMT') at time zone 'America/Chicago','YYYY-MM-DD
HH24:MI:SS'),'YYYY-MM-DD HH24:MI:SS')
BETWEEN TO_DATE('01-JAN-2009 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('08-JAN-2009 00:00:00', 'DD-MON-YYYY
HH24:MI:SS')) OR
(TO_DATE(TO_CHAR(FROM_TZ(CAST(CF.MODIFID_DT as timestamp),'GMT') at time zone 'America/Chicago','YYYY-MM-DD
HH24:MI:SS'),'YYYY-MM-DD HH24:MI:SS')
BETWEEN TO_DATE('01-JAN-2009 00:00:00','DD-MON-YYYY HH24:MI:SS') AND TO_DATE('08-JAN-2009 00:00:00', 'DD-MON-YYYY
HH24:MI:SS'))
Recdt - indexed
Modifieddt - not iddexed
bigtable used many times in select to avoid Subquery factoring used (with select) but it increased cost as per explain plan in sqldevleoper please suggest me to increase performance
Lots of thanks,
Kalinganow the above query use as
with subfact as
( select
select
columns
from
bigtable
where
<condition with recdate and modified date
select
a.colums,
b.columns
from
( select
Colums
from
F ,
subfact
where condition
) a,
( select
Colums
from
tables,
subfact
where condition
) b
it is cost increased in nested loop in explain plan why? is thre any other detail required.
Maybe you are looking for
-
When I take a picture with iphone 4s the phone dies. I hold power button to power up. Thanks for any Help.
-
I have a routine in my update rule that performs a lookup to another ODS. To improve my performance I would like to try writing a temporary variable to memory that can then be referenced when loading each record. For example here's some pseudo code
-
Will my Macromedia Studio MX 2004 run on Windows 8?
Will my Macromedia Studio MX 2004 run on Windows 8? I'm planning to update from Windows 7 (where everythings works perfectly fine) to Windows 8.
-
CS3 script runs slow with CS4 and CS5
I have written a table transformation script for InDesign CS3, which formats an imported Excel table. With InDesign CS3 the script runs well. Now I tried the same script with InDesign CS4 and CS5 and it runs very slow. It's about 10 times slower than
-
Hi, I have done some package link in some applications. I want to implement another one in another application. When I try to insert the first step of the package link I retrieve this message: "Run time error 35602 Key is not unique in collection" An