Merge By ROWID, Implications
Hi,
could someone give me a run down of the implications of MERGE by ROWID in such a fashion:
MERGE
INTO XXWT_AP_ACCRUALS_RECEIPT_F EXT
USING (
SELECT PO_DISTRIBUTION_ID,
ROWID AS ARR_ROWID,
FUNC_ACCRUAL_AMOUNT * ((QUANTITY_RECEIVED_ATOMIC - QUANTITY_BILLED_ATOMIC)
/ SUM( QUANTITY_RECEIVED_ATOMIC-QUANTITY_BILLED_ATOMIC) OVER (PARTITION BY PO_DISTRIBUTION_ID) ) AS ACCRUAL_AMOUNT_ATOMIC
FROM XXWT_AP_ACCRUALS_RECEIPT_F AAR
WHERE PO_DISTRIBUTION_ID IS NOT NULL
AND PERIOD_KEY = LN_PERIOD_KEY
AND SEGMENT1_LEGAL_ENTITY = LV_COMPANY
AND NVL(QUANTITY_ACCRUED,0) !=0
) SUB
ON (
EXT.ROWID = SUB.ARR_ROWID
WHEN MATCHED THEN
UPDATE SET EXT.ACCRUAL_AMOUNT_ATOMIC = SUB.ACCRUAL_AMOUNT_ATOMIC
Can this lead to an "Unstable Set of Rows?". Is it possible for the ROWID's to change during the execution of this statement - meaning certain ROWIDs identified in the SELECT will not actually be updated when it comes to the MERGE operation?
Basically, is it sound practice to use ROWID to merge on - in cases where you dont have a WHEN NOT MATCHED condition?
Thanks in advance for any input......
Sorry Michael my mistake. I should have thought so.
But, do complete the prove that this makes the ROWID update not recommended it should work work with the PK right?
merge into t
using (select rowid rid, t.* from t where n = 1 union all
select rowid rid, t.* from t where n = 1) t2
on (t.n = t2.n)
when matched
then update set n = 2
Fehler bei Befehlszeile:4 Spalte:12
Fehlerbericht:
SQL-Fehler: ORA-38104: Columns referenced in the ON Clause cannot be updated: "T"."N"
38104. 00000 - "Columns referenced in the ON Clause cannot be updated: %s"Of course you can build an example where the PK stays but the rowid changes. E.g. having a sub-partition on an additional field. But, at the end, can this be the reason of generally not using ROWID in MERGE, even it's faster? The fact that when you (by purpose??!) update the same row more than once, it does not work?
I better to get an error on this than having a performance, or even worse a logical issue.
The fastest thing is NOT to do something if you can, followed by doing it once,... doing it multiple times.. and make the code that it can... I don't know.
But thanks anyhow for the example :-) I really have not thought of that.
Similar Messages
-
Dear Friends,
We are in the process of merging 2 company codes (say1000 & 1200) in one of our customers into a new company code 1800. I would invite valuable suggestion from my forum friends on the following
1. Is there anyway we can transfer the entire master data from the two existing company codes to the new company code. It is an intra SAP data transfer, so the implications would be different.
2.How do we treat the open sales & purchase orders, Open deliveries and open billing documents before we go live on 1st of April.
3. What all balances needs to be transferred from the existing company codes to the new company code.
4.After the cut over, do we need to delete the existing customers/Vendors in the earlier company codes.
As we are doing this process for the very first time, we would be requiring your valuable suggestion on the above processes.
Thanks & regardsDear Friends,
We are in the process of merging 2 company codes (say1000 & 1200) in one of our customers into a new company code 1800. I would invite valuable suggestion from my forum friends on the following
1. Is there anyway we can transfer the entire master data from the two existing company codes to the new company code. It is an intra SAP data transfer, so the implications would be different. Means the customers/vendors need to be extended to the new company code & sales areas.
2.How do we treat the open sales & purchase orders, Open deliveries and open billing documents before we go live on 1st of April.
3. What all balances needs to be transferred from the existing company codes to the new company code.
4.After the cut over, do we need to delete the existing customers/Vendors in the earlier company codes.
As we are doing this process for the very first time, we would be requiring your valuable suggestion on the above processes.
Thanks & regards -
[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 -
Hi,
I have created view and instead of insert, delete, update triggers on it. It is working fine for insert, delete, update. However, the application uses lots of merge command. For merge command on the view, I get following error
ORA-01446: cannot select ROWID from, or sample, a view with DISTINCT, GROUP BY, etc.
I dont have any rowid mentioned in merge command. Is there way how to make MERGE working over view with instead of triggers ?
Thanks for advices.my view is simple, it is "union all" operation over several tables without any other conditions, original tables are index organized with PK consisting of 4 columns
EDIT:
here is simplified example of the problem
create table val_00 (
id number(10),
data varchar2(100),
constraint pk_val_00 primary key (id) validate
) organization index;
create table val_01 (
id number(10),
data varchar2(100),
constraint pk_val_01 primary key (id) validate
) organization index;
create or replace view val as
select id, data from (
select id, data from val_00
union all
select id, data from val_01
create or replace trigger trg_val_ins
instead of insert on val
referencing new as new
for each row
begin
case mod(:new.id, 2)
when 0 then insert into val_00 (id, data) values (:new.id, :new.data);
when 1 then insert into val_01 (id, data) values (:new.id, :new.data);
end case;
end;
create or replace trigger trg_val_upd
instead of update on val
referencing old as old new as new
for each row
begin
if updating('id') then
raise_application_error(-20999, 'you can not update primary key in val');
end if;
case mod(:new.id, 2)
when 0 then update val_00 set data = :new.data where id = :old.id;
when 1 then update val_01 set data = :new.data where id = :old.id;
end case;
end;
create or replace trigger trg_val_del
instead of delete on val
referencing old as old
for each row
begin
case mod(:old.id, 2)
when 0 then delete from val_00 where id = :old.id;
when 1 then delete from val_01 where id = :old.id;
end case;
end;
insert into val values (1, 'one');
insert into val values (2, 'two');
insert into val values (3, 'three');
insert into val values (4, 'four');
insert into val values (5, 'five');
delete from val where id = 2;
insert into val values (2, 'twooo');
update val set data = 'two' where id = 2;
commit;
merge into val using
( select 10 as id, 'ten' as data from dual ) newdata
on (val.id = newdata.id)
when matched then
update set val.data = newdata.data
when not matched then
insert (id, data) values (newdata.id, newdata.data);
ERROR at line 1:
ORA-01446: cannot select ROWID from, or sample, a view with DISTINCT, GROUP BY, etc.
Edited by: kamilp on Aug 18, 2012 8:17 AM -
Instead of trigger is NOT firing for merge statements in Oracle 10gR2
The trigger fires fine for a update statement, but not when I use a merge statement
with an update clause. Instead I get the normal error for the view ( which is a union all view, and therefore not updatable.)
The error is :-
ORA-01733: virtual column not allowed here
oracle release is 10.2.0.2 for AIX 64L
Is this a known bug ?
I've used a multi-table insert statement to work around the problem for inserts, but
for updates, I'd really like to be able to use a merge statement instead of an update.
Mark.This is my cut-down version :-
In this case case I'm getting an :-
ORA-01446: cannot select ROWID from, or sample, a view with DISTINCT, GROUP BY, etc.
rather then the ora-01733 error I get in the real code ( which is an update from an involved
XML expression - cast to a table form)
create table a ( a int primary key , b char(30) ) ;
create table b ( a int primary key , b char(30) ) ;
create view vw_a as
select *
from a
union all
select *
from b ;
ALTER VIEW vw_a ADD (
PRIMARY KEY
(a) DISABLE);
DROP TRIGGER TRG_IO_U_ALL_AB;
CREATE OR REPLACE trigger TRG_IO_U_ALL_AB
instead of update ON vw_a
for each row
begin
update a targ
set b = :new.b
where targ.a = :new.a
if SQL%ROWCOUNT = 0
then
update b targ
set b = :new.b
where targ.a = :new.a
end if ;
end ;
insert into a values (1,'one');
insert into a values (2,'two');
insert into a values (3,'three');
insert into b values (4,'quatre');
insert into b values (5,'cinq');
insert into b values (6,'six');
commit;
create table c as select a + 3 as a, b from a ;
commit;
merge into vw_a targ
using (select * from c ) src
on ( targ.a = src.a )
when matched
then update
set targ.b = src. b
select * from vw_a ;
rollback ;
update vw_a b
set b = ( select c.b from c where b.a = c.a )
where exists ( select c.b from c where b.a = c.a ) ;
select * from vw_a ;
rollback ; -
Performance tuning in merge command
HI
My merge statement takes 45 mins to merge source table to target
below is execution plan
This is no of rows merged
906703 rows merged.
later I need to merge every day stage table to traget table -- 14701358 no of rows
I suspect this will take more than two hrs how i can improve this
My merge syntax as follows
MERGE /*+ INDEX_FFS(s idx_pis_test1a_branchcode idx_pis_test1a_invoiceno idx_pis_test1a_vouchertype idx_pis_test1a_shpmtno ) */ into scott.pis_test1_A s
using
(select * from scott.pis_test11) t
on
(s.BRANCH_CODE =t.BRANCH_CODE
and nvl(s.shpmt_no,'X')=nvl(t.shpmt_no,'X')
and s.invoice_no=t.invoice_no
and s.VOUCHER_TYPE=t.VOUCHER_TYPE
and s.suffix_invoice=t.suffix_invoice
and TRIM(s.suffix_shpmt)=TRIM(t.suffix_shpmt))
when not matched
then
INSERT
values
commit
Execution Plan
0 MERGE STATEMENT Optimizer=ALL_ROWS (Cost=32310 Card=1115245
Bytes=649072590)
1 0 MERGE OF 'PIS_TEST1_A'
2 1 VIEW
3 2 HASH JOIN (RIGHT OUTER) (Cost=32310 Card=1115245 Bytes
=630113425)
4 3 TABLE ACCESS (BY INDEX ROWID) OF 'PIS_TEST1_A' (TABL
E) (Cost=827 Card=658889 Bytes=188442254)
5 4 INDEX (FULL SCAN) OF 'IDX_PIS_TEST1A_BRANCHCODE' (
INDEX) (Cost=26 Card=658889)
6 3 TABLE ACCESS (FULL) OF 'PIS_TEST1' (TABLE) (Cost=674
6 Card=1115245 Bytes=311153355)Hi Justin
my ans as below
1) Are your statistics accurate and up to date?
No i did not gather stats , itry with stats in target table no improvement
2) Why do you have to hint the query? What happens if you remove the hint?
if i take out the hint it take bit longer
3) Why are you merging 14 million rows every day? Are you sure that you have to update the existing
rows and that you can't just load each days records into a new partition with a new effective date?
yes i need to load 14 million records every daye and merge with target table everyday
the reason i cannot get one day records , the txt file come with appended records (whole years data in text file)
currently in my merge there is no update only insert
Justin
Hi greg
my asn as below
As Justin mentioned, this index hint seems unlikely to help matters
(is this hint even syntactically correct anyway?). Depending on your responses to
Justin's questions and the number of columns you are updating,
you could also consider adding a condition(s) to the ON clause that specifically
checks that the columns you want to update are actually different. The actual act of updating
can be a lot slower than just checking for differences.
AND s.col1 != t.col1
-- Iam not update at all only insert
If you are running this one time a day only, you could also consider a /*+ parallel */ hint (or hints) to speed things up.
I cannot use palallel & append command in hint because i only use insert in merge
If i use palallel & append hint it corrupted the index due to i use insert only in merge
rds
ak -
Issue with "read by other session" and a parallel MERGE query
Hi everyone,
we have run into an issue with a batch process updating a large table (12 million rows / a few GB, so it's not that large). The process is quite simple - load the 'increment' from a file into a working table (INCREMENT_TABLE) and apply it to the main table using a MERGE. The increment is rather small (usually less than 10k rows), but the MERGE runs for hours (literally) although the execution plan seems quite reasonable (can post it tomorrow, if needed).
The first thing we've checked is AWR report, and we've noticed this:
Top 5 Timed Foreground Events
Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 10,086 43.82
read by other session 3,968,673 9,179 2 39.88 User I/O
db file scattered read 1,058,889 2,307 2 10.02 User I/O
db file sequential read 408,499 600 1 2.61 User I/O
direct path read 132,430 459 3 1.99 User I/OSo obviously most of the time was consumed by "read by other session" wait event. There were no other queries running at the server, so in this case "other session" actually means "parallel processes" used to execute the same query. The main table (the one that's updated by the batch process) has "PARALLEL DEGREE 4" so Oracle spawns 4 processes.
I'm not sure how to fix this. I've read a lot of details about "read by other session" but I'm not sure it's the root cause - in the end, when two processes read the same block, it's quite natural that only one does the physical I/O while the other waits. What really seems suspicious is the number of waits - 4 million waits means 4 million blocks, 8kB each. That's about 32GB - the table has about 4GB, and there are less than 10k rows updated. So 32 GB is a bit overkill (OK, there are indexes etc. but still, that's 8x the size of the table).
So I'm thinking that the buffer cache is too small - one process reads the data into cache, then it's removed and read again. And again ...
One of the recommendations I've read was to increase the PCTFREE, to eliminate 'hot blocks' - but wouldn't that make the problem even worse (more blocks to read and keep in the cache)? Or am I completely wrong?
The database is 11gR2, the buffer cache is about 4GB. The storage is a SAN (but I don't think this is the bottleneck - according to the iostat results it performs much better in case of other batch jobs).OK, so a bit more details - we've managed to significantly decrease the estimated cost and runtime. All we had to do was a small change in the SQL - instead of
MERGE /*+ parallel(D DEFAULT)*/ INTO T_NOTUNIFIED_CLIENT D /*+ append */
USING (SELECT
FROM TMP_SODW_BB) S
ON (D.NCLIENT_KEY = S.NCLIENT_KEY AND D.CURRENT_RECORD = 'Y' AND S.DIFF_FLAG IN ('U', 'D'))
...(which is the query listed above) we have done this
MERGE /*+ parallel(D DEFAULT)*/ INTO T_NOTUNIFIED_CLIENT D /*+ append */
USING (SELECT
FROM TMP_SODW_BB AND DIFF_FLAG IN ('U', 'D')) S
ON (D.NCLIENT_KEY = S.NCLIENT_KEY AND D.CURRENT_RECORD = 'Y')
...i.e. we have moved the condition from the MERGE ON clause to the SELECT. And suddenly, the execution plan is this
OPERATION OBJECT_NAME OPTIONS COST
MERGE STATEMENT 239
MERGE T_NOTUNIFIED_CLIENT
PX COORDINATOR
PX SEND :TQ10000 QC (RANDOM) 239
VIEW
NESTED LOOPS OUTER 239
PX BLOCK ITERATOR
TABLE ACCESS TMP_SODW_BB FULL 2
Filter Predicates
OR
DIFF_FLAG='D'
DIFF_FLAG='U'
TABLE ACCESS T_NOTUNIFIED_CLIENT BY INDEX ROWID 3
INDEX AK_UQ_NOTUNIF_T_NOTUNI RANGE SCAN 2
Access Predicates
AND
D.NCLIENT_KEY(+)=NCLIENT_KEY
D.CURRENT_RECORD(+)='Y'
Filter Predicates
D.CURRENT_RECORD(+)='Y' Yes, I know the queries are not exactly the same - but we can fix that. The point is that the TMP_SODW_BB table contains 1639 rows in total, and 284 of them match the moved 'IN' condition. Even if we remove the condition altogether (i.e. 1639 rows have to be merged), the execution plan does not change (the cost increases to about 1300, which is proportional to the number of rows).
But with the original IN condition (that turns into an OR combination of predicates) in the MERGE ON clausule, the cost suddenly skyrockets to 990.000 and it's damn slow. It seems like a problem with cost estimation, because once we remove one of the values (so there's only one value in the IN clausule), it works fine again. So I guess it's a planner/estimator issue ... -
MERGE INTO table_a
USING (SELECT table_a.ROWID row_id, table_2.format_a
FROM table_2
WHERE table_2.sales_class = sales_class) src
ON ( table_1.ROWID = src.row_id )
WHEN MATCHED THEN UPDATE SET FORMAT = src.format_a;while executing the above code i am getting an error
SQL Error: ORA-00904: "TT_PRODUCT_INFO_PIMS"."ROWID": invalid identifier
00904. 00000 - "%s: invalid identifier"
*Cause:
*Action:how to solve this error ?Merge Into Tt_Product_Info_Pims
USING (SELECT a.ROWID row_id, a.category, b.mat_type_code, CASE
When ( Select Distinct 1
FROM sfs_prod_matrix_t D Where D.Isbn = Tt_Product_Info_Pims.Isbn ------GETTING ERROR here -- ----"
--"Tt_Product_Info_Pims.isbn INVALID IDENTIFIER"
AND D.smpl_yr = 19 ) = 1 THEN 'Y'
ELSE 'N'
END AS pos_4, c.est_flag_cost, c.est_flag_price, CASE
WHEN isbn_price = 0
OR isbn_price IS NULL THEN c.isbn_price
ELSE isbn_price
END AS pos_7, CASE
WHEN isbn_cost = 0
OR isbn_cost IS NULL THEN c.isbn_cost
ELSE isbn_cost
END AS pos_8
FROM Demand.program_t a ,Demand.pgt_t b ,Demand.product_t c
WHERE a.cmpy_id = b.cmpy_id
AND a.discipline = b.discipline
AND a.prod_grp = b.prod_grp
AND a.cpy_yr = b.cpy_yr
AND a.cmpy_id = c.cmpy_id
AND a.discipline = c.discipline
AND a.prod_grp = c.prod_grp
AND a.cpy_yr = c.cpy_yr
AND b.prod_type = c.prod_type
AND c.isbn = isbn) src
On ( Tt_Product_Info_Pims.Rowid = Src.Row_Id )
WHEN MATCHED THEN UPDATE SET category = src.category;
{code}
is it necessary to include Tt_Product_Info_Pims table inside the select clause -
Hello All,
I want to change a rowid of a row when somebody updates it. I put the table in partition. Table is having 47 fields and I have give "PARTITION BY HASH" on 16 fields. I only updates this fiels who are n partition so how many percent chance are there for the rowid to get changed.If you have an application which depends on database-specific functionality in the source database (ROWID changing when data is updated), I would suggest that you're better off writing database-specific functionality in the target database to accomplish the same business goal than to try to coerce the same functionality from the target database. If you aren't using partitioning elsewhere, for example, the extra cost of licensing this option in the hope of often causing a ROWID to change would be hard to justify.
Can you explain the business purpose that your Centura SQLBase code was accomplishing and how changing ROWID's factored in? There may be a much simpler Oracle solution.
If you are really wedded to ROWID's changing, you may be able to build index-organized tables rather than heap organized tables, but be sure that you understand the implications of this sort of approach.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC -
Merge with where clause after matched and unmatched
Hai,
Can anybody give me one example of merge statement with
where clause after matched condition and after the unmatched condition.
MERGE INTO V1 VV1
USING (SELECT A.CNO XXCNO, A.SUNITS XXSU, A.DDATE XXDD, XX.SUM_UNITS SUMMED
FROM V1 A,
(SELECT
SUM(SUNITS) SUM_UNITS FROM V1 B
GROUP BY CNO) c
WHERE
A.DDATE=0 AND A.SUNITS <>0 AND
A.ROWID=(SELECT MAX(ROWID) FROM V1 )) XX
ON (1=1)
WHEN MATCHED THEN UPDATE SET
VV1.SUNITS=XX.SUMMED
WHERE XX.XXDD=0
WHEN NOT MATCHED THEN INSERT
(VV1.CNO, VV1.SUNITS, VV1.SUNITS)
VALUES (XX.XXCNO, XX.XXSU, XX.XXDD)
WHERE XX.XXDD<>0
i am getting the error
WHERE XX.XXDD=0
ERROR at line 13:
ORA-00905: missing keyword
Thanks,
PalOne of the example is there:
http://download-west.oracle.com/docs/cd/B14117_01/server.101/b10759/statements_9016.htm#sthref7014
What Oracle version do you use ?
Besides the condition (1=1) is non-deterministic,
I would expect there an exception like "unable to get a stable set of rows".
Rgds. -
Query taking long because of merge cartesion join
Hi,
please suggest me to tune this query.
SELECT DISTINCT acct_promo_hdr.row_id, '401000', 'EXPORTED',
acct_promo_hdr.src_num, 'PLAN_ACCOUNT_PROMOTION',
promo_hdr_org.NAME
FROM siebel.s_src acct_promo_hdr,
siebel.s_mdf_alloc deal,
siebel.s_bu promo_hdr_org
-- siebel.s_contact contact,
-- siebel.s_user usr
WHERE -- acct_promo_hdr.sub_type = 'PLAN_ACCOUNT_PROMOTION'
deal.promo_id =acct_promo_hdr.row_id
AND acct_promo_hdr.bu_id = promo_hdr_org.row_id
-- AND acct_promo_hdr.created_by = contact.row_id
-- AND contact.row_id = usr.row_id
AND EXISTS (
SELECT 1
FROM approval acb_approval
WHERE acb_approval.status NOT IN
('11', '12', '65', '77')
AND acct_promo_hdr.src_num =
acb_approval.commit_num)
AND deal.status_cd IN
('Cancel', 'Cancelled', 'Committed', 'On Hold',
'Processing Claim', 'Paid In Part',
'Paid In Full', 'Hold')
explain plan
PLAN_TABLE_OUTPUT
Plan hash value: 115701554
| Id | Operation | Name | Rows | Bytes | Cost
(%CPU)| Time |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT | | 1 | 105 | 206 (2)| 00:00:03 |
| 1 | HASH UNIQUE | | 1 | 105 | 206 (2)| 00:00:03 |
| 2 | NESTED LOOPS | | | || |
| 3 | NESTED LOOPS | | 1 | 105 | 205(1)| 00:00:03 |
PLAN_TABLE_OUTPUT
| 4 | NESTED LOOPS | | 1 | 84 | 204 (1)| 00:00:03 |
| 5 | MERGE JOIN CARTESIAN | | 1 | 57 | 67(2)| 00:00:01 |
| 6 | SORT UNIQUE | | 1 | 30 | 64 (0)| 00:00:01 |
|* 7 | TABLE ACCESS FULL | APPROVAL | 1 | 30 | 64 PLAN_TABLE_OUTPUT--(0)| 00:00:01 |
| 8 | BUFFER SORT | | 3 | 81 | 3(34)| 00:00:01 |
| 9 | TABLE ACCESS FULL | S_BU | 3 | 81 | 2(0)| 00:00:01 |
| 10 | TABLE ACCESS BY INDEX ROWID| S_SRC | 1 | 27 | 136(0)| 00:00:02 |
PLAN_TABLE_OUTPUT
|* 11 | INDEX RANGE SCAN | S_SRC_U2 | 1 | | 136(0)| 00:00:02 |
Thanks,
|* 12 | INDEX RANGE SCAN | S_MDF_ALLOC_F8 | 12 | | 1(0)| 00:00:01 |
|* 13 | TABLE ACCESS BY INDEX ROWID | S_MDF_ALLOC | 10 | 210 | 1(0)| 00:00:01 |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
7 - filter("ACB_APPROVAL"."STATUS" <>'11' AND "ACB_APPROVAL"."STATUS"<> '12' AN
D
"ACB_APPROVAL"."STATUS"<> '65' AND "ACB_APPROVAL"."STATUS"<> '77')
11 - access("ACCT_PROMO_HDR"."BU_ID" ;="PROMO_HDR_ORG"."ROW_ID")
filter("ACB_APPROVAL"."COMMIT_NUM&q uot;=TO_NUMBER("ACCT_PROMO_HDR"."SRC_N UM"))
PLAN_TABLE_OUTPUTPlease format your code and stick between tags to preserve the formatting.
From the look of it, merge cartesian is not unreasonable given the low cardinality.
However I suspect that the number of rows the optimiser is estimating may be wrong.
Have you analysed your tables recently? -
Why is LOWER function producing a cartesian merge join, when UPPER doesn't?
Hi there,
I have an odd scenario that I would like to understand correctly...
We have a query that is taking a long time to run on one of our databases, further investigation of the explain plan showed that the query was in fact producing a Cartesian merge join even though there is clearly join criteria specified. I know that the optimiser can and will do this if it is a more efficient way of producing the results, however in this scenario it is producing the Cartesian merge on two unrelated tables and seemingly ignoring the Join condition...
*** ORIGINAL QUERY ***
SELECT count(*)
FROM srs_sce sce,
srs_scj scj,
men_mre mre,
srs_mst mst,
cam_smo cam,
ins_spr spr,
men_mua mua,
temp_webct_users u
WHERE sce.sce_scjc = scj.scj_code
AND sce.sce_stuc = mre.mre_code
AND mst.mst_code = mre.mre_mstc
AND mre.mre_mrcc = 'STU'
AND mst.mst_code = mua.mua_mstc
AND cam.ayr_code = sce.sce_ayrc
AND cam.spr_code = scj.scj_sprc
AND spr.spr_code = scj.scj_sprc
-- Ignored Join Condition
AND LOWER(mua.mua_extu) = LOWER(u.login)
AND SUBSTR (sce.sce_ayrc, 1, 4) = '2008'
AND sce.sce_stac IN ('RCE', 'RLL', 'RPD', 'RIN', 'RSAS', 'RHL_R', 'RCO', 'RCI', 'RCA');
*** CARTESIAN EXPLAIN PLAN ***
SELECT STATEMENT CHOOSECost: 83
20 NESTED LOOPS Cost: 83 Bytes: 176 Cardinality: 1
18 NESTED LOOPS Cost: 82 Bytes: 148 Cardinality: 1
15 NESTED LOOPS Cost: 80 Bytes: 134 Cardinality: 1
13 NESTED LOOPS Cost: 79 Bytes: 123 Cardinality: 1
10 NESTED LOOPS Cost: 78 Bytes: 98 Cardinality: 1
7 NESTED LOOPS Cost: 77 Bytes: 74 Cardinality: 1
NOTE: The Cartesian product is performed on the men_mre & temp_webct_users tables not the men_mua mua & temp_webct_users tables specified in the join condition.
4 MERGE JOIN CARTESIAN Cost: 74 Bytes: 32 Cardinality: 1
1 TABLE ACCESS FULL EXETER.TEMP_WEBCT_USERS Cost: 3 Bytes: 6 Cardinality: 1
3 BUFFER SORT Cost: 71 Bytes: 1,340,508 Cardinality: 51,558
2 TABLE ACCESS FULL SIPR.MEN_MRE Cost: 71 Bytes: 1,340,508 Cardinality: 51,558
6 TABLE ACCESS BY INDEX ROWID SIPR.SRS_SCE Cost: 3 Bytes: 42 Cardinality: 1
5 INDEX RANGE SCAN SIPR.SRS_SCEI3 Cost: 2 Cardinality: 3
9 TABLE ACCESS BY INDEX ROWID SIPR.SRS_SCJ Cost: 1 Bytes: 24 Cardinality: 1
8 INDEX UNIQUE SCAN SIPR.SRS_SCJP1 Cardinality: 1
12 TABLE ACCESS BY INDEX ROWID SIPR.INS_SPR Cost: 1 Bytes: 25 Cardinality: 1
11 INDEX UNIQUE SCAN SIPR.INS_SPRP1 Cardinality: 1
14 INDEX UNIQUE SCAN SIPR.SRS_MSTP1 Cost: 1 Bytes: 11 Cardinality: 1
17 TABLE ACCESS BY INDEX ROWID SIPR.MEN_MUA Cost: 2 Bytes: 14 Cardinality: 1
16 INDEX RANGE SCAN SIPR.MEN_MUAI3 Cost: 2 Cardinality: 1
19 INDEX RANGE SCAN SIPR.CAM_SMOP1 Cost: 2 Bytes: 28 Cardinality: 1 After speaking with data experts I realised one of the fields being LOWERed for the join condition generally always had uppercase values so I tried modifying the query to use the UPPER function rather than the LOWER one originally used, in this scenario the query executed in seconds and the Cartesian merge had been eradicated which by all accounts is a good result.
*** WORKING QUERY ***
SELECT count(*)
FROM srs_sce sce,
srs_scj scj,
men_mre mre,
srs_mst mst,
cam_smo cam,
ins_spr spr,
men_mua mua,
temp_webct_users u
WHERE sce.sce_scjc = scj.scj_code
AND sce.sce_stuc = mre.mre_code
AND mst.mst_code = mre.mre_mstc
AND mre.mre_mrcc = 'STU'
AND mst.mst_code = mua.mua_mstc
AND cam.ayr_code = sce.sce_ayrc
AND cam.spr_code = scj.scj_sprc
AND spr.spr_code = scj.scj_sprc
-- Working Join Condition
AND UPPER(mua.mua_extu) = UPPER(u.login)
AND SUBSTR (sce.sce_ayrc, 1, 4) = '2008'
AND sce.sce_stac IN ('RCE', 'RLL', 'RPD', 'RIN', 'RSAS', 'RHL_R', 'RCO', 'RCI', 'RCA');
*** WORKING EXPLAIN PLAN ***
SELECT STATEMENT CHOOSECost: 13
20 SORT AGGREGATE Bytes: 146 Cardinality: 1
19 NESTED LOOPS Cost: 13 Bytes: 146 Cardinality: 1
17 NESTED LOOPS Cost: 12 Bytes: 134 Cardinality: 1
15 NESTED LOOPS Cost: 11 Bytes: 115 Cardinality: 1
12 NESTED LOOPS Cost: 10 Bytes: 91 Cardinality: 1
9 NESTED LOOPS Cost: 7 Bytes: 57 Cardinality: 1
6 NESTED LOOPS Cost: 6 Bytes: 31 Cardinality: 1
4 NESTED LOOPS Cost: 5 Bytes: 20 Cardinality: 1
1 TABLE ACCESS FULL EXETER.TEMP_WEBCT_USERS Cost: 3 Bytes: 6 Cardinality: 1
3 TABLE ACCESS BY INDEX ROWID SIPR.MEN_MUA Cost: 2 Bytes: 42 Cardinality: 3
2 INDEX RANGE SCAN EXETER.TEST Cost: 1 Cardinality: 1
5 INDEX UNIQUE SCAN SIPR.SRS_MSTP1 Cost: 1 Bytes: 11 Cardinality: 1
8 TABLE ACCESS BY INDEX ROWID SIPR.MEN_MRE Cost: 2 Bytes: 26 Cardinality: 1
7 INDEX RANGE SCAN SIPR.MEN_MREI2 Cost: 2 Cardinality: 1
11 TABLE ACCESS BY INDEX ROWID SIPR.SRS_SCE Cost: 3 Bytes: 34 Cardinality: 1
10 INDEX RANGE SCAN SIPR.SRS_SCEI3 Cost: 2 Cardinality: 3
14 TABLE ACCESS BY INDEX ROWID SIPR.SRS_SCJ Cost: 1 Bytes: 24 Cardinality: 1
13 INDEX UNIQUE SCAN SIPR.SRS_SCJP1 Cardinality: 1
16 INDEX RANGE SCAN SIPR.CAM_SMOP1 Cost: 2 Bytes: 19 Cardinality: 1
18 INDEX UNIQUE SCAN SIPR.INS_SPRP1 Bytes: 12 Cardinality: 1 *** RESULT ***
COUNT(*)
83299I am still struggling to understand why this would have worked as to my knowledge the LOWER & UPPER functions are similar enough in function and regardless of that why would one version cause the optimiser to effectively ignore a join condition.
If anyone can shed any light on this for me it would be very much appreciated.
Regards,
Kieron
Edited by: Kieron_Bird on Nov 19, 2008 6:09 AM
Edited by: Kieron_Bird on Nov 19, 2008 6:41 AMMy mistake on the predicate information, was in a rush to run off to a meeting when I posted the entry...
*** UPPER Version of the Explain Plan ***
| Id | Operation | Name | Rows | Bytes | Cost | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 146 | 736 | | | |
| 1 | SORT AGGREGATE | | 1 | 146 | | | | |
| 2 | SORT AGGREGATE | | 1 | 146 | | 86,10 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 241 | 35186 | 736 | 86,10 | PCWP | |
|* 4 | HASH JOIN | | 774 | 105K| 733 | 86,09 | P->P | HASH |
|* 5 | HASH JOIN | | 12608 | 1489K| 642 | 86,08 | P->P | BROADCAST |
| 6 | NESTED LOOPS | | 14657 | 1531K| 491 | 86,07 | P->P | HASH |
|* 7 | HASH JOIN | | 14657 | 1359K| 490 | 86,07 | PCWP | |
|* 8 | HASH JOIN | | 14371 | 996K| 418 | 86,06 | P->P | HASH |
|* 9 | TABLE ACCESS FULL | SRS_SCE | 3211 | 106K| 317 | 86,00 | S->P | BROADCAST |
|* 10 | HASH JOIN | | 52025 | 1879K| 101 | 86,06 | PCWP | |
|* 11 | TABLE ACCESS FULL | MEN_MRE | 51622 | 1310K| 71 | 86,01 | S->P | HASH |
| 12 | INDEX FAST FULL SCAN| SRS_MSTP1 | 383K| 4119K| 30 | 86,05 | P->P | HASH |
| 13 | TABLE ACCESS FULL | SRS_SCJ | 114K| 2672K| 72 | 86,02 | S->P | HASH |
|* 14 | INDEX UNIQUE SCAN | INS_SPRP1 | 1 | 12 | | 86,07 | PCWP | |
| 15 | TABLE ACCESS FULL | MEN_MUA | 312K| 4268K| 151 | 86,03 | S->P | HASH |
| 16 | INDEX FAST FULL SCAN | CAM_SMOP1 | 527K| 9796K| 91 | 86,09 | PCWP | |
| 17 | TABLE ACCESS FULL | TEMP_WEBCT_USERS | 33276 | 194K| 3 | 86,04 | S->P | HASH |
Predicate Information (identified by operation id):
3 - access(UPPER("MUA"."MUA_EXTU")=UPPER("U"."LOGIN"))
4 - access("CAM"."AYR_CODE"="SCE"."SCE_AYRC" AND "CAM"."SPR_CODE"="SCJ"."SCJ_SPRC")
5 - access("MST"."MST_CODE"="MUA"."MUA_MSTC")
7 - access("SCE"."SCE_SCJC"="SCJ"."SCJ_CODE")
8 - access("SCE"."SCE_STUC"="MRE"."MRE_CODE")
9 - filter(SUBSTR("SCE"."SCE_AYRC",1,4)='2008' AND ("SCE"."SCE_STAC"='RCA' OR "SCE"."SCE_STAC"='RCE' OR
"SCE"."SCE_STAC"='RCI' OR "SCE"."SCE_STAC"='RCO' OR "SCE"."SCE_STAC"='RHL_R' OR "SCE"."SCE_STAC"='RIN' OR
"SCE"."SCE_STAC"='RLL' OR "SCE"."SCE_STAC"='RPD' OR "SCE"."SCE_STAC"='RSAS'))
10 - access("MST"."MST_CODE"="MRE"."MRE_MSTC")
11 - filter("MRE"."MRE_MRCC"='STU')
14 - access("SPR"."SPR_CODE"="SCJ"."SCJ_SPRC")
Note: cpu costing is off
40 rows selected.*** LOWER Version of the Explain Plan ***
| Id | Operation | Name | Rows | Bytes | Cost | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 146 | 736 | | | |
| 1 | SORT AGGREGATE | | 1 | 146 | | | | |
| 2 | SORT AGGREGATE | | 1 | 146 | | 88,10 | P->S | QC (RAND) |
|* 3 | HASH JOIN | | 257K| 35M| 736 | 88,10 | PCWP | |
|* 4 | HASH JOIN | | 774 | 105K| 733 | 88,09 | P->P | HASH |
|* 5 | HASH JOIN | | 12608 | 1489K| 642 | 88,08 | P->P | BROADCAST |
| 6 | NESTED LOOPS | | 14657 | 1531K| 491 | 88,07 | P->P | HASH |
|* 7 | HASH JOIN | | 14657 | 1359K| 490 | 88,07 | PCWP | |
|* 8 | HASH JOIN | | 14371 | 996K| 418 | 88,06 | P->P | HASH |
|* 9 | TABLE ACCESS FULL | SRS_SCE | 3211 | 106K| 317 | 88,00 | S->P | BROADCAST |
|* 10 | HASH JOIN | | 52025 | 1879K| 101 | 88,06 | PCWP | |
|* 11 | TABLE ACCESS FULL | MEN_MRE | 51622 | 1310K| 71 | 88,01 | S->P | HASH |
| 12 | INDEX FAST FULL SCAN| SRS_MSTP1 | 383K| 4119K| 30 | 88,05 | P->P | HASH |
| 13 | TABLE ACCESS FULL | SRS_SCJ | 114K| 2672K| 72 | 88,02 | S->P | HASH |
|* 14 | INDEX UNIQUE SCAN | INS_SPRP1 | 1 | 12 | | 88,07 | PCWP | |
| 15 | TABLE ACCESS FULL | MEN_MUA | 312K| 4268K| 151 | 88,03 | S->P | HASH |
| 16 | INDEX FAST FULL SCAN | CAM_SMOP1 | 527K| 9796K| 91 | 88,09 | PCWP | |
| 17 | TABLE ACCESS FULL | TEMP_WEBCT_USERS | 33276 | 194K| 3 | 88,04 | S->P | HASH |
Predicate Information (identified by operation id):
3 - access(LOWER("MUA"."MUA_EXTU")=LOWER("U"."LOGIN"))
4 - access("CAM"."AYR_CODE"="SCE"."SCE_AYRC" AND "CAM"."SPR_CODE"="SCJ"."SCJ_SPRC")
5 - access("MST"."MST_CODE"="MUA"."MUA_MSTC")
7 - access("SCE"."SCE_SCJC"="SCJ"."SCJ_CODE")
8 - access("SCE"."SCE_STUC"="MRE"."MRE_CODE")
9 - filter(SUBSTR("SCE"."SCE_AYRC",1,4)='2008' AND ("SCE"."SCE_STAC"='RCA' OR "SCE"."SCE_STAC"='RCE' OR
"SCE"."SCE_STAC"='RCI' OR "SCE"."SCE_STAC"='RCO' OR "SCE"."SCE_STAC"='RHL_R' OR "SCE"."SCE_STAC"='RIN' OR
"SCE"."SCE_STAC"='RLL' OR "SCE"."SCE_STAC"='RPD' OR "SCE"."SCE_STAC"='RSAS'))
10 - access("MST"."MST_CODE"="MRE"."MRE_MSTC")
11 - filter("MRE"."MRE_MRCC"='STU')
14 - access("SPR"."SPR_CODE"="SCJ"."SCJ_SPRC")
Note: cpu costing is off
40 rows selected.As you state something has obviously changed, but nothing obvious has been changed.
We gather statistics via...
exec dbms_stats.gather_schema_stats(ownname => 'USERNAME', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE , degree => 4, granularity => ''ALL'', cascade => TRUE);
We run a script nightly which works out which indexes require a rebuild and rebuild those only it doesn;t just rebuild all indexes.
It would be nice to be able to use the 10g statistics history, but on this instance we aren't yet at that version, hopefully we will be there soon though.
Hope this helps,
Kieron -
Facing Merge Join Cartersian in the explain plan after adding gl periods
Hi All
I have added gl periods table to the below query , checked the explain plan and it shows merge join cartesian. This query is taking long time to fetch the results.
Need help ASAP , Please let me know where i am going wrong . Any suggestions will be appreciated.
SELECT gljh.period_name, gljh.ledger_id, gljh.je_source,
glcc.segment2,
SUM ( NVL (gljl.accounted_dr, 0)
- NVL (gljl.accounted_cr, 0)
) total_amt,
gljh.currency_code
FROM gl_je_headers gljh,
gl_je_lines gljl,
gl_code_combinations glcc,
gl_periods gps
WHERE 1=1
AND gljh.period_name = gps.period_name
AND gljl.period_name = gps.period_name
AND gps.period_set_name = 'MCD_MONTH_'
AND gps.start_date >= :p_from_date
AND gps.start_date <= :p_to_date
AND gljh.ledger_id = :p_ledger_id
AND gljh.je_header_id = gljl.je_header_id
AND gljl.code_combination_id = glcc.code_combination_id
AND glcc.segment2 = '10007'--get_segment2_rec.flex_value
AND gljh.currency_code <> 'STAT'
GROUP BY gljh.je_source,
gljh.period_name,
glcc.segment2,
gljh.ledger_id,
gljh.currency_code
HAVING SUM ( NVL (gljl.accounted_dr, 0)
- NVL (gljl.accounted_cr, 0)
) <> 0;
Plan
SELECT STATEMENT ALL_ROWSCost: 73,146 Bytes: 2,266 Cardinality: 22
15 FILTER
14 HASH GROUP BY Cost: 73,146 Bytes: 2,266 Cardinality: 22
13 FILTER
12 NESTED LOOPS Cost: 73,145 Bytes: 61,079 Cardinality: 593
9 NESTED LOOPS Cost: 31,603 Bytes: 1,452,780 Cardinality: 20,754
6 MERGE JOIN CARTESIAN Cost: 2,108 Bytes: 394,181 Cardinality: 9,167
2 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_PERIODS Cost: 4 Bytes: 31 Cardinality: 1
1 INDEX RANGE SCAN INDEX (UNIQUE) GL.GL_PERIODS_U2 Cost: 1 Cardinality: 64
5 BUFFER SORT Cost: 2,104 Bytes: 683,988 Cardinality: 56,999
4 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 2,104 Bytes: 683,988 Cardinality: 56,999
3 INDEX RANGE SCAN INDEX GL.GL_CODE_COMBINATIONS_N2 Cost: 155 Cardinality: 56,999
8 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_JE_LINES Cost: 18 Bytes: 54 Cardinality: 2
7 INDEX RANGE SCAN INDEX GL.GL_JE_LINES_N1 Cost: 3 Cardinality: 37
11 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_JE_HEADERS Cost: 2 Bytes: 33 Cardinality: 1
10 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_JE_HEADERS_U1 Cost: 1 Cardinality: 1
Thanks
ChandraLots of things come into play when you're tuning a query.
An (unformatted) execution plan isn't enough.
Tuning takes time and understanding how (a lot of) things work, there is no ASAP in the world of tuning.
Please post other important details, like your database version, optimizer settings, how/when are table statistics gathered etc.
So, read the following informative threads (and please take your time, this really is important stuff), and adust your thread as needed.
That way you'll have a bigger chance of getting help that makes sense...
Your DBA should/ought to be able to help you in this as well.
Re: HOW TO: Post a SQL statement tuning request - template posting
http://oracle-randolf.blogspot.com/2009/02/basic-sql-statement-performance.html -
Group by causing merge join cartesian?
Hi All,
Database Version: Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi
Database Version: PL/SQL Release 10.2.0.5.0 - ProductionI've written a query which runs in under a second and produces a few hundred rows (as you can see below). I only wanted to find the number of distinct incident ID's returned so I put a group by at the end and it ran for ever.
I produced an explain plan (as shown below) for the query with the group by in it and it is trying to perform a cartesian join!
WTF is going on? I've never known a group by statement to do that before.
basic structure of the tables is as follows:
SQL> desc answer_master
Name Null? Type
ANSWER_ID NOT NULL NUMBER(12)
INCIDENT_ID NOT NULL NUMBER(12)
PLAN_ID NOT NULL NUMBER(12)
QUESTION_ID NOT NULL NUMBER(12)
SQL> desc question_master
Name Null? Type
QUESTION_PLAN_ID NOT NULL NUMBER(12)
QUESTION_ID NOT NULL NUMBER(12)
QUESTION_TYPE NOT NULL NUMBER(2)
QUESTION_TEXT NOT NULL VARCHAR2(255)
QUESTION_PARENT_ID NUMBER(12)the offending SQL statement
SQL> explain plan for
2 select incident_id
3 from answer_master am
4 where exists (select 'x'
5 from answer_master am1
6 where question_id in (select question_id
7 from question_master qms
8 where question_plan_id = 1477
9 and question_parent_id = 69067
10 and substr(question_text,-3) = 'PDF')
11 and am1.incident_id = am.incident_id)
12 and exists (select 'x'
13 from answer_master am1
14 where question_id in (select question_id
15 from question_master qms
16 where question_plan_id = 1477
17 and question_parent_id = 69067
18 and substr(question_text,-3) != 'PDF')
19 and am1.incident_id = am.incident_id);
Explained.
Elapsed: 00:00:00.01
SQL> set linesize 132;
SQL> select plan_table_output from table(dbms_xplan.display('plan_table',null,'serial'));
PLAN_TABLE_OUTPUT
Plan hash value: 1710257923
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 32 | 171 (6)| 00:00:01 |
|* 1 | HASH JOIN RIGHT SEMI | | 1 | 32 | 171 (6)| 00:00:01 |
| 2 | VIEW | VW_SQ_2 | 71 | 923 | 70 (5)| 00:00:01 |
| 3 | NESTED LOOPS | | 71 | 3266 | 70 (5)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID | QUESTION_MASTER | 1 | 35 | 2 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | QUESTION_MASTER_IX1 | 3 | | 1 (0)| 00:00:01 |
|* 6 | INDEX RANGE SCAN | ANSWER_MASTER_QID_IX2 | 18731 | 201K| 68 (5)| 00:00:01 |
| 7 | NESTED LOOPS | | 304 | 5776 | 100 (5)| 00:00:01 |
| 8 | VIEW | VW_SQ_1 | 14 | 182 | 70 (5)| 00:00:01 |
| 9 | HASH UNIQUE | | 14 | 644 | | |
| 10 | NESTED LOOPS | | 14 | 644 | 70 (5)| 00:00:01 |
|* 11 | TABLE ACCESS BY INDEX ROWID| QUESTION_MASTER | 1 | 35 | 2 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | QUESTION_MASTER_IX1 | 3 | | 1 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | ANSWER_MASTER_QID_IX2 | 18731 | 201K| 68 (5)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | ANSWER_MASTER_QID_IX3 | 22 | 132 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
1 - access("ITEM_2"="AM"."INCIDENT_ID")
4 - filter("QUESTION_PLAN_ID"=1477 AND SUBSTR("QUESTION_TEXT",-3)!='PDF')
5 - access("QUESTION_PARENT_ID"=69067)
6 - access("QUESTION_ID"="QUESTION_ID")
11 - filter("QUESTION_PLAN_ID"=1477 AND SUBSTR("QUESTION_TEXT",-3)='PDF')
12 - access("QUESTION_PARENT_ID"=69067)
13 - access("QUESTION_ID"="QUESTION_ID")
14 - access("ITEM_1"="AM"."INCIDENT_ID")
33 rows selected.
Elapsed: 00:00:00.06
SQL> explain plan for
2 select incident_id
3 from answer_master am
4 where exists (select 'x'
5 from answer_master am1
6 where question_id in (select question_id
7 from question_master qms
8 where question_plan_id = 1477
9 and question_parent_id = 69067
10 and substr(question_text,-3) = 'PDF')
11 and am1.incident_id = am.incident_id)
12 and exists (select 'x'
13 from answer_master am1
14 where question_id in (select question_id
15 from question_master qms
16 where question_plan_id = 1477
17 and question_parent_id = 69067
18 and substr(question_text,-3) != 'PDF')
19 and am1.incident_id = am.incident_id)
20 group by incident_id;
Explained.
Elapsed: 00:00:00.00
SQL> select plan_table_output from table(dbms_xplan.display('plan_table',null,'serial'));
PLAN_TABLE_OUTPUT
Plan hash value: 1433543102
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 98 | 77 (6)| 00:00:01 |
| 1 | HASH GROUP BY | | 1 | 98 | 77 (6)| 00:00:01 |
| 2 | NESTED LOOPS | | 1 | 98 | 76 (4)| 00:00:01 |
| 3 | NESTED LOOPS | | 1 | 87 | 74 (5)| 00:00:01 |
| 4 | NESTED LOOPS | | 1 | 81 | 72 (5)| 00:00:01 |
| 5 | MERGE JOIN CARTESIAN | | 1 | 70 | 4 (0)| 00:00:01 |
|* 6 | TABLE ACCESS BY INDEX ROWID | QUESTION_MASTER | 1 | 35 | 2 (0)| 00:00:01 |
|* 7 | INDEX RANGE SCAN | QUESTION_MASTER_IX1 | 3 | | 1 (0)| 00:00:01 |
| 8 | BUFFER SORT | | 1 | 35 | 2 (0)| 00:00:01 |
|* 9 | TABLE ACCESS BY INDEX ROWID| QUESTION_MASTER | 1 | 35 | 2 (0)| 00:00:01 |
|* 10 | INDEX RANGE SCAN | QUESTION_MASTER_IX1 | 3 | | 1 (0)| 00:00:01 |
|* 11 | INDEX RANGE SCAN | ANSWER_MASTER_QID_IX2 | 18731 | 201K| 68 (5)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | ANSWER_MASTER_QID_IX3 | 22 | 132 | 2 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | ANSWER_MASTER_QID_IX2 | 1 | 11 | 2 (0)| 00:00:01 |
Predicate Information (identified by operation id):
6 - filter("QUESTION_PLAN_ID"=1477 AND SUBSTR("QUESTION_TEXT",-3)='PDF')
7 - access("QUESTION_PARENT_ID"=69067)
9 - filter("QUESTION_PLAN_ID"=1477 AND SUBSTR("QUESTION_TEXT",-3)!='PDF')
10 - access("QUESTION_PARENT_ID"=69067)
11 - access("QUESTION_ID"="QUESTION_ID")
12 - access("AM1"."INCIDENT_ID"="AM"."INCIDENT_ID")
13 - access("QUESTION_ID"="QUESTION_ID" AND "AM1"."INCIDENT_ID"="AM"."INCIDENT_ID")
31 rows selected.
Elapsed: 00:00:00.00
SQL> spool offedit: changing greater-than/less-than signs to != so it displays on forum
Edited by: WhiteHat on Feb 11, 2011 9:37 AMThe "Cartesian" product is nothing "wrong", if (!) the optimizer is right and the number or rows it's picking for that part of the execution plan is really 1. And that can be true, as ORACLE also changed from HASH join to NL. So that NL might be the cause of your performance issue not the Cartesian.
The performance of IN, EXISTS and SUBQUERIES got better over the versions, but I still see no reason in most cases to use them for good readable and performing code.
What you do think about this:
WITH my_selection As
(SELECT incident_id
from question_master qms
where question_plan_id = 1477
and question_parent_id = 69067
and (substr(question_text,-3) = 'PDF'
or and substr(question_text,-3) != 'PDF')
GROUP BY incident_id
HAVING COUNT(*) >1)
SELECT am.incident_id
FROM answer_master am
INNER JOIN my_selection s
ON am.incident_id = s.incident_id
group by am.incident_id; -
Performance of merge statement
hi all,
any advices or tips on how to optimize the performance the of the merge statement?
can indexes on the target /source tables do some help?
thanksuser2361373 wrote:
you cannot improve the performance of merge A bit of a misleading answer when the merge encompasses a query that can be improved, hence the merge performance can be improved.
but the source query inside merge is to be optimized based on rowid or primary key update runs faster.There are many ways to improve a query and it all depends on the query itself. It doesn't necessarily have to be to do with rowid or the primary key. Firstly the cause of the performance issue needs identifying.
Maybe you are looking for
-
Uploading multiple items one at a time - file view resets
In my work, I need to upload many files, one at a time, using an interface through the browser. When I go to upload multiple files, one at a time, using 10.6.2, the Finder takes me back one or two levels down from the file location between uploads. I
-
Load Balancing with Reverse Proxy Plug-in in SunOne 6.1
Hello we are configuring our reverse proxy web server SunOn 6.1 for load balancing and we have some conflicting information that we have found on the internet. The options we have found are the following: 1- In one case, it seems that all we need to
-
Shuffle Problems - Now Laptop Hosed Up
My Shuffle quit on me a couple of weeks ago. Got the flashing green and amber lights. Called support, and they shipped me a new one. But, in the course of trying all the stuff recommended in the user guide and the online help (5 things to check), I s
-
Need help! When mac both I see folder with question
after this BiG problem with space after uninstall Boot Camp I Can't both my mac, and maybe someone know how I can both him without data erasing
-
Creating a Windows installer for Java applications
Hello, I have a question about deployment: I have a pure Java desktop application. Obviously, it's in the form of a JAR file. I want to sell this to users who are "clueless" about Java, so I need to wrap it up in an installer file that does the follo