Hash group by improvement
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
20396407
So 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>
Similar Messages
-
'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+ -
Wouldn't it be great to have a really good explaining groups wiki-page?
I know of that page which already is there, but it doesn't really provide enough information.
I had a look at the gentoo-wiki groups page, and it provides even less information than the arch-wiki.
What I want is better explanation of each group, (ie. why a specific group exists) and why you should, or should not be a member of this group.
I myself have more groups than those listed in the wiki, and as a linux n00b, bareley starting with arch, (ubuntu is not for me, and gentoo is too hard)
a good explanation would be helpful in both solving problems, and gaining an understanding of how *nix systems work.
I have myself tried to figure out about groups, (yes, using google too) but ended up giving up, and just moving on without solving whatever it was I set out to solve.
this is kind of like the other thread where one asked for informations about the xorg modules, but I want information about groups, and in the wiki too
KristofferIts a good idea... if you've been doing some research so far, just put what information you know into the existing wiki page. Then you can add to it as you find more resources here, on google, in man pages, or elsewhere, and other users can add their knowledge as well.
Dusty -
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.
thanksuser9074365 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+ -
Query Degradation--Hash Join Degraded
Hi All,
I found one query degradation issue.I am on 10.2.0.3.0 (Sun OS) with optimizer_mode=ALL_ROWS.
This is a dataware house db.
All 3 tables involved are parition tables (with daily partitions).Partitions are created in advance and ELT jobs loads bulk data into daily partitions.
I have checked that CBO is not using local indexes-created on them which i believe,is appropriate because when i used INDEX HINT, elapsed time increses.
I checked giving index hint for all tables one by one but dint get any performance improvement.
Partitions are daily loaded and after loading,partition-level stats are gathered with dbms_stats.
We are collecting stats at partition level(granularity=>'PARTITION').Even after collecting global stats,there is no change in access pattern.Stats gather command is given below.
PROCEDURE gather_table_part_stats(i_owner_name,i_table_name,i_part_name,i_estimate:= DBMS_STATS.AUTO_SAMPLE_SIZE, i_invalidate IN VARCHAR2 := 'Y',i_debug:= 'N')
Only SOT_KEYMAP.IPK_SOT_KEYMAP is GLOBAL.Rest all indexes are LOCAL.
Earlier,we were having BIND PEEKING issue,which i fixed but introducing NO_INVALIDATE=>FALSE in stats gather job.
Here,Partition_name (20090219) is being passed through bind variables.
SELECT a.sotrelstg_sot_ud sotcrct_sot_ud,
b.sotkey_ud sotcrct_orig_sot_ud, a.ROWID stage_rowid
FROM (SELECT sotrelstg_sot_ud, sotrelstg_sys_ud,
sotrelstg_orig_sys_ord_id, sotrelstg_orig_sys_ord_vseq
FROM sot_rel_stage
WHERE sotrelstg_trd_date_ymd_part = '20090219'
AND sotrelstg_crct_proc_stat_cd = 'N'
AND sotrelstg_sot_ud NOT IN(
SELECT sotcrct_sot_ud
FROM sot_correct
WHERE sotcrct_trd_date_ymd_part ='20090219')) a,
(SELECT MAX(sotkey_ud) sotkey_ud, sotkey_sys_ud,
sotkey_sys_ord_id, sotkey_sys_ord_vseq,
sotkey_trd_date_ymd_part
FROM sot_keymap
WHERE sotkey_trd_date_ymd_part = '20090219'
AND sotkey_iud_cd = 'I'
--not to select logical deleted rows
GROUP BY sotkey_trd_date_ymd_part,
sotkey_sys_ud,
sotkey_sys_ord_id,
sotkey_sys_ord_vseq) b
WHERE a.sotrelstg_sys_ud = b.sotkey_sys_ud
AND a.sotrelstg_orig_sys_ord_id = b.sotkey_sys_ord_id
AND NVL(a.sotrelstg_orig_sys_ord_vseq, 1) = NVL(b.sotkey_sys_ord_vseq, 1);
During normal business hr, i found that query takes 5-7 min(which is also not acceptable), but during high load business hr,it is taking 30-50 min.
I found that most of the time it is spending on HASH JOIN (direct path write temp).We have sufficient RAM (64 GB total/41 GB available).
Below is the execution plan i got during normal business hr.
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | Writes | OMem | 1Mem | Used-Mem | Used-Tmp|
| 1 | HASH GROUP BY | | 1 | 1 | 7844K|00:05:28.78 | 16M| 217K| 35969 | | | | |
|* 2 | HASH JOIN | | 1 | 1 | 9977K|00:04:34.02 | 16M| 202K| 20779 | 580M| 10M| 563M (1)| 650K|
| 3 | NESTED LOOPS ANTI | | 1 | 6 | 7855K|00:01:26.41 | 16M| 1149 | 0 | | | | |
| 4 | PARTITION RANGE SINGLE| | 1 | 258K| 8183K|00:00:16.37 | 25576 | 1149 | 0 | | | | |
|* 5 | TABLE ACCESS FULL | SOT_REL_STAGE | 1 | 258K| 8183K|00:00:16.37 | 25576 | 1149 | 0 | | | | |
| 6 | PARTITION RANGE SINGLE| | 8183K| 326K| 327K|00:01:10.53 | 16M| 0 | 0 | | | | |
|* 7 | INDEX RANGE SCAN | IDXL_SOTCRCT_SOT_UD | 8183K| 326K| 327K|00:00:53.37 | 16M| 0 | 0 | | | | |
| 8 | PARTITION RANGE SINGLE | | 1 | 846K| 14M|00:02:06.36 | 289K| 180K| 0 | | | | |
|* 9 | TABLE ACCESS FULL | SOT_KEYMAP | 1 | 846K| 14M|00:01:52.32 | 289K| 180K| 0 | | | | |
I will attached the same for high load business hr once query gives results.It is still executing for last 50 mins.
INDEX STATS (INDEXES ARE LOCAL INDEXES)
TABLE_NAME INDEX_NAME COLUMN_NAME COLUMN_POSITION NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
SOT_REL_STAGE IDXL_SOTRELSTG_SOT_UD SOTRELSTG_SOT_UD 1 25461560 25461560 184180
SOT_REL_STAGE SOTRELSTG_TRD_DATE 2 25461560 25461560 184180
_YMD_PART
TABLE_NAME INDEX_NAME COLUMN_NAME COLUMN_POSITION NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
SOT_KEYMAP IDXL_SOTKEY_ENTORDSYS_UD SOTKEY_ENTRY_ORD_S 1 1012306940 3 38308680
YS_UD
SOT_KEYMAP IDXL_SOTKEY_HASH SOTKEY_HASH 1 1049582320 1049582320 1049579520
SOT_KEYMAP SOTKEY_TRD_DATE_YM 2 1049582320 1049582320 1049579520
D_PART
SOT_KEYMAP IDXL_SOTKEY_SOM_ORD SOTKEY_SOM_UD 1 1023998560 268949136 559414840
SOT_KEYMAP SOTKEY_SYS_ORD_ID 2 1023998560 268949136 559414840
SOT_KEYMAP IPK_SOT_KEYMAP SOTKEY_UD 1 1030369480 1015378900 24226580
TABLE_NAME INDEX_NAME COLUMN_NAME COLUMN_POSITION NUM_ROWS DISTINCT_KEYS CLUSTERING_FACTOR
SOT_CORRECT IDXL_SOTCRCT_SOT_UD SOTCRCT_SOT_UD 1 412484756 412484756 411710982
SOT_CORRECT SOTCRCT_TRD_DATE_Y 2 412484756 412484756 411710982
MD_PART
INDEX partiton stas (from dba_ind_partitions)
INDEX_NAME PARTITION_NAME STATUS BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR NUM_ROWS SAMPLE_SIZE LAST_ANALYZ GLO
IDXL_SOTCRCT_SOT_UD P20090219 USABLE 1 372 327879 216663 327879 327879 20-Feb-2009 YES
IDXL_SOTKEY_ENTORDSYS_UD P20090219 USABLE 2 2910 3 36618 856229 856229 19-Feb-2009 YES
IDXL_SOTKEY_HASH P20090219 USABLE 2 7783 853956 853914 853956 119705 19-Feb-2009 YES
IDXL_SOTKEY_SOM_ORD P20090219 USABLE 2 6411 531492 157147 799758 132610 19-Feb-2009 YES
IDXL_SOTRELSTG_SOT_UD P20090219 USABLE 2 13897 9682052 45867 9682052 794958 20-Feb-2009 YESThanks in advance.
Bhavik DesaiHi Randolf,
Thanks for the time you spent on this issue.I appreciate it.
Please see my comments below:
1. You've mentioned several times that you're passing the partition name as bind variable, but you're obviously testing the statement with literals rather than bind
variables. So your tests obviously don't reflect what is going to happen in case of the actual execution. The cardinality estimates are potentially quite different when
using bind variables for the partition key.
Yes.I intentionaly used literals in my tests.I found couple of times that plan used by the application and plan generated by AUTOTRACE+EXPLAIN PLAN command...is same and
caused hrly elapsed time.
As i pointed out earlier,last month we solved couple of bind peeking issue by intproducing NO_VALIDATE=>FALSE in stats gather procedure,which we execute just after data
load into such daily partitions and before start of jobs which executes this query.
Execution plans From AWR (with parallelism on at table level DEGREE>1)-->This plan is one which CBO has used when degradation occured.This plan is used most of the times.
ELAPSED_TIME_DELTA BUFFER_GETS_DELTA DISK_READS_DELTA CURSOR(SELECT*FROMTA
1918506000 46154275 918 CURSOR STATEMENT : 4
CURSOR STATEMENT : 4
PLAN_TABLE_OUTPUT
SQL_ID 39708a3azmks7
SELECT A.SOTRELSTG_SOT_UD SOTCRCT_SOT_UD, B.SOTKEY_UD SOTCRCT_ORIG_SOT_UD, A.ROWID STAGE_ROWID FROM (SELECT SOTRELSTG_SOT_UD,
SOTRELSTG_SYS_UD, SOTRELSTG_ORIG_SYS_ORD_ID, SOTRELSTG_ORIG_SYS_ORD_VSEQ FROM SOT_REL_STAGE WHERE SOTRELSTG_TRD_DATE_YMD_PART = :B1 AND
SOTRELSTG_CRCT_PROC_STAT_CD = 'N' AND SOTRELSTG_SOT_UD NOT IN( SELECT SOTCRCT_SOT_UD FROM SOT_CORRECT WHERE SOTCRCT_TRD_DATE_YMD_PART =
:B1 )) A, (SELECT MAX(SOTKEY_UD) SOTKEY_UD, SOTKEY_SYS_UD, SOTKEY_SYS_ORD_ID, SOTKEY_SYS_ORD_VSEQ, SOTKEY_TRD_DATE_YMD_PART FROM
SOT_KEYMAP WHERE SOTKEY_TRD_DATE_YMD_PART = :B1 AND SOTKEY_IUD_CD = 'I' GROUP BY SOTKEY_TRD_DATE_YMD_PART, SOTKEY_SYS_UD,
SOTKEY_SYS_ORD_ID, SOTKEY_SYS_ORD_VSEQ) B WHERE A.SOTRELSTG_SYS_UD = B.SOTKEY_SYS_UD AND A.SOTRELSTG_ORIG_SYS_ORD_ID =
B.SOTKEY_SYS_ORD_ID AND NVL(A.SOTRELSTG_ORIG_SYS_ORD_VSEQ, 1) = NVL(B.SOTKEY_SYS_ORD_VSEQ, 1)
Plan hash value: 1213870831
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | | | 19655 (100)| | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 1 | 116 | 19655 (1)| 00:05:54 | | | Q1,03 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 1 | 116 | 19655 (1)| 00:05:54 | | | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 1 | 116 | 19655 (1)| 00:05:54 | | | Q1,03 | PCWP | |
| 5 | PX SEND HASH | :TQ10002 | 1 | 116 | 19655 (1)| 00:05:54 | | | Q1,02 | P->P | HASH |
| 6 | HASH GROUP BY | | 1 | 116 | 19655 (1)| 00:05:54 | | | Q1,02 | PCWP | |
| 7 | NESTED LOOPS ANTI | | 1 | 116 | 19654 (1)| 00:05:54 | | | Q1,02 | PCWP | |
| 8 | HASH JOIN | | 1 | 102 | 19654 (1)| 00:05:54 | | | Q1,02 | PCWP | |
| 9 | PX JOIN FILTER CREATE| :BF0000 | 13M| 664M| 2427 (3)| 00:00:44 | | | Q1,02 | PCWP | |
| 10 | PX RECEIVE | | 13M| 664M| 2427 (3)| 00:00:44 | | | Q1,02 | PCWP | |
| 11 | PX SEND HASH | :TQ10000 | 13M| 664M| 2427 (3)| 00:00:44 | | | Q1,00 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 13M| 664M| 2427 (3)| 00:00:44 | KEY | KEY | Q1,00 | PCWC | |
| 13 | TABLE ACCESS FULL| SOT_REL_STAGE | 13M| 664M| 2427 (3)| 00:00:44 | KEY | KEY | Q1,00 | PCWP | |
| 14 | PX RECEIVE | | 27M| 1270M| 17209 (1)| 00:05:10 | | | Q1,02 | PCWP | |
| 15 | PX SEND HASH | :TQ10001 | 27M| 1270M| 17209 (1)| 00:05:10 | | | Q1,01 | P->P | HASH |
| 16 | PX JOIN FILTER USE | :BF0000 | 27M| 1270M| 17209 (1)| 00:05:10 | | | Q1,01 | PCWP | |
| 17 | PX BLOCK ITERATOR | | 27M| 1270M| 17209 (1)| 00:05:10 | KEY | KEY | Q1,01 | PCWC | |
| 18 | TABLE ACCESS FULL| SOT_KEYMAP | 27M| 1270M| 17209 (1)| 00:05:10 | KEY | KEY | Q1,01 | PCWP | |
| 19 | PARTITION RANGE SINGLE| | 16185 | 221K| 0 (0)| | KEY | KEY | Q1,02 | PCWP | |
| 20 | INDEX RANGE SCAN | IDXL_SOTCRCT_SOT_UD | 16185 | 221K| 0 (0)| | KEY | KEY | Q1,02 | PCWP | |
Other Execution plan from AWR
ELAPSED_TIME_DELTA BUFFER_GETS_DELTA DISK_READS_DELTA CURSOR(SELECT*FROMTA
1053251381 0 2925 CURSOR STATEMENT : 4
CURSOR STATEMENT : 4
PLAN_TABLE_OUTPUT
SQL_ID 39708a3azmks7
SELECT A.SOTRELSTG_SOT_UD SOTCRCT_SOT_UD, B.SOTKEY_UD SOTCRCT_ORIG_SOT_UD, A.ROWID STAGE_ROWID FROM (SELECT SOTRELSTG_SOT_UD,
SOTRELSTG_SYS_UD, SOTRELSTG_ORIG_SYS_ORD_ID, SOTRELSTG_ORIG_SYS_ORD_VSEQ FROM SOT_REL_STAGE WHERE SOTRELSTG_TRD_DATE_YMD_PART = :B1 AND
SOTRELSTG_CRCT_PROC_STAT_CD = 'N' AND SOTRELSTG_SOT_UD NOT IN( SELECT SOTCRCT_SOT_UD FROM SOT_CORRECT WHERE SOTCRCT_TRD_DATE_YMD_PART =
:B1 )) A, (SELECT MAX(SOTKEY_UD) SOTKEY_UD, SOTKEY_SYS_UD, SOTKEY_SYS_ORD_ID, SOTKEY_SYS_ORD_VSEQ, SOTKEY_TRD_DATE_YMD_PART FROM
SOT_KEYMAP WHERE SOTKEY_TRD_DATE_YMD_PART = :B1 AND SOTKEY_IUD_CD = 'I' GROUP BY SOTKEY_TRD_DATE_YMD_PART, SOTKEY_SYS_UD,
SOTKEY_SYS_ORD_ID, SOTKEY_SYS_ORD_VSEQ) B WHERE A.SOTRELSTG_SYS_UD = B.SOTKEY_SYS_UD AND A.SOTRELSTG_ORIG_SYS_ORD_ID =
B.SOTKEY_SYS_ORD_ID AND NVL(A.SOTRELSTG_ORIG_SYS_ORD_VSEQ, 1) = NVL(B.SOTKEY_SYS_ORD_VSEQ, 1)
Plan hash value: 3434900850
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | | | 1830 (100)| | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10003 | 1 | 131 | 1830 (2)| 00:00:33 | | | Q1,03 | P->S | QC (RAND) |
| 3 | HASH GROUP BY | | 1 | 131 | 1830 (2)| 00:00:33 | | | Q1,03 | PCWP | |
| 4 | PX RECEIVE | | 1 | 131 | 1830 (2)| 00:00:33 | | | Q1,03 | PCWP | |
| 5 | PX SEND HASH | :TQ10002 | 1 | 131 | 1830 (2)| 00:00:33 | | | Q1,02 | P->P | HASH |
| 6 | HASH GROUP BY | | 1 | 131 | 1830 (2)| 00:00:33 | | | Q1,02 | PCWP | |
| 7 | NESTED LOOPS ANTI | | 1 | 131 | 1829 (2)| 00:00:33 | | | Q1,02 | PCWP | |
| 8 | HASH JOIN | | 1 | 117 | 1829 (2)| 00:00:33 | | | Q1,02 | PCWP | |
| 9 | PX JOIN FILTER CREATE| :BF0000 | 1010K| 50M| 694 (1)| 00:00:13 | | | Q1,02 | PCWP | |
| 10 | PX RECEIVE | | 1010K| 50M| 694 (1)| 00:00:13 | | | Q1,02 | PCWP | |
| 11 | PX SEND HASH | :TQ10000 | 1010K| 50M| 694 (1)| 00:00:13 | | | Q1,00 | P->P | HASH |
| 12 | PX BLOCK ITERATOR | | 1010K| 50M| 694 (1)| 00:00:13 | KEY | KEY | Q1,00 | PCWC | |
| 13 | TABLE ACCESS FULL| SOT_KEYMAP | 1010K| 50M| 694 (1)| 00:00:13 | KEY | KEY | Q1,00 | PCWP | |
| 14 | PX RECEIVE | | 11M| 688M| 1129 (3)| 00:00:21 | | | Q1,02 | PCWP | |
| 15 | PX SEND HASH | :TQ10001 | 11M| 688M| 1129 (3)| 00:00:21 | | | Q1,01 | P->P | HASH |
| 16 | PX JOIN FILTER USE | :BF0000 | 11M| 688M| 1129 (3)| 00:00:21 | | | Q1,01 | PCWP | |
| 17 | PX BLOCK ITERATOR | | 11M| 688M| 1129 (3)| 00:00:21 | KEY | KEY | Q1,01 | PCWC | |
| 18 | TABLE ACCESS FULL| SOT_REL_STAGE | 11M| 688M| 1129 (3)| 00:00:21 | KEY | KEY | Q1,01 | PCWP | |
| 19 | PARTITION RANGE SINGLE| | 5209 | 72926 | 0 (0)| | KEY | KEY | Q1,02 | PCWP | |
| 20 | INDEX RANGE SCAN | IDXL_SOTCRCT_SOT_UD | 5209 | 72926 | 0 (0)| | KEY | KEY | Q1,02 | PCWP | |
EXECUTION PLAN AFTER SETTING DEGREE=1 (It was also degraded)
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 1 | 129 | | 42336 (2)| 00:12:43 | | |
| 1 | HASH GROUP BY | | 1 | 129 | | 42336 (2)| 00:12:43 | | |
| 2 | NESTED LOOPS ANTI | | 1 | 129 | | 42335 (2)| 00:12:43 | | |
|* 3 | HASH JOIN | | 1 | 115 | 51M| 42334 (2)| 00:12:43 | | |
| 4 | PARTITION RANGE SINGLE| | 846K| 41M| | 8241 (1)| 00:02:29 | 81 | 81 |
|* 5 | TABLE ACCESS FULL | SOT_KEYMAP | 846K| 41M| | 8241 (1)| 00:02:29 | 81 | 81 |
| 6 | PARTITION RANGE SINGLE| | 8161K| 490M| | 12664 (3)| 00:03:48 | 81 | 81 |
|* 7 | TABLE ACCESS FULL | SOT_REL_STAGE | 8161K| 490M| | 12664 (3)| 00:03:48 | 81 | 81 |
| 8 | PARTITION RANGE SINGLE | | 6525K| 87M| | 1 (0)| 00:00:01 | 81 | 81 |
|* 9 | INDEX RANGE SCAN | IDXL_SOTCRCT_SOT_UD | 6525K| 87M| | 1 (0)| 00:00:01 | 81 | 81 |
Predicate Information (identified by operation id):
3 - access("SOTRELSTG_SYS_UD"="SOTKEY_SYS_UD" AND "SOTRELSTG_ORIG_SYS_ORD_ID"="SOTKEY_SYS_ORD_ID" AND
NVL("SOTRELSTG_ORIG_SYS_ORD_VSEQ",1)=NVL("SOTKEY_SYS_ORD_VSEQ",1))
5 - filter("SOTKEY_TRD_DATE_YMD_PART"=20090219 AND "SOTKEY_IUD_CD"='I')
7 - filter("SOTRELSTG_CRCT_PROC_STAT_CD"='N' AND "SOTRELSTG_TRD_DATE_YMD_PART"=20090219)
9 - access("SOTRELSTG_SOT_UD"="SOTCRCT_SOT_UD" AND "SOTCRCT_TRD_DATE_YMD_PART"=20090219)2. Why are you passing the partition name as bind variable? A statement executing 5 mins. best, > 2 hours worst obviously doesn't suffer from hard parsing issues and
doesn't need to (shouldn't) share execution plans therefore. So I strongly suggest to use literals instead of bind variables. This also solves any potential issues caused
by bind variable peeking.
This is a custom application which uses bind variables to extract data from daily partitions.So,daily automated data extract from daily paritions after load and ELT process.
Here,Value of bind variable is being passed through a procedure parameter.It would be bit difficult to use literals in such application.
3. All your posted plans suffer from bad cardinality estimates. The NO_MERGE hint suggested by Timur only caused a (significant) damage limitation by obviously reducing
the row source size by the group by operation before joining, but still the optimizer is way off, apart from the obviously wrong join order (larger row set first) in
particular the NESTED LOOP operation is causing the main troubles due to excessive logical I/O, as already pointed out by Timur.
Can i ask for alternatives to NESTED LOOP?
4. Your PLAN_TABLE seems to be old (you should see a corresponding note at the bottom of the DBMS_XPLAN.DISPLAY output), because none of the operations have a
filter/access predicate information attached. Since your main issue are the bad cardinality estimates, I strongly suggest to drop any existing PLAN_TABLEs in any non-Oracle
owned schemas because 10g already provides one in the SYS schema (GTT PLAN_TABLE$) exposed via a public synonym, so that the EXPLAIN PLAN information provides the
"Predicate Information" section below the plan covering the "Filter/Access" predicates.
Please post a revised explain plan output including this crucial information so that we get a clue why the cardinality estimates are way off.
I have dropped the old plan.Got above execution plan(listed above in first point) with PREDICATE information.
"As already mentioned the usage of bind variables for the partition name makes this issue potentially worse."
Is there any workaround without replacing bind variable.I am on 10g so 11g's feature will not help !!!
How are you gathering the statistics daily, can you post the exact command(s) used?
gather_table_part_stats(i_owner_name,i_table_name,i_part_name,i_estimate:= DBMS_STATS.AUTO_SAMPLE_SIZE, i_invalidate IN VARCHAR2 := 'Y',i_debug:= 'N')
Thanks & Regards,
Bhavik Desai -
How to improve the performance of the attached query, Please help
Hi,
How to improve performance of the below query, Please help. also attached explain plan -
SELECT Camp.Id,
rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount,
(SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
rCam.AccountKey as AccountKey
FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
WHERE Camp.AccountKey = rCam.AccountKey
AND Camp.AvCampaignKey = rCam.AvCampaignKey
AND Camp.AccountKey = CamBilling.AccountKey
AND Camp.CampaignKey = CamBilling.CampaignKey
AND rCam.AccountKey = xSite.AccountKey
AND rCam.AvSiteKey = xSite.AvSiteKey
AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
to_date('01-01-2011', 'DD-MM-YYYY')
GROUP By rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount
Explain Plan :-
Description Object_owner Object_name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
SORT AGGREGATE 1 13
VIEW GEMINI_REPORTING 14 1 13
HASH GROUP BY 14 1 103
NESTED LOOPS 13 1 103
HASH JOIN 12 1 85
TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
NESTED LOOPS 9 5 325
HASH JOIN 7 1 40
SORT UNIQUE 2 1 18
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1Hello,
This has really nothing to do with the Oracle Forms product.
Please, send the SQL or/and PL/SQL questions in the corresponding forums.
Francois -
How to improve performance of the attached query
Hi,
How to improve performance of the below query, Please help. also attached explain plan -
SELECT Camp.Id,
rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount,
(SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
rCam.AccountKey as AccountKey
FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
WHERE Camp.AccountKey = rCam.AccountKey
AND Camp.AvCampaignKey = rCam.AvCampaignKey
AND Camp.AccountKey = CamBilling.AccountKey
AND Camp.CampaignKey = CamBilling.CampaignKey
AND rCam.AccountKey = xSite.AccountKey
AND rCam.AvSiteKey = xSite.AvSiteKey
AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
to_date('01-01-2011', 'DD-MM-YYYY')
GROUP By rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount
Explain Plan :-
Description Object_owner Object_name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
SORT AGGREGATE 1 13
VIEW GEMINI_REPORTING 14 1 13
HASH GROUP BY 14 1 103
NESTED LOOPS 13 1 103
HASH JOIN 12 1 85
TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
NESTED LOOPS 9 5 325
HASH JOIN 7 1 40
SORT UNIQUE 2 1 18
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1duplicate thread..
How to improve performance of attached query -
How to improve performance of attached query
Hi,
How to improve performance of the below query, Please help. also attached explain plan -
SELECT Camp.Id,
rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount,
(SUM(rCam.Impressions) * 0.001 + SUM(rCam.Clickthrus)) AS GR,
rCam.AccountKey as AccountKey
FROM Campaign Camp, rCamSit rCam, CamBilling, Site xSite
WHERE Camp.AccountKey = rCam.AccountKey
AND Camp.AvCampaignKey = rCam.AvCampaignKey
AND Camp.AccountKey = CamBilling.AccountKey
AND Camp.CampaignKey = CamBilling.CampaignKey
AND rCam.AccountKey = xSite.AccountKey
AND rCam.AvSiteKey = xSite.AvSiteKey
AND rCam.RmWhen BETWEEN to_date('01-01-2009', 'DD-MM-YYYY') and
to_date('01-01-2011', 'DD-MM-YYYY')
GROUP By rCam.AccountKey,
Camp.Id,
CamBilling.Cpm,
CamBilling.Cpc,
CamBilling.FlatRate,
Camp.CampaignKey,
Camp.AccountKey,
CamBilling.billoncontractedamount
Explain Plan :-
Description Object_owner Object_name Cost Cardinality Bytes
SELECT STATEMENT, GOAL = ALL_ROWS 14 1 13
SORT AGGREGATE 1 13
VIEW GEMINI_REPORTING 14 1 13
HASH GROUP BY 14 1 103
NESTED LOOPS 13 1 103
HASH JOIN 12 1 85
TABLE ACCESS BY INDEX ROWID GEMINI_REPORTING RCAMSIT 2 4 100
NESTED LOOPS 9 5 325
HASH JOIN 7 1 40
SORT UNIQUE 2 1 18
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY SITE 2 1 18
INDEX RANGE SCAN GEMINI_PRIMARY SITE_I0 1 1
TABLE ACCESS FULL GEMINI_PRIMARY SITE 3 27 594
INDEX RANGE SCAN GEMINI_REPORTING RCAMSIT_I 1 1 5
TABLE ACCESS FULL GEMINI_PRIMARY CAMPAIGN 3 127 2540
TABLE ACCESS BY INDEX ROWID GEMINI_PRIMARY CAMBILLING 1 1 18
INDEX UNIQUE SCAN GEMINI_PRIMARY CAMBILLING_U1 0 1duplicate thread..
How to improve performance of attached query -
Hash join ending up in huge wait events
Hi,
We are experiencing huge wait events ( direct path read temp , direct path write temp) on our Materialized View refresh in 10.2.0.4 version of oracle 10g in linux rhel5 environment while monitoring the refresh session from db console. While checking the explain plan of the mv query there is a huge hash_join (due to self join nature of the query) is shown. As advised in some dba forums, i have increased my pga_aggregate_target to a value of 4 gb from 1800 mb. The PGA_HIT % is raised to 60% from 58% ( just 2% improvement). But still my direct path read temp and direct path write temp wait event have not reduced and a huge temp space is taken for hash join.
Since we have some usage limit set by some hidden parameters for a each session on pga_aggregate_target, increase the size did not helped me much. The mv refresh is taking more than 5 hours ( sometimes it exceeds 5 hrs) to completes it refresh where as the same query in window (production) is completed less than two hours. Before a month, the refresh time in both environment was nearly close. But now it has changed and not able to figure it out.
STATISTICS have been collected regularly using dbms_gather_stats in both environment. Both mv refresh are scheduled to run using dbms_scheduler (Manual refresh). SGA_TARGET and other memory parameters are almost same.
Environment : Dataware house
O/s : RHEL 5
Oracle version : 10.2.0.4
Work_policy=auto
Is there any possibility to reduce this wait event and there by reducing the elapsed time? I am also interested to know changing the plan to use other sort will help? I don't know whether the details are sufficient to analyze this issue. If you need more details on this just let me know.
I really appreciate your help and thanks in advance to all.Thans for your comments. Here is the code, explan plan and autotrace trace stat output.
SELECT lasg.employee_number "EMPLOYEE_NUM",
lasg.full_name "FULL_NAME",
lasg.person_id "PERSON_ID",
SUBSTR (lasg.organization, 1, 4) "DEPT",
casg.assign_start_date "EFFECTIVE_START_DATE",
casg.assign_end_date "EFFECTIVE_END_DATE",
hasg.organization "PRIOR_ORG",
casg.organization organization,
hasg.supervisor "PRIOR_SUPERVISOR",
casg.supervisor "SUPERVISOR_NAME",
hasg.location "PRIOR_LOCATION",
casg.location location,
hasg.job_title "PRIOR_TITLE",
casg.job_title job_name,
CASE
WHEN hasg.organization = casg.organization THEN 'No Change'
ELSE 'Change'
END
org_change,
CASE
WHEN hasg.location = casg.location THEN 'No Change'
ELSE 'Change'
END
loc_change,
CASE
WHEN hasg.supervisor = casg.supervisor THEN 'No Change'
ELSE 'Change'
END
sup_change,
CASE
WHEN hasg.job_title = casg.job_title THEN 'No Change'
ELSE 'Change'
END
job_change
FROM panad.data_employ_details lasg,
panad.data_employ_details casg,
panad.data_employ_details hasg
WHERE lasg.person_id = casg.person_id(+)
AND lasg.assign_end_date = (SELECT MAX (lasg2.assign_end_date)
FROM panad.data_employ_details lasg2
WHERE lasg.person_id = lasg2.person_id)
AND casg.person_id = hasg.person_id(+)
AND hasg.assign_start_date =
(SELECT MAX (hasg2.assign_start_date)
FROM panad.data_employ_details hasg2
WHERE hasg2.person_id = lasg.person_id
AND hasg2.assign_end_date < casg.assign_start_date)
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 303 | | 10261 (91)| 00:02:04 |
|* 1 | FILTER | | | | | | |
|* 2 | HASH JOIN | | 1 | 303 | | 10179 (91)| 00:02:03 |
|* 3 | HASH JOIN | | 5 | 1060 | | 10095 (92)| 00:02:02 |
|* 4 | HASH JOIN | | 6786 | 960K| | 10011 (93)| 00:02:01 |
| 5 | VIEW | VW_SQ_1 | 6786 | 225K| | 9927 (94)| 00:02:00 |
| 6 | HASH GROUP BY | | 6786 | 384K| | 9927 (94)| 00:02:00 |
| 7 | MERGE JOIN | | 50M| 2820M| | 1427 (53)| 00:00:18 |
| 8 | SORT JOIN | | 31937 | 998K| 2776K| 367 (2)| 00:00:05 |
| 9 | TABLE ACCESS FULL| DATA_EMPLOY_DETAILS | 31937 | 998K| | 82 (2)| 00:00:01 |
|* 10 | SORT JOIN | | 31937 | 810K| 2520K| 324 (2)| 00:00:04 |
| 11 | TABLE ACCESS FULL| DATA_EMPLOY_DETAILS | 31937 | 810K| | 82 (2)| 00:00:01 |
| 12 | TABLE ACCESS FULL | DATA_EMPLOY_DETAILS | 31937 | 3461K| | 83 (3)| 00:00:01 |
| 13 | TABLE ACCESS FULL | DATA_EMPLOY_DETAILS | 31937 | 2089K| | 83 (3)| 00:00:01 |
| 14 | TABLE ACCESS FULL | DATA_EMPLOY_DETAILS | 31937 | 2838K| | 83 (3)| 00:00:01 |
| 15 | SORT AGGREGATE | | 1 | 13 | | | |
|* 16 | TABLE ACCESS FULL | DATA_EMPLOY_DETAILS | 5 | 65 | | 82 (2)| 00:00:01 |
Predicate Information (identified by operation id):
1 - filter("LASG"."ASSIGN_END_DATE"= (SELECT MAX("LASG2"."ASSIGN_END_DATE") FROM
"PANAD"."DATA_EMPLOY_DETAILS" "LASG2" WHERE "LASG2"."PERSON_ID"=:B1))
2 - access("CASG"."PERSON_ID"="HASG"."PERSON_ID" AND "HASG"."ASSIGN_START_DATE"="VW_COL_1")
3 - access("LASG"."PERSON_ID"="CASG"."PERSON_ID" AND "PERSON_ID"="LASG"."PERSON_ID")
4 - access("ROWID"=ROWID)
10 - access(INTERNAL_FUNCTION("HASG2"."ASSIGN_END_DATE")<INTERNAL_FUNCTION("CASG"."ASSIGN_START_DATE")
filter(INTERNAL_FUNCTION("HASG2"."ASSIGN_END_DATE")<INTERNAL_FUNCTION("CASG"."ASSIGN_START_DATE")
16 - filter("LASG2"."PERSON_ID"=:B1)
37 rows selected.
- autot trace stat output -
5070 rows selected.
Statistics
35203 recursive calls
0 db block gets
3675913 consistent gets
4269882 physical reads
0 redo size
1046781 bytes sent via SQL*Net to client
4107 bytes received via SQL*Net from client
339 SQL*Net roundtrips to/from client
69 sorts (memory)
0 sorts (disk)
5070 rows processed I have tried running this query with paralell but not helped.
I have read the links provided by both of you. Dictionary and fixed table stats are collected as a routine.
From the link given byTaral, Greg Rahn has suggested that it is a bug as below.
Its bug 9041800 and there is a 10.2.0.4 backport available as of 01/29/10.How can i get this bug fixed since there is no explanation of what need to be done? Do i need to contact oracle support for the 10.2.0.4 backport for RHEL5?
Thanks in advance
Edited by: Karthikambalav on Mar 9, 2010 2:43 AM -
Any room for improvement for this query? Explain Plan attached.
Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??
select sum(CONF
when (cd.actl_qty - cd.total_alloc_qty - lsd.Q < 0) then
0
else
cd.actl_qty - cd.total_alloc_qty - lsd.Q
end)
from (select sum(reqd_qty) as Q, ITEM_ID as ITEM
from SHIP_DTL SD
where exists (select 1
from CONF_dtl
where CONF_nbr = '1'
and ITEM_id = SD.ITEM_id)
group by ITEM_id) lsd,
CONF_dtl cd
where lsd.ITEM = cd.ITEM_id
and cd.CONF_nbr = '1'Total number of rows in the tables involved
select count(*) from CONF_DTL;
COUNT(*)
1785889
select count(*) from shp_dtl;
COUNT(*)
286675
Explain Plan
PLAN_TABLE_OUTPUT
Plan hash value: 2325658044
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 1 | 39 | 4 (25)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 39 | | |
| 2 | VIEW | | 1 | 39 | 4 (25)| 00:00:01 |
| 3 | HASH GROUP BY | | 1 | 117 | 4 (25)| 00:00:01 |
| 4 | TABLE ACCESS BY INDEX ROWID | SHIP_DTL | 1 | 15 | 1 (0)| 00:00:01
| 5 | NESTED LOOPS | | 1 | 117 | 3 (0)| 00:00:01 |
| 6 | MERGE JOIN CARTESIAN | | 1 | 102 | 2 (0)| 00:00:01 |
| 7 | TABLE ACCESS BY INDEX ROWID | CONF_DTL | 1 | 70 | 1 (0)| 00:00:01 |
|* 8 | INDEX RANGE SCAN | PK_CONF_DTL | 1 | | 1 (0)| 00:00:01 |
| 9 | BUFFER SORT | | 1 | 32 | 1 (0)| 00:00:01 |
| 10 | SORT UNIQUE | | 1 | 32 | 1 (0)| 00:00:01 |
| 11 | TABLE ACCESS BY INDEX ROWID| CONF_DTL | 1 | 32 | 1 (0)| 00:00:01 |
|* 12 | INDEX RANGE SCAN | PK_CONF_DTL | 1 | | 1 (0)| 00:00:01 |
|* 13 | INDEX RANGE SCAN | SHIP_DTL_IND_6 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
8 - access("CD"."CONF_NBR"='1')
12 - access("CONF_NBR"='1')
13 - access("ITEM_ID"="SD"."ITEM_ID")
filter("ITEM_ID"="CD"."ITEM_ID")Citizen_2 wrote:
Is there any room for improvement for this query? Table stats are up-to-date. Any suggestions Query rewrite, addition of indexes,...etc ??You say that the table stats are up-to-date, but is the following assumption of the optimizer correct:
select count(*)
from CONF_dtl
where CONF_nbr = '1';Does this query return a count of 1? I doubt that, but that's what Oracle estimates in the EXPLAIN PLAN output. Based on that assumption you get a cartesian join between the two CONF_DTL table instances, and the result - which is still expected to be one row at most - is then joined to the SHIP_DTL table using a NESTED LOOP.
If above assumption is incorrect, the number of rows generated by the cartesian join can be tremendous rendering the NESTED LOOP operation quite inefficient.
You can verify this by using the DBMS_XPLAN.DISPLAY_CURSOR function together with the GATHER_PLAN_STATISTICS hint, if you're already on 10g or later.
For more information regarding the DISPLAY_CURSOR function, see e.g. here: http://jonathanlewis.wordpress.com/2006/11/09/dbms_xplan-in-10g/
It will show you the actual cardinalities compared to the estimated cardinalities.
If the estimate of the optimizer is incorrect, you should find out why. There still might be some issues with the statistics, since this is most obvious reason for incorrect estimates.
Are your index statistics up-to-date?
Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/ -
Can i use an analytic function instead of a group by clause?
Can i use an analytic function instead of a group by clause? Will this help in any performance improvement?
analytic can sometimes avoid scanning the table more than once :
SQL> select ename, sal, (select sum(sal) from emp where deptno=e.deptno) sum from emp e;
ENAME SAL SUM
SMITH 800 10875
ALLEN 1600 9400
WARD 1250 9400
JONES 2975 10875
MARTIN 1250 9400
BLAKE 2850 9400
CLARK 2450 8750
SCOTT 3000 10875
KING 5000 8750
TURNER 1500 9400
ADAMS 1100 10875
JAMES 950 9400
FORD 3000 10875
MILLER 1300 8750
14 rows selected.
Execution Plan
Plan hash value: 3189885365
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 14 | 182 | 3 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 7 | | |
|* 2 | TABLE ACCESS FULL| EMP | 5 | 35 | 3 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL | EMP | 14 | 182 | 3 (0)| 00:00:01 |
Predicate Information (identified by operation id):
2 - filter("DEPTNO"=:B1)which could be rewritten as
SQL> select ename, sal, sum(sal) over (partition by deptno) sum from emp e;
ENAME SAL SUM
CLARK 2450 8750
KING 5000 8750
MILLER 1300 8750
JONES 2975 10875
FORD 3000 10875
ADAMS 1100 10875
SMITH 800 10875
SCOTT 3000 10875
WARD 1250 9400
TURNER 1500 9400
ALLEN 1600 9400
JAMES 950 9400
BLAKE 2850 9400
MARTIN 1250 9400
14 rows selected.
Execution Plan
Plan hash value: 1776581816
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 14 | 182 | 4 (25)| 00:00:01 |
| 1 | WINDOW SORT | | 14 | 182 | 4 (25)| 00:00:01 |
| 2 | TABLE ACCESS FULL| EMP | 14 | 182 | 3 (0)| 00:00:01 |
---------------------------------------------------------------------------well, there is no group by and no visible performance enhancement in my example, but Oracle7, you must have written the query as :
SQL> select ename, sal, sum from emp e,(select deptno,sum(sal) sum from emp group by deptno) s where e.deptno=s.deptno;
ENAME SAL SUM
SMITH 800 10875
ALLEN 1600 9400
WARD 1250 9400
JONES 2975 10875
MARTIN 1250 9400
BLAKE 2850 9400
CLARK 2450 8750
SCOTT 3000 10875
KING 5000 8750
TURNER 1500 9400
ADAMS 1100 10875
JAMES 950 9400
FORD 3000 10875
MILLER 1300 8750
14 rows selected.
Execution Plan
Plan hash value: 2661063502
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 14 | 546 | 8 (25)| 00:00:01 |
|* 1 | HASH JOIN | | 14 | 546 | 8 (25)| 00:00:01 |
| 2 | VIEW | | 3 | 78 | 4 (25)| 00:00:01 |
| 3 | HASH GROUP BY | | 3 | 21 | 4 (25)| 00:00:01 |
| 4 | TABLE ACCESS FULL| EMP | 14 | 98 | 3 (0)| 00:00:01 |
| 5 | TABLE ACCESS FULL | EMP | 14 | 182 | 3 (0)| 00:00:01 |
-----------------------------------------------------------------------------So maybe it helps -
Hash Table Infrastructure ran out of memory Issue
I am getting ORA-32690 : Hash Table Infrastructure ran out of memory error, while executing an Informatica mapping using Oracle Database ( Test Environment)
The partition creation is as shown below.
TABLESPACE MAIN_LARGE_DATA1
PARTITION BY LIST (MKTCD)
PARTITION AAM VALUES ('AAM')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION AHT VALUES ('AHT')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION GIM VALUES ('GIM')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION CNS VALUES ('CNS')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION AOBE VALUES ('AOBE')
TABLESPACE MAIN_LARGE_DATA1,
PARTITION DBM VALUES ('DBM')
TABLESPACE MAIN_LARGE_DATA1
Could you please provide me with a solution to this problem asap?SQL statement and execution plan? Is there a server-side trace file created for the session?
From the brief description, it sounds like bug 6471770. See Metalink for details. The workaround for this particular bug is to either disable hash group-by, by setting +"_gby_hash_aggregation_enabled"+ to FALSE (using an ALTER SESSION statement . Or by using a NO_USE_HASH_AGGREGATION hint.
Suggest you research this problem on Metalink (aka MyOracleSupport at https://support.oracle.com) -
SQL Performance issue: Using user defined function with group by
Hi Everyone,
im new here and I really could need some help on a weird performance issue. I hope this is the right topic for SQL performance issues.
Well ok, i create a function for converting a date from timezone GMT to a specified timzeone.
CREATE OR REPLACE FUNCTION I3S_REP_1.fnc_user_rep_date_to_local (date_in IN date, tz_name_in IN VARCHAR2) RETURN date
IS
tz_name VARCHAR2(100);
date_out date;
BEGIN
SELECT
to_date(to_char(cast(from_tz(cast( date_in AS TIMESTAMP),'GMT')AT
TIME ZONE (tz_name_in) AS DATE),'dd-mm-yyyy hh24:mi:ss'),'dd-mm-yyyy hh24:mi:ss')
INTO date_out
FROM dual;
RETURN date_out;
END fnc_user_rep_date_to_local;The following statement is just an example, the real statement is much more complex. So I select some date values from a table and aggregate a little.
select
stp_end_stamp,
count(*) noi
from step
where
stp_end_stamp
BETWEEN
to_date('23-05-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
AND
to_date('23-07-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
group by
stp_end_stampThis statement selects ~70000 rows and needs ~ 70ms
If i use the function it selects the same number of rows ;-) and takes ~ 4 sec ...
select
fnc_user_rep_date_to_local(stp_end_stamp,'Europe/Berlin'),
count(*) noi
from step
where
stp_end_stamp
BETWEEN
to_date('23-05-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
AND
to_date('23-07-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
group by
fnc_user_rep_date_to_local(stp_end_stamp,'Europe/Berlin')I understand that the DB has to execute the function for each row.
But if I execute the following statement, it takes only ~90ms ...
select
fnc_user_rep_date_to_gmt(stp_end_stamp,'Europe/Berlin','ny21654'),
noi
from
select
stp_end_stamp,
count(*) noi
from step
where
stp_end_stamp
BETWEEN
to_date('23-05-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
AND
to_date('23-07-2009 00:00:00','dd-mm-yyyy hh24:mi:ss')
group by
stp_end_stamp
)The execution plan for all three statements is EXACTLY the same!!!
Usually i would say, that I use the third statement and the world is in order. BUT I'm working on a BI project with a tool called Business Objects and it generates SQL, so my hands are bound and I can't make this tool to generate the SQL as a subselect.
My questions are:
Why is the second statement sooo much slower than the third?
and
Howcan I force the optimizer to do whatever he is doing to make the third statement so fast?
I would really appreciate some help on this really weird issue.
Thanks in advance,
AndiHi,
The execution plan for all three statements is EXACTLY the same!!!Not exactly. Plans are the same - true. They uses slightly different approach to call function. See:
drop table t cascade constraints purge;
create table t as select mod(rownum,10) id, cast('x' as char(500)) pad from dual connect by level <= 10000;
exec dbms_stats.gather_table_stats(user, 't');
create or replace function test_fnc(p_int number) return number is
begin
return trunc(p_int);
end;
explain plan for select id from t group by id;
select * from table(dbms_xplan.display(null,null,'advanced'));
explain plan for select test_fnc(id) from t group by test_fnc(id);
select * from table(dbms_xplan.display(null,null,'advanced'));
explain plan for select test_fnc(id) from (select id from t group by id);
select * from table(dbms_xplan.display(null,null,'advanced'));Output:
PLAN_TABLE_OUTPUT
Plan hash value: 47235625
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 10 | 30 | 162 (3)| 00:00:02 |
| 1 | HASH GROUP BY | | 10 | 30 | 162 (3)| 00:00:02 |
| 2 | TABLE ACCESS FULL| T | 10000 | 30000 | 159 (1)| 00:00:02 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
2 - SEL$1 / T@SEL$1
Outline Data
/*+
BEGIN_OUTLINE_DATA
FULL(@"SEL$1" "T"@"SEL$1")
OUTLINE_LEAF(@"SEL$1")
ALL_ROWS
OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
IGNORE_OPTIM_EMBEDDED_HINTS
END_OUTLINE_DATA
Column Projection Information (identified by operation id):
1 - (#keys=1) "ID"[NUMBER,22]
2 - "ID"[NUMBER,22]
34 rows selected.
SQL>
Explained.
SQL>
PLAN_TABLE_OUTPUT
Plan hash value: 47235625
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 10 | 30 | 162 (3)| 00:00:02 |
| 1 | HASH GROUP BY | | 10 | 30 | 162 (3)| 00:00:02 |
| 2 | TABLE ACCESS FULL| T | 10000 | 30000 | 159 (1)| 00:00:02 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$1
2 - SEL$1 / T@SEL$1
Outline Data
/*+
BEGIN_OUTLINE_DATA
FULL(@"SEL$1" "T"@"SEL$1")
OUTLINE_LEAF(@"SEL$1")
ALL_ROWS
OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
IGNORE_OPTIM_EMBEDDED_HINTS
END_OUTLINE_DATA
Column Projection Information (identified by operation id):
1 - (#keys=1) "TEST_FNC"("ID")[22]
2 - "ID"[NUMBER,22]
34 rows selected.
SQL>
Explained.
SQL> select * from table(dbms_xplan.display(null,null,'advanced'));
PLAN_TABLE_OUTPUT
Plan hash value: 47235625
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 10 | 30 | 162 (3)| 00:00:02 |
| 1 | HASH GROUP BY | | 10 | 30 | 162 (3)| 00:00:02 |
| 2 | TABLE ACCESS FULL| T | 10000 | 30000 | 159 (1)| 00:00:02 |
Query Block Name / Object Alias (identified by operation id):
1 - SEL$F5BB74E1
2 - SEL$F5BB74E1 / T@SEL$2
Outline Data
/*+
BEGIN_OUTLINE_DATA
FULL(@"SEL$F5BB74E1" "T"@"SEL$2")
OUTLINE(@"SEL$2")
OUTLINE(@"SEL$1")
MERGE(@"SEL$2")
OUTLINE_LEAF(@"SEL$F5BB74E1")
ALL_ROWS
OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
IGNORE_OPTIM_EMBEDDED_HINTS
END_OUTLINE_DATA
Column Projection Information (identified by operation id):
1 - (#keys=1) "ID"[NUMBER,22]
2 - "ID"[NUMBER,22]
37 rows selected.
Maybe you are looking for
-
Need to group digits in Indian Format
Post Author: bhagwad CA Forum: Formula Good afternoon to all who read this thread. I am using CR v10 I need to find a way to format a number such that it groups not in thousands, as it happens in Europe and the US, but first by three digits, and the
-
BP not updating in Customer Master data KNA1
Guys, I am creating a BP in CRM 7.0. Once the BP is saved & created successfully entry is present in all CRM tables as well as in the ECC side. But for few cases the Customer Master data Table KNA1, KNVV is not getting updated, i.e no value for the B
-
I really need to know what my runtime errors are in DIAdem when I am using VBS code to write a DataPlugin, right now it tells me to refer to the log file, but previous posts show that the log file is a joke. I really need to know what runtime errors
-
Not able to start the Presentation services and BI Server
Hi, My prsentation services has gone down, after the changed the default rpd and oped another rpd which was password lock. De-Commented the AUTHENTICATION_TYPE = BYPASS_NQS and restarted the BI Server and stopped it again, then logged into the rpd wi
-
External hard drives, media folders and iTunes Library folder
Hello All, I have an external hard drive with all of my iTunes media files and am wondering if I should also have the iTunes Library folder and related iTunes files on this same drive. Is this the preferred arrangement? It seems that backups would be