Tuning hash group by
Hi all,
my database:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production
I have a extraction query which involves group by clause on a table partition consisting around 2 billion of rows. It extracts rows with max(column) in each group and returns around 152 million rows. Then the result is joined to another table with 1M rows using the same key used in group by clause. It is using alot of temporary tablespace and taking around 20 hours.
I ran sql_tuning_advisor not any recommendation. How can i tune this query? Does creating the index on group by (same as join) column will help me. Any advice will appreciated.
thanks
user9074365 wrote:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
I have a extraction query which involves group by clause on a table partition consisting around 2 billion of rows. It extracts rows with max(column) in each group and returns around 152 million rows. Then the result is joined to another table with 1M rows using the same key used in group by clause. It is using alot of temporary tablespace and taking around 20 hours.
I ran sql_tuning_advisor not any recommendation. How can i tune this query? Does creating the index on group by (same as join) column will help me. Any advice will appreciated.
The first step is to examine the execution plan to see if it's sensible. Remember to use the "code" tags (see below) to make it easy to read.
I'd guess that Oracle is doing a "group by pushdown" to aggregate 2B rows to 152M, then joining to 1M, when it seems possible that a join before aggregation would be better.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"Science is more than a body of knowledge; it is a way of thinking"+
+Carl Sagan+
Similar Messages
-
I see that one of my queries from an application time is spending most of its time in the hash group by. I'm running Oracle 11g with a quarter rack exadata appliance. Is there a better way to run or design this table?
query:
SELECT COUNT(*)
FROM (
SELECT "DDTMDAY", "MRKTNM", "BSMNM", "BSCNM", "CLNM", "CSCDNM", "BTSID", "SECTSEQID", "BNDID", "FAID", SUM("VATTCNT"), SUM("VMBLORGCNT"), SUM("VMBLTERCNT"), SUM("VSILENTRETRYCNT"), SUM("VCUSTBLKCNT"), SUM("VAXSFCNT"), SUM("VCEBLKCNT"), SUM("VWCDBLKCNT"), SUM("VT1BHLBLKCNT"), SUM("VPWRBLKCNT"), SUM("VNONBTSEQBLKCNT"), SUM("VSFULCALLCNT"), SUM("VDRPCALLCNT"), SUM("DATTCNT"), SUM("DMBLORGCNT"), SUM("DMBLTERCNT"), SUM("DSILENTRETRYCNT"), SUM("DCUSTBLKCNT"), SUM("DAXSFCNT"), SUM("DCEBLKCNT"), SUM("DWCDBLKCNT"), SUM("DT1BHLBLKCNT"), SUM("DPWRBLKCNT"), SUM("DNONBTSEQBLKCNT"), SUM("DSFULCALLCNT"), SUM("DDRPCALLCNT"), SUM("VPRIMCALLERL"), SUM("VMOUTMS"), SUM("DPRIMCALLERL"), SUM("SMSATTCNT"), SUM("SMSSXSCNT"), SUM("VHHIATTCNT"), SUM("VHHIBADFRMCNT"), SUM("VHHICALLSETUPSXSCNT"), SUM("DHHIATTCNT"), SUM("DHHIBADFRMCNT"), SUM("DHHICALLSETUPSXSCNT") FROM (SELECT
trunc(D1."D_DTM", 'dd') AS "DDTMDAY",
D2."MRKT_NM" AS "MRKTNM",
D3."BSC_NM" AS "BSMNM",
D3."BSC_NM" AS "BSCNM",
D2."CLUSTER_NM" AS "CLNM",
D1."CSCD_NM" AS "CSCDNM",
D1."BTS_ID" AS "BTSID",
D1."SECT_SEQ_ID" AS "SECTSEQID",
D1."BND_ID" AS "BNDID",
D1."FA_ID" AS "FAID",
D1."V_ATT_CNT" AS "VATTCNT",
D1."V_MBL_ORG_CNT" AS "VMBLORGCNT",
D1."V_MBL_TER_CNT" AS "VMBLTERCNT",
D1."V_SILENT_RETRY_CNT" AS "VSILENTRETRYCNT",
D1."V_CUST_BLK_CNT" AS "VCUSTBLKCNT",
D1."V_AXS_F_CNT" AS "VAXSFCNT",
D1."V_CE_BLK_CNT" AS "VCEBLKCNT",
D1."V_WCD_BLK_CNT" AS "VWCDBLKCNT",
D1."V_T1_BHL_BLK_CNT" AS "VT1BHLBLKCNT",
D1."V_PWR_BLK_CNT" AS "VPWRBLKCNT",
D1."V_NON_BTS_EQ_BLK_CNT" AS "VNONBTSEQBLKCNT",
D1."V_SFUL_CALL_CNT" AS "VSFULCALLCNT",
D1."V_DRP_CALL_CNT" AS "VDRPCALLCNT",
D1."D_ATT_CNT" AS "DATTCNT",
D1."D_MBL_ORG_CNT" AS "DMBLORGCNT",
D1."D_MBL_TER_CNT" AS "DMBLTERCNT",
D1."D_SILENT_RETRY_CNT" AS "DSILENTRETRYCNT",
D1."D_CUST_BLK_CNT" AS "DCUSTBLKCNT",
D1."D_AXS_F_CNT" AS "DAXSFCNT",
D1."D_CE_BLK_CNT" AS "DCEBLKCNT",
D1."D_WCD_BLK_CNT" AS "DWCDBLKCNT",
D1."D_T1_BHL_BLK_CNT" AS "DT1BHLBLKCNT",
D1."D_PWR_BLK_CNT" AS "DPWRBLKCNT",
D1."D_NON_BTS_EQ_BLK_CNT" AS "DNONBTSEQBLKCNT",
D1."D_SFUL_CALL_CNT" AS "DSFULCALLCNT",
D1."D_DRP_CALL_CNT" AS "DDRPCALLCNT",
D1."V_PRIM_CALL_ERL" AS "VPRIMCALLERL",
D1."V_MOU_TMS" AS "VMOUTMS",
D1."D_PRIM_CALL_ERL" AS "DPRIMCALLERL",
D1."SMS_ATT_CNT" AS "SMSATTCNT",
D1."SMS_SXS_CNT" AS "SMSSXSCNT",
D1."V_HHI_ATT_CNT" AS "VHHIATTCNT",
D1."V_HHI_BAD_FRM_CNT" AS "VHHIBADFRMCNT",
D1."V_HHI_CALL_SETUP_SXS_CNT" AS "VHHICALLSETUPSXSCNT",
D1."D_HHI_ATT_CNT" AS "DHHIATTCNT",
D1."D_HHI_BAD_FRM_CNT" AS "DHHIBADFRMCNT",
D1."D_HHI_CALL_SETUP_SXS_CNT" AS "DHHICALLSETUPSXSCNT"
FROM
"DMSN"."DS3R_FH_1XRTT_FA_LVL_KPI_TEMP" D1
LEFT OUTER JOIN "DMSN"."SITES_GEO_HIERARCHY" D2
ON
D1."BTS_ID" = D2."BTS_ID"
AND
D1."CSCD_NM" = D2."CSCD_NM"
LEFT OUTER JOIN "DMSN"."SITES_SYS_HIERARCHY" D3
ON
D1."BTS_ID" = D3."BTS_ID"
AND
D1."CSCD_NM" = D3."CSCD_NM"
WHERE
trunc(D1."D_DTM", 'dd') >= SYSDATE - 40 and trunc(D1."D_DTM", 'dd') < SYSDATE - 1
) T GROUP BY "DDTMDAY", "MRKTNM", "BSMNM", "BSCNM", "CLNM", "CSCDNM", "BTSID", "SECTSEQID", "BNDID", "FAID" ORDER BY "DDTMDAY", "MRKTNM", "BSMNM", "BSCNM", "CLNM", "CSCDNM", "BTSID", "SECTSEQID", "BNDID", "FAID"
Explain plan
SQL> alter session set statistics_level = all
2
SQL> @C:\TEST.SQL
COUNT(*)
1101270
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR);
PLAN_TABLE_OUTPUT
SQL_ID gqj9q831g6s78, child number 0
SELECT COUNT(*) FROM ( SELECT "DDTMDAY", "MRKTNM", "BSMNM",
"BSCNM", "CLNM", "CSCDNM", "BTSID", "SECTSEQID", "BNDID", "FAID",
SUM("VATTCNT"), SUM("VMBLORGCNT"), SUM("VMBLTERCNT"),
SUM("VSILENTRETRYCNT"), SUM("VCUSTBLKCNT"), SUM("VAXSFCNT"),
SUM("VCEBLKCNT"), SUM("VWCDBLKCNT"), SUM("VT1BHLBLKCNT"),
SUM("VPWRBLKCNT"), SUM("VNONBTSEQBLKCNT"), SUM("VSFULCALLCNT"),
SUM("VDRPCALLCNT"), SUM("DATTCNT"), SUM("DMBLORGCNT"),
SUM("DMBLTERCNT"), SUM("DSILENTRETRYCNT"), SUM("DCUSTBLKCNT"),
SUM("DAXSFCNT"), SUM("DCEBLKCNT"), SUM("DWCDBLKCNT"),
PLAN_TABLE_OUTPUT
SUM("DT1BHLBLKCNT"), SUM("DPWRBLKCNT"), SUM("DNONBTSEQBLKCNT"),
SUM("DSFULCALLCNT"), SUM("DDRPCALLCNT"), SUM("VPRIMCALLERL"),
SUM("VMOUTMS"), SUM("DPRIMCALLERL"), SUM("SMSATTCNT"),
SUM("SMSSXSCNT"), SUM("VHHIATTCNT"), SUM("VHHIBADFRMCNT"),
SUM("VHHICALLSETUPSXSCNT"), SUM("DHHIATTCNT"), SUM("DHHIBADFRMCNT"),
SUM("DHHICALLSETUPSXSCNT") FROM (SELECT trunc(D1."D_DTM", 'dd') AS
"DDTMDAY", D2."MRKT_NM" AS "MRKTNM", D3."BSC_NM" AS "BSMNM",
D3."BSC_
Plan hash value: 1618890056
PLAN_TABLE_OUTPUT
| Id | Operation | Name
| Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT
| PQ Distrib |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT |
| | | | 139K(100)| | | | |
| |
| 1 | SORT AGGREGATE |
| 1 | | | | | | | |
| |
|* 2 | PX COORDINATOR |
| | | | | | | | |
PLAN_TABLE_OUTPUT
| |
| 3 | PX SEND QC (RANDOM) | :TQ10003
| 1 | | | | | | | Q1,03 | P->S
| QC (RAND) |
| 4 | SORT AGGREGATE |
| 1 | | | | | | | Q1,03 | PCWP
| |
| 5 | VIEW |
PLAN_TABLE_OUTPUT
| 44M| | | 139K (1)| 00:27:51 | | | Q1,03 | PCWP
| |
| 6 | HASH GROUP BY |
| 44M| 10G| 11G| 139K (1)| 00:27:51 | | | Q1,03 | PCWP
| |
| 7 | PX RECEIVE |
| 44M| 10G| | 34102 (1)| 00:06:50 | | | Q1,03 | PCWP
| |
PLAN_TABLE_OUTPUT
| 8 | PX SEND HASH | :TQ10002
| 44M| 10G| | 34102 (1)| 00:06:50 | | | Q1,02 | P->P
| HASH |
|* 9 | FILTER |
| | | | | | | | Q1,02 | PCWC
| |
|* 10 | HASH JOIN RIGHT OUTER |
| 44M| 10G| | 34102 (1)| 00:06:50 | | | Q1,02 | PCWP
| |
PLAN_TABLE_OUTPUT
| 11 | BUFFER SORT |
| | | | | | | | Q1,02 | PCWC
| |
| 12 | PX RECEIVE |
| 13410 | 261K| | 15 (0)| 00:00:01 | | | Q1,02 | PCWP
| |
| 13 | PX SEND BROADCAST | :TQ10000
| 13410 | 261K| | 15 (0)| 00:00:01 | | | | S->P
PLAN_TABLE_OUTPUT
| BROADCAST |
| 14 | TABLE ACCESS STORAGE FULL | SITES_SYS_HIERARCHY
| 13410 | 261K| | 15 (0)| 00:00:01 | | | |
| |
|* 15 | HASH JOIN RIGHT OUTER |
| 44M| 10G| | 34082 (1)| 00:06:49 | | | Q1,02 | PCWP
| |
| 16 | BUFFER SORT |
PLAN_TABLE_OUTPUT
| | | | | | | | Q1,02 | PCWC
| |
| 17 | PX RECEIVE |
| 13410 | 667K| | 34 (0)| 00:00:01 | | | Q1,02 | PCWP
| |
| 18 | PX SEND BROADCAST | :TQ10001
| 13410 | 667K| | 34 (0)| 00:00:01 | | | | S->P
| BROADCAST |
PLAN_TABLE_OUTPUT
| 19 | TABLE ACCESS STORAGE FULL| SITES_GEO_HIERARCHY
| 13410 | 667K| | 34 (0)| 00:00:01 | | | |
| |
| 20 | PX BLOCK ITERATOR |
| 44M| 8193M| | 34042 (1)| 00:06:49 | 1 |1048575| Q1,02 | PCWC
| |
|* 21 | TABLE ACCESS STORAGE FULL | DS3R_FH_1XRTT_FA_LVL_KPI_TEMP
| 44M| 8193M| | 34042 (1)| 00:06:49 | 1 |1048575| Q1,02 | PCWP
| |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(SYSDATE@!-40<SYSDATE@!-1)
9 - filter(SYSDATE@!-40<SYSDATE@!-1)
PLAN_TABLE_OUTPUT
10 - access("D1"."CSCD_NM"="D3"."CSCD_NM" AND "D1"."BTS_ID"=TO_NUMBER("D3"."BT
S_ID"))
15 - access("D1"."CSCD_NM"="D2"."CSCD_NM" AND "D1"."BTS_ID"=TO_NUMBER("D2"."BT
S_ID"))
21 - storage(:Z>=:Z AND :Z<=:Z AND (TRUNC(INTERNAL_FUNCTION("D1"."D_DTM"),'fmd
d')>=SYSDATE@!-40 AND TRUNC(INTERNAL_FUNCTION("D1"."D_DTM"),'fmdd')<SYSDATE@!-1)
filter((TRUNC(INTERNAL_FUNCTION("D1"."D_DTM"),'fmdd')>=SYSDATE@!-40 AND T
PLAN_TABLE_OUTPUT
RUNC(INTERNAL_FUNCTION("D1"."D_DTM"),'fmdd')<SYSDATE@!-1))
Note
- dynamic sampling used for this statement (level=6)
63 rows selected.
Create table:
CREATE TABLE DMSN.DS3R_FH_1XRTT_FA_LVL_KPI_TEMP
D_DTM DATE NOT NULL,
F_ID NUMBER NOT NULL,
REG_DTM DATE,
MRKT_ID NUMBER NOT NULL,
MRKT_NM VARCHAR2(150 BYTE),
CL_ID NUMBER NOT NULL,
CL_NM VARCHAR2(150 BYTE),
BSM_ID NUMBER NOT NULL,
BSM_NM VARCHAR2(150 BYTE),
BSC_SEQ_ID NUMBER NOT NULL,
CSCD_ID NUMBER NOT NULL,
CSCD_NM VARCHAR2(150 BYTE),
BTS_ID NUMBER NOT NULL,
SECT_SEQ_ID NUMBER NOT NULL,
BND_ID NUMBER NOT NULL,
FA_ID NUMBER NOT NULL,
V_ATT_CNT NUMBER,
V_MBL_ORG_CNT NUMBER,
V_MBL_TER_CNT NUMBER,
V_SILENT_RETRY_CNT NUMBER,
V_CUST_BLK_CNT NUMBER,
V_AXS_F_CNT NUMBER,
V_CE_BLK_CNT NUMBER,
V_WCD_BLK_CNT NUMBER,
V_T1_BHL_BLK_CNT NUMBER,
V_PWR_BLK_CNT NUMBER,
V_NON_BTS_EQ_BLK_CNT NUMBER,
V_SFUL_CALL_CNT NUMBER,
V_DRP_CALL_CNT NUMBER,
D_ATT_CNT NUMBER,
D_MBL_ORG_CNT NUMBER,
D_MBL_TER_CNT NUMBER,
D_SILENT_RETRY_CNT NUMBER,
D_CUST_BLK_CNT NUMBER,
D_AXS_F_CNT NUMBER,
D_CE_BLK_CNT NUMBER,
D_WCD_BLK_CNT NUMBER,
D_T1_BHL_BLK_CNT NUMBER,
D_PWR_BLK_CNT NUMBER,
D_NON_BTS_EQ_BLK_CNT NUMBER,
D_SFUL_CALL_CNT NUMBER,
D_DRP_CALL_CNT NUMBER,
V_PRIM_CALL_ERL NUMBER,
V_MOU_TMS NUMBER,
D_PRIM_CALL_ERL NUMBER,
SMS_ATT_CNT NUMBER,
SMS_SXS_CNT NUMBER,
V_HHI_BAD_FRM_CNT NUMBER,
V_HHI_CALL_SETUP_SXS_CNT NUMBER,
V_HHI_ATT_CNT NUMBER,
D_HHI_BAD_FRM_CNT NUMBER,
D_HHI_CALL_SETUP_SXS_CNT NUMBER,
D_HHI_ATT_CNT NUMBER,
BSC_ALTR_ID VARCHAR2(5 BYTE),
V_BZ_HH_FLAG NUMBER(1),
D_BZ_HH_FLAG NUMBER(1),
V_BNCN_BZ_HH_FLAG NUMBER(1),
D_BNCN_BZ_HH_FLAG NUMBER(1),
V_PRIM_CALL_ERL_N NUMBER,
V_MOU_TMS_N NUMBER
COMPRESS FOR QUERY LOW
TABLESPACE DMD_SN_01
RESULT_CACHE (MODE DEFAULT)
PCTUSED 0
PCTFREE 0
INITRANS 1
MAXTRANS 255
STORAGE (
PCTINCREASE 5
BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT
PARTITION BY RANGE (D_DTM)
INTERVAL( NUMTODSINTERVAL(1,'DAY'))
PARTITION P_1 VALUES LESS THAN (TO_DATE(' 2013-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
COMPRESS FOR QUERY LOW
TABLESPACE DMD_SN_01
PCTFREE 0
INITRANS 1
MAXTRANS 255
STORAGE (
BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT
PARTITION VALUES LESS THAN (TO_DATE(' 2013-01-28 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
COMPRESS FOR QUERY LOW
TABLESPACE DMD_SN_01
PCTFREE 0
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 8M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT
PARTITION VALUES LESS THAN (TO_DATE(' 2013-01-29 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN'))
LOGGING
COMPRESS FOR QUERY LOW
TABLESPACE DMD_SN_01
PCTFREE 0
INITRANS 1
MAXTRANS 255
STORAGE (
INITIAL 8M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT
etc...
NOCACHE
PARALLEL ( DEGREE DEFAULT INSTANCES DEFAULT )
MONITORING;
CREATE INDEX DMSN.XIF1DS3R_FH_1XRTT_FA_LVL_TEMP ON DMSN.DS3R_FH_1XRTT_FA_LVL_KPI_TEMP
(BTS_ID, CSCD_NM)
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
BUFFER_POOL DEFAULT
FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT
LOCAL (
PARTITION P_1
LOGGING
NOCOMPRESS
TABLESPACE DMD_SN_01
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
BUFFER_POOL DEFAULT
PARTITION
LOGGING
NOCOMPRESS
TABLESPACE DMD_SN_01
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
BUFFER_POOL DEFAULT
PARTITION
LOGGING
NOCOMPRESS
TABLESPACE DMD_SN_01
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE (
INITIAL 64K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
BUFFER_POOL DEFAULT
etc....
NOPARALLEL
Also, in the v$sql_workarea session, the memory stats seem pretty high...
ADDRESS
HASH_VALUE
SQL_ID
CHILD_NUMBER
WORKAREA_ADDRESS
OPERATION_TYPE
OPERATION_ID
POLICY
ESTIMATED_OPTIMAL_SIZE
ESTIMATED_ONEPASS_SIZE
LAST_MEMORY_USED
LAST_EXECUTION
LAST_DEGREE
TOTAL_EXECUTIONS
OPTIMAL_EXECUTIONS
ONEPASS_EXECUTIONS
MULTIPASSES_EXECUTIONS
ACTIVE_TIME
MAX_TEMPSEG_SIZE
LAST_TEMPSEG_SIZE
000000046CC73120
3270729960
gqj9q831g6s78
0
000000041C6CE108
GROUP BY (HASH)
6
AUTO
1175704576
29911040
50704384
OPTIMAL
24
189
189
0
0
13324368
000000046CC73120
3270729960
gqj9q831g6s78
0
000000041C6CE0A0
HASH-JOIN
10
AUTO
15517696
2760704
1811456
OPTIMAL
24
192
192
0
0
20231391
000000046CC73120
3270729960
gqj9q831g6s78
0
000000041C6CE038
HASH-JOIN
15
AUTO
26851328
4585472
1797120
OPTIMAL
24
192
192
0
0
20197157
000000046CC73120
3270729960
gqj9q831g6s78
0
000000041C6CDFD0
BUFFER
16
AUTO
1214464
580608
1079296
OPTIMAL
1
192
192
0
0
20358402
000000046CC73120
3270729960
gqj9q831g6s78
0
000000041C6CDF68
BUFFER
11
AUTO
779264
510976
692224
OPTIMAL
1
192
192
0
0
20396407So I may have spoken too soon. I ran the test against the partitioned tabled, and then ran it against the original, which is just indexed and the times weren't that different.
xPlan with Paritioning:
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR);
PLAN_TABLE_OUTPUT
SQL_ID 0vtpb0zuf3suj, child number 0
SELECT COUNT(*) FROM ( SELECT "DDTMDAY", "MRKTNM", "BSMNM",
"BSCNM", "CLNM", "CSCDNM", "BTSID", "SECTSEQID", "BNDID", "FAID",
SUM("VATTCNT"), SUM("VMBLORGCNT"), SUM("VMBLTERCNT"),
SUM("VSILENTRETRYCNT"), SUM("VCUSTBLKCNT"), SUM("VAXSFCNT"),
SUM("VCEBLKCNT"), SUM("VWCDBLKCNT"), SUM("VT1BHLBLKCNT"),
SUM("VPWRBLKCNT"), SUM("VNONBTSEQBLKCNT"), SUM("VSFULCALLCNT"),
SUM("VDRPCALLCNT"), SUM("DATTCNT"), SUM("DMBLORGCNT"),
SUM("DMBLTERCNT"), SUM("DSILENTRETRYCNT"), SUM("DCUSTBLKCNT"),
SUM("DAXSFCNT"), SUM("DCEBLKCNT"), SUM("DWCDBLKCNT"),
PLAN_TABLE_OUTPUT
SUM("DT1BHLBLKCNT"), SUM("DPWRBLKCNT"), SUM("DNONBTSEQBLKCNT"),
SUM("DSFULCALLCNT"), SUM("DDRPCALLCNT"), SUM("VPRIMCALLERL"),
SUM("VMOUTMS"), SUM("DPRIMCALLERL"), SUM("SMSATTCNT"),
SUM("SMSSXSCNT"), SUM("VHHIATTCNT"), SUM("VHHIBADFRMCNT"),
SUM("VHHICALLSETUPSXSCNT"), SUM("DHHIATTCNT"), SUM("DHHIBADFRMCNT"),
SUM("DHHICALLSETUPSXSCNT") FROM (SELECT trunc(D1."D_DTM", 'dd') AS
"DDTMDAY", D2."MRKT_NM" AS "MRKTNM", D3."BSC_NM" AS "BSMNM",
D3."BSC_
Plan hash value: 2810106464
PLAN_TABLE_OUTPUT
| Id | Operation | Name
| Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT
| PQ Distrib |
PLAN_TABLE_OUTPUT
| 0 | SELECT STATEMENT |
| | | | 75444 (100)| | | | |
| |
| 1 | SORT AGGREGATE |
| 1 | | | | | | | |
| |
|* 2 | PX COORDINATOR |
| | | | | | | | |
PLAN_TABLE_OUTPUT
| |
| 3 | PX SEND QC (RANDOM) | :TQ10003
| 1 | | | | | | | Q1,03 | P->S
| QC (RAND) |
| 4 | SORT AGGREGATE |
| 1 | | | | | | | Q1,03 | PCWP
| |
| 5 | VIEW |
PLAN_TABLE_OUTPUT
| 17M| | | 75444 (1)| 00:15:06 | | | Q1,03 | PCWP
| |
| 6 | HASH GROUP BY |
| 17M| 4409M| 4682M| 75444 (1)| 00:15:06 | | | Q1,03 | PCWP
| |
| 7 | PX RECEIVE |
| 17M| 4409M| | 33988 (1)| 00:06:48 | | | Q1,03 | PCWP
| |
PLAN_TABLE_OUTPUT
| 8 | PX SEND HASH | :TQ10002
| 17M| 4409M| | 33988 (1)| 00:06:48 | | | Q1,02 | P->P
| HASH |
|* 9 | FILTER |
| | | | | | | | Q1,02 | PCWC
| |
|* 10 | HASH JOIN RIGHT OUTER |
| 17M| 4409M| | 33988 (1)| 00:06:48 | | | Q1,02 | PCWP
| |
PLAN_TABLE_OUTPUT
| 11 | BUFFER SORT |
| | | | | | | | Q1,02 | PCWC
| |
| 12 | PX RECEIVE |
| 13410 | 261K| | 15 (0)| 00:00:01 | | | Q1,02 | PCWP
| |
| 13 | PX SEND BROADCAST | :TQ10000
| 13410 | 261K| | 15 (0)| 00:00:01 | | | | S->P
PLAN_TABLE_OUTPUT
| BROADCAST |
| 14 | TABLE ACCESS STORAGE FULL | SITES_SYS_HIERARCHY
| 13410 | 261K| | 15 (0)| 00:00:01 | | | |
| |
|* 15 | HASH JOIN RIGHT OUTER |
| 17M| 4077M| | 33971 (1)| 00:06:48 | | | Q1,02 | PCWP
| |
| 16 | BUFFER SORT |
PLAN_TABLE_OUTPUT
| | | | | | | | Q1,02 | PCWC
| |
| 17 | PX RECEIVE |
| 13410 | 667K| | 34 (0)| 00:00:01 | | | Q1,02 | PCWP
| |
| 18 | PX SEND BROADCAST | :TQ10001
| 13410 | 667K| | 34 (0)| 00:00:01 | | | | S->P
| BROADCAST |
PLAN_TABLE_OUTPUT
| 19 | TABLE ACCESS STORAGE FULL| SITES_GEO_HIERARCHY
| 13410 | 667K| | 34 (0)| 00:00:01 | | | |
| |
| 20 | PX BLOCK ITERATOR |
| 17M| 3232M| | 33934 (1)| 00:06:48 | KEY | KEY | Q1,02 | PCWC
| |
|* 21 | TABLE ACCESS STORAGE FULL | DS3R_FH_1XRTT_FA_LVL_KPI_TEMP
| 17M| 3232M| | 33934 (1)| 00:06:48 | KEY | KEY | Q1,02 | PCWP
| |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(SYSDATE@!-40<SYSDATE@!)
9 - filter(SYSDATE@!-40<SYSDATE@!)
PLAN_TABLE_OUTPUT
10 - access("D1"."CSCD_NM"="D3"."CSCD_NM" AND "D1"."BTS_ID"=TO_NUMBER("D3"."BT
S_ID"))
15 - access("D1"."CSCD_NM"="D2"."CSCD_NM" AND "D1"."BTS_ID"=TO_NUMBER("D2"."BT
S_ID"))
21 - storage(:Z>=:Z AND :Z<=:Z AND ("D1"."D_DTM">=SYSDATE@!-40 AND "D1"."D_DTM
"<SYSDATE@!))
filter(("D1"."D_DTM">=SYSDATE@!-40 AND "D1"."D_DTM"<SYSDATE@!))
59 rows selected.
XPLAN NON PARTIONED BUT INDEXED TABLE
SQL> @C:\TEST.SQL
COUNT(*)
1158056
SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR);
PLAN_TABLE_OUTPUT
SQL_ID 5527bmds6pfmq, child number 0
SELECT COUNT(*) FROM ( SELECT "DDTMDAY", "MRKTNM", "BSMNM",
"BSCNM", "CLNM", "CSCDNM", "BTSID", "SECTSEQID", "BNDID", "FAID",
SUM("VATTCNT"), SUM("VMBLORGCNT"), SUM("VMBLTERCNT"),
SUM("VSILENTRETRYCNT"), SUM("VCUSTBLKCNT"), SUM("VAXSFCNT"),
SUM("VCEBLKCNT"), SUM("VWCDBLKCNT"), SUM("VT1BHLBLKCNT"),
SUM("VPWRBLKCNT"), SUM("VNONBTSEQBLKCNT"), SUM("VSFULCALLCNT"),
SUM("VDRPCALLCNT"), SUM("DATTCNT"), SUM("DMBLORGCNT"),
SUM("DMBLTERCNT"), SUM("DSILENTRETRYCNT"), SUM("DCUSTBLKCNT"),
SUM("DAXSFCNT"), SUM("DCEBLKCNT"), SUM("DWCDBLKCNT"),
PLAN_TABLE_OUTPUT
SUM("DT1BHLBLKCNT"), SUM("DPWRBLKCNT"), SUM("DNONBTSEQBLKCNT"),
SUM("DSFULCALLCNT"), SUM("DDRPCALLCNT"), SUM("VPRIMCALLERL"),
SUM("VMOUTMS"), SUM("DPRIMCALLERL"), SUM("SMSATTCNT"),
SUM("SMSSXSCNT"), SUM("VHHIATTCNT"), SUM("VHHIBADFRMCNT"),
SUM("VHHICALLSETUPSXSCNT"), SUM("DHHIATTCNT"), SUM("DHHIBADFRMCNT"),
SUM("DHHICALLSETUPSXSCNT") FROM (SELECT trunc(D1."D_DTM", 'dd') AS
"DDTMDAY", D2."MRKT_NM" AS "MRKTNM", D3."BSC_NM" AS "BSMNM",
D3."BSC_
Plan hash value: 3388800334
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Row
s | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | |
| | | 77843 (100)| | | | |
PLAN_TABLE_OUTPUT
| 1 | SORT AGGREGATE | |
1 | | | | | | | |
|* 2 | PX COORDINATOR | |
| | | | | | | |
| 3 | PX SEND QC (RANDOM) | :TQ10003 |
1 | | | | | Q1,03 | P->S | QC (RAND) |
| 4 | SORT AGGREGATE | |
PLAN_TABLE_OUTPUT
1 | | | | | Q1,03 | PCWP | |
| 5 | VIEW | |
13M| | | 77843 (1)| 00:15:35 | Q1,03 | PCWP | |
| 6 | HASH GROUP BY | |
13M| 3523M| 3762M| 77843 (1)| 00:15:35 | Q1,03 | PCWP | |
| 7 | PX RECEIVE | |
13M| 3523M| | 28163 (1)| 00:05:38 | Q1,03 | PCWP | |
PLAN_TABLE_OUTPUT
| 8 | PX SEND HASH | :TQ10002 |
13M| 3523M| | 28163 (1)| 00:05:38 | Q1,02 | P->P | HASH |
|* 9 | FILTER | |
| | | | | Q1,02 | PCWC | |
|* 10 | HASH JOIN RIGHT OUTER | |
13M| 3523M| | 28163 (1)| 00:05:38 | Q1,02 | PCWP | |
| 11 | BUFFER SORT | |
| | | | | Q1,02 | PCWC | |
PLAN_TABLE_OUTPUT
| 12 | PX RECEIVE | | 134
10 | 261K| | 15 (0)| 00:00:01 | Q1,02 | PCWP | |
| 13 | PX SEND BROADCAST | :TQ10000 | 134
10 | 261K| | 15 (0)| 00:00:01 | | S->P | BROADCAST |
| 14 | TABLE ACCESS STORAGE FULL | SITES_SYS_HIERARCHY | 134
10 | 261K| | 15 (0)| 00:00:01 | | | |
|* 15 | HASH JOIN RIGHT OUTER | |
PLAN_TABLE_OUTPUT
13M| 3266M| | 28145 (1)| 00:05:38 | Q1,02 | PCWP | |
| 16 | BUFFER SORT | |
| | | | | Q1,02 | PCWC | |
| 17 | PX RECEIVE | | 134
10 | 667K| | 34 (0)| 00:00:01 | Q1,02 | PCWP | |
| 18 | PX SEND BROADCAST | :TQ10001 | 134
10 | 667K| | 34 (0)| 00:00:01 | | S->P | BROADCAST |
PLAN_TABLE_OUTPUT
| 19 | TABLE ACCESS STORAGE FULL| SITES_GEO_HIERARCHY | 134
10 | 667K| | 34 (0)| 00:00:01 | | | |
| 20 | PX BLOCK ITERATOR | |
13M| 2610M| | 28109 (1)| 00:05:38 | Q1,02 | PCWC | |
|* 21 | TABLE ACCESS STORAGE FULL | DS3R_FH_1XRTT_FA_LVL_KPI |
13M| 2610M| | 28109 (1)| 00:05:38 | Q1,02 | PCWP | |
PLAN_TABLE_OUTPUT
Predicate Information (identified by operation id):
2 - filter(SYSDATE@!-40<SYSDATE@!)
9 - filter(SYSDATE@!-40<SYSDATE@!)
10 - access("D1"."CSCD_NM"="D3"."CSCD_NM" AND "D1"."BTS_ID"=TO_NUMBER("D3"."BT
S_ID"))
15 - access("D1"."CSCD_NM"="D2"."CSCD_NM" AND "D1"."BTS_ID"=TO_NUMBER("D2"."BT
PLAN_TABLE_OUTPUT
S_ID"))
21 - storage(:Z>=:Z AND :Z<=:Z AND ("D1"."D_DTM">=SYSDATE@!-40 AND "D1"."D_DTM
"<SYSDATE@!))
filter(("D1"."D_DTM">=SYSDATE@!-40 AND "D1"."D_DTM"<SYSDATE@!))
59 rows selected.
SQL> -
'HASH GROUP BY' and 'SORT GROUP BY' 11.2.0.2
deleting this thread..
Edited by: OraDBA02 on Oct 3, 2012 2:35 PMselect * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE 11.2.0.2.0 Production
TNS for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
Optimizer parameter
NAME TYPE VALUE
optimpeek_user_binds boolean FALSE
filesystemio_options string setall
object_cache_optimal_size integer 102400
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.2.0.2
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUE
optimizer_use_invisible_indexes boolean FALSE
optimizer_use_pending_statistics boolean FALSE
optimizer_use_sql_plan_baselines boolean FALSE
db_file_multiblock_read_count integer 128
optimizer_index_caching integer 0
optimizer_index_cost_adj integer 100
SQL
SELECT sum(this_.AMOUNT) as y0_, count(this_.GC_ID) as y1_,count(distinct this_.GC_ID) as y2_, this_.GC_TRANSACTION_TYPE_ID as y3_
from GC_TRANSACTIONS this_ where this_.MARKETPLACE_ID=:1 and this_.CUSTOMER_ID=:2 and this_.EXTERNAL_GC_TRANSACTION_ID=:3
group by this_.GC_TRANSACTION_TYPE_ID;
Indexes and Histograms
INDEX_NAME LAST_ANALYZED COLUMN_NAME COLUMN_POSITION NUM_ROWS BLEVEL CLUSTERING_FACTOR DESCEND
I_GCT_CUSMKTLSTUPD 17-jul-2012:00:15:09 CUSTOMER_ID 1 222812460 3 150983660 ASC
MARKETPLACE_ID 2 3 150983660 ASC
GC_TRANSACTION_TYPE_ID 3 3 150983660 ASC
I_GCT_EXT_GC_TRANS_ID_EXE 17-jul-2012:00:17:35 EXTERNAL_GC_TRANSACTION_ID 1 234832560 3 165680180 ASC
C_ID
EXTERNAL_GC_EXECUTION_ID 2 3 165680180 ASC
Histograms
COLUMN_NAME NUM_DISTINCT NUM_NULLS LAST_ANALYZED SAMPLE_SIZE AVG_COL_LEN HISTOGRAM
COLUMN_NAME NUM_DISTINCT NUM_NULLS LAST_ANALYZED SAMPLE_SIZE AVG_COL_LEN HISTOGRAM
EXTERNAL_GC_EXECUTION_I 21657463 54047480 24.Jul.12/00:21:28 8788182 12 HEIGHT BALANCED
D
EXTERNAL_GC_TRANSACTION 20790576 0 24.Jul.12/00:21:28 11481216 18 HEIGHT BALANCED
_ID
CUSTOMER_ID 5130572 0 24.Jul.12/00:21:28 11483246 7 HEIGHT BALANCED
MARKETPLACE_ID 6 0 24.Jul.12/00:21:28 11482295 4 FREQUENCY
GC_TRANSACTION_TYPE_ID 21 0 24.Jul.12/00:21:28 11483039 3 FREQUENCY
GC_TRANSACTION_ID 229686260 0 24.Jul.12/00:21:28 11484313 8 NONE
Histograms distibution for MARKTEPLACE_ID
Enter value for column_name: MARKETPLACE_ID
COLUMN_NAME ENDPOINT_VALUE CUMMULATIVE_FREQUENCY FREQUENCY ENDPOINT_ACTUAL_VALU
MARKETPLACE_ID 3 6543166 6543166
MARKETPLACE_ID 4 11041781 4498615
MARKETPLACE_ID 5 11459282 417501
MARKETPLACE_ID 35691 11469536 10254
MARKETPLACE_ID 44551 11475336 5800
MARKETPLACE_ID 78931 11482295 6959
6 rows selected.
CBO switches between two plans
plan-1
Plan hash value: 2380563624
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 13 (100)| |
| 1 | HASH GROUP BY | | 1 | 42 | 13 (8)| 00:00:01 |
| 2 | VIEW | VW_DAG_0 | 1 | 42 | 13 (8)| 00:00:01 |
| 3 | HASH GROUP BY | | 1 | 43 | 13 (8)| 00:00:01 |
|* 4 | TABLE ACCESS BY INDEX ROWID| GC_TRANSACTIONS | 1 | 43 | 12 (0)| 00:00:01 |
|* 5 | INDEX RANGE SCAN | I_GCT_EXT_GC_TRANS_ID_EXEC_ID | 11 | | 4 (0)| 00:00:01 |
Predicate Information (identified by operation id):
4 - filter(("THIS_"."CUSTOMER_ID"=:2 AND "THIS_"."MARKETPLACE_ID"=:1))
5 - access("THIS_"."EXTERNAL_GC_TRANSACTION_ID"=:3)
Bind (child_curosr=1)
select SQL_ID,CHILD_NUMBER,HASH_VALUE,NAME,DATATYPE,WAS_CAPTURED,LAST_CAPTURED,VALUE_STRING from V$SQL_BIND_CAPTURE where SQL_ID='&sql_id'
order by LAST_CAPTURED;
Enter value for sql_id: 1hc1r8qubfdnh
1hc1r8qubfdnh 1 3031905936 :1 2 YES 24.Jul.12/00:52:29 3
1hc1r8qubfdnh 1 3031905936 :2 2 YES 24.Jul.12/00:52:29 535098352
1hc1r8qubfdnh 1 3031905936 :3 1 YES 24.Jul.12/00:52:29 203-2351701-6925919
Plan-2
Bind (child_curosr=6)
Plan hash value: 700639342
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | | | 13 (100)| |
| 1 | SORT GROUP BY | | 1 | 43 | 13 (8)| 00:00:01 |
|* 2 | TABLE ACCESS BY INDEX ROWID| GC_TRANSACTIONS | 1 | 43 | 12 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | I_GCT_EXT_GC_TRANS_ID_EXEC_ID | 11 | | 4 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter(("THIS_"."CUSTOMER_ID"=:2 AND "THIS_"."MARKETPLACE_ID"=:1))
3 - access("THIS_"."EXTERNAL_GC_TRANSACTION_ID"=:3)
bind values
select SQL_ID,CHILD_NUMBER,HASH_VALUE,NAME,DATATYPE,WAS_CAPTURED,LAST_CAPTURED,VALUE_STRING from V$SQL_BIND_CAPTURE where SQL_ID='&sql_id'
order by LAST_CAPTURED;
Enter value for sql_id: 1hc1r8qubfdnh
1hc1r8qubfdnh 6 3031905936 :1 2 YES 24.Jul.12/03:06:04 5
1hc1r8qubfdnh 6 3031905936 :2 2 YES 24.Jul.12/03:06:04 1278126152
1hc1r8qubfdnh 6 3031905936 :3 1 YES 24.Jul.12/03:06:04 171-5012459-0045134
Why is CBO using two different 'HASH GROUP BY' with view 'VW_DAG_0' in first plan ?
Is that due to difference in MARKETPLACE_ID =4 And 5 ? -
Hash GROUP BY And Sort GROUP BY
Can anyone please explain how does Hash GROUP BY And Sort GROUP BY exactly work ?
Thank you.As the name suggests, SORT GROUP BY achieves the same goal by sorting.According to Tom SORT GROUP BY doesn't always sort correctly .. tried to understand his explanation as he said "It always did a BINARY SORT - not a character set sort. So the data would be sorted incorrectly if you use anything but very simple ASCII strings..."
can you give me an example where binary value of a string A is greater than string B while ascii value of string B is greater than string A ?
http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:75397449124988
Thank you -
Two different HASH GROUP BY in execution plan
Hi ALL;
Oracle version
select *From v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
PL/SQL Release 11.1.0.7.0 - Production
CORE 11.1.0.7.0 Production
TNS for Linux: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - ProductionSQL
select company_code, account_number, transaction_id,
decode(transaction_id_type, 'CollectionID', 'SettlementGroupID', transaction_id_type) transaction_id_type,
(last_day(to_date('04/21/2010','MM/DD/YYYY')) - min(z.accounting_date) ) age,sum(z.amount)
from
select /*+ PARALLEL(use, 2) */ company_code,substr(account_number, 1, 5) account_number,transaction_id,
decode(transaction_id_type, 'CollectionID', 'SettlementGroupID', transaction_id_type) transaction_id_type,use.amount,use.accounting_date
from financials.unbalanced_subledger_entries use
where use.accounting_date >= to_date('04/21/2010','MM/DD/YYYY')
and use.accounting_date < to_date('04/21/2010','MM/DD/YYYY') + 1
UNION ALL
select /*+ PARALLEL(se, 2) */ company_code, substr(se.account_number, 1, 5) account_number,transaction_id,
decode(transaction_id_type, 'CollectionID', 'SettlementGroupID', transaction_id_type) transaction_id_type,se.amount,se.accounting_date
from financials.temp2_sl_snapshot_entries se,financials.account_numbers an
where se.account_number = an.account_number
and an.subledger_type in ('C', 'AC')
) z
group by company_code,account_number,transaction_id,decode(transaction_id_type, 'CollectionID', 'SettlementGroupID', transaction_id_type)
having abs(sum(z.amount)) >= 0.01explain plan
Plan hash value: 1993777817
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | | | 76718 (100)| | | | |
| 1 | PX COORDINATOR | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10002 | 15M| 2055M| 76718 (2)| 00:15:21 | Q1,02 | P->S | QC (RAND) |
|* 3 | FILTER | | | | | | Q1,02 | PCWC | |
| 4 | HASH GROUP BY | | 15M| 2055M| 76718 (2)| 00:15:21 | Q1,02 | PCWP | |
| 5 | PX RECEIVE | | 15M| 2055M| 76718 (2)| 00:15:21 | Q1,02 | PCWP | |
| 6 | PX SEND HASH | :TQ10001 | 15M| 2055M| 76718 (2)| 00:15:21 | Q1,01 | P->P | HASH |
| 7 | HASH GROUP BY | | 15M| 2055M| 76718 (2)| 00:15:21 | Q1,01 | PCWP | |
| 8 | VIEW | | 15M| 2055M| 76116 (1)| 00:15:14 | Q1,01 | PCWP | |
| 9 | UNION-ALL | | | | | | Q1,01 | PCWP | |
| 10 | PX BLOCK ITERATOR | | 11 | 539 | 1845 (1)| 00:00:23 | Q1,01 | PCWC | |
|* 11 | TABLE ACCESS FULL | UNBALANCED_SUBLEDGER_ENTRIES | 11 | 539 | 1845 (1)| 00:00:23 | Q1,01 | PCWP | |
|* 12 | HASH JOIN | | 15M| 928M| 74270 (1)| 00:14:52 | Q1,01 | PCWP | |
| 13 | BUFFER SORT | | | | | | Q1,01 | PCWC | |
| 14 | PX RECEIVE | | 21 | 210 | 2 (0)| 00:00:01 | Q1,01 | PCWP | |
| 15 | PX SEND BROADCAST | :TQ10000 | 21 | 210 | 2 (0)| 00:00:01 | | S->P | BROADCAST |
|* 16 | TABLE ACCESS FULL| ACCOUNT_NUMBERS | 21 | 210 | 2 (0)| 00:00:01 | | | |
| 17 | PX BLOCK ITERATOR | | 25M| 1250M| 74183 (1)| 00:14:51 | Q1,01 | PCWC | |
|* 18 | TABLE ACCESS FULL | TEMP2_SL_SNAPSHOT_ENTRIES | 25M| 1250M| 74183 (1)| 00:14:51 | Q1,01 | PCWP | |
Predicate Information (identified by operation id):
3 - filter(ABS(SUM(SYS_OP_CSR(SYS_OP_MSR(SUM("Z"."AMOUNT"),MIN("Z"."ACCOUNTING_DATE")),0)))>=.01)
11 - access(:Z>=:Z AND :Z<=:Z)
filter(("USE"."ACCOUNTING_DATE"<TO_DATE(' 2010-04-22 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"USE"."ACCOUNTING_DATE">=TO_DATE(' 2010-04-21 00:00:00', 'syyyy-mm-dd hh24:mi:ss')))
12 - access("SE"."ACCOUNT_NUMBER"="AN"."ACCOUNT_NUMBER")
16 - filter(("AN"."SUBLEDGER_TYPE"='AC' OR "AN"."SUBLEDGER_TYPE"='C'))
18 - access(:Z>=:Z AND :Z<=:Z)I have few doubts regarding this execution plan and i am sure my questions would get answered here.
Q-1: Why am i getting two different HASH GROUP BY operations (Operation id 4 & 7) even though there is only a single GROUP BY clause ? Is that due to UNION ALL operator that is merging two different row sources and HASH GROUP BY is being applied on both of them individually ?
Q-2: What does 'BUFFER SORT' (Operation id 13) indicate ? Some time i got this operation and sometime i am not. For some other queries, i have observing around 10GB TEMP space and high cost against this operation. So just curious about whether it is really helpful ? if no, how to avoid that ?
Q-3: Under PREDICATE Section, what does step 18 suggest ? I am not using any filter like this ? access(:Z>=:Z AND :Z<=:Z)aychin wrote:
Hi,
About BUFFER SORT, first of all it is not specific for Parallel Executions. This step in the plan indicates that internal sorting have a place. It doesn't mean that rows will be returned sorted, in other words it doesn't guaranty that rows will be sorted in resulting row set, because it is not the main purpose of this operation. I've previously suggested that the "buffer sort" should really simply say "buffering", but that it hijacks the buffering mechanism of sorting and therefore gets reported completely spuriously as a sort. (see http://jonathanlewis.wordpress.com/2006/12/17/buffer-sorts/ ).
In this case, I think the buffer sort may be a consequence of the broadcast distribution - and tells us that the entire broadcast is being buffered before the hash join starts. It's interesting to note that in the recent of the two plans with a buffer sort the second (probe) table in the hash join seems to be accessed first and broadcast before the first table is scanned to allow the join to occur.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
There is a +"Preview"+ tab at the top of the text entry panel. Use this to check what your message will look like before you post the message. If it looks a complete mess you're unlikely to get a response. (Click on the +"Plain text"+ tab if you want to edit the text to tidy it up.)
+"Science is more than a body of knowledge; it is a way of thinking"+
+Carl Sagan+ -
Hi all,
I run this query
select max(prelevement_dt), mpr
from labo_demande
group by mpr;The table labo_demande contains 1.688.883 rows and an index on (MPR, PRELEVEMENT_DT) exists. (I have already rebuilt this index).
I gather stats on the table but the query still takes 10 seconds running.
The explain plan shows a TABLE ACCESS FULL on the table.
Have someone an idea on how to tune this sql statement ?
Thanks for your helpfcjunic wrote:
Hi all,
I run this query
select max(prelevement_dt), mpr
from labo_demande
group by mpr;The table labo_demande contains 1.688.883 rows and an index on (MPR, PRELEVEMENT_DT) exists. (I have already rebuilt this index).
I gather stats on the table but the query still takes 10 seconds running.
The explain plan shows a TABLE ACCESS FULL on the table.
Unless at least one of the two columns is declared to be non-null (or you add a predicate like (e.g.): "mpr is not null") then this is the only possible execution path for the query. If there is a NOT NULL constraint on one of the columns then an index fast full scan with "sort group by "is possible, and an index full scan with "sort group by nosort" is possible - but the cost of the the index full scan could (for valid reasons) be larger than the cost of the tablescan, and there are various bugs with costing index fast full scans that means the optimizer can make the cost of that plan too high (for invalid reasons).
If either of the paths are valid, you can hint them: /*+ index(labo_demande(mpr, prelevement_dt)) */ or /*+ index_ffs(....) */
Regards
Jonathan Lewis -
Hi,
I need some help in performing tuning of a big query. Explain plan is as under:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
Edited by: AbdulHadi on Sep 16, 2011 3:56 PM
Edited by: AHadi on Sep 19, 2011 10:02 AM3 SORT GROUP BY 47916 25M 491G 15M (3) 17:30:31
4 VIEW 870M 445G 15M (2) 17:24:08
5 HASH GROUP BY 870M 427G 885G 15M (2) 17:24:08
In above steps its using very high temporary tablespace usage. please try to tune your query.
- dynamic sampling used for this statement
The statistics appears to be stale. -
Hi All,
My Oracle database is running on 10.2.0.2.0 on RHEL 5.4 64 bit.
I need some tuning guide line for below SQL:
select rnii.order_id,
rnii.asin,
rnii.gl_product_group,
rnii.warehouse_id,
rtrim(rnii.vendor_ordering_id) distributor_id,
rnii.cost,
sum(rnii.rnii_quantity_available + rnii.rnii_quantity_in_progress) quantity
from
O_RECEIVED_NOT_INVOICED_ITEMS rnii
where
rnii.legal_entity_id = 101 and
rnii.received_date < to_date('2010-02-28','YYYY-MM-DD') + 1 and
rnii.snapshot_day = to_date('2010-02-28','YYYY-MM-DD') + 1 and
rnii.rnii_quantity_available + rnii.rnii_quantity_in_progress != 0
group by
rnii.order_id,
rnii.asin,
rnii.gl_product_group,
rnii.warehouse_id,
rtrim(rnii.vendor_ordering_id),
rnii.cost
having
sum(rnii.rnii_quantity_available + rnii.rnii_quantity_in_progress) != 0
/Here is execution plan :
PLAN_TABLE_OUTPUT
Plan hash value: 2086243943
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 366K| 23M| | 103K (3)| 00:20:37 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10001 | 366K| 23M| | 103K (3)| 00:20:37 | | | Q1,01 | P->S | QC (RAND) |
|* 3 | FILTER | | | | | | | | | Q1,01 | PCWC | |
| 4 | HASH GROUP BY | | 366K| 23M| 707M| 103K (3)| 00:20:37 | | | Q1,01 | PCWP | |
| 5 | PX RECEIVE | | 7326K| 475M| | 102K (3)| 00:20:35 | | | Q1,01 | PCWP | |
| 6 | PX SEND HASH | :TQ10000 | 7326K| 475M| | 102K (3)| 00:20:35 | | | Q1,00 | P->P | HASH |
| 7 | PX BLOCK ITERATOR | | 7326K| 475M| | 102K (3)| 00:20:35 | 1 | 4 | Q1,00 | PCWC | |
|* 8 | TABLE ACCESS FULL| O_RECEIVED_NOT_INVOICED_ITEMS | 7326K| 475M| | 102K (3)| 00:20:35 | 197 | 200 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
3 - filter(SUM("RNII"."RNII_QUANTITY_AVAILABLE"+"RNII"."RNII_QUANTITY_IN_PROGRESS")<>0)
8 - filter("RNII"."RNII_QUANTITY_AVAILABLE"+"RNII"."RNII_QUANTITY_IN_PROGRESS"<>0 AND "RNII"."LEGAL_ENTITY_ID"=101 AND
"RNII"."SNAPSHOT_DAY"=TO_DATE('2010-03-01 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND "RNII"."RECEIVED_DATE"<TO_DATE('2010-03-01 00:00:00', 'yyyy-mm-dd
hh24:mi:ss'))I tried to auto trace it and got below results:
3522852 rows selected.
Elapsed: 00:03:29.65
Statistics
101 recursive calls
3 db block gets
4033298 consistent gets
4019237 physical reads
972 redo size
169791511 bytes sent via SQL*Net to client
2583851 bytes received via SQL*Net from client
234858 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
3522852 rows processed
select partition_name,num_rows,sample_size,last_analyzed from dba_tab_partitions where table_name='O_RECEIVED_NOT_INVOICED_ITEMS' AND
PARTITION_NAME LIKE '%ORNII101_2010%' ORDER BY 1;
PARTITION_NAME NUM_ROWS SAMPLE_SIZE LAST_ANALYZED
ORNII101_201001 135228000 2704560 2010/03/02 06:30:39
ORNII101_201002 143515850 2870317 2010/03/02 06:30:48
ORNII101_201003 146559550 2931191 2010/03/02 06:30:57
ORNII101_201004 0 2010/03/02 06:30:57Table 'O_RECEIVED_NOT_INVOICED_ITEMS' is COMPOSITE PARTITIONED by 'LEGAL_ENTITY_ID' & 'SNAPSHOT_DAY' and subpartitioned by 'RNII_ID'.
There are 227 partitions (Monthly) with 4 sub partitions in each of them.
Table is sized at 520 GB and there is no index on the table. Table is having DEGREE=8.
Query runs on first date of every month.
Looking forward to have tuning recommendations to reduce query elapsed time. Is there any advantage by creating any index (local ?) on this table?The parallel processing of the query is not helping (at least when executed from SQL*Plus) much.can you bit elaborate this please ?
Here is TKPROF report :
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.01 0.21 0 32 0 0
Fetch 234858 8.47 123.70 0 0 0 3522852
total 234860 8.48 123.93 0 32 0 3522852
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 153
Rows Row Source Operation
3522852 PX COORDINATOR (cr=32 pr=0 pw=0 time=119427010 us)
0 PX SEND QC (RANDOM) :TQ10001 (cr=0 pr=0 pw=0 time=0 us)
0 FILTER (cr=0 pr=0 pw=0 time=0 us)
0 HASH GROUP BY (cr=0 pr=0 pw=0 time=0 us)
0 PX RECEIVE (cr=0 pr=0 pw=0 time=0 us)
0 PX SEND HASH :TQ10000 (cr=0 pr=0 pw=0 time=0 us)
0 PX BLOCK ITERATOR PARTITION: 1 4 (cr=0 pr=0 pw=0 time=0 us)
0 TABLE ACCESS FULL O_RECEIVED_NOT_INVOICED_ITEMS PARTITION: 197 200 (cr=0 pr=0 pw=0 time=0 us)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
reliable message 1 0.00 0.00
enq: KO - fast object checkpoint 1 0.00 0.00
PX Deq: Join ACK 10 0.00 0.00
os thread startup 8 0.02 0.18
PX Deq: Parse Reply 9 0.00 0.00
SQL*Net message to client 234858 0.00 0.10
PX Deq: Execute Reply 405 1.95 115.65
PX qref latch 3 0.00 0.00
SQL*Net message from client 234858 0.27 75.93
PX Deq: Signal ACK 11 0.00 0.00
latch: session allocation 2 0.00 0.00
enq: PS - contention 2 0.00 0.00
******************************************************************************** -
Performance tuning in 11g for said query
Hello,
I have the below query which needs to be tuned:
SELECT DISTINCT a.emplid
, a.upa_fiscal_year
, b.balance_period
, 0
, a.descr
, a.UPA_CURRENT_AMT
, a.UPA_CURRENT_AMT2
, a.UPA_CURRENT_AMT3
, a.UPA_CURRENT_AMT4
FROM ps_upa_eq_incal_vw a
, ps_upa_eq_incal_vw b
WHERE a.emplid = b.emplid
AND a.UPA_FISCAL_YEAR = b.UPA_FISCAL_YEAR
AND a.balance_period = (
SELECT MAX(balance_period)
FROM ps_upa_eq_incal_vw
WHERE emplid = a.emplid
AND upa_fiscal_year = a.upa_fiscal_year
AND descr = a.descr
AND balance_period <= b.balance_period)
AND a.descr NOT IN (
SELECT DISTINCT descr
FROM ps_upa_eq_incal_vw
WHERE emplid = b.emplid
AND upa_fiscal_year = b.upa_fiscal_year
AND balance_period = b.balance_period
AND b.balance_period > a.balance_period )
UNION
SELECT emplid
, upa_fiscal_year
, balance_period
, 1
, 'Total'
, SUM ( UPA_CURRENT_AMT )
, SUM ( UPA_CURRENT_AMT2 )
, SUM ( UPA_CURRENT_AMT3 )
, SUM ( UPA_CURRENT_AMT4 )
FROM (
SELECT DISTINCT a.emplid emplid
, a.upa_fiscal_year upa_fiscal_year
, b.balance_period balance_period
, a.descr
, a.UPA_CURRENT_AMT UPA_CURRENT_AMT
, a.UPA_CURRENT_AMT2 UPA_CURRENT_AMT2
, a.UPA_CURRENT_AMT3 UPA_CURRENT_AMT3
, a.UPA_CURRENT_AMT4 UPA_CURRENT_AMT4
FROM ps_upa_eq_incal_vw a
, ps_upa_eq_incal_vw b
WHERE a.emplid = b.emplid
AND a.UPA_FISCAL_YEAR = b.UPA_FISCAL_YEAR
AND a.BALANCE_PERIOD = (
SELECT MAX(balance_period)
FROM ps_upa_eq_incal_vw
WHERE emplid = a.emplid
AND upa_fiscal_year = a.upa_fiscal_year
AND descr = a.descr
AND balance_period <= b.balance_period)
AND a.descr NOT IN (
SELECT DISTINCT descr
FROM ps_upa_eq_incal_vw
WHERE emplid = b.emplid
AND upa_fiscal_year = b.upa_fiscal_year
AND balance_period = b.balance_period
AND b.balance_period > a.balance_period ) )
GROUP BY emplid , upa_fiscal_year , balance_period;The EXPLAIN plan for this query is as under:
Plan hash value: 3550380953
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 24 | 2784 | | 429M (53)|999:59:59 |
| 1 | SORT UNIQUE | | 24 | 2784 | | 429M (53)|999:59:59 |
| 2 | UNION-ALL | | | | | | |
|* 3 | FILTER | | | | | | |
| 4 | NESTED LOOPS | | 196M| 29G| | 205M (4)|685:32:54 |
| 5 | VIEW | PS_UPA_EQ_INCAL_VW | 4513K| 146M| | 72281 (2)| 00:14:28 |
| 6 | HASH GROUP BY | | 4513K| 249M| 329M| 72281 (2)| 00:14:28 |
|* 7 | HASH JOIN | | 4513K| 249M| | 8644 (4)| 00:01:44 |
| 8 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 513 | 14364 | | 3 (0)| 00:00:01 |
|* 9 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
| 10 | VIEW PUSHED PREDICATE | PS_UPA_EQ_INCAL_VW | 1 | 127 | | 46 (5)| 00:00:01 |
| 11 | SORT GROUP BY | | 33 | 1914 | | 46 (5)| 00:00:01 |
|* 12 | HASH JOIN | | 33 | 1914 | | 45 (3)| 00:00:01 |
|* 13 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 44 | 1320 | | 41 (0)| 00:00:01 |
|* 15 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 44 | | | 3 (0)| 00:00:01 |
|* 16 | FILTER | | | | | | |
| 17 | HASH GROUP BY | | 1 | 53 | | 8 (25)| 00:00:01 |
|* 18 | FILTER | | | | | | |
|* 19 | HASH JOIN | | 4 | 212 | | 7 (15)| 00:00:01 |
|* 20 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 4 | 100 | | 3 (0)| 00:00:01 |
|* 21 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 22 | SORT AGGREGATE | | 1 | 91 | | | |
| 23 | VIEW | PS_UPA_EQ_INCAL_VW | 1 | 91 | | 6 (0)| 00:00:01 |
| 24 | SORT GROUP BY | | 1 | 58 | | 6 (0)| 00:00:01 |
| 25 | NESTED LOOPS | | | | | | |
| 26 | NESTED LOOPS | | 1 | 58 | | 6 (0)| 00:00:01 |
| 27 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 2 | 60 | | 4 (0)| 00:00:01 |
|* 28 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 1 | | | 3 (0)| 00:00:01 |
|* 29 | INDEX UNIQUE SCAN | PS_UPA_EQ_TRCD_TBL | 1 | | | 0 (0)| 00:00:01 |
|* 30 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_TRCD_TBL | 1 | 28 | | 1 (0)| 00:00:01 |
| 31 | HASH GROUP BY | | 12 | 852 | | 214M (5)|715:46:12 |
| 32 | VIEW | | 12 | 852 | | 214M (5)|715:46:12 |
| 33 | HASH UNIQUE | | 12 | 1932 | | 214M (5)|715:46:12 |
|* 34 | FILTER | | | | | | |
| 35 | NESTED LOOPS | | 196M| 29G| | 205M (4)|685:32:54 |
| 36 | VIEW | PS_UPA_EQ_INCAL_VW | 4513K| 146M| | 72281 (2)| 00:14:28 |
| 37 | HASH GROUP BY | | 4513K| 249M| 329M| 72281 (2)| 00:14:28 |
|* 38 | HASH JOIN | | 4513K| 249M| | 8644 (4)| 00:01:44 |
| 39 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 513 | 14364 | | 3 (0)| 00:00:01 |
|* 40 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
| 41 | VIEW PUSHED PREDICATE | PS_UPA_EQ_INCAL_VW | 1 | 127 | | 46 (5)| 00:00:01 |
| 42 | SORT GROUP BY | | 33 | 1914 | | 46 (5)| 00:00:01 |
|* 43 | HASH JOIN | | 33 | 1914 | | 45 (3)| 00:00:01 |
|* 44 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_DC_BAL | 44 | 1320 | | 41 (0)| 00:00:01 |
|* 46 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 44 | | | 3 (0)| 00:00:01 |
|* 47 | FILTER | | | | | | |
| 48 | HASH GROUP BY | | 1 | 53 | | 8 (25)| 00:00:01 |
|* 49 | FILTER | | | | | | |
|* 50 | HASH JOIN | | 4 | 212 | | 7 (15)| 00:00:01 |
|* 51 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 4 | 100 | | 3 (0)| 00:00:01 |
|* 52 | TABLE ACCESS FULL | PS_UPA_EQ_TRCD_TBL | 32 | 896 | | 3 (0)| 00:00:01 |
| 53 | SORT AGGREGATE | | 1 | 91 | | | |
| 54 | VIEW | PS_UPA_EQ_INCAL_VW | 1 | 91 | | 6 (0)| 00:00:01 |
| 55 | SORT GROUP BY | | 1 | 58 | | 6 (0)| 00:00:01 |
| 56 | NESTED LOOPS | | | | | | |
| 57 | NESTED LOOPS | | 1 | 58 | | 6 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID| PS_UPA_EQ_DC_BAL | 2 | 60 | | 4 (0)| 00:00:01 |
|* 59 | INDEX RANGE SCAN | PS_UPA_EQ_DC_BAL | 1 | | | 3 (0)| 00:00:01 |
|* 60 | INDEX UNIQUE SCAN | PS_UPA_EQ_TRCD_TBL | 1 | | | 0 (0)| 00:00:01 |
|* 61 | TABLE ACCESS BY INDEX ROWID | PS_UPA_EQ_TRCD_TBL | 1 | 28 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
3 - filter( NOT EXISTS (SELECT 0 FROM SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE
:B1>:B2 AND "J"."BALANCE_PERIOD"=:B3 AND "J"."UPA_FISCAL_YEAR"=:B4 AND "J"."EMPLID"=:B5 AND
("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND
"J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR" AND "J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND
"V"."UPA_FISCAL_YEAR"=:B6 GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR"
HAVING "V"."DESCR"=:B7) AND "A"."BALANCE_PERIOD"= (SELECT MAX("BALANCE_PERIOD") FROM (SELECT "J"."EMPLID"
"EMPLID","J"."UPA_FISCAL_YEAR" "UPA_FISCAL_YEAR","J"."BALANCE_PERIOD" "BALANCE_PERIOD","V"."DESCR"
"DESCR",SUM(DECODE("J"."UPA_INC_TYPE",'D',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT",SUM(DECODE("J"."UPA_INC_TYPE",'M',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT2",SUM(DECODE("J"."UPA_INC_TYPE",'C',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT3",SUM(DECODE("J"."UPA_INC_TYPE",'P',"J"."UPA_CURRENT_AMT",0)) "UPA_CURRENT_AMT4" FROM
SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE "J"."BALANCE_PERIOD"<=:B8 AND
"J"."UPA_FISCAL_YEAR"=:B9 AND "J"."EMPLID"=:B10 AND ("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR
"J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND "V"."UPA_FISCAL_YEAR"=:B11 AND
"J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."DESCR"=:B12 AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR"
GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR") "PS_UPA_EQ_INCAL_VW"))
7 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
9 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
12 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
13 - filter("V"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
15 - access("J"."EMPLID"="B"."EMPLID" AND "J"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
16 - filter("V"."DESCR"=:B1)
18 - filter(:B1>:B2)
19 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
20 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
21 - filter("V"."UPA_FISCAL_YEAR"=:B1)
28 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"<=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
29 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."UPA_FISCAL_YEAR"=:B1)
filter("J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
30 - filter("V"."DESCR"=:B1)
34 - filter( NOT EXISTS (SELECT 0 FROM SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE
:B1>:B2 AND "J"."BALANCE_PERIOD"=:B3 AND "J"."UPA_FISCAL_YEAR"=:B4 AND "J"."EMPLID"=:B5 AND
("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND
"J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR" AND "J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND
"V"."UPA_FISCAL_YEAR"=:B6 GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR"
HAVING "V"."DESCR"=:B7) AND "A"."BALANCE_PERIOD"= (SELECT MAX("BALANCE_PERIOD") FROM (SELECT "J"."EMPLID"
"EMPLID","J"."UPA_FISCAL_YEAR" "UPA_FISCAL_YEAR","J"."BALANCE_PERIOD" "BALANCE_PERIOD","V"."DESCR"
"DESCR",SUM(DECODE("J"."UPA_INC_TYPE",'D',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT",SUM(DECODE("J"."UPA_INC_TYPE",'M',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT2",SUM(DECODE("J"."UPA_INC_TYPE",'C',"J"."UPA_CURRENT_AMT",0))
"UPA_CURRENT_AMT3",SUM(DECODE("J"."UPA_INC_TYPE",'P',"J"."UPA_CURRENT_AMT",0)) "UPA_CURRENT_AMT4" FROM
SYSADM."PS_UPA_EQ_TRCD_TBL" "V",SYSADM."PS_UPA_EQ_DC_BAL" "J" WHERE "J"."BALANCE_PERIOD"<=:B8 AND
"J"."UPA_FISCAL_YEAR"=:B9 AND "J"."EMPLID"=:B10 AND ("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR
"J"."UPA_INC_TYPE"='M' OR "J"."UPA_INC_TYPE"='P') AND "V"."UPA_FISCAL_YEAR"=:B11 AND
"J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."DESCR"=:B12 AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR"
GROUP BY "J"."EMPLID","J"."UPA_FISCAL_YEAR","J"."BALANCE_PERIOD","V"."DESCR") "PS_UPA_EQ_INCAL_VW"))
38 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
40 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
43 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
44 - filter("V"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
46 - access("J"."EMPLID"="B"."EMPLID" AND "J"."UPA_FISCAL_YEAR"="B"."UPA_FISCAL_YEAR")
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
47 - filter("V"."DESCR"=:B1)
49 - filter(:B1>:B2)
50 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
51 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
52 - filter("V"."UPA_FISCAL_YEAR"=:B1)
59 - access("J"."EMPLID"=:B1 AND "J"."UPA_FISCAL_YEAR"=:B2 AND "J"."BALANCE_PERIOD"<=:B3)
filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
60 - access("J"."UPA_EQ_INC_CD"="V"."UPA_EQ_INC_CD" AND "V"."UPA_FISCAL_YEAR"=:B1)
filter("J"."UPA_FISCAL_YEAR"="V"."UPA_FISCAL_YEAR")
61 - filter("V"."DESCR"=:B1)Any directions as to how to tune this query would be greatly appreciated!
Thanks,
Suddhasatwalooks like these two steps hurts the most (causing the NL join take forever - because of the 4,5M rows)
|* 9 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
|* 40 | TABLE ACCESS FULL | PS_UPA_EQ_DC_BAL | 4513K| 129M| | 8592 (4)| 00:01:44 |
9 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')
40 - filter("J"."UPA_INC_TYPE"='C' OR "J"."UPA_INC_TYPE"='D' OR "J"."UPA_INC_TYPE"='M' OR
"J"."UPA_INC_TYPE"='P')do you have an index on PS_UPA_EQ_DC_BAL.UPA_INC_TYPE column?
reducing the number of rows returned in this step would be critical to speed up the NL join -
Query Tuning (sequential read + direct path read/write temp)
Following query takes nearly 10 minutes under 10.2.0.2 on WIN2K3 to execute but I am sure there would be an alternate to tune it further.
Major waits are 'db file sequential read' and 'direct path read temp' in addition to 'direct path write temp'
Increasing/tuning the work_area_policy/sort_area_size would help? moving the tables to faster disk would reduce PIO causing sequential read, query re-writing would prove to be helpful?.
Below is the tkprof:
SELECT
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, '')) PHONE
, SUM(CASE
WHEN FT.FT_TYPE_FLG IN ('BS','BX','AD','AX') THEN FT.CUR_AMT
ELSE 0
END) BILL
, SUM(CASE
WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
ELSE 0
END) PAY
, SUM(FT.CUR_AMT) DUE
, SUM(CASE
WHEN FT.FREEZE_DTTM > '03-JUN-08' THEN
CASE WHEN FT.FT_TYPE_FLG IN ('PS','PX') THEN FT.CUR_AMT * -1
ELSE 0
END
ELSE 0
END) PAY_02JUN
FROM
CI_FT FT
, CI_SA SA
, CI_ACCT_CHAR AC
, CI_CUST_CL_L CL
, CI_ACCT A
, CI_ACCT_PER AP
SELECT
P.PER_ID
, (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY) ADDR
, MAX(DECODE(PP.PHONE_TYPE_CD, 'MOB ', PP.PHONE)) MOB
, MAX(DECODE(PP.PHONE_TYPE_CD, 'BUSN ', PP.PHONE)) BUS
, MAX(DECODE(PP.PHONE_TYPE_CD, 'HOME ', PP.PHONE)) HOME
, MAX(DECODE(PP.PHONE_TYPE_CD, 'FAX ', PP.PHONE)) FAX
, MAX(DECODE(PN.NAME_TYPE_FLG, 'PRIM', PN.ENTITY_NAME)) ENG_NAME
, MAX(DECODE(PN.NAME_TYPE_FLG, 'ALT ', PN.ENTITY_NAME)) ARA_NAME
, MAX(DECODE(PC.CHAR_TYPE_CD, 'NATION ', PC.CHAR_VAL)) NATION
FROM
CI_PER P
, CI_PER_PHONE PP
, CI_PER_NAME PN
, CI_PER_CHAR PC
WHERE
P.PER_ID = PP.PER_ID (+)
AND P.PER_ID = PN.PER_ID (+)
AND P.PER_ID = PC.PER_ID (+)
GROUP BY
P.PER_ID
, (P.CITY || ', ' || P.STATE || ',' || P.COUNTRY)
) P
WHERE
P.PER_ID = AP.PER_ID
AND AP.ACCT_ID = AC.ACCT_ID
AND AP.ACCT_ID = SA.ACCT_ID
AND AP.MAIN_CUST_SW = 'Y'
AND A.ACCT_ID = SA.ACCT_ID
AND A.ACCT_ID = AP.ACCT_ID
AND AC.CHAR_TYPE_CD = 'ACCTYPE'
AND AC.CHAR_VAL IN ('UOS', 'DEFAULT')
AND AC.ACCT_ID = SA.ACCT_ID
AND CL.LANGUAGE_CD = 'ENG'
AND A.ACCT_ID = AC.ACCT_ID
AND A.CUST_CL_CD = CL.CUST_CL_CD
AND SA.SA_ID = FT.SA_ID
AND FT.FREEZE_DTTM IS NOT NULL
GROUP BY
P.PER_ID
, CL.DESCR
, P.ENG_NAME
, P.ARA_NAME
, P.NATION
, P.ADDR
, ('Mob:' || NVL(P.MOB, '') || ', Home:' || NVL(P.HOME, '') || ', Bus.:' || NVL(P.BUS, '') || ', Fax:' || NVL(P.FAX, ''))
HAVING
SUM(FT.CUR_AMT) > 0
call count cpu elapsed disk query current rows
Parse 1 0.64 0.64 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 304 353.09 430.04 21720 52997832 0 4543
total 306 353.73 430.69 21720 52997832 0 4543
Misses in library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 79 (CISADM)
Rows Row Source Operation
4543 FILTER (cr=52997832 pr=21720 pw=10311 time=430019418 us)
5412 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=430015729 us)
199471 VIEW (cr=52997832 pr=21720 pw=10311 time=423392346 us)
199471 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304 TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)
13704480 NESTED LOOPS (cr=21818135 pr=7655 pw=0 time=287797921 us)
2782119 NESTED LOOPS OUTER (cr=3915432 pr=2950 pw=0 time=38953485 us)
571492 NESTED LOOPS OUTER (cr=2545763 pr=2711 pw=0 time=7433194 us)
286061 NESTED LOOPS OUTER (cr=2253263 pr=2671 pw=0 time=26607373 us)
123411 NESTED LOOPS (cr=1989056 pr=2642 pw=0 time=22711194 us)
123411 NESTED LOOPS (cr=1864959 pr=2642 pw=0 time=20860026 us)
123411 NESTED LOOPS (cr=1494040 pr=1754 pw=0 time=15553373 us)
243088 NESTED LOOPS (cr=29540 pr=1754 pw=0 time=10213331 us)
13227 TABLE ACCESS FULL CI_PER (cr=251 pr=49 pw=0 time=43331 us)
243088 INDEX RANGE SCAN XM150S1 (cr=29289 pr=1705 pw=0 time=6178159 us)(object id 97173)
123411 INLIST ITERATOR (cr=1464500 pr=0 pw=0 time=7220251 us)
123411 INDEX RANGE SCAN CM064S0 (cr=1464500 pr=0 pw=0 time=5631936 us)(object id 108631)
123411 TABLE ACCESS BY INDEX ROWID CI_ACCT (cr=370919 pr=888 pw=0 time=7241286 us)
123411 INDEX UNIQUE SCAN XM148P0 (cr=247508 pr=0 pw=0 time=1198649 us)(object id 97147)
123411 TABLE ACCESS BY INDEX ROWID CI_CUST_CL_L (cr=124097 pr=0 pw=0 time=1391837 us)
123411 INDEX UNIQUE SCAN XC523P0 (cr=686 pr=0 pw=0 time=595005 us)(object id 97745)
283749 TABLE ACCESS BY INDEX ROWID CI_PER_PHONE (cr=264207 pr=29 pw=0 time=3549713 us)
283749 INDEX RANGE SCAN XM172P0 (cr=125886 pr=4 pw=0 time=1307395 us)(object id 98733)
571492 INDEX RANGE SCAN XM171S2 (cr=292500 pr=40 pw=0 time=2976807 us)(object id 98728)
2777066 TABLE ACCESS BY INDEX ROWID CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761 us)
2777066 INDEX RANGE SCAN XM168P0 (cr=596156 pr=53 pw=0 time=7394319 us)(object id 98719)
13704480 TABLE ACCESS BY INDEX ROWID CI_SA (cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480 INDEX RANGE SCAN XM199S1 (cr=5688247 pr=104 pw=0 time=51063061 us)(object id 98973)
4013304 INDEX RANGE SCAN CM112S1 (cr=27477335 pr=1332 pw=0 time=124063022 us)(object id 116797)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 304 0.00 0.00
db file sequential read 11366 0.34 65.63
direct path write temp 1473 0.06 2.91
latch: cache buffers chains 17 0.00 0.00
db file scattered read 7 0.01 0.03
read by other session 2 0.00 0.00
direct path read temp 1473 0.03 6.85
SQL*Net message from client 304 0.02 2.74
SQL*Net more data to client 292 0.00 0.00
********************************************************************************Luckys
I've just realised that I mis-read part of your plan:
199471 HASH GROUP BY (cr=52997832 pr=21720 pw=10311 time=423192867 us)
4013304 TABLE ACCESS BY INDEX ROWID CI_FT (cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987 pw=0 time=407554071 us)The time component for a line is the time it supplies, plus the sum of the time from its direct descendents.
In this case I looked at the HASH GROUP BY and TABLE ACCESS and got a difference of about 283 seconds. In fact I should have taken more notice of the other lines in the plan - comparing the HASH GROUP BY with the NESTED LOOP for a difference of about 16 seconds and assuming that the time in the TABLE ACCESS line was not to be trusted. (See http://jonathanlewis.wordpress.com/2007/04/26/heisenberg/ for a couple of comments on the timing issue).
So the grouping is responsible for relatively little of the excess time - most of the time goes into the nested loop.
I shall be using the Hints as advised, when we say we
have to "rewrite the query"
given the current context excluding the HINTS, what
exactly should I be
considering in terms of query rewrite, what
additional intelligence I can add to the
query in question so that CBO produces a different
plan.
The main consideration is what the query is supposed to report. Compare this with the way the optimizer is running the query and see if it makes sense.
When are talking about high intermediate rows
processing are we referring to this
section of the plan?;
4013304 TABLE ACCESS BY INDEX ROWID CI_FT
(cr=52997832 pr=11409 pw=0 time=140469508 us)
17717785 NESTED LOOPS (cr=49295470 pr=8987
pw=0 time=407554071 us)
13704480 NESTED LOOPS (cr=21818135 pr=7655
pw=0 time=287797921 us)
2782119 NESTED LOOPS OUTER (cr=3915432
pr=2950 pw=0 time=38953485 us)
2777066 TABLE ACCESS BY INDEX ROWID
CI_PER_CHAR (cr=1369669 pr=239 pw=0 time=23084761
us)
2777066 INDEX RANGE SCAN XM168P0 (cr=596156
pr=53 pw=0 time=7394319 us)(object id 98719)
13704480 TABLE ACCESS BY INDEX ROWID CI_SA
(cr=17902703 pr=4705 pw=0 time=163320548 us)
13704480 INDEX RANGE SCAN XM199S1
(cr=5688247 pr=104 pw=0 time=51063061 us)(object id
98973)
4013304 INDEX RANGE SCAN CM112S1 (cr=27477335
pr=1332 pw=0 time=124063022 us)(object id 116797)
Correct - one of the nested loops returns 2.78M rows - but as you run the next join you end up collecting 13.7M entires from the next index and table. That step is responsible for quite a lot of your work and time (as is the following step where you USE the 13.7M rows to probe the next index/table combination). If the optimizer had not grown the data set by merging the P view earlier on, the data sizes would be significantly smaller at that point.
Your inline view looks as if it is trying to turn rows into columns (the max(decode()) trick) - which is why I think it might be a good idea to stop Oracle from merging the view. So, as I suggested, look at the query withouth that bit of complexity and work out a sensible way to walk through the tables - bearing in mind the statistics below and the available indexes, and the amount of data your predicates identify at each stage.
Moreover tables have been analyzed:
CI_ACCT 243068
CI_ACCT_CHAR 222320
CI_ACCT_PER 242971
CI_FT 794510
CI_PER 13227
CI_PER_CHAR 42555
CI_PER_PHONE 18488
CI_SA 1082301
Parameters:
optimizer_features_enable string 10.2.0.2
optimizer_index_caching integer 100
optimizer_index_cost_adj integer 1
Unless you've been given strict instructions by a 3rd-part supplier, those settings for the optimizer_index_caching and optimizer_index_cost_adj are particularly bad - especially in 10g. With those settings, the optimizer is quite likely to choose stupid plans with excessive use of indexes - and pick the wrong index while doing it.
It's not appropriate to fiddle with system parameters to address one query - but at some stage you need to rethink your entire set of parameter settings to do things the 10g way. See this note from the Optimizer Group: http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_bidw_optimizer_10gr2_0208.pdf
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
"The greatest enemy of knowledge is not ignorance,
it is the illusion of knowledge." Stephen Hawking. -
Hi
I am new to Performance tuning and I know only very basic things.
My DB version is 10.2.0.4.
I want to tune my query which uses like clause and it is a dynamically created with either left truncation or right truncation or both.
I found in some sites that catserach will solve my problem and i tried the same in test DB.
So I did the following.
SQL >alter system flush buffer_cache;
GRANT EXECUTE ON CTX_DDL TO user;
EXEC CTX_DDL.DROP_INDEX_SET('test_set');
EXEC CTX_DDL.CREATE_INDEX_SET('test_set');
EXEC CTX_DDL.ADD_INDEX('test_set','d');
create index test_table_idx on test_table(c) INDEXTYPE IS CTXSYS.CTXCAT PARAMETERS ('index set test_set');
SQL> SELECT COUNT(*) COUNT, a, b FROM test_table
WHERE UPPER(c) LIKE '%270%' AND d = 0 GROUP BY a, b ;
5664 rows selected.
Elapsed: 00:00:12.29
Execution Plan
Plan hash value: 4088289091
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Ti
me |
| 0 | SELECT STATEMENT | | 59358 | 1739K| | 8039 (4)| 00:01:37 |
| 1 | HASH GROUP BY | | 59358 | 1739K| 5144K| 8039 (4)| 00:01:37 |
|* 2 | TABLE ACCESS FULL| test_table | 59358 | 1739K| | 7547 (4)| 00:01:31 |
Predicate Information (identified by operation id):
2 - filter(UPPER("C") LIKE '%270%' AND "D"=0)
Statistics
812 recursive calls
0 db block gets
33459 consistent gets
33206 physical reads
0 redo size
168223 bytes sent via SQL*Net to client
4639 bytes received via SQL*Net from client
379 SQL*Net roundtrips to/from client
22 sorts (memory)
0 sorts (disk)
5664 rows processed
SQL >alter system flush buffer_cache;
SQL> SELECT COUNT(*) COUNT, COUNT, a, b FROM test_table
WHERE CATSEARCH(C,'<query> <textquery grammar="context">%270% </textquery></query>',NULL) > 0
GROUP BY a, b;
5664 rows selected.
Elapsed: 00:00:27.51
Execution Plan
Plan hash value: 2203090224
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 59369 | 2261K| | 606 (2)| 00:00:08 |
| 1 | HASH GROUP BY | | 59369 | 2261K| 6072K| 606 (2)| 00:00:08 |
| 2 | TABLE ACCESS BY INDEX ROWID| test_table | 59369 | 2261K| | 2 (0)| 00:00:01 |
|* 3 | DOMAIN INDEX | test_table_idx | | | | | |
Predicate Information (identified by operation id):
3 - access("CTXSYS"."CATSEARCH"("C",'<query> <textquery grammar="context">%270% </textquery></query>',NULL)>0)
Statistics
17856 recursive calls
0 db block gets
26550 consistent gets
9047 physical reads
0 redo size
168223 bytes sent via SQL*Net to client
4639 bytes received via SQL*Net from client
379 SQL*Net roundtrips to/from client
8 sorts (memory)
0 sorts (disk)
5664 rows processed.
I did all the above steps purely from reading some documents.
Can anyone explain me
1. if catsearch is the best option based on the stats (as catsearch option has many recursive calls).
2. What is the purpose of Oracle Grammar
3. What is the purpose of EXEC CTX_DDL.CREATE_INDEX_SET('test_set'); ??
4. I used grammar only for right and both side truncation and for left truncation my where clause is
WHERE CATSEARCH(C,'1044*',NULL) > 0 AND D = 0 GROUP BY A,B;
Also Can I modify the above where clause as
WHERE CATSEARCH(C,'1044*',' D = 0 ' > 0 GROUP BY A,B;
and explain the same pls.Here is the Trace for bit map.
DROP INDEX test_table_idx;
CREATE bitmap INDEX test_table_idx ON test_table(c) PARALLEL 20 nologging;
SELECT COUNT(*) COUNT, a, b FROM test_tableWHERE UPPER(c) LIKE '1044270%' AND d = 0 GROUP BY a, b
Elapsed: 00:00:00.85
Execution Plan
Plan hash value: 7812215
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 59358 | 1739K| | 87592 (1)| 00:17:32 |
| 1 | HASH GROUP BY | | 59358 | 1739K| 5144K| 87592 (1)| 00:17:32 |
|* 2 | TABLE ACCESS BY INDEX ROWID | test_table | 59358 | 1739K| | 87100 (1)| 00:17:26 |
| 3 | BITMAP CONVERSION TO ROWIDS| | | | | | |
|* 4 | BITMAP INDEX FULL SCAN | test_table_idx | | | | | |
Predicate Information (identified by operation id):
2 - filter("C"=0)
4 - filter(UPPER("C") LIKE '1044270%')
Statistics
1 recursive calls
0 db block gets
5310 consistent gets
0 physical reads
0 redo size
657 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SELECT COUNT(*) COUNT, a, b FROM test_table WHERE UPPER(c) LIKE '10%' AND d = 0 GROUP BY a, b ;
687644 rows selected.
Elapsed: 00:00:35.26
Execution Plan
Plan hash value: 7812215
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 59358 | 1739K| | 87592 (1)| 00:17:32 |
| 1 | HASH GROUP BY | | 59358 | 1739K| 5144K| 87592 (1)| 00:17:32 |
|* 2 | TABLE ACCESS BY INDEX ROWID | test_table | 59358 | 1739K| | 87100 (1)| 00:17:26 |
| 3 | BITMAP CONVERSION TO ROWIDS| | | | | | |
|* 4 | BITMAP INDEX FULL SCAN | test_table_idx | | | | | |
Predicate Information (identified by operation id):
2 - filter("C"=0)
4 - filter(UPPER("C") LIKE '10%')
Statistics
21 recursive calls
0 db block gets
246786 consistent gets
10328 physical reads
0 redo size
20956978 bytes sent via SQL*Net to client
504754 bytes received via SQL*Net from client
45844 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
687644 rows processed
SELECT COUNT(*) COUNT, a, b FROM test_table WHERE UPPER(c) LIKE '%EXT' AND d = 0 GROUP BY a, b
118760 rows selected.
Elapsed: 00:01:13.34
Execution Plan
Plan hash value: 7812215
| Id | Operation | Name | Rows | Bytes |TempS
pc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 59358 | 1739K| | 87592 (1)| 00:17:32 |
| 1 | HASH GROUP BY | | 59358 | 1739K| 5144K| 87592 (1)| 00:17:32 |
|* 2 | TABLE ACCESS BY INDEX ROWID | test_table | 59358 | 1739K| | 87100 (1)| 00:17:26 |
| 3 | BITMAP CONVERSION TO ROWIDS| | | |
| | |
|* 4 | BITMAP INDEX FULL SCAN | test_table_idx | | | | | |
Predicate Information (identified by operation id):
2 - filter("C"=0)
4 - filter(UPPER("C") LIKE '%0EXT')
Statistics
1 recursive calls
0 db block gets
122629 consistent gets
13682 physical reads
0 redo size
3534421 bytes sent via SQL*Net to client
87579 bytes received via SQL*Net from client
7919 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
118760 rows processed -
Hi,
In a data warehousing env, version 11.1.0.7.0 on Redhat linux.
run a query like below,select sum(case when T495255.PAYMENT_TYPE_ID = 3 then T495255.PAYMENT_ADJUSTMENT_AMOUNT end ) as c1,
max(T494961.DATE_VALUE) as c2,
sum(T495343.CURRENT_BALANCE_AMOUNT) as c3,
sum(T495343.FINAL_BILL_AMOUNT) as c4,
T495414.RECORDSTATUSIND_DESC as c5,
T495272.DATE_DESC as c6,
T495414.BTN as c7,
T495414.FINAL_RECEIVED_AMOUNT as c8,
T495414.ACCOUNT_NUMBER as c9,
T495414.DISCONNECT_REASON_DESC as c10,
T495414.LIQUIDITY_SCORE as c11,
T495414.STATE as c12,
T495414.REGION_DESCRIPTION as c13,
T495323.LIQUIDITY_SCORE_DESCRIPTION as c14,
T495360.BATCH_STATUS as c15
from
D_DATE T495294 /* D_DATE_CREATED */ ,
F_BATCH T495360 /* F_BATCH_Lscore */ ,
D_LIQUIDITY_SCORE_REASON T495323 /* D_LIQUIDITY_SCORE_REASON_DETAIL */ ,
F_LIQUIDITY_SCORE T495343 /* F_LIQUIDITY_SCORE_DETAIL */ left outer join (
F_PAYMENT_ADJUSTMENT_FINALS T495255 /* F_PAYMENT_ADJUSTMENT_FINALS_LSCORE */ left outer join D_DATE T494961 /* D_DATE_PAYMENT_ADJUSTMENT */ On T494961.DATE_ID = T495255.PAYMENT_ADJUSTMENT_DATE) On T495255.ACCOUNT_ID = T495343.ACCOUNT_ID,
D_DATE T495272 /* D_DATE_BILL_DATE */ ,
T_ACCOUNT_FINALS_DTL T495414 /* T_ACCOUNT_FINALS_DTL_LSCORE */
where ( T495294.DATE_ID = T495360.START_DATE and T495272.DATE_ID = T495414.FINAL_BILL_DATE and T495323.LIQUIDITY_SCORE_ID = T495343.LIQUIDITY_SCORE_REASON_ID and T495343.ACCOUNT_ID = T495414.ACCOUNT_ID and T495294.YEAR_DESC = 'Year 2010' and T495343.LIQUIDITY_SCORE_IMP_BATCH_ID = T495360.SOURCE_BATCH_ID and T495414.REGION_DESCRIPTION = '8-FinalsRM' )
group by T495272.DATE_DESC, T495323.LIQUIDITY_SCORE_DESCRIPTION, T495360.BATCH_STATUS, T495414.ACCOUNT_NUMBER, T495414.BTN, T495414.DISCONNECT_REASON_DESC, T495414.FINAL_RECEIVED_AMOUNT, T495414.LIQUIDITY_SCORE, T495414.RECORDSTATUSIND_DESC, T495414.REGION_DESCRIPTION, T495414.STATE;
explain is like below,
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 26M| 5784M| | 45903 (1)| 00:09:11 | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10010 | 26M| 5784M| | 45903 (1)| 00:09:11 | Q1,10 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 26M| 5784M| 6243M| 45903 (1)| 00:09:11 | Q1,10 | PCWP | |
| 4 | PX RECEIVE | | 26M| 5784M| | 45903 (1)| 00:09:11 | Q1,10 | PCWP | |
| 5 | PX SEND HASH | :TQ10009 | 26M| 5784M| | 45903 (1)| 00:09:11 | Q1,09 | P->P | HASH |
| 6 | HASH GROUP BY | | 26M| 5784M| 6243M| 45903 (1)| 00:09:11 | Q1,09 | PCWP | |
|* 7 | HASH JOIN OUTER | | 26M| 5784M| | 25403 (1)| 00:05:05 | Q1,09 | PCWP | |
| 8 | PX RECEIVE | | 3648K| 657M| | 20227 (1)| 00:04:03 | Q1,09 | PCWP | |
| 9 | PX SEND HASH | :TQ10007 | 3648K| 657M| | 20227 (1)| 00:04:03 | Q1,07 | P->P | HASH |
|* 10 | HASH JOIN BUFFERED | | 3648K| 657M| | 20227 (1)| 00:04:03 | Q1,07 | PCWP | |
| 11 | PX RECEIVE | | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,07 | PCWP | |
| 12 | PX SEND BROADCAST | :TQ10003 | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | P->P | BROADCAST |
| 13 | PX BLOCK ITERATOR | | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | PCWC | |
| 14 | TABLE ACCESS FULL | D_DATE | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 15 | HASH JOIN | | 3648K| 577M| | 20224 (1)| 00:04:03 | Q1,07 | PCWP | |
| 16 | BUFFER SORT | | | | | | | Q1,07 | PCWC | |
| 17 | PX RECEIVE | | 10 | 200 | | 3 (0)| 00:00:01 | Q1,07 | PCWP | |
| 18 | PX SEND BROADCAST | :TQ10001 | 10 | 200 | | 3 (0)| 00:00:01 | | S->P | BROADCAST |
| 19 | TABLE ACCESS FULL | D_LIQUIDITY_SCORE_REASON | 10 | 200 | | 3 (0)| 00:00:01 | | | |
|* 20 | HASH JOIN | | 3648K| 507M| | 20220 (1)| 00:04:03 | Q1,07 | PCWP | |
| 21 | PX RECEIVE | | 3649K| 180M| | 337 (3)| 00:00:05 | Q1,07 | PCWP | |
| 22 | PX SEND HASH | :TQ10004 | 3649K| 180M| | 337 (3)| 00:00:05 | Q1,04 | P->P | HASH |
|* 23 | HASH JOIN | | 3649K| 180M| | 337 (3)| 00:00:05 | Q1,04 | PCWP | |
| 24 | PX RECEIVE | | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,04 | PCWP | |
| 25 | PX SEND BROADCAST | :TQ10002 | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,02 | P->P | BROADCAST |
| 26 | PX BLOCK ITERATOR | | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,02 | PCWC | |
|* 27 | TABLE ACCESS FULL | D_DATE | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,02 | PCWP | |
|* 28 | HASH JOIN | | 9431K| 323M| | 334 (2)| 00:00:05 | Q1,04 | PCWP | |
| 29 | BUFFER SORT | | | | | | | Q1,04 | PCWC | |
| 30 | PX RECEIVE | | 1975 | 25675 | | 8 (0)| 00:00:01 | Q1,04 | PCWP | |
| 31 | PX SEND BROADCAST | :TQ10000 | 1975 | 25675 | | 8 (0)| 00:00:01 | | S->P | BROADCAST |
| 32 | TABLE ACCESS FULL| F_BATCH | 1975 | 25675 | | 8 (0)| 00:00:01 | | | |
| 33 | PX BLOCK ITERATOR | | 9431K| 206M| | 324 (2)| 00:00:04 | Q1,04 | PCWC | |
| 34 | TABLE ACCESS FULL | F_LIQUIDITY_SCORE | 9431K| 206M| | 324 (2)| 00:00:04 | Q1,04 | PCWP | |
| 35 | PX RECEIVE | | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,07 | PCWP | |
| 36 | PX SEND HASH | :TQ10005 | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | P->P | HASH |
| 37 | PX BLOCK ITERATOR | | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | PCWC | |
|* 38 | TABLE ACCESS FULL | T_ACCOUNT_FINALS_DTL | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | PCWP | |
| 39 | PX RECEIVE | | 113M| 4448M| | 5165 (1)| 00:01:02 | Q1,09 | PCWP | |
| 40 | PX SEND HASH | :TQ10008 | 113M| 4448M| | 5165 (1)| 00:01:02 | Q1,08 | P->P | HASH |
| 41 | VIEW | | 113M| 4448M| | 5165 (1)| 00:01:02 | Q1,08 | PCWP | |
|* 42 | HASH JOIN RIGHT OUTER | | 113M| 3472M| | 5165 (1)| 00:01:02 | Q1,08 | PCWP | |
| 43 | PX RECEIVE | | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,08 | PCWP | |
| 44 | PX SEND BROADCAST | :TQ10006 | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | P->P | BROADCAST |
| 45 | PX BLOCK ITERATOR | | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | PCWC | |
| 46 | TABLE ACCESS FULL | D_DATE | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | PCWP | |
| 47 | PX BLOCK ITERATOR | | 113M| 1953M| | 5151 (1)| 00:01:02 | Q1,08 | PCWC | |
| 48 | TABLE ACCESS FULL | F_PAYMENT_ADJUSTMENT_FINALS | 113M| 1953M| | 5151 (1)| 00:01:02 | Q1,08 | PCWP | |
Predicate Information (identified by operation id):
7 - access("T495255"."ACCOUNT_ID"(+)="T495343"."ACCOUNT_ID")
10 - access("T495272"."DATE_ID"="T495414"."FINAL_BILL_DATE")
15 - access("T495323"."LIQUIDITY_SCORE_ID"="T495343"."LIQUIDITY_SCORE_REASON_ID")
20 - access("T495343"."ACCOUNT_ID"="T495414"."ACCOUNT_ID")
23 - access("T495294"."DATE_ID"="T495360"."START_DATE")
27 - filter("T495294"."YEAR_DESC"='Year 2010')
28 - access("T495343"."LIQUIDITY_SCORE_IMP_BATCH_ID"="T495360"."SOURCE_BATCH_ID")
38 - filter("T495414"."REGION_DESCRIPTION"='8-FinalsRM')
42 - access("T494961"."DATE_ID"(+)="T495255"."PAYMENT_ADJUSTMENT_DATE")
Put hint into query, like
select /*+ star_transformation CACHE(T495294) PARALLEL(T495414 32,2) PARALLEL(T495255 32,2) PARALLEL(T495343 32,2) PARALLEL(T495272 32,2) PARALLEL(T495360 32,2) */ sum(case when T495255.PAYMENT_TYPE_ID = 3 then T495255.PAYMENT_ADJUSTMENT_AMOUNT end ) as c1,
max(T494961.DATE_VALUE) as c2,
sum(T495343.CURRENT_BALANCE_AMOUNT) as c3,
sum(T495343.FINAL_BILL_AMOUNT) as c4,
T495414.RECORDSTATUSIND_DESC as c5,
T495272.DATE_DESC as c6,
T495414.BTN as c7,
T495414.FINAL_RECEIVED_AMOUNT as c8,
T495414.ACCOUNT_NUMBER as c9,
T495414.DISCONNECT_REASON_DESC as c10,
T495414.LIQUIDITY_SCORE as c11,
T495414.STATE as c12,
T495414.REGION_DESCRIPTION as c13,
T495323.LIQUIDITY_SCORE_DESCRIPTION as c14,
T495360.BATCH_STATUS as c15
from
D_DATE T495294 /* D_DATE_CREATED */ ,
F_BATCH T495360 /* F_BATCH_Lscore */ ,
D_LIQUIDITY_SCORE_REASON T495323 /* D_LIQUIDITY_SCORE_REASON_DETAIL */ ,
F_LIQUIDITY_SCORE T495343 /* F_LIQUIDITY_SCORE_DETAIL */ left outer join (
F_PAYMENT_ADJUSTMENT_FINALS T495255 /* F_PAYMENT_ADJUSTMENT_FINALS_LSCORE */ left outer join D_DATE T494961 /* D_DATE_PAYMENT_ADJUSTMENT */ On T494961.DATE_ID = T495255.PAYMENT_ADJUSTMENT_DATE) On T495255.ACCOUNT_ID = T495343.ACCOUNT_ID,
D_DATE T495272 /* D_DATE_BILL_DATE */ ,
T_ACCOUNT_FINALS_DTL T495414 /* T_ACCOUNT_FINALS_DTL_LSCORE */
where ( T495294.DATE_ID = T495360.START_DATE and T495272.DATE_ID = T495414.FINAL_BILL_DATE and T495323.LIQUIDITY_SCORE_ID = T495343.LIQUIDITY_SCORE_REASON_ID and T495343.ACCOUNT_ID = T495414.ACCOUNT_ID and T495294.YEAR_DESC = 'Year 2010' and T495343.LIQUIDITY_SCORE_IMP_BATCH_ID = T495360.SOURCE_BATCH_ID and T495414.REGION_DESCRIPTION = '8-FinalsRM' )
group by T495272.DATE_DESC, T495323.LIQUIDITY_SCORE_DESCRIPTION, T495360.BATCH_STATUS, T495414.ACCOUNT_NUMBER, T495414.BTN, T495414.DISCONNECT_REASON_DESC, T495414.FINAL_RECEIVED_AMOUNT, T495414.LIQUIDITY_SCORE, T495414.RECORDSTATUSIND_DESC, T495414.REGION_DESCRIPTION, T495414.STATE;
explain plan is
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 69M| 14G| | 76473 (1)| 00:15:18 | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10010 | 69M| 14G| | 76473 (1)| 00:15:18 | Q1,10 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 69M| 14G| 15G| 76473 (1)| 00:15:18 | Q1,10 | PCWP | |
| 4 | PX RECEIVE | | 69M| 14G| | 25397 (1)| 00:05:05 | Q1,10 | PCWP | |
| 5 | PX SEND HASH | :TQ10009 | 69M| 14G| | 25397 (1)| 00:05:05 | Q1,09 | P->P | HASH |
|* 6 | HASH JOIN OUTER BUFFERED | | 69M| 14G| | 25397 (1)| 00:05:05 | Q1,09 | PCWP | |
| 7 | PX RECEIVE | | 3648K| 657M| | 20221 (1)| 00:04:03 | Q1,09 | PCWP | |
| 8 | PX SEND HASH | :TQ10007 | 3648K| 657M| | 20221 (1)| 00:04:03 | Q1,07 | P->P | HASH |
|* 9 | HASH JOIN BUFFERED | | 3648K| 657M| | 20221 (1)| 00:04:03 | Q1,07 | PCWP | |
| 10 | PX RECEIVE | | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,07 | PCWP | |
| 11 | PX SEND BROADCAST | :TQ10003 | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | P->P | BROADCAST |
| 12 | PX BLOCK ITERATOR | | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | PCWC | |
| 13 | TABLE ACCESS FULL | D_DATE | 34707 | 779K| | 2 (0)| 00:00:01 | Q1,03 | PCWP | |
|* 14 | HASH JOIN | | 3648K| 577M| | 20218 (1)| 00:04:03 | Q1,07 | PCWP | |
| 15 | BUFFER SORT | | | | | | | Q1,07 | PCWC | |
| 16 | PX RECEIVE | | 10 | 200 | | 3 (0)| 00:00:01 | Q1,07 | PCWP | |
| 17 | PX SEND BROADCAST | :TQ10000 | 10 | 200 | | 3 (0)| 00:00:01 | | S->P | BROADCAST |
| 18 | TABLE ACCESS FULL | D_LIQUIDITY_SCORE_REASON | 10 | 200 | | 3 (0)| 00:00:01 | | | |
|* 19 | HASH JOIN | | 3648K| 507M| | 20214 (1)| 00:04:03 | Q1,07 | PCWP | |
| 20 | PX RECEIVE | | 3649K| 180M| | 331 (3)| 00:00:04 | Q1,07 | PCWP | |
| 21 | PX SEND HASH | :TQ10004 | 3649K| 180M| | 331 (3)| 00:00:04 | Q1,04 | P->P | HASH |
|* 22 | HASH JOIN | | 3649K| 180M| | 331 (3)| 00:00:04 | Q1,04 | PCWP | |
| 23 | PX RECEIVE | | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,04 | PCWP | |
| 24 | PX SEND BROADCAST | :TQ10001 | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,01 | P->P | BROADCAST |
| 25 | PX BLOCK ITERATOR | | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,01 | PCWC | |
|* 26 | TABLE ACCESS FULL | D_DATE | 360 | 5760 | | 2 (0)| 00:00:01 | Q1,01 | PCWP | |
|* 27 | HASH JOIN | | 9431K| 323M| | 328 (2)| 00:00:04 | Q1,04 | PCWP | |
| 28 | PX RECEIVE | | 1975 | 25675 | | 2 (0)| 00:00:01 | Q1,04 | PCWP | |
| 29 | PX SEND BROADCAST | :TQ10002 | 1975 | 25675 | | 2 (0)| 00:00:01 | Q1,02 | P->P | BROADCAST |
| 30 | PX BLOCK ITERATOR | | 1975 | 25675 | | 2 (0)| 00:00:01 | Q1,02 | PCWC | |
| 31 | TABLE ACCESS FULL| F_BATCH | 1975 | 25675 | | 2 (0)| 00:00:01 | Q1,02 | PCWP | |
| 32 | PX BLOCK ITERATOR | | 9431K| 206M| | 324 (2)| 00:00:04 | Q1,04 | PCWC | |
| 33 | TABLE ACCESS FULL | F_LIQUIDITY_SCORE | 9431K| 206M| | 324 (2)| 00:00:04 | Q1,04 | PCWP | |
| 34 | PX RECEIVE | | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,07 | PCWP | |
| 35 | PX SEND HASH | :TQ10005 | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | P->P | HASH |
| 36 | PX BLOCK ITERATOR | | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | PCWC | |
|* 37 | TABLE ACCESS FULL | T_ACCOUNT_FINALS_DTL | 15M| 1346M| | 19880 (1)| 00:03:59 | Q1,05 | PCWP | |
| 38 | PX RECEIVE | | 113M| 3038M| | 5165 (1)| 00:01:02 | Q1,09 | PCWP | |
| 39 | PX SEND HASH | :TQ10008 | 113M| 3038M| | 5165 (1)| 00:01:02 | Q1,08 | P->P | HASH |
| 40 | VIEW | | 113M| 3038M| | 5165 (1)| 00:01:02 | Q1,08 | PCWP | |
|* 41 | HASH JOIN OUTER | | 113M| 3472M| | 5182 (2)| 00:01:03 | Q1,08 | PCWP | |
| 42 | PX BLOCK ITERATOR | | 113M| 1953M| | 5151 (1)| 00:01:02 | Q1,08 | PCWC | |
| 43 | TABLE ACCESS FULL | F_PAYMENT_ADJUSTMENT_FINALS | 113M| 1953M| | 5151 (1)| 00:01:02 | Q1,08 | PCWP | |
| 44 | BUFFER SORT | | | | | | | Q1,08 | PCWC | |
| 45 | PX RECEIVE | | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,08 | PCWP | |
| 46 | PX SEND BROADCAST | :TQ10006 | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | P->P | BROADCAST |
| 47 | PX BLOCK ITERATOR | | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | PCWC | |
| 48 | TABLE ACCESS FULL | D_DATE | 34707 | 474K| | 2 (0)| 00:00:01 | Q1,06 | PCWP | |
it return 19000 row with elapse time 2 mins (before tuning, its 3 minutes and more)
(T_ACCOUNT_FINALS_DTL (51G) AND F_PAYMENT_ADJUSTMENT_FINALS (13G) ARE TWO HUGE TALBES HERE)
Is there better way to tune it??
thanks a lot
Jerry
Edited by: jerrygreat on Jul 13, 2010 2:19 PM
Edited by: jerrygreat on Jul 13, 2010 2:57 PMCan you please (after 414 posts you should know)
a) use the templates to post a tuning question
b) format your code
c) use the tags to make sure identation is preserved.
Other than that: why are you not using the templates and using the tag?
It is minimal effort on your part, and it would take others hours to format the JUNK you are posting everytime!
Sybrand Bakker
Senior Oracle DBA -
Query performance tuning need your suggestions
Hi,
Below is the sql query and explain plan which is taking 2 hours to execute and sometime it is breaking up( erroring out) due to memory issue.
Below it the query which i need to improve the performance of the code please need your suggestion in order to tweak so that time take for execution become less and also in less memory consumption
select a11.DATE_ID DATE_ID,
sum(a11.C_MEASURE) WJXBFS1,
count(a11.PKEY_GUID) WJXBFS2,
count(Case when a11.C_MEASURE <= 10 then a11.PKEY_GUID END) WJXBFS3,
count(Case when a11.STATUS = 'Y' and a11.C_MEASURE > 10 then a11.PKEY_GUID END) WJXBFS4,
count(Case when a11.STATUS = 'N' then a11.PKEY_GUID END) WJXBFS5,
sum(((a11.C_MEASURE ))) WJXBFS6,
a17.DESC_DATE_MM_DD_YYYY DESC_DATE_MM_DD_YYYY,
a11.DNS DNS,
a12.VVALUE VVALUE,
a12.VNAME VNAME,
a13.VVALUE VVALUE0,
a13.VNAME VNAME0,
9 a14.VVALUE VVALUE1,
a14.VNAME VNAME1,
a15.VVALUE VVALUE2,
a15.VNAME VNAME2,
a16.VVALUE VVALUE3,
a16.VNAME VNAME3,
a11.PKEY_GUID PKEY_GUID,
a11.UPKEY_GUID UPKEY_GUID,
a17.DAY_OF_WEEK DAY_OF_WEEK,
a17.D_WEEK D_WEEK,
a17.MNTH_ID DAY_OF_MONTH,
a17.YEAR_ID YEAR_ID,
a17.DESC_YEAR_FULL DESC_YEAR_FULL,
a17.WEEK_ID WEEK_ID,
a17.WEEK_OF_YEAR WEEK_OF_YEAR
from ACTIVITY_F a11
join (SELECT A.ORG as ORG,
A.DATE_ID as DATE_ID,
A.TIME_OF_DAY_ID as TIME_OF_DAY_ID,
A.DATE_HOUR_ID as DATE_HOUR_ID,
A.TASK as TASK,
A.PKEY_GUID as PKEY_GUID,
A.VNAME as VNAME,
A.VVALUE as VVALUE
FROM W_ORG_D A join W_PERSON_D B on
(A.TASK = B.TASK AND A.ORG = B.ID
AND A.VNAME = B.VNAME)
WHERE B.VARIABLE_OBJ = 1 ) a12
on (a11.PKEY_GUID = a12.PKEY_GUID and
a11.DATE_ID = a12.DATE_ID and
a11.ORG = a12.ORG)
join (SELECT A.ORG as ORG,
A.DATE_ID as DATE_ID,
A.TIME_OF_DAY_ID as TIME_OF_DAY_ID,
A.DATE_HOUR_ID as DATE_HOUR_ID,
A.TASK as TASK,
A.PKEY_GUID as PKEY_GUID,
A.VNAME as VNAME,
A.VVALUE as VVALUE
FROM W_ORG_D A join W_PERSON_D B on
(A.TASK = B.TASK AND A.ORG = B.ID
AND A.VNAME = B.VNAME)
WHERE B.VARIABLE_OBJ = 2) a13
on (a11.PKEY_GUID = a13.PKEY_GUID and
a11.DATE_ID = a13.DATE_ID and
a11.ORG = a13.ORG)
join (SELECT A.ORG as ORG,
A.DATE_ID as DATE_ID,
A.TIME_OF_DAY_ID as TIME_OF_DAY_ID,
A.DATE_HOUR_ID as DATE_HOUR_ID,
A.TASK as TASK,
A.PKEY_GUID as PKEY_GUID,
A.VNAME as VNAME,
A.VVALUE as VVALUE
FROM W_ORG_D A join W_PERSON_D B on
(A.TASK = B.TASK AND A.ORG = B.ID
AND A.VNAME = B.VNAME)
WHERE B.VARIABLE_OBJ = 3 ) a14
on (a11.PKEY_GUID = a14.PKEY_GUID and
a11.DATE_ID = a14.DATE_ID and
a11.ORG = a14.ORG)
join (SELECT A.ORG as ORG,
A.DATE_ID as DATE_ID,
A.TIME_OF_DAY_ID as TIME_OF_DAY_ID,
A.DATE_HOUR_ID as DATE_HOUR_ID,
A.TASK as TASK,
A.PKEY_GUID as PKEY_GUID,
A.VNAME as VNAME,
A.VVALUE as VVALUE
FROM W_ORG_D A join W_PERSON_D B on
(A.TASK = B.TASK AND A.ORG = B.ID
AND A.VNAME = B.VNAME)
WHERE B.VARIABLE_OBJ = 4) a15
on (a11.PKEY_GUID = a15.PKEY_GUID and
89 a11.DATE_ID = a15.DATE_ID and
a11.ORG = a15.ORG)
join (SELECT A.ORG as ORG,
A.DATE_ID as DATE_ID,
A.TIME_OF_DAY_ID as TIME_OF_DAY_ID,
A.DATE_HOUR_ID as DATE_HOUR_ID,
A.TASK as TASK,
A.PKEY_GUID as PKEY_GUID,
A.VNAME as VNAME,
A.VVALUE as VVALUE
FROM W_ORG_D A join W_PERSON_D B on
(A.TASK = B.TASK AND A.ORG = B.ID
AND A.VNAME = B.VNAME)
WHERE B.VARIABLE_OBJ = 9) a16
on (a11.PKEY_GUID = a16.PKEY_GUID and
a11.DATE_ID = a16.DATE_ID and
A11.ORG = A16.ORG)
join W_DATE_D a17
ON (A11.DATE_ID = A17.ID)
join W_SALES_D a18
on (a11.TASK = a18.ID)
where (a17.TIMSTAMP between To_Date('2001-02-24 00:00:00', 'YYYY-MM-DD HH24:MI:SS') and To_Date('2002-09-12 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
and a11.ORG in (12)
and a18.SRC_TASK = 'AX012Z')
group by a11.DATE_ID,
a17.DESC_DATE_MM_DD_YYYY,
a11.DNS,
a12.VVALUE,
a12.VNAME,
a13.VVALUE,
a13.VNAME,
a14.VVALUE,
a14.VNAME,
a15.VVALUE,
a15.VNAME,
a16.VVALUE,
a16.VNAME,
a11.PKEY_GUID,
a11.UPKEY_GUID,
a17.DAY_OF_WEEK,
a17.D_WEEK,
a17.MNTH_ID,
a17.YEAR_ID,
a17.DESC_YEAR_FULL,
a17.WEEK_ID,
a17.WEEK_OF_YEAR;
Explained.
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 1245 | 47 (9)| 00:00:01 |
| 1 | HASH GROUP BY | | 1 | 1245 | 47 (9)| 00:00:01 |
|* 2 | HASH JOIN | | 1 | 1245 | 46 (7)| 00:00:01 |
|* 3 | HASH JOIN | | 1 | 1179 | 41 (5)| 00:00:01 |
|* 4 | HASH JOIN | | 1 | 1113 | 37 (6)| 00:00:01 |
|* 5 | HASH JOIN | | 1 | 1047 | 32 (4)| 00:00:01 |
|* 6 | HASH JOIN | | 1 | 981 | 28 (4)| 00:00:01 |
| 7 | NESTED LOOPS | | 1 | 915 | 23 (0)| 00:00:01 |
| 8 | NESTED LOOPS | | 1 | 763 | 20 (0)| 00:00:01 |
| 9 | NESTED LOOPS | | 1 | 611 | 17 (0)| 00:00:01 |
| 10 | NESTED LOOPS | | 1 | 459 | 14 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 1 | 307 | 11 (0)| 00:00:01 |
| 12 | NESTED LOOPS | | 1 | 155 | 7 (0)| 00:00:01 |
| 13 | NESTED LOOPS | | 1 | 72 | 3 (0)| 00:00:01 |
| 14 | TABLE ACCESS BY INDEX ROWID| W_SALES_D | 1 | 13 | 2 (0)| 00:00:01 |
|* 15 | INDEX UNIQUE SCAN | CONS_UNQ_W_SALES_D_SRC_ID | 1 | | 1 (0)| 00:00:01 |
| 16 | TABLE ACCESS BY INDEX ROWID| W_DATE_D | 1 | 59 | 1 (0)| 00:00:01 |
|* 17 | INDEX UNIQUE SCAN | UIDX_DD_TIMSTAMP | 1 | | 0 (0)| 00:00:01 |
| 18 | TABLE ACCESS BY INDEX ROWID | ACTIVITY_F | 1 | 83 | 4 (0)| 00:00:01 |
|* 19 | INDEX RANGE SCAN | PK_ACTIVITY_F | 1 | | 3 (0)| 00:00:01 |
|* 20 | TABLE ACCESS BY INDEX ROWID | W_ORG_D | 1 | 152 | 4 (0)| 00:00:01 |
|* 21 | INDEX RANGE SCAN | IDX_FK_CVSF_PKEY_GUID | 10 | | 3 (0)| 00:00:01 |
|* 22 | TABLE ACCESS BY INDEX ROWID | W_ORG_D | 1 | 152 | 3 (0)| 00:00:01 |
|* 23 | INDEX RANGE SCAN | IDX_FK_CVSF_PKEY_GUID | 10 | | 3 (0)| 00:00:01 |
|* 24 | TABLE ACCESS BY INDEX ROWID | W_ORG_D | 1 | 152 | 3 (0)| 00:00:01 |
|* 25 | INDEX RANGE SCAN | IDX_FK_CVSF_PKEY_GUID | 10 | | 3 (0)| 00:00:01 |
|* 26 | TABLE ACCESS BY INDEX ROWID | W_ORG_D | 1 | 152 | 3 (0)| 00:00:01 |
|* 27 | INDEX RANGE SCAN | IDX_FK_CVSF_PKEY_GUID | 10 | | 3 (0)| 00:00:01 |
|* 28 | TABLE ACCESS BY INDEX ROWID | W_ORG_D | 1 | 152 | 3 (0)| 00:00:01 |
|* 29 | INDEX RANGE SCAN | IDX_FK_CVSF_PKEY_GUID | 10 | | 3 (0)| 00:00:01 |
|* 30 | TABLE ACCESS FULL | W_PERSON_D | 1 | 66 | 4 (0)| 00:00:01 |
|* 31 | TABLE ACCESS FULL | W_PERSON_D | 1 | 66 | 4 (0)| 00:00:01 |
|* 32 | TABLE ACCESS FULL | W_PERSON_D | 1 | 66 | 4 (0)| 00:00:01 |
|* 33 | TABLE ACCESS FULL | W_PERSON_D | 1 | 66 | 4 (0)| 00:00:01 |
|* 34 | TABLE ACCESS FULL | W_PERSON_D | 1 | 66 | 4 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------------------------------------Hi,
I'm not a tuning expert but I can suggest you to post your request according to this template:
Thread: HOW TO: Post a SQL statement tuning request - template posting
HOW TO: Post a SQL statement tuning request - template posting
Then:
a) you should posting a code which is easy to read. What about formatting? Your code had to be fixed in a couple of lines.
b) You could simplify your code using the with statement. This has nothing to do with the tuning but it will help the readability of the query.
Check it below:
WITH tab1 AS (SELECT a.org AS org
, a.date_id AS date_id
, a.time_of_day_id AS time_of_day_id
, a.date_hour_id AS date_hour_id
, a.task AS task
, a.pkey_guid AS pkey_guid
, a.vname AS vname
, a.vvalue AS vvalue
, b.variable_obj
FROM w_org_d a
JOIN
w_person_d b
ON ( a.task = b.task
AND a.org = b.id
AND a.vname = b.vname))
SELECT a11.date_id date_id
, SUM (a11.c_measure) wjxbfs1
, COUNT (a11.pkey_guid) wjxbfs2
, COUNT (CASE WHEN a11.c_measure <= 10 THEN a11.pkey_guid END) wjxbfs3
, COUNT (CASE WHEN a11.status = 'Y' AND a11.c_measure > 10 THEN a11.pkey_guid END) wjxbfs4
, COUNT (CASE WHEN a11.status = 'N' THEN a11.pkey_guid END) wjxbfs5
, SUM ( ( (a11.c_measure))) wjxbfs6
, a17.desc_date_mm_dd_yyyy desc_date_mm_dd_yyyy
, a11.dns dns
, a12.vvalue vvalue
, a12.vname vname
, a13.vvalue vvalue0
, a13.vname vname0
, a14.vvalue vvalue1
, a14.vname vname1
, a15.vvalue vvalue2
, a15.vname vname2
, a16.vvalue vvalue3
, a16.vname vname3
, a11.pkey_guid pkey_guid
, a11.upkey_guid upkey_guid
, a17.day_of_week day_of_week
, a17.d_week d_week
, a17.mnth_id day_of_month
, a17.year_id year_id
, a17.desc_year_full desc_year_full
, a17.week_id week_id
, a17.week_of_year week_of_year
FROM activity_f a11
JOIN tab1 a12
ON ( a11.pkey_guid = a12.pkey_guid
AND a11.date_id = a12.date_id
AND a11.org = a12.org
AND a12.variable_obj = 1)
JOIN tab1 a13
ON ( a11.pkey_guid = a13.pkey_guid
AND a11.date_id = a13.date_id
AND a11.org = a13.org
AND a13.variable_obj = 2)
JOIN tab1 a14
ON ( a11.pkey_guid = a14.pkey_guid
AND a11.date_id = a14.date_id
AND a11.org = a14.org
AND a14.variable_obj = 3)
JOIN tab1 a15
ON ( a11.pkey_guid = a15.pkey_guid
AND a11.date_id = a15.date_id
AND a11.org = a15.org
AND a15.variable_obj = 4)
JOIN tab1 a16
ON ( a11.pkey_guid = a16.pkey_guid
AND a11.date_id = a16.date_id
AND a11.org = a16.org
AND a16.variable_obj = 9)
JOIN w_date_d a17
ON (a11.date_id = a17.id)
JOIN w_sales_d a18
ON (a11.task = a18.id)
WHERE (a17.timstamp BETWEEN TO_DATE ('2001-02-24 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
AND TO_DATE ('2002-09-12 00:00:00', 'YYYY-MM-DD HH24:MI:SS')
AND a11.org IN (12)
AND a18.src_task = 'AX012Z')
GROUP BY a11.date_id, a17.desc_date_mm_dd_yyyy, a11.dns, a12.vvalue
, a12.vname, a13.vvalue, a13.vname, a14.vvalue
, a14.vname, a15.vvalue, a15.vname, a16.vvalue
, a16.vname, a11.pkey_guid, a11.upkey_guid, a17.day_of_week
, a17.d_week, a17.mnth_id, a17.year_id, a17.desc_year_full
, a17.week_id, a17.week_of_year;
{code}
I hope I did not miss anything while reformatting the code. I could not test it not having the proper tables.
As I said before I'm not a tuning expert nor I pretend to be but I see this:
1) Table W_PERSON_D is read in full scan. Any possibility of using indexes?
2) Tables W_SALES_D, W_DATE_D, ACTIVITY_F and W_ORG_D have TABLE ACCESS BY INDEX ROWID which definitely is not fast.
You should provide additional information for tuning your query checking the post I mentioned previously.
Regards.
Al -
Query Performance tuning and scope of imporvement
Hi All ,
I am on oracle 10g and on Linux OS.
I have this below query which I am trying to optimise :
SELECT 'COMPANY' AS device_brand, mach_sn AS device_source_id,
'COMPANY' AS device_brand_raw,
CASE
WHEN fdi.serial_number IS NOT NULL THEN
fdi.serial_number
ELSE
mach_sn || model_no
END AS serial_number_raw,
gmd.generic_meter_name AS counter_id,
meter_name AS counter_id_raw,
meter_value AS counter_value,
meter_hist_tstamp AS device_timestamp,
rcvd_tstamp AS server_timestamp
FROM rdw.v_meter_hist vmh
JOIN rdw.generic_meter_def gmd
ON vmh.generic_meter_id = gmd.generic_meter_id
LEFT OUTER JOIN fdr.device_info fdi
ON vmh.mach_sn = fdi.clean_serial_number
WHERE meter_hist_id IN
(SELECT /*+ PUSH_SUBQ */ MAX(meter_hist_id)
FROM rdw.v_meter_hist
WHERE vmh.mach_sn IN
('URR893727')
AND vmh.meter_name IN
('TotalImpressions','TotalBlackImpressions''TotalColorImpressions')
AND vmh.meter_hist_tstamp >=to_date ('04/16/2011', 'mm/dd/yyyy')
AND vmh.meter_hist_tstamp <= to_date ('04/18/2011', 'mm/dd/yyyy')
GROUP BY mach_sn, vmh.meter_def_id)
ORDER BY device_source_id, vmh.meter_def_id, meter_hist_tstamp;Earlier , it was taking too much time but it started to work faster when i added this :
/*+ PUSH_SUBQ */ in the select query.
The explain plan generated for the same is :
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 29M| 3804M| | 15M (4)| 53:14:08 |
| 1 | SORT ORDER BY | | 29M| 3804M| 8272M| 15M (4)| 53:14:08 |
|* 2 | FILTER | | | | | | |
|* 3 | HASH JOIN | | 29M| 3804M| | 8451K (2)| 28:10:19 |
| 4 | TABLE ACCESS FULL | GENERIC_METER_DEF | 11 | 264 | | 3 (0)| 00:00:01 |
|* 5 | HASH JOIN RIGHT OUTER| | 29M| 3137M| 19M| 8451K (2)| 28:10:17 |
| 6 | TABLE ACCESS FULL | DEVICE_INFO | 589K| 12M| | 799 (2)| 00:00:10 |
|* 7 | HASH JOIN | | 29M| 2527M| 2348M| 8307K (2)| 27:41:29 |
|* 8 | HASH JOIN | | 28M| 2016M| | 6331K (2)| 21:06:19 |
|* 9 | TABLE ACCESS FULL | METER_DEF | 33 | 990 | | 4 (0)| 00:00:01 |
| 10 | TABLE ACCESS FULL | METER_HIST | 3440M| 137G| | 6308K (2)| 21:01:44 |
| 11 | TABLE ACCESS FULL | MACH_XFER_HIST | 436M| 7501M| | 1233K (1)| 04:06:41 |
|* 12 | FILTER | | | | | | |
| 13 | HASH GROUP BY | | 1 | 26 | | 6631K (7)| 22:06:15 |
|* 14 | FILTER | | | | | | |
| 15 | TABLE ACCESS FULL | METER_HIST | 3440M| 83G| | 6304K (2)| 21:00:49 |
------------------------------------------------------------------------------------------------------Is there any other way to optimise it more ... PLease suggest since I am new to query tuning.
Thanks and Regards
KKHi Dom ,
Greetings. Sorry for the delayed response. I have read the How to Post document.
I will provide all the required information here now :
Version : 10.2.0.4
OS : LinuxThe SQL Query which is facing the performance issue :
SELECT mh.meter_hist_id, mxh.mach_sn, mxh.collectiontag, mxh.rcvd_tstamp,
mxh.mach_xfer_id, md.meter_def_id, md.meter_name, md.meter_type,
md.meter_units, md.meter_desc, mh.meter_value, mh.meter_hist_tstamp,
mh.max_value, md.generic_meter_id
FROM meter_hist mh JOIN mach_xfer_hist mxh
ON mxh.mach_xfer_id = mh.mach_xfer_id
JOIN meter_def md ON md.meter_def_id = mh.meter_def_id;Explain plan for this query :
Plan hash value: 1878059220
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 3424M| 497G| | 17M (1)| 56:42:49 |
|* 1 | HASH JOIN | | 3424M| 497G| | 17M (1)| 56:42:49 |
| 2 | TABLE ACCESS FULL | METER_DEF | 423 | 27918 | | 4 | 00:00:01 |
|* 3 | HASH JOIN | | 3424M| 287G| 26G| 16M (1)| 56:38:16 |
| 4 | TABLE ACCESS FULL| MACH_XFER_HIST | 432M| 21G| | 1233K (1)| 04:06:40 |
| 5 | TABLE ACCESS FULL| METER_HIST | 3438M| 115G| | 6299K (2)| 20:59:54 |
Predicate Information (identified by operation id):
1 - access("MD"."METER_DEF_ID"="MH"."METER_DEF_ID")
3 - access("MH"."MACH_XFER_ID"="MXH"."MACH_XFER_ID")Parameters :
show parameter optimizer
NAME TYPE VALUE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 10.2.0.4
optimizer_index_caching integer 70
optimizer_index_cost_adj integer 50
optimizer_mode string ALL_ROWS
optimizer_secure_view_merging boolean TRUEshow parameter db_file_multi
db_file_multiblock_read_count integer 8
show parameter cursor_sharing
NAME TYPE VALUE
cursor_sharing string EXACT
select sname , pname , pval1 , pval2 from sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 07-12-2011 09:22
SYSSTATS_INFO DSTOP 07-12-2011 09:52
SYSSTATS_INFO FLAGS 0
SYSSTATS_MAIN CPUSPEEDNW 1153.92254
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM 4.398
SYSSTATS_MAIN MREADTIM 3.255
SYSSTATS_MAIN CPUSPEED 180
SYSSTATS_MAIN MBRC 8
SYSSTATS_MAIN MAXTHR 244841472
SYSSTATS_MAIN SLAVETHR 933888
show parameter db_block_size
NAME TYPE VALUE
db_block_size integer 8192Please let me me if any other information is needed. This Query is currently taking almost one hour to run right now.
Also , we have two indexes on the columns : xfer_id and meter_def_id in both the tables , but its not getting used without any filtering ( Where clause).
Do addition of hint in the query above will be of some help.
Thanks and Regards
KK -
Complex Query which needs tuning
Hello :
I have a complex query that needs to be tuned. I have little experience in tuning the sql and hence taking the help of your guys.
The Query is as given below:
Database version 11g
SELECT DISTINCT P.RESPONSIBILITY, P.PRODUCT_MAJOR, P.PRODUCT_MINOR,
P.PRODUCT_SERIES, P.PRODUCT_CATEGORY AS Category1, SO.REGION_CODE,
SO.STORE_CODE, S.Store_Name, SOL.PRODUCT_CODE, PRI.REPLENISHMENT_TYPE,
PRI.SUPPLIER_CODE,
SOL.SOLD_WITH_NIC, SOL.SUGGESTED_PRICE,
PRI.INVOICE_COST, SOL.FIFO_COST,
SO.ORDER_TYPE_CODE, SOL.DOCUMENT_NUM,
SOS.SLSP_CD, '' AS FNAME, '' AS LNAME,
SOL.PRICE_EXCEPTION_CODE, SOL.AS_IS,
SOL.STATUS_DATE,
Sum(SOL.QUANTITY) AS SumOfQUANTITY,
Sum(SOL.EXTENDED_PRICE) AS SumOfEXTENDED_PRICE
--Format([SALES_ORDER].[STATUS_DATE],"mmm-yy") AS [Month]
FROM PRODUCT P,
PRODUCT_MAJORS PM,
SALES_ORDER_LINE SOL,
STORE S,
SALES_ORDER SO,
SALES_ORDER_SPLITS SOS,
PRODUCT_REGIONAL_INFO PRI,
REGION_MAP R
WHERE P.product_major = PM.PRODUCT_MAJOR
and SOL.PRODUCT_CODE = P.PRODUCT_CODE
and SO.STORE_CODE = S.STORE_CODE
AND SO.REGION_CODE = S.REGION_CODE
AND SOL.REGION_CODE = SO.REGION_CODE
AND SOL.DOCUMENT_NUM = SO.DOCUMENT_NUM
AND SOL.DELIVERY_SEQUENCE_NUM = SO.DELIVERY_SEQUENCE_NUM
AND SOL.STATUS_CODE = SO.STATUS_CODE
AND SOL.STATUS_DATE = SO.STATUS_DATE
AND SO.REGION_CODE = SOS.REGION_CODE
AND SO.DOCUMENT_NUM = SOS.DOCUMENT_NUM
AND SOL.PRODUCT_CODE = PRI.PRODUCT_CODE
AND PRI.REGION_CODE = R.CORP_REGION_CODE
AND SO.REGION_CODE = R.DS_REGION_CODE
AND P.PRODUCT_MAJOR In ('STEREO','TELEVISION','VIDEO')
AND SOL.STATUS_CODE = 'D'
AND SOL.STATUS_DATE BETWEEN '01-JUN-09' AND '30-JUN-09'
AND SO.STORE_CODE NOT IN
('10','20','30','40','70','91','95','93','94','96','97','98','99',
'9V','9W','9X','9Y','9Z','8Z',
'8Y','92','CZ','FR','FS','FT','FZ','FY','FX','FW','FV','GZ','GY','GU','GW','GV','GX')
GROUP BY
P.RESPONSIBILITY, P.PRODUCT_MAJOR, P.PRODUCT_MINOR, P.PRODUCT_SERIES, P.PRODUCT_CATEGORY,
SO.REGION_CODE, SO.STORE_CODE, /*S.Short Name, */
S.Store_Name, SOL.PRODUCT_CODE,
PRI.REPLENISHMENT_TYPE, PRI.SUPPLIER_CODE,
SOL.SOLD_WITH_NIC, SOL.SUGGESTED_PRICE, PRI.INVOICE_COST,
SOL.FIFO_COST, SO.ORDER_TYPE_CODE, SOL.DOCUMENT_NUM,
SOS.SLSP_CD, '', '', SOL.PRICE_EXCEPTION_CODE,
SOL.AS_IS, SOL.STATUS_DATE
Explain Plan:
SELECT STATEMENT, GOAL = ALL_ROWS Cost=583 Cardinality=1 Bytes=253
HASH GROUP BY Cost=583 Cardinality=1 Bytes=253
FILTER
NESTED LOOPS Cost=583 Cardinality=1 Bytes=253
HASH JOIN OUTER Cost=582 Cardinality=1 Bytes=234
NESTED LOOPS
NESTED LOOPS Cost=571 Cardinality=1 Bytes=229
NESTED LOOPS Cost=571 Cardinality=1 Bytes=207
NESTED LOOPS Cost=569 Cardinality=2 Bytes=368
NESTED LOOPS Cost=568 Cardinality=2 Bytes=360
NESTED LOOPS Cost=556 Cardinality=3 Bytes=435
NESTED LOOPS Cost=178 Cardinality=4 Bytes=336
NESTED LOOPS Cost=7 Cardinality=1 Bytes=49
HASH JOIN Cost=7 Cardinality=1 Bytes=39
VIEW Object owner=CORP Object name=index$_join$_015 Cost=2 Cardinality=3 Bytes=57
HASH JOIN
INLIST ITERATOR
INDEX UNIQUE SCAN Object owner=CORP Object name=PRODMJR_PK Cost=0 Cardinality=3 Bytes=57
INDEX FAST FULL SCAN Object owner=CORP Object name=PRDMJR_PR_FK_I Cost=1 Cardinality=3 Bytes=57
VIEW Object owner=CORP Object name=index$_join$_016 Cost=4 Cardinality=37 Bytes=740
HASH JOIN
INLIST ITERATOR
INDEX RANGE SCAN Object owner=CORP Object name=PRDMNR1 Cost=3 Cardinality=37 Bytes=740
INDEX FAST FULL SCAN Object owner=CORP Object name=PRDMNR_PK Cost=4 Cardinality=37 Bytes=740
INDEX UNIQUE SCAN Object owner=CORP Object name=PRODMJR_PK Cost=0 Cardinality=1 Bytes=10
MAT_VIEW ACCESS BY INDEX ROWID Object owner=CORP Object name=PRODUCTS Cost=171 Cardinality=480 Bytes=16800
INDEX RANGE SCAN Object owner=CORP Object name=PRD2 Cost=3 Cardinality=681
TABLE ACCESS BY INDEX ROWID Object owner=DS Object name=SALES_ORDER_LINE Cost=556 Cardinality=1 Bytes=145
BITMAP CONVERSION TO ROWIDS
BITMAP INDEX SINGLE VALUE Object owner=DS Object name=SOL2
TABLE ACCESS BY INDEX ROWID Object owner=DS Object name=SALES_ORDER Cost=4 Cardinality=1 Bytes=35
INDEX RANGE SCAN Object owner=DS Object name=SO1 Cost=3 Cardinality=1
TABLE ACCESS BY INDEX ROWID Object owner=DS Object name=REGION_MAP Cost=1 Cardinality=1 Bytes=4
INDEX RANGE SCAN Object owner=DS Object name=REGCD Cost=0 Cardinality=1
MAT_VIEW ACCESS BY INDEX ROWID Object owner=CORP Object name=PRODUCT_REGIONAL_INFO Cost=2 Cardinality=1 Bytes=23
INDEX UNIQUE SCAN Object owner=CORP Object name=PRDRI_PK Cost=1 Cardinality=1
INDEX UNIQUE SCAN Object owner=CORP Object name=BI_STORE_INFO_PK Cost=0 Cardinality=1
MAT_VIEW ACCESS BY INDEX ROWID Object owner=CORP Object name=BI_STORE_INFO Cost=1 Cardinality=1 Bytes=22
VIEW Object owner=DS cost=11 Cardinality=342 Bytes=1710
HASH JOIN Cost=11 Cardinality=342 Bytes=7866
MAT_VIEW ACCESS FULL Object owner=CORP Object name=STORE_CORP Cost=5 Cardinality=429 Bytes=3003
NESTED LOOPS Cost=5 Cardinality=478 Bytes=7648
MAT_VIEW ACCESS FULL Object owner=CORP Object name=STORE_GROUP Cost=5 Cardinality=478 Bytes=5258
INDEX UNIQUE SCAN Object owner=CORP Object name=STORE_REGIONAL_INFO_PK Cost=0 Cardinality=1 Bytes=5
INDEX RANGE SCAN Object owner=DS Object name=SOS_PK Cost=2 Cardinality=1 Bytes=19
Regards,
BMPFirst thing that i notice in this query is you are Using Distinct as well as Group by.
Your group by will always give you distinct results ,then again why do you need the Distinct?
For example
WITH t AS
(SELECT 'clm1' col1, 'contract1' col2,10 value
FROM DUAL
UNION ALL
SELECT 'clm1' , 'contract1' ,10 value
FROM DUAL
UNION ALL
SELECT 'clm1', 'contract2',10
FROM DUAL
UNION ALL
SELECT 'clm2', 'contract1',10
FROM DUAL
UNION ALL
SELECT 'clm3', 'contract1',10
FROM DUAL
UNION ALL
SELECT 'clm4', 'contract2',10
FROM DUAL)
SELECT distinct col1,col2,sum(value) from t
group by col1,col2Is always same as
WITH t AS
(SELECT 'clm1' col1, 'contract1' col2,10 value
FROM DUAL
UNION ALL
SELECT 'clm1' , 'contract1' ,10 value
FROM DUAL
UNION ALL
SELECT 'clm1', 'contract2',10
FROM DUAL
UNION ALL
SELECT 'clm2', 'contract1',10
FROM DUAL
UNION ALL
SELECT 'clm3', 'contract1',10
FROM DUAL
UNION ALL
SELECT 'clm4', 'contract2',10
FROM DUAL)
SELECT col1,col2,sum(value) from t
group by col1,col2And also
AND SOL.STATUS_DATE BETWEEN '01-JUN-09' AND '30-JUN-09'It would be best to use a to_date when hard coding your dates.
Edited by: user5495111 on Aug 6, 2009 1:32 PM
Maybe you are looking for
-
Spaces disappear from folder name when opened thrugh Web Client
Hi, I am opening a pdf or word document through method EXECUTE of class CL_GUI_FRONTEND_SERVICES. Now if there are more than one space in the path (ex. D:tes t.pdf ) then file gets opened sucessfully if I log in through WIN client in SAP. But if i
-
How to add rows in table control for data recording BDC?
hello, pl tell me the way to upload data through BDC in table control of screen . how to add fields inrecording of table control? Please give some code in this regard. I am generous in giving points..pl help!
-
Sleep blocked by "active remote client"
Using powercfg -requests I get: [DRIVER] Filesystem\srvnet An active remote client has recently sent requests to this machine This blocks sleep mode (a "feature" of sleep mode). I have tried disabling wake for sleep on adaptors. Disabling home group
-
People, I have uninstalled scribus 1.16 and downloaded and installed the scribus 1.17.pkg.tar.gz But trying to execute it, the following message appears: error while loading shared libraries libssl.so.0.9.7 Cannot open shared object file. No such fil
-
I have a canon rebel T5i and all my functions not work, like black and white etc.
Haven't used the camera for about 5 weeks and now I'm on vacation and my functions don't work. First I thought it was just the black and white function but I have tried them all. I can take the picture but it doesn't save it. I saves all other pictur