Problematic SQL
Hi,
We have the problem with the one SQL statement, after migration from 9.2.0.7 to 11.2.0.1 Oracle database.
I also must to say that value of the parameter: optimizer_features_enable is 9.2.0
We have one problematic SQL statement.
What is happening?
Sometimes, this SQL statement takes a big stress to the CPU to execute (we see it from ADDM report and other monitoring tools).
In this situation we react with exec sys.DBMS_SHARED_POOL.PURGE(('******************', 'C'); command.
I don't have to much tunning experience, but it's look like the execution plan become different which reacts negatively to the CPU.
After purging from shared pool everything going fine, CPU is normally stressed.
Please, can anybody give me some advice.
How I can fix the good execution plan for this problematic SQL (created after purging), so optimizer will always use this good execution plan.
Is it possible to use SQL Plan Baselines in this situation (any problem here)?
Please sorry because, I am new in this area.
Best regards,
D.R
Thanks sb92075,
select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 15 | 2895 | 208 |
| 1 | SORT ORDER BY | | 15 | 2895 | 208 |
| 2 | VIEW | RADNA_LISTA_ZADATAKA | 15 | 2895 | 162 |
| 3 | SORT UNIQUE | | 15 | 1875 | 162 |
| 4 | FILTER | | | | |
| 5 | NESTED LOOPS OUTER | | 15 | 1875 | 115 |
| 6 | NESTED LOOPS | | 15 | 1470 | 70 |
| 7 | NESTED LOOPS | | 15 | 1050 | 40 |
| 8 | TABLE ACCESS BY INDEX ROWID| ZADATAK | 15 | 450 | 10 |
| 9 | INDEX RANGE SCAN | ZADATAK_OJ_DATUM_DAJE_STATUS | 15 | | 4 |
| 10 | TABLE ACCESS BY INDEX ROWID| ZAHTEV | 1 | 40 | 2 |
| 11 | INDEX UNIQUE SCAN | ZAHTEV_POSAO_ID_UNIQUE | 1 | | 1 |
| 12 | TABLE ACCESS BY INDEX ROWID | KORISNIK_USLUGA | 1 | 28 | 2 |
| 13 | INDEX UNIQUE SCAN | KORISNIK_PK | 1 | | 1 |
| 14 | TABLE ACCESS BY INDEX ROWID | ADRESA_INSTALACIJE | 1 | 27 | 3 |
| 15 | INDEX RANGE SCAN | ADR_INSTAL_PK | 1 | | 2 |
Note
- 'PLAN_TABLE' is old version
- cpu costing is off (consider enabling it)
Best regards
D.R.
Similar Messages
-
Problematic SQL after changing database version
Hi,
We have the problem with the one SQL statement, after migration from 9.2.0.7 to 11.2.0.1 Oracle database.
I also must to say that value of the parameter: optimizer_features_enable is 9.2.0
We have one problematic SQL statement.
What is happening?
Sometimes, this SQL statement takes a big stress to the CPU to execute (we see it from ADDM report and other monitoring tools).
In this situation we react with exec sys.DBMS_SHARED_POOL.PURGE(('******************', 'C'); command.
I don't have to much tunning experience, but it's look like the execution plan become different which reacts negatively to the CPU.
After purging from shared pool everything going fine, CPU is normally stressed.
Please, can anybody give me some advice.
How I can fix the good execution plan for this problematic SQL (created after purging), so optimizer will always use this good execution plan.
Is it possible to use SQL Plan Baselines in this situation (any problem here)?
Please sorry because, I am new in this area.
Best regards,
D.RThanks William,
The following SQL statement has been identified to perform poorly.
This is the statement:
SELECT POSAO_POSAO_ID,BROJ_PROTOKOLA,NAZIV,IME,ULICA_OPSTINA_ID,ULICA_ID
,BROJ_ZGRADE,DATUM_DAJE,VRSTA_ZAHTEVA_ID,STA_ZADATK_STATUS_ZADATKA_ID
FROM FTPRO.RADNA_LISTA_ZADATAKA WHERE sta_zadatk_status_zadatka_id ='1'
and vr_zadatka_vrsta_zadatka_id='0321' and oj_ftpro_oj_ftpro_id_zadatak='7822'
and (datum_daje between to_date('01.10.2010','dd.mm.yyyy') and
to_date('18.10.2010','dd.mm.yyyy')+1) and (ulica_opstina_id like '%' or
ulica_opstina_id is null) and (ulica_id like '%' or ulica_id is null)
and (broj_zgrade like '%'||'%' or broj_zgrade is null) and
broj_protokola like '%' and posao_posao_id like '%' and (('%'='%' and
naziv like '%') or ('%'!='%' and ime like '%' and naziv like '%'))
order by DATUM_DAJE DESC;The version of the database is 11.2.0.1.0
These are the parameters relevant to the optimizer:
system> show parameter optimizer
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 1
optimizer_features_enable string 9.2.0
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string CHOOSE
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean TRUE
system>Here is the output of EXPLAIN PLAN:
system> explain plan for
2 SELECT POSAO_POSAO_ID,BROJ_PROTOKOLA,NAZIV,IME,ULICA_OPSTINA_ID,ULICA_ID
3 ,BROJ_ZGRADE,DATUM_DAJE,VRSTA_ZAHTEVA_ID,STA_ZADATK_STATUS_ZADATKA_ID
4 FROM FTPRO.RADNA_LISTA_ZADATAKA WHERE sta_zadatk_status_zadatka_id ='1'
5 and vr_zadatka_vrsta_zadatka_id='0321' and oj_ftpro_oj_ftpro_id_zadatak='7822'
6 and (datum_daje between to_date('01.10.2010','dd.mm.yyyy') and
7 to_date('18.10.2010','dd.mm.yyyy')+1) and (ulica_opstina_id like '%' or
8 ulica_opstina_id is null) and (ulica_id like '%' or ulica_id is null)
9 and (broj_zgrade like '%'||'%' or broj_zgrade is null) and
10 broj_protokola like '%' and posao_posao_id like '%' and (('%'='%' and
11 naziv like '%') or ('%'!='%' and ime like '%' and naziv like '%'))
12 order by DATUM_DAJE DESC;
Explained.
Elapsed: 00:00:00.01
system> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3274296436
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 15 | 2895 | 208 |
| 1 | SORT ORDER BY | | 15 | 2895 | 208 |
| 2 | VIEW | RADNA_LISTA_ZADATAKA | 15 | 2895 | 162 |
| 3 | SORT UNIQUE | | 15 | 1875 | 162 |
|* 4 | FILTER | | | | |
| 5 | NESTED LOOPS OUTER | | 15 | 1875 | 115 |
| 6 | NESTED LOOPS | | 15 | 1470 | 70 |
| 7 | NESTED LOOPS | | 15 | 1050 | 40 |
|* 8 | TABLE ACCESS BY INDEX ROWID| ZADATAK | 15 | 450 | 10 |
|* 9 | INDEX RANGE SCAN | ZADATAK_OJ_DATUM_DAJE_STATUS | 15 | | 4 |
|* 10 | TABLE ACCESS BY INDEX ROWID| ZAHTEV | 1 | 40 | 2 |
|* 11 | INDEX UNIQUE SCAN | ZAHTEV_POSAO_ID_UNIQUE | 1 | | 1 |
|* 12 | TABLE ACCESS BY INDEX ROWID | KORISNIK_USLUGA | 1 | 28 | 2 |
|* 13 | INDEX UNIQUE SCAN | KORISNIK_PK | 1 | | 1 |
| 14 | TABLE ACCESS BY INDEX ROWID | ADRESA_INSTALACIJE | 1 | 27 | 3 |
|* 15 | INDEX RANGE SCAN | ADR_INSTAL_PK | 1 | | 2 |
Predicate Information (identified by operation id):
4 - filter((("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='1' OR
"ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='7' OR
"ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' OR
"ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='9') OR
"ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID" IS NULL) AND (CASE WHEN
("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."ULICA_OPSTINA_ID"
END LIKE '%' OR CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."ULICA_OPSTINA_ID"
END IS NULL) AND (CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."ULICA_ID" END LIKE
'%' OR CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."ULICA_ID" END IS
NULL) AND (CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."BROJ_ZGRADE" END
LIKE '%%' OR CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."BROJ_ZGRADE" END
IS NULL))
8 - filter("ZADATAK"."POSAO_POSAO_ID" LIKE '%')
9 - access("ZADATAK"."OJ_FTPRO_OJ_FTPRO_ID_ZADATAK"='7822' AND
"ZADATAK"."VR_ZADATKA_VRSTA_ZADATKA_ID"='0321' AND
"ZADATAK"."STA_ZADATK_STATUS_ZADATKA_ID"='1' AND "ZADATAK"."DATUM_DAJE">=TO_DATE('
2010-10-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "ZADATAK"."DATUM_DAJE"<=TO_DATE('
2010-10-19 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
10 - filter("ZAHTEV"."BROJ_PROTOKOLA" LIKE '%')
11 - access("ZADATAK"."POSAO_POSAO_ID"="ZAHTEV"."ZAHTEV_POSAO_ID")
filter("ZAHTEV"."ZAHTEV_POSAO_ID" LIKE '%')
12 - filter("KORISNIK_USLUGA"."NAZIV" LIKE '%')
13 - access("KORISNIK_USLUGA"."KORISNIK_ID"="ZAHTEV"."KORISNIK_KORISNIK_ID")
15 - access("ADRESA_INSTALACIJE"."ZAHTEV_ZAHTEV_ID"(+)="ZAHTEV"."ZAHTEV_ID")
Note
- cpu costing is off (consider enabling it)
60 rows selected.
Elapsed: 00:00:00.14
Execution Plan
Plan hash value: 3013799171
| Id | Operation | Name |
| 0 | SELECT STATEMENT | |
| 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY |
Note
- rule based optimizer used (consider using cbo)
Statistics
27 recursive calls
12 db block gets
54 consistent gets
0 physical reads
0 redo size
5112 bytes sent via SQL*Net to client
264 bytes received via SQL*Net from client
5 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
60 rows processed
system>Here is the output of SQL*Plus AUTOTRACE including the TIMING information:
system> set autotrace on
system> SELECT POSAO_POSAO_ID,BROJ_PROTOKOLA,NAZIV,IME,ULICA_OPSTINA_ID,ULICA_ID
2 ,BROJ_ZGRADE,DATUM_DAJE,VRSTA_ZAHTEVA_ID,STA_ZADATK_STATUS_ZADATKA_ID
3 FROM FTPRO.RADNA_LISTA_ZADATAKA WHERE sta_zadatk_status_zadatka_id ='1'
4 and vr_zadatka_vrsta_zadatka_id='0321' and oj_ftpro_oj_ftpro_id_zadatak='7822'
5 and (datum_daje between to_date('01.10.2010','dd.mm.yyyy') and
6 to_date('18.10.2010','dd.mm.yyyy')+1) and (ulica_opstina_id like '%' or
7 ulica_opstina_id is null) and (ulica_id like '%' or ulica_id is null)
8 and (broj_zgrade like '%'||'%' or broj_zgrade is null) and
9 broj_protokola like '%' and posao_posao_id like '%' and (('%'='%' and
10 naziv like '%') or ('%'!='%' and ime like '%' and naziv like '%'))
11 order by DATUM_DAJE DESC;
POSAO_POSA BROJ_PROTO NAZIV
IME ULI
A ULICA BROJ DATUM_DA VRS S
158183910 158183910 SJAJ SZR BESLAĂ BOSILJKA
709
4 01465 BB 15.10.10 94 1
158171213 158171213 BEZAREVIĂ
JANKO 000
0 14597 72 15.10.10 94 1
157029103 280083-35 NAFTNA INDUSTRIJA SRBIJE AD NOVI SAD
802
9 02358 27 05.10.10 103 1
Elapsed: 00:00:00.01
Execution Plan
Plan hash value: 3274296436
| Id | Operation | Name | Rows | Bytes | Cost |
| 0 | SELECT STATEMENT | | 15 | 2895 | 208 |
| 1 | SORT ORDER BY | | 15 | 2895 | 208 |
| 2 | VIEW | RADNA_LISTA_ZADATAKA | 15 | 2895 | 162 |
| 3 | SORT UNIQUE | | 15 | 1875 | 162 |
|* 4 | FILTER | | | | |
| 5 | NESTED LOOPS OUTER | | 15 | 1875 | 115 |
| 6 | NESTED LOOPS | | 15 | 1470 | 70 |
| 7 | NESTED LOOPS | | 15 | 1050 | 40 |
|* 8 | TABLE ACCESS BY INDEX ROWID| ZADATAK | 15 | 450 | 10 |
|* 9 | INDEX RANGE SCAN | ZADATAK_OJ_DATUM_DAJE_STATUS | 15 | | 4 |
|* 10 | TABLE ACCESS BY INDEX ROWID| ZAHTEV | 1 | 40 | 2 |
|* 11 | INDEX UNIQUE SCAN | ZAHTEV_POSAO_ID_UNIQUE | 1 | | 1 |
|* 12 | TABLE ACCESS BY INDEX ROWID | KORISNIK_USLUGA | 1 | 28 | 2 |
|* 13 | INDEX UNIQUE SCAN | KORISNIK_PK | 1 | | 1 |
| 14 | TABLE ACCESS BY INDEX ROWID | ADRESA_INSTALACIJE | 1 | 27 | 3 |
|* 15 | INDEX RANGE SCAN | ADR_INSTAL_PK | 1 | | 2 |
Predicate Information (identified by operation id):
4 - filter((("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='1' OR
"ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='7' OR
"ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' OR
"ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='9') OR
"ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID" IS NULL) AND (CASE WHEN
("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."ULICA_OPSTINA_ID"
END LIKE '%' OR CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."ULICA_OPSTINA_ID"
END IS NULL) AND (CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."ULICA_ID" END LIKE
'%' OR CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."ULICA_ID" END IS
NULL) AND (CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."BROJ_ZGRADE" END
LIKE '%%' OR CASE WHEN ("ADRESA_INSTALACIJE"."TIP_ADRESE_TIP_ADRESE_ID"='8' AND
"ZAHTEV"."VRSTA_ZAHTEVA_ID"<>'136') THEN '' ELSE "ADRESA_INSTALACIJE"."BROJ_ZGRADE" END
IS NULL))
8 - filter("ZADATAK"."POSAO_POSAO_ID" LIKE '%')
9 - access("ZADATAK"."OJ_FTPRO_OJ_FTPRO_ID_ZADATAK"='7822' AND
"ZADATAK"."VR_ZADATKA_VRSTA_ZADATKA_ID"='0321' AND
"ZADATAK"."STA_ZADATK_STATUS_ZADATKA_ID"='1' AND "ZADATAK"."DATUM_DAJE">=TO_DATE('
2010-10-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "ZADATAK"."DATUM_DAJE"<=TO_DATE('
2010-10-19 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
10 - filter("ZAHTEV"."BROJ_PROTOKOLA" LIKE '%')
11 - access("ZADATAK"."POSAO_POSAO_ID"="ZAHTEV"."ZAHTEV_POSAO_ID")
filter("ZAHTEV"."ZAHTEV_POSAO_ID" LIKE '%')
12 - filter("KORISNIK_USLUGA"."NAZIV" LIKE '%')
13 - access("KORISNIK_USLUGA"."KORISNIK_ID"="ZAHTEV"."KORISNIK_KORISNIK_ID")
15 - access("ADRESA_INSTALACIJE"."ZAHTEV_ZAHTEV_ID"(+)="ZAHTEV"."ZAHTEV_ID")
Note
- cpu costing is off (consider enabling it)
Statistics
0 recursive calls
0 db block gets
44 consistent gets
0 physical reads
0 redo size
799 bytes sent via SQL*Net to client
243 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
2 sorts (memory)
0 sorts (disk)
3 rows processed
system>The TKPROF output for this statement looks like the following:
TKPROF: Release 11.2.0.1.0 - Development on Mon Oct 25 09:49:35 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: tis1_ora_21826_Look_For_Me.trc
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT POSAO_POSAO_ID,BROJ_PROTOKOLA,NAZIV,IME,ULICA_OPSTINA_ID,ULICA_ID
,BROJ_ZGRADE,DATUM_DAJE,VRSTA_ZAHTEVA_ID,STA_ZADATK_STATUS_ZADATKA_ID
FROM FTPRO.RADNA_LISTA_ZADATAKA WHERE sta_zadatk_status_zadatka_id ='1'
and vr_zadatka_vrsta_zadatka_id='0321' and oj_ftpro_oj_ftpro_id_zadatak='7822'
and (datum_daje between to_date('01.10.2010','dd.mm.yyyy') and
to_date('18.10.2010','dd.mm.yyyy')+1) and (ulica_opstina_id like '%' or
"a.txt" 144 lines, 7472 characters
TKPROF: Release 11.2.0.1.0 - Development on Mon Oct 25 09:49:35 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Trace file: tis1_ora_21826_Look_For_Me.trc
Sort options: prsela exeela fchela
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
SELECT POSAO_POSAO_ID,BROJ_PROTOKOLA,NAZIV,IME,ULICA_OPSTINA_ID,ULICA_ID
,BROJ_ZGRADE,DATUM_DAJE,VRSTA_ZAHTEVA_ID,STA_ZADATK_STATUS_ZADATKA_ID
FROM FTPRO.RADNA_LISTA_ZADATAKA WHERE sta_zadatk_status_zadatka_id ='1'
and vr_zadatka_vrsta_zadatka_id='0321' and oj_ftpro_oj_ftpro_id_zadatak='7822'
and (datum_daje between to_date('01.10.2010','dd.mm.yyyy') and
to_date('18.10.2010','dd.mm.yyyy')+1) and (ulica_opstina_id like '%' or
ulica_opstina_id is null) and (ulica_id like '%' or ulica_id is null)
and (broj_zgrade like '%'||'%' or broj_zgrade is null) and
broj_protokola like '%' and posao_posao_id like '%' and (('%'='%' and
naziv like '%') or ('%'!='%' and ime like '%' and naziv like '%'))
order by DATUM_DAJE DESC
call count cpu elapsed disk query current rows
Parse 1 0.02 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.00 0.00 2 44 0 3
total 4 0.02 0.02 2 44 0 3
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 5
Rows Row Source Operation
3 SORT ORDER BY (cr=44 pr=2 pw=0 time=0 us cost=208 size=2895 card=15)
3 VIEW RADNA_LISTA_ZADATAKA (cr=44 pr=2 pw=0 time=6 us cost=162 size=2895 card=15)
3 SORT UNIQUE (cr=44 pr=2 pw=0 time=2 us cost=162 size=1875 card=15)
3 FILTER (cr=44 pr=2 pw=0 time=10406 us)
3 NESTED LOOPS OUTER (cr=44 pr=2 pw=0 time=10402 us cost=115 size=1875 card=15)
3 NESTED LOOPS (cr=33 pr=2 pw=0 time=10310 us cost=70 size=1470 card=15)
3 NESTED LOOPS (cr=22 pr=0 pw=0 time=120 us cost=40 size=1050 card=15)
3 TABLE ACCESS BY INDEX ROWID ZADATAK (cr=11 pr=0 pw=0 time=58 us cost=10 size=450 card=15)
3 INDEX RANGE SCAN ZADATAK_OJ_DATUM_DAJE_STATUS (cr=8 pr=0 pw=0 time=46 us cost=4 size=0 card=15)(object id 74612)
3 TABLE ACCESS BY INDEX ROWID ZAHTEV (cr=11 pr=0 pw=0 time=0 us cost=2 size=40 card=1)
3 INDEX UNIQUE SCAN ZAHTEV_POSAO_ID_UNIQUE (cr=8 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 74674)
3 TABLE ACCESS BY INDEX ROWID KORISNIK_USLUGA (cr=11 pr=2 pw=0 time=0 us cost=2 size=28 card=1)
3 INDEX UNIQUE SCAN KORISNIK_PK (cr=8 pr=0 pw=0 time=0 us cost=1 size=0 card=1)(object id 70404)
3 TABLE ACCESS BY INDEX ROWID ADRESA_INSTALACIJE (cr=11 pr=0 pw=0 time=0 us cost=3 size=27 card=1)
3 INDEX RANGE SCAN ADR_INSTAL_PK (cr=8 pr=0 pw=0 time=0 us cost=2 size=0 card=1)(object id 74677)
SQL ID: 9babjv8yq8ru3
Plan Hash: 0
BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
call count cpu elapsed disk query current rows
Parse 2 0.00 0.00 0 0 0 0
Execute 2 0.00 0.00 0 0 0 2
Fetch 0 0.00 0.00 0 0 0 0
total 4 0.00 0.00 0 0 0 2
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 5
SQL ID: 1a2g3z4rj1uq2
Plan Hash: 0
alter session set sql_trace true
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 1 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: 5
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 3 0.02 0.01 0 0 0 0
Execute 4 0.00 0.00 0 0 0 2
Fetch 2 0.00 0.00 2 44 0 3
total 9 0.02 0.02 2 44 0 5
Misses in library cache during parse: 1
Misses in library cache during execute: 1
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 6 0.01 0.00 0 0 0 0
Execute 6 0.00 0.01 0 1 4 1
Fetch 5 0.00 0.00 0 11 0 4
total 17 0.01 0.01 0 12 4 5
Misses in library cache during parse: 3
Misses in library cache during execute: 3
4 user SQL statements in session.
6 internal SQL statements in session.
10 SQL statements in session.
Trace file: tis1_ora_21826_Look_For_Me.trc
Trace file compatibility: 11.1.0.7
Sort options: prsela exeela fchela
1 session in tracefile.
4 user SQL statements in trace file.
6 internal SQL statements in trace file.
10 SQL statements in trace file.
8 unique SQL statements in trace file.
140 lines in trace file.
43 elapsed seconds in trace file.
Fetch 5 0.00 0.00 0 11 0 4
total 17 0.01 0.01 0 12 4 5
Misses in library cache during parse: 3
Misses in library cache during execute: 3
4 user SQL statements in session.
6 internal SQL statements in session.
10 SQL statements in session.
Trace file: tis1_ora_21826_Look_For_Me.trc
Trace file compatibility: 11.1.0.7
Sort options: prsela exeela fchela
1 session in tracefile.
4 user SQL statements in trace file.
6 internal SQL statements in trace file.
10 SQL statements in trace file.
8 unique SQL statements in trace file.
140 lines in trace file.
43 elapsed seconds in trace file.I am not sure now about the chenging execution plan when the problem exists.
I am sure that ADDM shows that this is problematic sql, and after purging this
SQL CPU burden is goring from 95% to 40%.
It's practicaly impossible to simulate this problem, because it's appear sometimes, after we take purging.
I have image from EM which show the CPU burden, but I don't know is it possible to insert image here.
Best regards,
D.R -
Problematic sql with outer join
There is one sql statement:
INSERT INTO XXOM_SSC_TEMP_MMI_GTEMP (HEADER_ID, LAST_UPDATE_DATE) SELECT DISTINCT OOH.HEADER_ID, XSOH.LAST_UPDATE_DATE FROM OE_ORDER_HEADERS_ALL OOH INNER JOIN (SELECT TRANSACTION_TYPE_ID FROM OE_TRANSACTION_TYPES_TL OTT WHERE OTT.NAME NOT IN ('ORDER_RMA_MMI' ) AND OTT.LANGUAGE = 'US') OTT ON (OTT.TRANSACTION_TYPE_ID = OOH.ORDER_TYPE_ID) LEFT OUTER JOIN XXOM_3LP_SYM_ORA_ORDER_HDR XSOH ON (TO_CHAR (XSOH.ORDERTYPE) = SUBSTR ( OOH.ORIG_SYS_DOCUMENT_REF, 1, INSTR (OOH.ORIG_SYS_DOCUMENT_REF, '-', 1) - 1) AND TO_CHAR (XSOH.ORDERNBR) = SUBSTR ( OOH.ORIG_SYS_DOCUMENT_REF, INSTR (OOH.ORIG_SYS_DOCUMENT_REF, '-', 1) + 1) AND (XSOH.LAST_UPDATE_DATE >= :B1 )) INNER JOIN OE_ORDER_LINES_ALL OOL ON (OOH.HEADER_ID = OOL.HEADER_ID AND OOL.SHIP_FROM_ORG_ID = :B2 ) WHERE OOH.BOOKED_FLAG = 'Y' AND XSOH.ORG_ID = OOH.ORG_ID
Porblematic query has insufficient and sub-optimal join conditions which makes it more expensive.One has recommended to remove one unnecessary outer join from the query and also fix the join to pick index.
But how can we remove outer join and in place of that what should we write.Your code is unreadable, man! Surely your boss does not let you produce stuff like that? Format it. Because I'm a helpful person, I just put it through the formatter on http://www.dpriver.com/pp/sqlformat.htm :INSERT INTO xxom_ssc_temp_mmi_gtemp
(header_id,
last_update_date)
SELECT DISTINCT OOH.header_id,
XSOH.last_update_date
FROM oe_order_headers_all OOH
inner join (SELECT transaction_type_id
FROM oe_transaction_types_tl OTT
WHERE OTT.name NOT IN ( 'ORDER_RMA_MMI' )
AND OTT.LANGUAGE = 'US') OTT
ON ( OTT.transaction_type_id = OOH.order_type_id )
left outer join xxom_3lp_sym_ora_order_hdr XSOH
ON ( To_char (XSOH.ordertype) =
Substr (OOH.orig_sys_document_ref,
1,
Instr (OOH.orig_sys_document_ref,
'-', 1)
- 1)
AND To_char (XSOH.ordernbr) =
Substr (OOH.orig_sys_document_ref,
Instr (OOH.orig_sys_document_ref, '-', 1) + 1
AND ( XSOH.last_update_date >= :B1 ) )
inner join oe_order_lines_all OOL
ON ( OOH.header_id = OOL.header_id
AND OOL.ship_from_org_id = :B2 )
WHERE OOH.booked_flag = 'Y'
AND XSOH.org_id = OOH.org_id -
Sql Query Tuning. Please help me to tune this query
Hi All ,
I have this problematic Sql . It is taking huge time to execute. It contains a view CIDV, which i think is the bottleneck.
I have pasted the query below. I will be pasting TKPROF and explain plan for the same. Please advice me to tune this query.
SELECT GCC.SEGMENT1 || '.' || GCC.SEGMENT2 || '.' || GCC.SEGMENT3 || '.' ||
GCC.SEGMENT4 || '.' || GCC.SEGMENT5 || '.' || GCC.SEGMENT6 || '.' ||
GCC.SEGMENT7 || '.' || GCC.SEGMENT8 || '.' || GCC.SEGMENT9 OFFSET_ACCOUNT,
OOD.ORGANIZATION_CODE,
CIDV.SUBINVENTORY_CODE OFFSET_SUBINV,
MIL.SEGMENT1 || '.' || MIL.SEGMENT2 || '.' || MIL.SEGMENT3 || '.' ||
MIL.SEGMENT4 || '.' || MIL.SEGMENT5 OFFSET_LOCATOR,
CIDV.LAST_UPDATE_LOGIN
FROM APPS.CST_INV_DISTRIBUTION_V CIDV,
APPS.GL_CODE_COMBINATIONS GCC,
APPS.MTL_ITEM_LOCATIONS MIL,
APPS.ORG_ORGANIZATION_DEFINITIONS OOD
WHERE CIDV.TRANSACTION_ID = :B2
AND CIDV.PRIMARY_QUANTITY = (-1) * :B1
AND CIDV.REFERENCE_ACCOUNT = GCC.CODE_COMBINATION_ID
AND OOD.ORGANIZATION_ID = CIDV.ORGANIZATION_ID
AND MIL.INVENTORY_LOCATION_ID = CIDV.LOCATOR_ID
AND GCC.ACCOUNT_TYPE = 'A'****************
TKPROF
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 68337 10.32 10.32 0 0 0 0
Fetch 68337 229.75 936.36 58819 6743323 1121 68232
total 136675 240.07 946.69 58819 6743323 1121 68232
Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: ALL_ROWS
Parsing user id: 203 (recursive depth: 1)
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 MERGE JOIN CARTESIAN (cr=102 pr=15 pw=0 time=193608 us cost=56 size=219 card=1)
1 1 1 NESTED LOOPS (cr=100 pr=15 pw=0 time=193483 us cost=53 size=219 card=1)
1 1 1 NESTED LOOPS (cr=99 pr=15 pw=0 time=193407 us cost=52 size=215 card=1)
1 1 1 NESTED LOOPS (cr=96 pr=15 pw=0 time=193378 us cost=51 size=190 card=1)
1 1 1 NESTED LOOPS (cr=93 pr=15 pw=0 time=193284 us cost=49 size=162 card=1)
1 1 1 NESTED LOOPS (cr=89 pr=14 pw=0 time=185515 us cost=46 size=138 card=1)
1 1 1 NESTED LOOPS (cr=85 pr=12 pw=0 time=157975 us cost=44 size=81 card=1)
1 1 1 NESTED LOOPS (cr=83 pr=12 pw=0 time=157925 us cost=43 size=73 card=1)
1 1 1 NESTED LOOPS (cr=81 pr=12 pw=0 time=157641 us cost=43 size=132 card=2)
1 1 1 VIEW CST_INV_DISTRIBUTION_V (cr=78 pr=12 pw=0 time=156386 us cost=41 size=118 card=2)
1 1 1 UNION-ALL (cr=78 pr=12 pw=0 time=156378 us)
0 0 0 NESTED LOOPS OUTER (cr=44 pr=9 pw=0 time=124997 us cost=20 size=291 card=1)
0 0 0 NESTED LOOPS (cr=44 pr=9 pw=0 time=124993 us cost=18 size=255 card=1)
0 0 0 NESTED LOOPS (cr=44 pr=9 pw=0 time=124990 us cost=18 size=251 card=1)
33 33 33 MERGE JOIN CARTESIAN (cr=25 pr=6 pw=0 time=98544 us cost=14 size=192 card=1)
1 1 1 NESTED LOOPS OUTER (cr=22 pr=5 pw=0 time=85754 us cost=12 size=156 card=1)
1 1 1 NESTED LOOPS (cr=19 pr=4 pw=0 time=79830 us cost=10 size=120 card=1)
1 1 1 NESTED LOOPS OUTER (cr=17 pr=4 pw=0 time=79813 us cost=9 size=113 card=1)
1 1 1 NESTED LOOPS (cr=15 pr=4 pw=0 time=79752 us cost=8 size=106 card=1)
1 1 1 NESTED LOOPS (cr=11 pr=2 pw=0 time=43120 us cost=6 size=93 card=1)
1 1 1 NESTED LOOPS (cr=7 pr=2 pw=0 time=43087 us cost=4 size=83 card=1)
1 1 1 NESTED LOOPS (cr=6 pr=2 pw=0 time=43072 us cost=4 size=80 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=5 pr=2 pw=0 time=43042 us cost=4 size=76 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_MATERIAL_TRANSACTIONS_U1 (cr=4 pr=2 pw=0 time=43011 us cost=3 size=0 card=1)(object id 12484094)
1 1 1 INDEX UNIQUE SCAN MTL_TRANSACTION_TYPES_U1 (cr=1 pr=0 pw=0 time=20 us cost=0 size=764 card=191)(object id 9983)
1 1 1 INDEX UNIQUE SCAN MTL_TXN_SOURCE_TYPES_U1 (cr=1 pr=0 pw=0 time=7 us cost=0 size=54 card=18)(object id 9987)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=4 pr=0 pw=0 time=27 us cost=2 size=736324450 card=73632445)(object id 12484155)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_TL_U1 (cr=4 pr=2 pw=0 time=36626 us cost=2 size=957481070 card=73652390)(object id 12484137)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=42 us cost=1 size=3290 card=470)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=28 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=12 us cost=1 size=3290 card=470)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=7 us cost=0 size=0 card=1)(object id 9847)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=5915 us cost=2 size=36 card=1)(object id 705891)
33 33 33 BUFFER SORT (cr=3 pr=1 pw=0 time=12713 us cost=12 size=36 card=1)
33 33 33 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=1 pw=0 time=12582 us cost=2 size=36 card=1)(object id 705891)
0 0 0 TABLE ACCESS BY INDEX ROWID MTL_TRANSACTION_ACCOUNTS (cr=19 pr=3 pw=0 time=26591 us cost=4 size=59 card=1)
66 66 66 INDEX RANGE SCAN MTL_TRANSACTION_ACCOUNTS_N1 (cr=18 pr=2 pw=0 time=13607 us cost=3 size=0 card=3)(object id 12484127)
0 0 0 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=0 pr=0 pw=0 time=0 us cost=0 size=4 card=1)(object id 9847)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=0 pr=0 pw=0 time=0 us cost=2 size=36 card=1)(object id 705891)
1 1 1 NESTED LOOPS (cr=34 pr=3 pw=0 time=31269 us cost=21 size=288 card=1)
1 1 1 NESTED LOOPS (cr=30 pr=3 pw=0 time=31161 us cost=19 size=275 card=1)
1 1 1 NESTED LOOPS (cr=26 pr=3 pw=0 time=31105 us cost=17 size=265 card=1)
1 1 1 NESTED LOOPS (cr=25 pr=3 pw=0 time=31082 us cost=17 size=261 card=1)
1 1 1 NESTED LOOPS OUTER (cr=23 pr=3 pw=0 time=31027 us cost=16 size=254 card=1)
1 1 1 NESTED LOOPS (cr=21 pr=3 pw=0 time=30980 us cost=15 size=247 card=1)
1 1 1 NESTED LOOPS (cr=20 pr=3 pw=0 time=30957 us cost=15 size=243 card=1)
1 1 1 NESTED LOOPS OUTER (cr=19 pr=3 pw=0 time=30926 us cost=15 size=240 card=1)
1 1 1 NESTED LOOPS (cr=16 pr=3 pw=0 time=30389 us cost=13 size=204 card=1)
1 1 1 NESTED LOOPS (cr=11 pr=0 pw=0 time=665 us cost=9 size=131 card=1)
1 1 1 NESTED LOOPS OUTER (cr=8 pr=0 pw=0 time=306 us cost=7 size=95 card=1)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_TRANSACTION_ACCOUNTS (cr=5 pr=0 pw=0 time=37 us cost=5 size=59 card=1)
2 2 2 INDEX RANGE SCAN MTL_TRANSACTION_ACCOUNTS_N1 (cr=4 pr=0 pw=0 time=17 us cost=4 size=0 card=3)(object id 12484127)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=216 us cost=2 size=36 card=1)(object id 705891)
1 1 1 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=352 us cost=2 size=36 card=1)(object id 705891)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_MATERIAL_TRANSACTIONS (cr=5 pr=3 pw=0 time=29716 us cost=4 size=73 card=1)
1 1 1 INDEX RANGE SCAN MTL_MATERIAL_TRANSACTIONS_N23 (cr=4 pr=3 pw=0 time=29588 us cost=3 size=0 card=1)(object id 12484133)
0 0 0 INDEX RANGE SCAN FND_LOOKUP_VALUES_U1 (cr=3 pr=0 pw=0 time=520 us cost=2 size=36 card=1)(object id 705891)
1 1 1 INDEX UNIQUE SCAN MTL_TXN_SOURCE_TYPES_U1 (cr=1 pr=0 pw=0 time=22 us cost=0 size=3 card=1)(object id 9987)
1 1 1 INDEX UNIQUE SCAN MTL_TRANSACTION_TYPES_U1 (cr=1 pr=0 pw=0 time=16 us cost=0 size=4 card=1)(object id 9983)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=34 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=19 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=44 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=14 us cost=0 size=0 card=1)(object id 9847)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=13 us cost=0 size=4 card=1)(object id 9847)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_B_U1 (cr=4 pr=0 pw=0 time=49 us cost=2 size=10 card=1)(object id 12484155)
1 1 1 INDEX UNIQUE SCAN MTL_SYSTEM_ITEMS_TL_U1 (cr=4 pr=0 pw=0 time=96 us cost=2 size=13 card=1)(object id 12484137)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ALL_ORGANIZATION_UNITS (cr=3 pr=0 pw=0 time=1246 us cost=1 size=7 card=1)
1 1 1 INDEX UNIQUE SCAN HR_ORGANIZATION_UNITS_PK (cr=2 pr=0 pw=0 time=24 us cost=0 size=0 card=1)(object id 250158)
1 1 1 INDEX UNIQUE SCAN HR_ALL_ORGANIZATION_UNTS_TL_PK (cr=2 pr=0 pw=0 time=275 us cost=0 size=7 card=1)(object id 689101)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_PARAMETERS (cr=2 pr=0 pw=0 time=38 us cost=1 size=8 card=1)
1 1 1 INDEX UNIQUE SCAN MTL_PARAMETERS_U1 (cr=1 pr=0 pw=0 time=15 us cost=0 size=0 card=1)(object id 9847)
1 1 1 TABLE ACCESS BY INDEX ROWID GL_CODE_COMBINATIONS (cr=4 pr=2 pw=0 time=27531 us cost=2 size=57 card=1)
1 1 1 INDEX UNIQUE SCAN GL_CODE_COMBINATIONS_U1 (cr=3 pr=1 pw=0 time=19925 us cost=1 size=0 card=1)(object id 51426)
1 1 1 TABLE ACCESS BY INDEX ROWID MTL_ITEM_LOCATIONS (cr=4 pr=1 pw=0 time=7758 us cost=3 size=24 card=1)
1 1 1 INDEX RANGE SCAN MTL_ITEM_LOCATIONS_U1 (cr=3 pr=0 pw=0 time=51 us cost=2 size=0 card=1)(object id 9761)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION (cr=3 pr=0 pw=0 time=85 us cost=2 size=28 card=1)
1 1 1 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 (cr=2 pr=0 pw=0 time=29 us cost=1 size=0 card=2)(object id 5379798)
1 1 1 TABLE ACCESS BY INDEX ROWID HR_ORGANIZATION_INFORMATION (cr=3 pr=0 pw=0 time=25 us cost=1 size=25 card=1)
1 1 1 INDEX RANGE SCAN HR_ORGANIZATION_INFORMATIO_FK2 (cr=2 pr=0 pw=0 time=11 us cost=1 size=0 card=1)(object id 5379798)
1 1 1 INDEX FULL SCAN GL_SETS_OF_BOOKS_U2 (cr=1 pr=0 pw=0 time=69 us cost=1 size=4 card=1)(object id 1380842)
1 1 1 BUFFER SORT (cr=2 pr=0 pw=0 time=110 us cost=55 size=0 card=1)
1 1 1 TABLE ACCESS FULL FND_PRODUCT_GROUPS (cr=2 pr=0 pw=0 time=59 us cost=3 size=0 card=1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
library cache lock 2 0.00 0.00
library cache pin 2 0.00 0.00
Disk file operations I/O 249 0.00 0.00
db file sequential read 58819 2.61 714.28
gc cr grant 2-way 5198 0.16 4.52
gc current grant busy 1 0.00 0.00
KJC: Wait for msg sends to complete 517 0.00 0.05
library cache: mutex X 433 0.01 0.04
gc cr grant congested 28 0.08 0.18
latch: ges resource hash list 5 0.00 0.00
gc current block 2-way 513 0.11 0.61
gc current block congested 2 0.00 0.00
latch: gc element 16 0.00 0.01
latch: cache buffers chains 4 0.00 0.00
latch: object queue header operation 3 0.00 0.00
********************************************************************************Explain Plan for the query
SELECT STATEMENT, GOAL = ALL_ROWS Cost=56 Cardinality=1 Bytes=219
MERGE JOIN CARTESIAN Cost=56 Cardinality=1 Bytes=219
NESTED LOOPS Cost=53 Cardinality=1 Bytes=219
NESTED LOOPS Cost=52 Cardinality=1 Bytes=215
NESTED LOOPS Cost=51 Cardinality=1 Bytes=190
NESTED LOOPS Cost=49 Cardinality=1 Bytes=162
NESTED LOOPS Cost=46 Cardinality=1 Bytes=138
NESTED LOOPS Cost=44 Cardinality=1 Bytes=81
NESTED LOOPS Cost=43 Cardinality=1 Bytes=73
NESTED LOOPS Cost=43 Cardinality=2 Bytes=132
VIEW Object owner=APPS Object name=CST_INV_DISTRIBUTION_V Cost=41 Cardinality=2 Bytes=118
UNION-ALL
NESTED LOOPS OUTER Cost=20 Cardinality=1 Bytes=291
NESTED LOOPS Cost=18 Cardinality=1 Bytes=255
NESTED LOOPS Cost=18 Cardinality=1 Bytes=251
MERGE JOIN CARTESIAN Cost=14 Cardinality=1 Bytes=192
NESTED LOOPS OUTER Cost=12 Cardinality=1 Bytes=156
NESTED LOOPS Cost=10 Cardinality=1 Bytes=120
NESTED LOOPS OUTER Cost=9 Cardinality=1 Bytes=113
NESTED LOOPS Cost=8 Cardinality=1 Bytes=106
NESTED LOOPS Cost=6 Cardinality=1 Bytes=93
NESTED LOOPS Cost=4 Cardinality=1 Bytes=83
NESTED LOOPS Cost=4 Cardinality=1 Bytes=80
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS Cost=4 Cardinality=1 Bytes=76
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS_U1 Cost=3 Cardinality=1
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TRANSACTION_TYPES_U1 Cost=0 Cardinality=191 Bytes=764
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TXN_SOURCE_TYPES_U1 Cost=0 Cardinality=18 Bytes=54
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_B_U1 Cost=2 Cardinality=73632445 Bytes=736324450
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_TL_U1 Cost=2 Cardinality=73652390 Bytes=957481070
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=470 Bytes=3290
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=470 Bytes=3290
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
BUFFER SORT Cost=12 Cardinality=1 Bytes=36
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS Cost=4 Cardinality=1 Bytes=59
INDEX RANGE SCAN Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS_N1 Cost=3 Cardinality=3
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1 Bytes=4
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
NESTED LOOPS Cost=21 Cardinality=1 Bytes=288
NESTED LOOPS Cost=19 Cardinality=1 Bytes=275
NESTED LOOPS Cost=17 Cardinality=1 Bytes=265
NESTED LOOPS Cost=17 Cardinality=1 Bytes=261
NESTED LOOPS OUTER Cost=16 Cardinality=1 Bytes=254
NESTED LOOPS Cost=15 Cardinality=1 Bytes=247
NESTED LOOPS Cost=15 Cardinality=1 Bytes=243
NESTED LOOPS OUTER Cost=15 Cardinality=1 Bytes=240
NESTED LOOPS Cost=13 Cardinality=1 Bytes=204
NESTED LOOPS Cost=9 Cardinality=1 Bytes=131
NESTED LOOPS OUTER Cost=7 Cardinality=1 Bytes=95
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS Cost=5 Cardinality=1 Bytes=59
INDEX RANGE SCAN Object owner=INV Object name=MTL_TRANSACTION_ACCOUNTS_N1 Cost=4 Cardinality=3
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS Cost=4 Cardinality=1 Bytes=73
INDEX RANGE SCAN Object owner=INV Object name=MTL_MATERIAL_TRANSACTIONS_N23 Cost=3 Cardinality=1
INDEX RANGE SCAN Object owner=APPLSYS Object name=FND_LOOKUP_VALUES_U1 Cost=2 Cardinality=1 Bytes=36
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TXN_SOURCE_TYPES_U1 Cost=0 Cardinality=1 Bytes=3
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_TRANSACTION_TYPES_U1 Cost=0 Cardinality=1 Bytes=4
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1 Bytes=4
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_B_U1 Cost=2 Cardinality=1 Bytes=10
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_SYSTEM_ITEMS_TL_U1 Cost=2 Cardinality=1 Bytes=13
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ALL_ORGANIZATION_UNITS Cost=1 Cardinality=1 Bytes=7
INDEX UNIQUE SCAN Object owner=HR Object name=HR_ORGANIZATION_UNITS_PK Cost=0 Cardinality=1
INDEX UNIQUE SCAN Object owner=HR Object name=HR_ALL_ORGANIZATION_UNTS_TL_PK Cost=0 Cardinality=1 Bytes=7
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_PARAMETERS Cost=1 Cardinality=1 Bytes=8
INDEX UNIQUE SCAN Object owner=INV Object name=MTL_PARAMETERS_U1 Cost=0 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=GL Object name=GL_CODE_COMBINATIONS Cost=2 Cardinality=1 Bytes=57
INDEX UNIQUE SCAN Object owner=GL Object name=GL_CODE_COMBINATIONS_U1 Cost=1 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=INV Object name=MTL_ITEM_LOCATIONS Cost=3 Cardinality=1 Bytes=24
INDEX RANGE SCAN Object owner=INV Object name=MTL_ITEM_LOCATIONS_U1 Cost=2 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ORGANIZATION_INFORMATION Cost=2 Cardinality=1 Bytes=28
INDEX RANGE SCAN Object owner=HR Object name=HR_ORGANIZATION_INFORMATIO_FK2 Cost=1 Cardinality=2
TABLE ACCESS BY INDEX ROWID Object owner=HR Object name=HR_ORGANIZATION_INFORMATION Cost=1 Cardinality=1 Bytes=25
INDEX RANGE SCAN Object owner=HR Object name=HR_ORGANIZATION_INFORMATIO_FK2 Cost=1 Cardinality=1
INDEX FULL SCAN Object owner=GL Object name=GL_SETS_OF_BOOKS_U2 Cost=1 Cardinality=1 Bytes=4
BUFFER SORT Cost=55 Cardinality=1
TABLE ACCESS FULL Object owner=APPLSYS Object name=FND_PRODUCT_GROUPS Cost=3 Cardinality=1 -
How to prove the SQL query will spawning the process
In a Oracle 10g database, i noticed a user running a sql query which contain lot of "group by" "order by" iin database, suspected it spawning multiple process in database then causing the ORA-00020: maximum number of processes exceeded.
My question is, is there any dictionary view or report that i can generate to prove that is the problematic sql causing the error?
Please help. Many thanks.John Stegeman wrote:
What makes you think that group by and order by spawn processes? In general, they don't. In fact, I cannot think of any reason they would (and if I'm wrong, I'm sure I'll be corrected forthwith)No, no correction.
A query is a query bound to a session.
I can only imagine that a query can spawn lots op parallel slaves when using parallel server. -
Invalid SQL command after upgrading to Oracle 9i
After upgrading to Oracle 9i, the SQL queries in some of our existing reports are no longer valid. The Oracle error returned is "old style outer join () can not be used with ANSI joins". It appears that the SQL query generated by Crystal Reports is correct in that it uses "LEFT OUTER JOIN" instead of just naming the tables separated by a comma, but it also includes the "()" qualifer on the matching columns which is no longer allowed. Is there any way to overcome this error short of rewriting the reports based on a command?
Hello,
A couple suggestions come to mind.
Business Objects tend to take problematic SQL generation very seriously at least on the SQL and Oracle platforms (due to their widespread use) and I would first grab the latest database/engine hotfixes to be certain it hasn't been tracked and corrected already. If you can clearly reproduce this issue (sounds like you can) then it should be easy to convince the support team at BOBJ to track the issue. However...
Since their hotfix release cycle is rather slow especially for items that have workarounds (even sometimes painful workarounds) you may want to consider using a Stored Procedure instead of a Command.
Commands have a notorious history of issues/limitations that tend to burn you later - especially when you have to update many reports. A stored procedure would likely render the + qualifier a moot point.
Cheers, Dylan
<p><strong>Dylan Lopez - </strong>604.628.4467 </p><p>Previously: Microsoft .NET Resource in Developer Support @ Business Objects</p><p>Currently: Principal @ Inno Software Inc / Independent Contractor Group</p> -
Hi there,
I please You for suggestions and advice.I appriciate it in advance.
I have some problematic sql , lets say by enormous disk reads or by full table scans which I got by some query and I can get his sql_hash_value, sql_address, or some other unique identificator for that query.
Is there a way for me that I can found out which user executed that query by using that identificators ?
ToniJust a quick note for completeness when it has to do with sql in stored procedures. This column will show invoker only in case the stored procedure supports invoker rights.
ops$oskar@test9i$ conn /
Connected.
ops$oskar@test9i$ show user
USER is "OPS$OSKAR"
ops$oskar@test9i$ drop procedure p1;
Procedure dropped.
ops$oskar@test9i$ create or replace procedure p1 as
2 x varchar2(30);
3 begin
4 select /* ITS_ME */ * into x from dual;
5 end;
6 /
Procedure created.
ops$oskar@test9i$ grant execute on p1 to u1;
Grant succeeded.
ops$oskar@test9i$ create or replace procedure p2
2 AUTHID CURRENT_USER
3 as
4 x varchar2(30);
5 begin
6 select /* ITS_YOU */ * into x from dual;
7 end;
8 /
Procedure created.
ops$oskar@test9i$ grant execute on p2 to u1;
Grant succeeded.
ops$oskar@test9i$ conn u1/u1
Connected.
ops$oskar@test9i$ exec ops$oskar.p1;
PL/SQL procedure successfully completed.
ops$oskar@test9i$ exec ops$oskar.p2;
PL/SQL procedure successfully completed.
ops$oskar@test9i$ conn /
Connected.
ops$oskar@test9i$ select sql_text, parsing_user_id, username from v$sqlarea sa, dba_users u
2 where (sa.sql_text like '%ITS_ME%' or sa.sql_text like '%ITS_YOU%') and u.user_id=sa.parsing_user_id;
SQL_TEXT
PARSING_USER_ID USERNAME
SELECT /* ITS_ME */ * from dual
61 OPS$OSKAR
SELECT /* ITS_YOU */ * from dual
94 U1
select sql_text, parsing_user_id, username from v$sqlarea sa, dba_users u where
(sa.sql_text like '%ITS_ME%' or sa.sql_text like '%ITS_YOU%') and u.user_id=sa.p
arsing_user_id
61 OPS$OSKAR -
Transferring SQL Profiles between databases
We'd like to be able to ship SQL Profiles for 10gR2 with our application for commonly problematic SQL.
Does anyone know of a way that we can extract these profiles and apply them during application installation/upgrade?
There is a bug indicating that Query Profiles get set to not force matching during exp/imp. What I can't see is whether or not there is a way to export just the SQL Profiles. There seems nothing appropriate in database_export_objects.
Maybe there is another way that I am not aware of...Thank you - but won't this retrieve profiles (resource limits applicable to users/sessions) rather than SQL Profiles (replacement sets of hints applied automatically to SQL statements - much like outlines - generated by SQL Tuning Advisor).
It is SQL Profiles generated by the SQL Tuning Advisor that I am looking to transfer. Few of our customers will want to spend money on the Tuning Advisor, but they will all want to have these queries running quickly! -
Dear Experts,
I created a SQL plan baseline for one of the problematic SQL's yesterday and am seeing multiple sql plan baselines are getting created and are all enabled for this SQL ID.
I would like to understand why there are so many plan baselines created? how to get rid of them?
Thanks for your help!Hi,
If intended to stop the collection of sql base lines kindly check the parameter "optimizer_capture_sql_plan_baselines" whether to enable based on your query execution with different bind variable inputs.
- Thanks
Pavan Kumar N -
DEAR ALL
I MAKE SOME SQL TUNING
AND FOUND THIS
Problematic SQL Statement
9 Table operations found in execution plan exceeding the upper limit of
the Complex SQL Table Range. Full table scan with table size larger than
the Problematic SQL Full Table Scan Threshold (8
Kbytes).(TEMPLATE.VPD_SEC_PRIVILEGES 64,
TEMPLATE.USERS_GROUPS 2048, HRMS.HRMS_ORG_CHART_VPD 128,
TEMPLATE.VPD_SEC_PRIVILEGES 64, TEMPLATE.USERS_GROUPS 2048)
BUT I DON'T UNDERSTAND WHAT THAT MEAN
CAN ANY ONE EXPLAINE THIS?Well if this output is from SQL Navigator then I suggest you ask on an SQL Navigator forum what their output means.
As for tuning "select * from employees" I can tell you it will do a full table scan and performance cannot be improved for such a statement.
If you're interested in tuning SQL's using Oracle facilities look at this thread...
When your query takes too long ... -
Performance problems post Oracle 10.2.0.5 upgrade
Hi All,
We have patched our SAP ECC6 system's Oracle database from 10.2.0.2 to 10.2.0.5. (Operating system Solaris). This was done using the SAP Bundle Patch released in February 2011. (patched DEV, QA and then Production).
Post patching production, we are now experiencing slower performance of our long running background jobs, e.g. our billing runs has increased from 2 hours to 4 hours. The slow down is constant and has not increased or decreased over a period of two weeks.
We have so far implemented the following in production without any affect:
We have double checked that database parameters are set correctly as per note Note 830576 - Parameter recommendations for Oracle 10g.
We have executed with db02old the abap<->db crosscheck to check for missing indexes.
Note 1020260 - Delivery of Oracle statistics (Oracle 10g, 11g).
It was suggested to look at adding specific indexes on tables and changing abap code identified by looking at the most "expensive" SQL statements being executed, but these were all there pre patching and not within the critical long running processes. Although a good idea to optimise, this will not resolve the root cause of the problem introduced by the upgrade to 10.2.0.5. It was thus not implemented in production, although suggested new indexes were tested in QA without effect, then backed out.
It was also suggested to implement SAP Note 1525673 - Optimizer merge fix for Oracle 10.2.0.5, which was not part of the SAP Bundle Patch released in February 2011 which we implemented. To do this we were required to implement the SAP Bundle Patch released in May 2011. As this also contains other Oracle fixes we did not want to implement this directly in production. We thus ran baseline tests to measure performance in our QA environment, implemented the SAP Bundle patch, and ran the same tests again (simplified version of the implementation route ).Result: No improvement in performance, in fact in some cases we had degradation of performance (double the time). As this had the potential to negatively effect production, we have not yet implemented this in production.
Any suggestions would be greatly appreciated !Hello Johan,
well the first goal should be to get the original performance so that you have time to do deeper analysis in your QA system (if the data set is the same).
If the problem is caused by some new optimizer features or bugs you can try to "force" the optimizer to use the "old" 10.2.0.2 behaviour. Just set the parameter OPTIMIZER_FEATURES_ENABLE to 10.2.0.2 and check your performance.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams142.htm#CHDFABEF
To get more information we need an AWR (for an overview) and the problematic SQL statements (with all the information like execution plan, statistics, etc.). This analysis are very hard through a forum. I would suggest to open a SAP SR for this issue.
Regards
Stefan -
Performance for a Specific Query:
Hi, i am using a multi-threaded java application to execute a stored procedure with bulks of data grouped in an array. I use oracle 9i and this is the SP definition:
create or replace
PROCEDURE IE_SP_SET_BANS_TO_RECLASSIFY(
MIN_AMOUNT IN NUMBER ,
MIN_PAY_ADJ_DATE IN DATE,
RECLA_CANDIDATES IN IE_RECLA_CANDIDATE_TBL )
AS
BEGIN
FOR idx IN 1.. RECLA_CANDIDATES.COUNT
LOOP
INSERT INTO IE_RESUMEN_RECLA
SELECT BA.BAN,
BA.BILL_CYCLE,
BA.COL_NEXT_STEP_NO ,
BA.COL_NEXT_STEP_DATE,
BA.COL_WAIVER_IND ,
BA.STATUS_ACTV_RSN_CODE ,
BA.COL_ASSIGNED_COLL,
BA.COL_PATH_CODE ,
BA.COL_CATEGORY_NO ,
BA.ACCOUNT_TYPE ,
BA.ACCOUNT_SUB_TYPE ,
ADJ.ENT_SEQ_NO,
ADJ.ACTV_DATE,
ADJ.ACTV_AMT,
ADJ.SUBSCRIBER_NO,
' ' AS SOURCE,
ADJ.DESIGNATION,
'ADJ' AS IDENT
FROM CDLAPPC.ADJUSTMENT ADJ
INNER JOIN CDLAPPC.BILLING_ACCOUNT BA
ON(BA.BAN = ADJ.BAN)
WHERE ADJ.BAN = RECLA_CANDIDATES(idx).ban
AND ADJ.BALANCE_IMPACT_CODE = 'I'
AND TRUNC(ADJ.SYS_CREATION_DATE) >= MIN_PAY_ADJ_DATE
AND NVL(ADJ.ACTV_AMT,0) >= MIN_AMOUNT
AND ROWNUM = 1;
IF(SQL%ROWCOUNT = 0) THEN
INSERT INTO IE_RESUMEN_RECLA
SELECT BA.BAN,
BA.BILL_CYCLE,
BA.COL_NEXT_STEP_NO ,
BA.COL_NEXT_STEP_DATE,
BA.COL_WAIVER_IND ,
BA.STATUS_ACTV_RSN_CODE ,
BA.COL_ASSIGNED_COLL,
BA.COL_PATH_CODE ,
BA.COL_CATEGORY_NO ,
BA.ACCOUNT_TYPE ,
BA.ACCOUNT_SUB_TYPE ,
P.ENT_SEQ_NO,
P.DEPOSIT_DATE,
P.ORIGINAL_AMT,
P.SUBSCRIBER_NO,
P.SOURCE_ID,
P.DESIGNATION,
'PAY' AS IDENT
FROM CDLAPPC.PAYMENT P
INNER JOIN CDLAPPC.BILLING_ACCOUNT BA
ON(BA.BAN = P.BAN)
WHERE P.BAN = RECLA_CANDIDATES(idx).ban
AND TRUNC(P.SYS_CREATION_DATE) >= MIN_PAY_ADJ_DATE
AND NVL(P.ORIGINAL_AMT,0) >= MIN_AMOUNT
AND ROWNUM = 1;
END IF;
END LOOP ;
END IE_SP_SET_BANS_TO_RECLASSIFY;
I want to improve it's efficiency but i still do not know how. But possible solutions are:
-i know that a FORALL loop would improve my insert speed but in this case there is a condition so i don't know how to implement it in a forall.
-I want to avoid doing the inner join with billing_account for the query but i do not know if providing the billing_account details in the input table would make it more efficient, is not a lot of data per row, but i am sending 10k rows per SP call, also i am not sure if there will be a lot of context switching with PL/SQL and SQL in case i do that.
Any help would be appreciated, thanks.Some of the suggestions I can make for improving the Queries are
1) Try using Indexed columns whereever possible , specially when you are joining tables. If there is no index on column that you are using to join ,then either try to use columns which have an index or create a new index on columns if required.
2) Try to see the Explain Plan for the select statements you are uisng. If you are using TOAD, try to use the tool's feature to generate different possible combinations of queries with the least cost. You need to supply TOAD with the problematic SQL statement, it will automatically generate different combinations of SQL statements and then you can choose the one with the least cost or the one with the best Explain plan results.
Hope this helps.
Regards
IQ -
Hi Everyone,
I am still in the process of learning SQL, and I am having trouble specifically with the the left outer join. I normally join tables using equijoin's, but I am not getting the right data set returns, and thought the using a left or right outer join would resolve the problem...
Here is my SQL that is working properly with 1 left outer join. I am building the query slowly so in the next SQL you will see where I am seeing the error. I don't expect you to understand the data and columns I am trying to join, I believe the problems I am experiencing are related to syntax, and I am hoping you can find where my syntax errors are.
select
s.name as "Screen Name",
sv.view_name as "View Name",
s_view.name
from
s_screen s,
s_screen_view sv
left outer join s_view
ON (sv.view_name = s_view.name)
where
sv.screen_id = '1-866A-1X3LU' and
s.row_id = sv.screen_id and
s.repository_id = '1-866A-1' and
s_view.repository_id = '1-866A-1';
Here is the SQL where I am experiencing the following error...
Error:
ORA-00904: "SV"."VIEW_NAME": invalid identifier
00904. 00000 - "%s: invalid identifier"
*Cause:
*Action:
Error at Line: 14 Column: 7
Problematic SQL:
select
s.name as "Screen Name",
sv.view_name as "View Name",
s_view.name,
s_applet.name as Applet
--a.name as "Applet Name"
from
s_screen s,
s_screen_view sv,
s_view_wtmpl_it wti
left outer join s_view
ON (sv.view_name = s_view.name)
left outer join s_applet
ON (wti.name = s_applet.name)
where
sv.screen_id = '1-866A-1X3LU' and
s.row_id = sv.screen_id and
s.repository_id = '1-866A-1' and
s_view.repository_id = '1-866A-1';
Thanks in advance for your help.
ChrisHi,
cjpicc11 wrote:
What is an Oracle style join vs. ANSI join?
Would this be Oracle Style or ANSI Join?
left outer join s_view
ON (sv.view_name = s_view.name)
left outer join s_applet
Would this be Oracle Style or ANSI Join?
s.row_id = sv.screen_id
"Oracle style" or "old style" joins have commas between tables in the FROM clause, and the join conditions are all in the WHERE clause. They do not use the keywords JOIN or ON.
ANSI style joins have the keyword JOIN between tables (sometimes accompanied by other keywords, such as LEFT, OUTER or CROSS), and the join conditions are given in the FROM clause, usually after the keyword ON.
The first example you gave is an ANSI style join. It has the JOIN keyword, not a comma, between tables.
The second example you gave:
s.row_id = sv.screen_id
could be part of either. It could occur in an ANSI join (in the FROM clause, after the keyword ON), or it could occur in an old-style join (in the WHERE clause). -
High enq: TX - row lock contention on RAC database
Hi Gurus,
I have SAP applications running on 5 Oracle 10g (10.2.0.5) RAC nodes.
I could observe high row lock contention in the database.
db file sequential read 13.555.789.712 7.148.542.630 5.27 65
enq: TX - row lock contention 45.685.386 1.622.457.531 355.14 15
CPU 0 1.123.793.901 10
gc buffer busy 969.769.720 365.874.242 3.77 3
gc cr grant 2-way 7.565.517.708 161.443.528 .21 1
log file sync 244.392.565 155.406.980 6.36 1
gc current block busy 86.643.267 139.935.394 16.15 1
db file parallel read 80.779.109 124.238.490 15.38 1
gc current block 3-way 2.412.777.861 98.748.193 .41 1
read by other session 227.935.152 95.543.751 4.19 1
I am able to observe one or two update/insert statements in this state.
I would need your help in go ahead for analyzing and finding out the problematic SQL statements.
Though there is no performance issue at the moment, I would like to initiate this proactively.
Database parameters are set consistently with the latest patches for 10.2.0.5.
Br,
VenkyIf you are licensed for diagnostic pack, look at the ASH data in v$active_session_history and dba_hist_active_sess_history.
Using the p1/p2/p3 columns and the blocking information, you should be able to see what sessions were waiting on and what sql was being run for the sessions waiting. -
Best way to update 8 out of10 million records
Hi friends,
I want to update a table 8 million records of a table which has 10 millions records, what could be the best strategy if the table has a BLOB column with 600GB worth of data. BLOB itself is 550GB. I am not updating the BLOB column.
Usually with non-BLOB data i have tried doing "CREATE TABLE new_table as select <do the update "here"> from old_table;" method .
How should i approach this one?@Mark D Powell
To give you a background my client faced this problem a week ago , This is part of a daily cleanup activity .
Right now i don't have the access to it due to security issue . I could only take few AWR reports and stats when the access window was opened. So basically next time when i get the access i want to close the issue once and for all
Coming to your questions:
So what is wrong with just issuing an update to update all 8 Million rows?
In a previous run , of a single update with full table scan in the plan with no parallel degree it started reading from UNDO(current_obj=-1 on event "db file sequential read" wait event) and errored out after 24 hours with tablespace full on the tablespace which contains the BLOB data(a separate tablespace)
To add to the problem redo log files were sized too less , about 50MB only .
The wait events (from DBA_HIST_ACTIVE_SESS_HISTORY )for the problematic sql id shows
- log file switch (checkpoint incomplete) and log file switch completion as the events comprising 62% of the wait events
-CPU 29%.
-db file sequential read 6%.
-direct path read 2% and others contributing a little.
30 % of the samples "db file sequential read" had a current_obj#=-1 & p1 showing undo file id.
Is there any concurrent DML against this table? If not, the parallel DML would be an option though it may not really be needed.
I think there was in the previous run and i have asked to avoid in the next run.
How large are the base table rows?
AVG_ROW_LEN is 227
How many indexes are effected by the update if any?
The last column of the primary key column is the only column to be updated ( i mean used in the "SET" clause of the update)
Do you expect the update will cause any row migration?
Yes i think so because the only column which is going to be updated is the same column on which the table is partitioned.
Now if there is a lot of concurrent DML on the table you probably want to use pl/sql so you can loop through the data issuing a commit every N rows so as to not lock other concurrent sessions out of the table for too long a period of time. This may well depend on if you can write a driving cursor that can be restarted in the event of interruption and would skip over rows that have already been updated. If not you might want to use a driving table to control the processing.
Right now to avoid UNDO issue i have suggested to use PL/SQL approach & have asked increasing the REDO size to atleast 10 times more.
My big question after seeing the wait events profile for the session is:
Which was the main issue here , redo log size or the reading from UNDO which hit the update statement. The buffer gets had shot to 600 million , There are only 220k blocks in the table.
Maybe you are looking for
-
Error in executing process from the UWL task list
Hi, I have created a process and assigned different users to different steps. For administrator, Overseer and Owner, i have kept role as initiator only. For the actions of the process, set the value as Initiation defined and in Default Roles tab, hav
-
Premiere Elements 11 says display drivers are incompatible
When I start Premiere Elements 11 there is an error message saying: "We have detected an incompatible display driver. To get a better and faster playback performance, please update your display driver. Display driver details: NVIDIA Corporation - Ge
-
Dear Experts, We have scheduled a background job using the program of IP30 and creating a variant for it. Now we want to add some more plans . But now the variant we are now able to see . But still the background job is scheduling as we created witho
-
Can't drag from purchased to iPhone 3G
I recently bought the season of Watchmen, and it automatically downloaded on my Mac. When I connected my iPhone 3G and tried to drag the episode to my 3G, nothing happens. In fact, all songs and videos are greyed out on the 3G and my purchased folder
-
I have problem login into my user account
i was using my macbook pro and it automatically logged off to the login window. since then i have been trying to log in but it seems to be login in and shows a flash blank screen and returns back to the login window. pls what is happening help me