Plan shows SQL execution time Hrs 999:59:59 Sec.
Dear Masters,
Today my development team reported that the below query is taking more time. When I check the plan for my shok it is showing Hrs 999:59:59 Sec.
Kindly help me in tuning this query.
I am using oracle 10.2.0.3 version.
SELECT
S_INVLOC.NAME , S_ORDER.ACCNT_ID , S_ORDER.APPR_BY_EMP_ID , S_ORDER.BL_CON_ID , S_ORDER.BL_OU_ID , S_ORDER.CARRIER_CD , S_ORDER.CONTACT_ID , S_ORDER.CURCY_CD , S_ORDER.TAX_EXEMPT_FLG ,
S_ORDER.REQ_SHIP_DT , S_ORDER.SHIP_ADDR_ID , S_ORDER.SHIP_CON_ID , S_ORDER.SHIP_METH_CD , S_ORDER.SHIP_OU_ID , S_ORDER.STATUS_CD , S_ORDER.TAX_EXEMPT_NUM , S_ORDER.TAX_EXEMPT_REASON ,
S_ORDER.OPTY_ID , S_ORDER.BU_ID PR_VIS_ORG_ID , S_ORDER.PROMO_ID , S_ORDER.PRI_LST_ID , S_ORDER.AGREE_ID AGREEMENT_ID , S_ORDER.ENTLMNT_ID ENTITLEMENT_ID , S_ORDER.SR_ID ,
S_ORDER.BILLABLE_FLG , S_ORDER_ITEM.ROW_ID , S_ORDER_ITEM.ORDER_ID , S_ORDER_ITEM.LN_NUM , S_ORDER_ITEM.PROD_ID , S_ORDER_ITEM.ADJ_UNIT_PRI , S_ORDER_ITEM.BASE_UNIT_PRI ,
S_ORDER_ITEM.CARRIER_CD CARRIER_CD1 , S_ORDER_ITEM.EXTD_QTY , S_ORDER_ITEM.QTY_SHIPPED , S_ORDER_ITEM.REQ_SHIP_DT REQ_SHIP_DT1 , S_ORDER_ITEM.SHIP_ADDR_ID SHIP_ADDR_ID1 ,
S_ORDER_ITEM.SHIP_CON_ID SHIP_CON_ID1 , S_ORDER_ITEM.SHIP_METH_CD SHIP_METH_CD1 , S_ORDER_ITEM.STATUS_CD STATUS_CD1 , S_ORDER_ITEM.PROD_STATUS_CD , S_ORDER_ITEM.PROD_NAME ,
S_ORDER_ITEM.LOANER_FLG , S_ORDER_ITEM.DISCNT_METH_CD , S_ORDER_ITEM.SHIP_OU_ID SHIP_OU_ID1 , S_ORDER_ITEM.STATUS_DT , S_ORDER_ITEM.MUST_DLVR_BY_DT , S_ORDER_ITEM.ACTION_CD ,
S_ORDER_ITEM.ROLLUP_PRI , S_PROD_INT.NAME NAME1 , A.NAME NAME2 , B.NAME NAME3 , S_VOL_DISCNT.NAME NAME4 , ACCNT.PR_INDUST_ID , POSCRTDORG.OU_ID CREATED_BY_ORG_ID ,
POSOWNERORG.OU_ID PR_OWNER_ORG_ID , PAROITEM.LN_NUM , PAROITEM.PROD_ID , SHIPOITEM.CITY , SHIPOITEM.COUNTRY , SHIPOITEM.ZIPCODE , SHIPO.CITY , SHIPO.COUNTRY , SHIPO.ZIPCODE ,
BILL.CITY , BILL.COUNTRY , BILL.ZIPCODE , S_CAMP_CON.PR_CALL_LST_ID SEGMENT_ID , S_ORDER.DCP_ID OFFER_ID , APPRBYPOS.PR_HELD_POSTN_ID , POSOWNERORG.ROW_ID , POSOWNERORG.PR_EMP_ID ,
S_ENTLMNT.PAR_AGREE_ID , ROOTOITEM.PROD_ID ROOT_LN_PROD_ID , ROOTOITEM.LN_NUM ROOT_LN_NUM , S_ORDER.PR_POSTN_ID , S_CAMP_CON.CAMP_LD_WAVE_ID , S_SRC.REGION_ID , OPRI.COST_PRI ,
S_ORDER_ITEM.ORDER_ITM_CURCY_CD OITM_CURCY_CD , ROOTOITEM.ORDER_ITM_CURCY_CD ROOTOITM_CURCY_CD , S_ORDER_ITEM.ORDER_ITM_EXCH_DT OITM_AMT_DT , S_ORDER.ORDER_EXCH_DT ,
S_ORDER_ITEM.CREATED , S_ORDER_ITEM.NET_PRI , S_ORDER_ITEM.CRSE_OFFR_ID , S_ORDER_ITEM.PRI_LST_ID OITM_PRI_LST_ID , ROOTOITEM.PRI_LST_ID ROOTOITM_PRI_LST_ID ,
OWNORG.PRTNR_FLG , VISORG.PRTNR_FLG , S_CAMP_LD_WAVE.LAUNCHED_TS , QUOTE.CREATED , S_ORDER.ACTIVE_FLG , S_ORDER.APPROVED_FLG , PARPROD.PROD_TYPE_CD , ROOTPROD.PROD_TYPE_CD ,
S_PROD_INT.PRICE_TYPE_CD , S_SRC.PROG_END_DT , S_SRC.PROG_START_DT , S_SRC.ROW_ID , S_ORDER.CREATED , OWNORG.ROW_ID , 0 AS X_CUSTOM , S_ORDER_ITEM. X_PHONE_NUMBER ,
S_ORDER_ITEM.X_BACKEND_SERVICE_ID , S_ORDER_ITEM.SERVICE_NUM , S_ORDER_ITEM.BILL_ACCNT_ID , S_ORDER_X.ATTRIB_04 , S_ORDER_X.ATTRIB_30 , S_ORDER_X.ATTRIB_31
FROM
SIEBEL.V_ORDER_ITEM S_ORDER_ITEM, SIEBEL.S_ORDER_ITEM PAROITEM, SIEBEL.S_ORDER_ITEM ROOTOITEM, SIEBEL.S_ORDER, SIEBEL.S_VDISCNT_ITEM A, SIEBEL.S_VOL_DISCNT, SIEBEL.S_PROD_INT,
SIEBEL.S_VDISCNT_ITEM B, SIEBEL.S_INVLOC, SIEBEL.S_ORG_EXT ACCNT, SIEBEL.S_POSTN POSOWNERORG, SIEBEL.S_CONTACT CRTD, SIEBEL.S_CONTACT APPRBYPOS, SIEBEL.S_POSTN POSCRTDORG,
SIEBEL.S_ADDR_ORG SHIPOITEM, SIEBEL.S_ADDR_ORG SHIPO, SIEBEL.S_ADDR_ORG BILL, SIEBEL.S_CAMP_CON, SIEBEL.S_ENTLMNT, SIEBEL.S_SRC, SIEBEL.S_ORDER_ITM_PRI OPRI,
SIEBEL.S_CAMP_LD_WAVE, SIEBEL.S_DOC_QUOTE QUOTE, SIEBEL.S_ORG_EXT OWNORG, SIEBEL.S_ORG_EXT OWNORG1, SIEBEL.S_ORG_EXT VISORG1, SIEBEL.S_ORG_EXT VISORG,
SIEBEL.S_PROD_INT PARPROD, SIEBEL.S_PROD_INT ROOTPROD, SIEBEL.S_ORDER_X
WHERE
S_ORDER_ITEM.ORDER_ID = S_ORDER.ROW_ID
AND S_ORDER_ITEM.ROOT_ORDER_ITEM_ID = ROOTOITEM.ROW_ID
AND S_ORDER_ITEM.PAR_ORDER_ITEM_ID = PAROITEM.ROW_ID(+)
AND S_ORDER_ITEM.PROD_ID = S_PROD_INT.ROW_ID(+)
AND S_ORDER_ITEM.SRC_INVLOC_ID = S_INVLOC.ROW_ID(+)
AND S_ORDER_ITEM.VOL_DISCNT_ITEM_ID = A.ROW_ID(+)
AND S_ORDER_ITEM.VOL_DISCNT_ID = S_VOL_DISCNT.ROW_ID(+)
AND S_ORDER_ITEM.VOL_UPSELL_ITEM_ID = B.ROW_ID(+)
AND S_ORDER_ITEM.SHIP_ADDR_ID = SHIPOITEM.ROW_ID(+)
AND S_ORDER.PR_POSTN_ID = POSOWNERORG.ROW_ID(+)
AND S_ORDER_ITEM.CREATED_BY = CRTD.ROW_ID(+)
AND CRTD.PR_HELD_POSTN_ID = POSCRTDORG.ROW_ID(+)
AND S_ORDER.ACCNT_ID = ACCNT.ROW_ID(+)
AND S_ORDER.CAMP_CON_ID = S_CAMP_CON.ROW_ID(+)
AND S_ORDER.SHIP_ADDR_ID = SHIPO.ROW_ID(+)
AND S_ORDER.BL_ADDR_ID = BILL.ROW_ID(+)
AND S_ORDER.APPR_BY_EMP_ID = APPRBYPOS.ROW_ID(+)
AND S_ORDER.ENTLMNT_ID = S_ENTLMNT.ROW_ID(+)
AND S_ORDER.PROMO_ID = S_SRC.ROW_ID(+)
AND S_ORDER_ITEM.ROW_ID = OPRI.PAR_ROW_ID(+)
AND S_CAMP_CON.CAMP_LD_WAVE_ID = S_CAMP_LD_WAVE.ROW_ID(+)
AND S_ORDER.QUOTE_ID = QUOTE.ROW_ID(+)
AND POSOWNERORG.OU_ID = OWNORG1.ROW_ID(+)
AND OWNORG1.PAR_BU_ID = OWNORG.ROW_ID(+)
AND S_ORDER.BU_ID = VISORG1.ROW_ID(+)
AND VISORG1.PAR_BU_ID = VISORG.ROW_ID(+)
AND PAROITEM.PROD_ID = PARPROD.ROW_ID(+)
AND ROOTOITEM.PROD_ID = ROOTPROD.ROW_ID(+)
AND S_ORDER_ITEM.ORDER_ID = S_ORDER_X.PAR_ROW_ID(+)
AND S_ORDER_ITEM.ROOT_ORDER_ITEM_ID IS NOT NULL;Execution Plan is : select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 73463824
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 3170K| 12G| 4100G (4)|999:59:59 |
| 1 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 2 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 3 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 4 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 5 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 6 | NESTED LOOPS | | 3170K| 12G| 4100G (4)|999:59:59 |
| 7 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 8 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 9 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 10 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 11 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 12 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 13 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 14 | NESTED LOOPS OUTER | | 3170K| 12G| 4100G (4)|999:59:59 |
| 15 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 |
| 16 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 |
| 17 | NESTED LOOPS OUTER | | 3170K| 11G| 4100G (4)|999:59:59 |
| 18 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 |
| 19 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 |
| 20 | NESTED LOOPS OUTER | | 3170K| 10G| 4100G (4)|999:59:59 |
| 21 | NESTED LOOPS | | 3170K| 9911M| 4100G (4)|999:59:59 |
| 22 | NESTED LOOPS OUTER | | 3108K| 4927M| 2569K (2)| 01:08:47 |
| 23 | NESTED LOOPS OUTER | | 3108K| 4835M| 115K (14)| 00:03:06 |
| 24 | NESTED LOOPS OUTER | | 3108K| 4782M| 115K (14)| 00:03:06 |
| 25 | NESTED LOOPS OUTER | | 3108K| 4660M| 112K (12)| 00:03:02 |
| 26 | NESTED LOOPS OUTER | | 3108K| 4417M| 112K (12)| 00:03:02 |
| 27 | NESTED LOOPS OUTER | | 3108K| 4227M| 112K (12)| 00:03:02 |
| 28 | NESTED LOOPS OUTER | | 3108K| 3943M| 112K (12)| 00:03:02 |
| 29 | NESTED LOOPS OUTER | | 3108K| 3178M| 111K (11)| 00:02:59 |
| 30 | TABLE ACCESS FULL | S_ORDER | 3108K| 2413M| 109K (9)| 00:02:56 |
| 31 | TABLE ACCESS BY INDEX ROWID| S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 |
| 33 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 |
| 35 | TABLE ACCESS BY INDEX ROWID | S_CAMP_CON | 1 | 96 | 1 (0)| 00:00:01 |
|* 36 | INDEX UNIQUE SCAN | S_CAMP_CON_P1 | 1 | | 1 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | S_ENTLMNT | 1 | 64 | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | S_ENTLMNT_P1 | 1 | | 1 (0)| 00:00:01 |
| 39 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 | 82 | 1 (0)| 00:00:01 |
|* 40 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 | | 1 (0)| 00:00:01 |
| 41 | TABLE ACCESS BY INDEX ROWID | S_CAMP_LD_WAVE | 1 | 41 | 1 (0)| 00:00:01 |
|* 42 | INDEX UNIQUE SCAN | S_CAMP_LD_WAVE_P1 | 1 | | 1 (0)| 00:00:01 |
| 43 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 | 18 | 1 (0)| 00:00:01 |
|* 44 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 | | 1 (0)| 00:00:01 |
| 45 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 31 | 1 (0)| 00:00:01 |
|* 46 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 | | 1 (0)| 00:00:01 |
|* 47 | VIEW | V_ORDER_ITEM | 1 | 1616 | 1318K (4)| 00:35:19 |
| 48 | NESTED LOOPS | | 3128K| 1372M| 1318K (4)| 00:35:19 |
| 49 | INDEX FAST FULL SCAN | S_ETL_I_IMG_25_M2 | 3128K| 32M| 2756 (11)| 00:00:05 |
|* 50 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 449 | 2 (0)| 00:00:01 |
|* 51 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 | 134 | 1 (0)| 00:00:01 |
|* 53 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 | | 1 (0)| 00:00:01 |
| 54 | TABLE ACCESS BY INDEX ROWID | S_VOL_DISCNT | 1 | 134 | 1 (0)| 00:00:01 |
|* 55 | INDEX UNIQUE SCAN | S_VOL_DISCNT_P1 | 1 | | 1 (0)| 00:00:01 |
| 56 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 | 134 | 1 (0)| 00:00:01 |
|* 57 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 | | 1 (0)| 00:00:01 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 | 258 | 1 (0)| 00:00:01 |
|* 59 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 | | 1 (0)| 00:00:01 |
|* 60 | TABLE ACCESS FULL | S_ORDER_ITM_PRI | 1 | 45 | 0 (0)| 00:00:01 |
| 61 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 | 33 | 1 (0)| 00:00:01 |
|* 62 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 | | 1 (0)| 00:00:01 |
| 63 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 58 | 1 (0)| 00:00:01 |
|* 64 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
| 65 | TABLE ACCESS BY INDEX ROWID | S_ORDER_X | 1 | 36 | 2 (0)| 00:00:01 |
|* 66 | INDEX RANGE SCAN | S_ORDER_X_U1 | 1 | | 2 (0)| 00:00:01 |
| 67 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 | 14 | 2 (0)| 00:00:01 |
|* 68 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0)| 00:00:01 |
| 69 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 | 20 | 1 (0)| 00:00:01 |
|* 70 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 | | 1 (0)| 00:00:01 |
| 71 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 | 14 | 1 (0)| 00:00:01 |
|* 72 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 | | 1 (0)| 00:00:01 |
| 73 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
| 75 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 |
|* 76 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
| 77 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 17 | 2 (0)| 00:00:01 |
|* 78 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
| 79 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 60 | 2 (0)| 00:00:01 |
|* 80 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 |
| 81 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 | 24 | 2 (0)| 00:00:01 |
|* 82 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 | | 2 (0)| 00:00:01 |
| 83 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 16 | 1 (0)| 00:00:01 |
|* 84 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
| 85 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 | 16 | 1 (0)| 00:00:01 |
|* 86 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 | | 1 (0)| 00:00:01 |
| 87 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 14 | 2 (0)| 00:00:01 |
|* 88 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
| 89 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 | 17 | 2 (0)| 00:00:01 |
|* 90 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 | | 1 (0)| 00:00:01 |
Predicate Information (identified by operation id):
32 - access("S_ORDER"."SHIP_ADDR_ID"="SHIPO"."ROW_ID"(+))
34 - access("S_ORDER"."BL_ADDR_ID"="BILL"."ROW_ID"(+))
36 - access("S_ORDER"."CAMP_CON_ID"="S_CAMP_CON"."ROW_ID"(+))
38 - access("S_ORDER"."ENTLMNT_ID"="S_ENTLMNT"."ROW_ID"(+))
40 - access("S_ORDER"."PROMO_ID"="S_SRC"."ROW_ID"(+))
42 - access("S_CAMP_CON"."CAMP_LD_WAVE_ID"="S_CAMP_LD_WAVE"."ROW_ID"(+))
44 - access("S_ORDER"."QUOTE_ID"="QUOTE"."ROW_ID"(+))
46 - access("S_ORDER"."PR_POSTN_ID"="POSOWNERORG"."ROW_ID"(+))
47 - filter("S_ORDER_ITEM"."ORDER_ID"="S_ORDER"."ROW_ID")
50 - filter("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID" IS NOT NULL)
51 - access("S_ORDER_ITEM"."ROW_ID"="S_ETL_I_IMG_25"."ROW_ID")
53 - access("S_ORDER_ITEM"."VOL_DISCNT_ITEM_ID"="A"."ROW_ID"(+))
55 - access("S_ORDER_ITEM"."VOL_DISCNT_ID"="S_VOL_DISCNT"."ROW_ID"(+))
57 - access("S_ORDER_ITEM"."VOL_UPSELL_ITEM_ID"="B"."ROW_ID"(+))
59 - access("S_ORDER_ITEM"."SHIP_ADDR_ID"="SHIPOITEM"."ROW_ID"(+))
60 - filter("S_ORDER_ITEM"."ROW_ID"="OPRI"."PAR_ROW_ID"(+))
PLAN_TABLE_OUTPUT
62 - access("S_ORDER_ITEM"."SRC_INVLOC_ID"="S_INVLOC"."ROW_ID"(+))
64 - access("S_ORDER_ITEM"."PROD_ID"="S_PROD_INT"."ROW_ID"(+))
66 - access("S_ORDER_ITEM"."ORDER_ID"="S_ORDER_X"."PAR_ROW_ID"(+))
68 - access("S_ORDER_ITEM"."CREATED_BY"="CRTD"."ROW_ID"(+))
70 - access("CRTD"."PR_HELD_POSTN_ID"="POSCRTDORG"."ROW_ID"(+))
72 - access("S_ORDER"."APPR_BY_EMP_ID"="APPRBYPOS"."ROW_ID"(+))
74 - access("S_ORDER"."ACCNT_ID"="ACCNT"."ROW_ID"(+))
76 - access("POSOWNERORG"."OU_ID"="OWNORG1"."ROW_ID"(+))
78 - access("OWNORG1"."PAR_BU_ID"="OWNORG"."ROW_ID"(+))
80 - access("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID"="ROOTOITEM"."ROW_ID")
82 - access("S_ORDER_ITEM"."PAR_ORDER_ITEM_ID"="PAROITEM"."ROW_ID"(+))
84 - access("PAROITEM"."PROD_ID"="PARPROD"."ROW_ID"(+))
86 - access("ROOTOITEM"."PROD_ID"="ROOTPROD"."ROW_ID"(+))
88 - access("S_ORDER"."BU_ID"="VISORG1"."ROW_ID"(+))
90 - access("VISORG1"."PAR_BU_ID"="VISORG"."ROW_ID"(+))
132 rows selected.Edited by: KODS on Dec 13, 2012 2:11 PM
Output of : select * from table(dbms_xplan.display_cursor('4nn6jbvwf0b2k', null, 'iostats last'));
PLAN_TABLE_OUTPUT
SQL_ID 4nn6jbvwf0b2k, child number 0
S_ORDER.APPR_BY_EMP_ID ,
S_ORDER.CARRIER_CD ,
S_ORDER.CURCY_CD ,
S_ORDER.SHIP_ADDR_ID,
S_ORDER.SHIP_METH_CD ,
S_ORDER.TAX_EXEMPT_NUM ,
S_ORDER.BU_IDID ,EASON ,
S_ORDER.PRI_LST_ID ,
S_ORDER.ENTLMNT_ID ENTITLEMENT_ID ,
S_ORDER_ITEM.ROW_ID ,,
S_ORDER_ITEM.PROD_ID,
S_ORDER_ITEM.BASE_UNIT_PRI ,
S_
Plan hash value: 73463824
| Id | Operation | Name | E-Rows |
| 1 | NESTED LOOPS OUTER | | 3170K|
| 2 | NESTED LOOPS OUTER | | 3170K|
| 3 | NESTED LOOPS OUTER | | 3170K|
| 4 | NESTED LOOPS OUTER | | 3170K|
| 5 | NESTED LOOPS OUTER | | 3170K|
| 6 | NESTED LOOPS | | 3170K|
| 7 | NESTED LOOPS OUTER | | 3170K|
| 8 | NESTED LOOPS OUTER | | 3170K|
| 9 | NESTED LOOPS OUTER | | 3170K|
| 10 | NESTED LOOPS OUTER | | 3170K|
| 11 | NESTED LOOPS OUTER | | 3170K|
| 12 | NESTED LOOPS OUTER | | 3170K|
| 13 | NESTED LOOPS OUTER | | 3170K|
| 14 | NESTED LOOPS OUTER | | 3170K|
| 15 | NESTED LOOPS OUTER | | 3170K|
| 16 | NESTED LOOPS OUTER | | 3170K|
| 17 | NESTED LOOPS OUTER | | 3170K|
| 18 | NESTED LOOPS OUTER | | 3170K|
| 19 | NESTED LOOPS OUTER | | 3170K|
| 20 | NESTED LOOPS OUTER | | 3170K|
| 21 | NESTED LOOPS | | 3170K|
| 22 | NESTED LOOPS OUTER | | 3108K|
| 23 | NESTED LOOPS OUTER | | 3108K|
| 24 | NESTED LOOPS OUTER | | 3108K|
| 25 | NESTED LOOPS OUTER | | 3108K|
| 26 | NESTED LOOPS OUTER | | 3108K|
| 27 | NESTED LOOPS OUTER | | 3108K|
| 28 | NESTED LOOPS OUTER | | 3108K|
| 29 | NESTED LOOPS OUTER | | 3108K|
| 30 | TABLE ACCESS FULL | S_ORDER | 3108K|
| 31 | TABLE ACCESS BY INDEX ROWID| S_ADDR_ORG | 1 |
|* 32 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 |
| 33 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 |
|* 34 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 |
| 35 | TABLE ACCESS BY INDEX ROWID | S_CAMP_CON | 1 |
|* 36 | INDEX UNIQUE SCAN | S_CAMP_CON_P1 | 1 |
| 37 | TABLE ACCESS BY INDEX ROWID | S_ENTLMNT | 1 |
|* 38 | INDEX UNIQUE SCAN | S_ENTLMNT_P1 | 1 |
| 39 | TABLE ACCESS BY INDEX ROWID | S_SRC | 1 |
|* 40 | INDEX UNIQUE SCAN | S_SRC_P1 | 1 |
| 41 | TABLE ACCESS BY INDEX ROWID | S_CAMP_LD_WAVE | 1 |
|* 42 | INDEX UNIQUE SCAN | S_CAMP_LD_WAVE_P1 | 1 |
| 43 | TABLE ACCESS BY INDEX ROWID | S_DOC_QUOTE | 1 |
|* 44 | INDEX UNIQUE SCAN | S_DOC_QUOTE_P1 | 1 |
| 45 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 |
|* 46 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 |
|* 47 | VIEW | V_ORDER_ITEM | 1 |
| 48 | NESTED LOOPS | | 3128K|
| 49 | INDEX FAST FULL SCAN | S_ETL_I_IMG_25_M2 | 3128K|
|* 50 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 |
|* 51 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 |
| 52 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 |
|* 53 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 |
| 54 | TABLE ACCESS BY INDEX ROWID | S_VOL_DISCNT | 1 |
|* 55 | INDEX UNIQUE SCAN | S_VOL_DISCNT_P1 | 1 |
| 56 | TABLE ACCESS BY INDEX ROWID | S_VDISCNT_ITEM | 1 |
|* 57 | INDEX UNIQUE SCAN | S_VDISCNT_ITEM_P1 | 1 |
| 58 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | 1 |
|* 59 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | 1 |
|* 60 | TABLE ACCESS FULL | S_ORDER_ITM_PRI | 1 |
| 61 | TABLE ACCESS BY INDEX ROWID | S_INVLOC | 1 |
|* 62 | INDEX UNIQUE SCAN | S_INVLOC_P1 | 1 |
| 63 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 |
|* 64 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 |
| 65 | TABLE ACCESS BY INDEX ROWID | S_ORDER_X | 1 |
|* 66 | INDEX RANGE SCAN | S_ORDER_X_U1 | 1 |
| 67 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 |
|* 68 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 |
| 69 | TABLE ACCESS BY INDEX ROWID | S_POSTN | 1 |
|* 70 | INDEX UNIQUE SCAN | S_POSTN_P1 | 1 |
| 71 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | 1 |
|* 72 | INDEX UNIQUE SCAN | S_CONTACT_P1 | 1 |
| 73 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 74 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
| 75 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 76 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
| 77 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 78 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
| 79 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 |
|* 80 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 |
| 81 | TABLE ACCESS BY INDEX ROWID | S_ORDER_ITEM | 1 |
|* 82 | INDEX UNIQUE SCAN | S_ORDER_ITEM_P1 | 1 |
| 83 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 |
|* 84 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 |
| 85 | TABLE ACCESS BY INDEX ROWID | S_PROD_INT | 1 |
|* 86 | INDEX UNIQUE SCAN | S_PROD_INT_P1 | 1 |
| 87 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 88 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
| 89 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | 1 |
|* 90 | INDEX UNIQUE SCAN | S_ORG_EXT_P1 | 1 |
Predicate Information (identified by operation id):
32 - access("S_ORDER"."SHIP_ADDR_ID"="SHIPO"."ROW_ID")
PLAN_TABLE_OUTPUT
34 - access("S_ORDER"."BL_ADDR_ID"="BILL"."ROW_ID")
36 - access("S_ORDER"."CAMP_CON_ID"="S_CAMP_CON"."ROW_ID")
38 - access("S_ORDER"."ENTLMNT_ID"="S_ENTLMNT"."ROW_ID")
40 - access("S_ORDER"."PROMO_ID"="S_SRC"."ROW_ID")
42 - access("S_CAMP_CON"."CAMP_LD_WAVE_ID"="S_CAMP_LD_WAVE"."ROW_ID")
44 - access("S_ORDER"."QUOTE_ID"="QUOTE"."ROW_ID")
46 - access("S_ORDER"."PR_POSTN_ID"="POSOWNERORG"."ROW_ID")
47 - filter("S_ORDER_ITEM"."ORDER_ID"="S_ORDER"."ROW_ID")
50 - filter("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID" IS NOT NULL)
51 - access("S_ORDER_ITEM"."ROW_ID"="S_ETL_I_IMG_25"."ROW_ID")
53 - access("S_ORDER_ITEM"."VOL_DISCNT_ITEM_ID"="A"."ROW_ID")
55 - access("S_ORDER_ITEM"."VOL_DISCNT_ID"="S_VOL_DISCNT"."ROW_ID")
57 - access("S_ORDER_ITEM"."VOL_UPSELL_ITEM_ID"="B"."ROW_ID")
59 - access("S_ORDER_ITEM"."SHIP_ADDR_ID"="SHIPOITEM"."ROW_ID")
60 - filter("S_ORDER_ITEM"."ROW_ID"="OPRI"."PAR_ROW_ID")
62 - access("S_ORDER_ITEM"."SRC_INVLOC_ID"="S_INVLOC"."ROW_ID")
64 - access("S_ORDER_ITEM"."PROD_ID"="S_PROD_INT"."ROW_ID")
66 - access("S_ORDER_ITEM"."ORDER_ID"="S_ORDER_X"."PAR_ROW_ID")
68 - access("S_ORDER_ITEM"."CREATED_BY"="CRTD"."ROW_ID")
70 - access("CRTD"."PR_HELD_POSTN_ID"="POSCRTDORG"."ROW_ID")
72 - access("S_ORDER"."APPR_BY_EMP_ID"="APPRBYPOS"."ROW_ID")
74 - access("S_ORDER"."ACCNT_ID"="ACCNT"."ROW_ID")
76 - access("POSOWNERORG"."OU_ID"="OWNORG1"."ROW_ID")
78 - access("OWNORG1"."PAR_BU_ID"="OWNORG"."ROW_ID")
80 - access("S_ORDER_ITEM"."ROOT_ORDER_ITEM_ID"="ROOTOITEM"."ROW_ID")
82 - access("S_ORDER_ITEM"."PAR_ORDER_ITEM_ID"="PAROITEM"."ROW_ID")
84 - access("PAROITEM"."PROD_ID"="PARPROD"."ROW_ID")
86 - access("ROOTOITEM"."PROD_ID"="ROOTPROD"."ROW_ID")
88 - access("S_ORDER"."BU_ID"="VISORG1"."ROW_ID")
90 - access("VISORG1"."PAR_BU_ID"="VISORG"."ROW_ID")
Note
- Warning: basic plan statistics not available. These are only collected when:
* hint 'gather_plan_statistics' is used for the statement or
* parameter 'statistics_level' is set to 'ALL', at session or system level
154 rows selected.
Similar Messages
-
To track SQL Execution time automatically
Hi All,
I have requirement of tracking execution time of for each SQL executed.
For Eg, If i run command create index, in SQLPLus session, time to execute create index command should be tracked.
Any idea how to implement this?
Any help is appreciated.899485 wrote:
You have mistaken me. We have 2 environments. Dev,Prod and QA. 2 or 3?
So when code is moving to Production we need atleast approx time of deployment of code. Why should there be a relationship between execution times on Prod and Dev?
Do Prod and Dev have the very same hardware? Same type storage system? Same storage system configuration ito redundancy? Same data volumes? Same processing loads? Are the execution plans the same? Are the Oracle version and patch levels the same? Are the instance and database initialisation settings the same? Etc. etc.
It may vary but we want approx time. For that we want to capture SQL execution time.So if the Prod execution time is larger than the Dev approx time, then there is a problem?
How is that a more sensible approach than looking at overall performance and utilisation on Prod, determining the most CPU intensive SQLs, the most I/O intensive SQLs, the most often executed SQLs, and addressing these within the context and environment and h/w and processing loads on Prod?
Comparing execution times will simply say that the may be a problem. Not that there is a definitive problem. You still need to evaluate that metric and determine if this indicates a problem.
So seeing that this evaluation needs to be done, why not use better metrics? Like what AWR uses? Like what OEM shows?
Our application is dataware house application. So before insertion we disable the index and after load we enable index while enabling we capture execution time for enabling.Instrumentation is a different principle. And instrumenting your code to record the process run, the number of rows processed is a sensible approach to keeping track of production run-times, data volumes processed and even failures.
But I see very little value in taking Dev runtimes and trying to apply that as a benchmark on Prod for identifying performance issues. -
Resource plan to limit execution time
Hi,
I am using 11.1.0.7 database. Can anyone guide me how should i create a resource consumer group/resource plan and assign to my user "dev" so that any query run by this user should not take more than 10 minutes for execution and should abort if execution time exceeds 10 minutes.
Thanks
SalmanBEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_consumer_group(consumer_group => 'mytest_group', comment => '', cpu_mth => 'ROUND-ROBIN');
dbms_resource_manager.submit_pending_area();
END;
BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.create_plan( 'MYTEST_PLAN', '');
dbms_resource_manager.create_plan_directive(
plan => 'MYTEST_PLAN',
group_or_subplan => 'MYTEST_GROUP',
comment => '',
cpu_p1 => NULL, cpu_p2 => NULL, cpu_p3 => NULL, cpu_p4 => NULL,
cpu_p5 => NULL, cpu_p6 => NULL, cpu_p7 => NULL, cpu_p8 => NULL,
parallel_degree_limit_p1 => NULL,
active_sess_pool_p1 => NULL,
queueing_p1 => NULL,
switch_group => 'KILL_SESSION',
switch_time => 600,
switch_estimate => false,
max_est_exec_time => NULL,
undo_pool => NULL,
max_idle_time => NULL,
max_idle_blocker_time => NULL,
switch_time_in_call => NULL
dbms_resource_manager.create_plan_directive(
plan => 'MYTEST_PLAN',
group_or_subplan => 'OTHER_GROUPS',
comment => '',
cpu_p1 => NULL, cpu_p2 => NULL, cpu_p3 => NULL, cpu_p4 => NULL,
cpu_p5 => NULL, cpu_p6 => NULL, cpu_p7 => NULL, cpu_p8 => NULL,
parallel_degree_limit_p1 => NULL,
active_sess_pool_p1 => NULL,
queueing_p1 => NULL,
switch_group => NULL,
switch_time => NULL,
switch_estimate => false,
max_est_exec_time => NULL,
undo_pool => NULL,
max_idle_time => NULL,
max_idle_blocker_time => NULL,
switch_time_in_call => NULL
dbms_resource_manager.submit_pending_area();
END;
BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.set_consumer_group_mapping(
dbms_resource_manager.oracle_user,
'DEV',
'MYTEST_GROUP'
dbms_resource_manager.submit_pending_area();
END; -
I would like to see exact execution time of SQL query (without seeing TOAD execution time, because that may not be correct if I executed the same query 2nd time).
Please let me know.If you want to display the information in the front end, you would have to do something like
start_time := dbms_utility.get_time();
<<your query>>
end_time := dbms_utility.get_time();end_time - start_time would give you the wall clock run time of the query in hundredths of a second.
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC -
Need help Recording SQL Execution Times in Database
Hello,
I have an interesting thing I am tiring to do. I want to record how much time (Wall Clock) it took the database to execute any select statement against o one particular view lets call it CUST_ORDERS_V.
I would like to record who ran it, what the select statement was (SQL Text) and how much time it took and maybe a few other ancillary things if possible.
Looking at most of my requirements took me right to Oracle Auditing and the SYS.AUD$ table. After setting up auditing with:
audit_trail=db,extended
and
audit select on ME.CUST_ORDERS_V by access;I get every piece of information I need except for the execution time! Wow that would be great if Oracle recorded that!!! So I was thinking if I could. I was considering a trigger on SYS.AUD$ (I know evil thoughts) that would look into some V$ view and get the execution time and write it into some custom table with a link back to SYS.AUD$.
This might be the complete wrong way to do it. I was wondering if anyone had any ideas on this.
I am running on 11.2.0.3 EE. I am on EE so I can use Fine Grained Auditing if it is needed. However I DO NOT have the Tuning or Diagnostic Pack.>
Hi again,
Yes, a complete set of times from end to end would be great. However
for now I need to stick with what is in my domain of control, the database.
Maybe after the DB I will look to get the others.But your point about the operators blaming the db brings up the probability
that after you tell them that the db is not the issue, they'll start to blame
the app server, the cabling, their OS, the browser, the tea-lady...
If you have click===> page, they have no more places to hide and have to
actually work for a living ;)
I do not think I can access v$active_session_history as I do not have the Tuning Pack.Well, presumably there is a business case for this project. Why not tell management
that it's required?
Otherwise, you could go to ashmasters.com - a site run by Kyle Hailey (Oak Table
member and author). He has an Open Source ASH "substitute" which you might
like to try - haven't used it myself, but if Kyle Hailey's behind it, then it's at
least worthy of investigation.
HTH,
Paul... -
Where can i get the sql execution time ?
Hi ,
I want to check for a particular execution time of an sql statement
from v$sqlarea shld i get both the cpu_time & elapsed_time ?
the no seems very huge i.e --> 12592966663 and they are in nanosecons , milliseconds or secs ??
is this the total time since it was in the library cache or the last time it ran it took 12592966663 ??
kindly adviseHi ,
But can i also check is this the cpu_time & elapsed_time for the most current execution or this is the total since it was last executed
as the nos --> 13,518,633,330 when even divided by 1000,000(micro seconds) seems abit long as well
tks & rdgs -
Explain plan shows 300T of TempSpc and 999 hours - tuning request
Hi,
I have a query which obtains summary statistics. There is an items table which contains the dictionary of items which can be recorded. There is an events table which contains the item ID, timestamp and a value. The query summarizes the data for each item. e.g. Mean, stddev, sample values, length. I have trimmed the query down as simply as possible and am having a problem with large temp space and runtime estimates in the explain plan. Here is the query:
WITH ChartItems AS (
SELECT
ci.itemid,
ci.label,
ci.category,
ci.description,
COUNT(*),
COUNT(distinct subject_id)
FROM mimic2v26.d_chartitems ci
JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
--WHERE ci.itemid = 51
GROUP BY ci.itemid,
ci.label,
ci.category,
ci.description
--select * from ChartItems;
, RawData AS (
SELECT DISTINCT
ci.itemid,
ci.label,
ci.category,
ci.description,
last_value(ce.value1) ignore nulls over (partition BY ci.itemid order by
ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS
value1_last
FROM ChartItems ci
JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
select * from RawData;Which gives this explain plan:
Plan hash value: 642453121
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 4811G| 1238T| | 3686M (13)|999:59:59 |
| 1 | VIEW | | 4811G| 1238T| | 3686M (13)|999:59:59 |
| 2 | HASH UNIQUE | | 4811G| 258T| | 3686M (13)|999:59:59 |
| 3 | WINDOW BUFFER | | 4811G| 258T| | 3686M (13)|999:59:59 |
| 4 | SORT GROUP BY | | 4811G| 258T| 317T| 3686M (13)|999:59:59 |
|* 5 | HASH JOIN | | 4811G| 258T| 4943M| 25M (90)| 85:14:28 |
| 6 | VIEW | VW_DAG_0 | 152M| 3199M| | 1366K (1)| 04:33:18 |
| 7 | HASH GROUP BY | | 152M| 4216M| 5839M| 1366K (1)| 04:33:18 |
|* 8 | HASH JOIN | | 152M| 4216M| | 147K (2)| 00:29:36 |
| 9 | TABLE ACCESS FULL | D_CHARTITEMS | 4832 | 96640 | | 7 (0)| 00:00:01 |
| 10 | INDEX FAST FULL SCAN| CHARTEVENTS_O2 | 196M| 1683M| | 147K (1)| 00:29:25 |
| 11 | TABLE ACCESS FULL | CHARTEVENTS | 196M| 6922M| | 616K (1)| 02:03:19 |
Predicate Information (identified by operation id):
5 - access("CE"."ITEMID"="ITEM_2")300T of temp space! Ouch.
TKPROF output (I let the query run for a short while. I let it run for ages earlier, but wasn't tracing the session. Should I let it run for longer?):
TKPROF: Release 11.2.0.3.0 - Development on Tue Jul 10 16:54:27 2012
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
Trace file: /oracle/11gr2/app/oracle/diag/rdbms/mimic2/mimic2/trace/mimic2_ora_6507.trc
Sort options: default
count = number of times OCI procedure was executed
cpu = cpu time in seconds executing
elapsed = elapsed time in seconds executing
disk = number of physical reads of buffers from disk
query = number of buffers gotten for consistent read
current = number of buffers gotten in current mode (usually for update)
rows = number of rows processed by the fetch or execute call
WITH ChartItems AS (
SELECT
ci.itemid,
ci.label,
ci.category,
ci.description,
COUNT(*),
COUNT(distinct subject_id)
FROM mimic2v26.d_chartitems ci
JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
GROUP BY ci.itemid,
ci.label,
ci.category,
ci.description
, RawData AS (
SELECT DISTINCT
ci.itemid,
ci.label,
ci.category,
ci.description,
last_value(ce.value1) ignore nulls over (partition BY ci.itemid order by
ce.charttime ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS
value1_last
FROM ChartItems ci
JOIN mimic2v26.chartevents ce ON ce.itemid = ci.itemid
select * from RawData
call count cpu elapsed disk query current rows
Parse 1 0.02 0.02 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 582.40 712.23 705238 737351 0 0
total 3 582.43 712.25 705238 737351 0 0
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 85
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
0 0 0 VIEW (cr=0 pr=0 pw=0 time=184 us cost=3686387254 size=1361581801333882 card=4811243114254)
0 0 0 HASH UNIQUE (cr=0 pr=0 pw=0 time=180 us cost=3686387254 size=283863343740986 card=4811243114254)
0 0 0 WINDOW BUFFER (cr=0 pr=0 pw=0 time=74 us cost=3686387254 size=283863343740986 card=4811243114254)
0 0 0 SORT GROUP BY (cr=0 pr=0 pw=0 time=59 us cost=3686387254 size=283863343740986 card=4811243114254)
178073889 178073889 178073889 HASH JOIN (cr=737351 pr=705238 pw=124635 time=476372451 us cost=25572251 size=283863343740986 card=4811243114254)
6211631 6211631 6211631 VIEW VW_DAG_0 (cr=613768 pr=581413 pw=35805 time=286546567 us cost=1366486 size=3354399576 card=152472708)
6211631 6211631 6211631 HASH GROUP BY (cr=613768 pr=581413 pw=35805 time=281271878 us cost=1366486 size=4421708532 card=152472708)
196182740 196182740 196182740 HASH JOIN (cr=613768 pr=545608 pw=0 time=557485047 us cost=147987 size=4421708532 card=152472708)
4832 4832 4832 TABLE ACCESS FULL D_CHARTITEMS (cr=18 pr=16 pw=0 time=13666 us cost=7 size=96640 card=4832)
196182740 196182740 196182740 INDEX FAST FULL SCAN CHARTEVENTS_O2 (cr=613750 pr=545592 pw=0 time=148428499 us cost=147046 size=1765644660 card=196182740)(object id 96501)
10683044 10683044 10683044 TABLE ACCESS FULL CHARTEVENTS (cr=123583 pr=123825 pw=0 time=25175510 us cost=616507 size=7258761380 card=196182740)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
db file sequential read 2 0.01 0.01
db file scattered read 3 0.02 0.03
direct path read 5265 0.75 77.13
asynch descriptor resize 1 0.00 0.00
direct path write temp 15077 0.71 45.54
direct path read temp 2387 0.29 13.54
SQL*Net break/reset to client 1 0.66 0.66
SQL*Net message from client 1 0.00 0.00
SQL ID: 7jby2dxrpkkm9 Plan Hash: 1388734953
select SYS_CONTEXT('USERENV','SESSIONID')
from
dual
call count cpu elapsed disk query current rows
Parse 1 0.00 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 0 0 1
total 3 0.00 0.01 0 0 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 85
Number of plan statistics captured: 1
Rows (1st) Rows (avg) Rows (max) Row Source Operation
1 1 1 FAST DUAL (cr=0 pr=0 pw=0 time=4 us cost=2 size=0 card=1)
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 1 0.00 0.00
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 2 0.02 0.04 0 0 0 0
Execute 2 0.00 0.00 0 0 0 0
Fetch 2 582.40 712.23 705238 737351 0 1
total 6 582.43 712.27 705238 737351 0 1
Misses in library cache during parse: 2
Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 4 0.00 0.00
db file sequential read 2 0.01 0.01
db file scattered read 3 0.02 0.03
direct path read 5265 0.75 77.13
asynch descriptor resize 1 0.00 0.00
direct path write temp 15077 0.71 45.54
direct path read temp 2387 0.29 13.54
SQL*Net break/reset to client 1 0.66 0.66
SQL*Net message from client 3 14.99 15.01
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
call count cpu elapsed disk query current rows
Parse 0 0.00 0.00 0 0 0 0
Execute 0 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
total 0 0.00 0.00 0 0 0 0
Misses in library cache during parse: 0
2 user SQL statements in session.
0 internal SQL statements in session.
2 SQL statements in session.
Trace file: /oracle/11gr2/app/oracle/diag/rdbms/mimic2/mimic2/trace/mimic2_ora_6507.trc
Trace file compatibility: 11.1.0.7
Sort options: default
1 session in tracefile.
2 user SQL statements in trace file.
0 internal SQL statements in trace file.
2 SQL statements in trace file.
2 unique SQL statements in trace file.
24245 lines in trace file.
728 elapsed seconds in trace file.Optimizer parameters:
NAME TYPE VALUE
optimizer_capture_sql_plan_baselines boolean FALSE
optimizer_dynamic_sampling integer 2
optimizer_features_enable string 11.2.0.3
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 TRUE Can anyone help me figure out what's wrong?
This is a data warehouse, with up to date statistics. The DB is version 11.2.0.3.0
Thanks,
Danrp0428 wrote:
>
I trimmed the query down to the simplest that I could which still exhibited the problem
>
The DISTINCT isn't the issue. The issue is that the query you posted isn't necessary and doesn't appear to be represented in the plan that you posted.
That makes it hard to tell where the cardinality misestimates are coming from. How many records does the actual first query (the one with the group by) return? You have a SELECT * commented out - how many rows?No, it's not necessary, but then it isn't the full query. The estimates are still wrong when I pass the count columns through to the second query. The full query contains many more analytic functions in the second query, and some additions to the first. It could probably be cleaned up a little, but the current structure makes logical sense. Should I change the aggregates to analytics and move them into the second query? In any case, there definitely seems to be something wrong with the plan.
I don't know what you mean when you say "doesn't appear to be represented in the plan that you posted".
I just checked the first query and while the temp space has dropped to a reasonable amount, the number of rows in the hash join is still way off (I didn't notice before because I was looking at the temp space). The rows for d_chartitems and the index on chartevents are correct:
Plan hash value: 1249235674
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 152M| 35G| | 1366K (1)| 04:33:18 |
| 1 | VIEW | | 152M| 35G| | 1366K (1)| 04:33:18 |
| 2 | WINDOW SORT | | 152M| 4216M| 5839M| 1366K (1)| 04:33:18 |
|* 3 | HASH JOIN | | 152M| 4216M| | 147K (2)| 00:29:36 |
| 4 | TABLE ACCESS FULL | D_CHARTITEMS | 4832 | 96640 | | 7 (0)| 00:00:01 |
| 5 | INDEX FAST FULL SCAN| CHARTEVENTS_O2 | 196M| 1683M| | 147K (1)| 00:29:25 |
Predicate Information (identified by operation id):
3 - access("CE"."ITEMID"="CI"."ITEMID")Edited by: danscott on Jul 10, 2012 5:43 PM
Edited by: danscott on Jul 11, 2012 6:28 AM -
Hi,
I want to know how can I show the time spent for procedures7functions??
Just like what i see for sql querys.
Regards..Not unless you grab start/stop times and display it yourself with DBMS_OUTPUT.
declare
lc_start constant date := sysdate;
begin
your_procedure_here;
dbms_ouput('Elapsed Seconds: ' || (sysdate-lv_start)*24*60*60);
end;
/...or even something like this if you don't want to save the above as a snippet or retype it every time...
procedure my_exec(p_proc_in in varchar2)
as
lc_start constant date := sysdate;
begin
execute immediate 'begin ' || p_proc_in || '; end;';
dbms_ouput('Elapsed Seconds: ' || (sysdate-lv_start)*24*60*60);
end my_exec;
exec my_exec('your_procedure_here')Edited by: DylanB123 on Sep 30, 2010 4:44 PM -
What will SQL execution Time of the information fatching and cost to Oralce
Hi
I would like to this information from oracle EBS and also know the process of fatching the information
1)
Product and invoice No
1. 01 – Asia
2. 02 – India
3. 03 –West Zone
4. 04 – Maharashtra
5. 05 –Customer Group X
6. 06 –Product category Y
7. 07 –Invoice for the year of 2009
8. 08 –Invoice for the month of Nov
9. 09 –Invoice for the day of 20
10. 10 –invoice No is 1001
Sales Purchase, Cash, Bank, Expenses Transaction information like as
Day Upto Week Upto Month Upto Quarter Upto Year
1 100 1200 25000 500000 4500000
2 140 2200 29000 560000 5000000
3 170 1800 35000 590000 5500000
Total
Any one can help me ?
Thanks & regardsNo database version, no formatted code, how are we supposed to be able to see anything in all that mess.
At a quick glance, the one point I'd certainly look at is this:
AND NOT ( chain_id LIKE '001182%'
OR chain_id LIKE '001471%'
OR chain_id LIKE '001771000001%'
OR chain_id LIKE '001773000001%'
OR chain_id LIKE '001776000001%'
OR chain_id LIKE '001780000001%'
.. cut ..
OR chain_id LIKE '010034000001%'
OR chain_id LIKE '010035000001%'
OR chain_id LIKE '010036000001%'
OR chain_id LIKE '010038000001%'
OR chain_id LIKE '010039000001%'
OR chain_id LIKE '010040000001%'
OR chain_id LIKE '010041000001%'
OR chain_id LIKE '010042000001%'
)Could these values not be put into a global temporary table or something and use proper joins rather than some nasty list of OR statements?
Consider reading the following threads:
[How to post a SQL statement tuning request|http://forums.oracle.com/forums/thread.jspa?threadID=863295&tstart=0]
and
[When your query takes too long...|http://forums.oracle.com/forums/thread.jspa?messageID=1812597#1812597] -
SQL Tuning and OPTIMIZER - Execution Time with " AND col .."
Hi all,
I get a question about SQL Tuning and OPTIMIZER.
There are three samples with EXPLAIN PLAN and execution time.
This "tw_pkg.getMaxAktion" is a PLSQL Package.
1.) Execution Time : 0.25 Second
2.) Execution Time : 0.59 Second
3.) Execution Time : 1.11 Second
The only difference is some additional "AND col <> .."
Why is this execution time growing so strong?
Many Thanks,
Thomas
----[First example]---
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as dbadmin2
SQL>
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3 FROM studie
4 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900 ;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| 0 | SELECT STATEMENT | | 220 | 880 | 5 (40)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 | 220 | 880 | 5 (40)| 00:00:
Predicate Information (identified by operation id):
1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900)
13 rows selected
SQL>
Execution time (PL/SQL Developer says): 0.25 seconds
----[/First]---
----[Second example]---
Connected to Oracle Database 10g Enterprise Edition Release 10.2.0.3.0
Connected as dbadmin2
SQL>
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3 FROM studie
4 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900
6 AND max_aktion.max_aktion_id <> 692;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| 0 | SELECT STATEMENT | | 11 | 44 | 6 (50)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 | 11 | 44 | 6 (50)| 00:00:
Predicate Information (identified by operation id):
1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
"TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692)
14 rows selected
SQL>
Execution time (PL/SQL Developer says): 0.59 seconds
----[/Second]---
----[Third example]---
SQL> EXPLAIN PLAN FOR
2 SELECT * FROM ( SELECT studie_id, tw_pkg.getMaxAktion(studie_id) AS max_aktion_id
3 FROM studie
4 ) max_aktion
5 WHERE max_aktion.max_aktion_id < 900
6 AND max_aktion.max_aktion_id <> 692
7 AND max_aktion.max_aktion_id <> 392;
Explained
SQL> SELECT * FROM TABLE(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 3201460684
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
| 0 | SELECT STATEMENT | | 1 | 4 | 6 (50)| 00:00:
|* 1 | INDEX FAST FULL SCAN| SYS_C005393 | 1 | 4 | 6 (50)| 00:00:
Predicate Information (identified by operation id):
1 - filter("TW_PKG"."GETMAXAKTION"("STUDIE_ID")<900 AND
"TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>692 AND
"TW_PKG"."GETMAXAKTION"("STUDIE_ID")<>392)
15 rows selected
SQL>
Execution time (PL/SQL Developer says): 1.11 seconds
----[/Third]---Edited by: thomas_w on Jul 9, 2010 11:35 AM
Edited by: thomas_w on Jul 12, 2010 8:29 AMHi,
this is likely because SQL Developer fetches and displays only limited number of rows from query results.
This number is a parameter called 'sql array fetch size', you can find it in SQL Developer preferences under Tools/Preferences/Database/Advanced tab, and it's default value is 50 rows.
Query scans a table from the beginning and continue scanning until first 50 rows are selected.
If query conditions are more selective, then more table rows (or index entries) must be scanned to fetch first 50 results and execution time grows.
This effect is usually unnoticeable when query uses simple and fast built-in comparison operators (like = <> etc) or oracle built-in functions, but your query uses a PL/SQL function that is much more slower than built-in functions/operators.
Try to change this parameter to 1000 and most likely you will see that execution time of all 3 queries will be similar.
Look at this simple test to figure out how it works:
CREATE TABLE studie AS
SELECT row_number() OVER (ORDER BY object_id) studie_id, o.*
FROM (
SELECT * FROM all_objects
CROSS JOIN
(SELECT 1 FROM dual CONNECT BY LEVEL <= 100)
) o;
CREATE INDEX studie_ix ON studie(object_name, studie_id);
ANALYZE TABLE studie COMPUTE STATISTICS;
CREATE OR REPLACE FUNCTION very_slow_function(action IN NUMBER)
RETURN NUMBER
IS
BEGIN
RETURN action;
END;
/'SQL array fetch size' parameter in SQLDeveloper has been set to 50 (default). We will run 3 different queries on test table.
Query 1:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id < 900
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 1.22 1.29 0 1310 0 50
total 3 1.22 1.29 0 1310 0 50
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
50 INDEX FAST FULL SCAN STUDIE_IX (cr=1310 pr=0 pw=0 time=355838 us cost=5536 size=827075 card=165415)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
50 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id < 900
AND max_aktion.max_aktion_id > 800
call count cpu elapsed disk query current rows
Parse 1 0.00 0.01 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 8.40 8.62 0 9351 0 50
total 3 8.40 8.64 0 9351 0 50
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
50 INDEX FAST FULL SCAN STUDIE_IX (cr=9351 pr=0 pw=0 time=16988202 us cost=5552 size=41355 card=8271)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
50 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id = 600
call count cpu elapsed disk query current rows
Parse 1 0.01 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 18.72 19.16 0 19315 0 1
total 3 18.73 19.16 0 19315 0 1
Misses in library cache during parse: 1
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
1 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 1 - 1,29 sec, 50 rows fetched, 1310 index entries scanned to find these 50 rows.
Query 2 - 8,64 sec, 50 rows fetched, 9351 index entries scanned to find these 50 rows.
Query 3 - 19,16 sec, only 1 row fetched, 19315 index entries scanned (full index).
Now 'SQL array fetch size' parameter in SQLDeveloper has been set to 1000.
Query 1:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id < 900
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 18.35 18.46 0 19315 0 899
total 3 18.35 18.46 0 19315 0 899
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
899 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=20571272 us cost=5536 size=827075 card=165415)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
899 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 2:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id < 900
AND max_aktion.max_aktion_id > 800
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 18.79 18.86 0 19315 0 99
total 3 18.79 18.86 0 19315 0 99
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
99 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=32805696 us cost=5552 size=41355 card=8271)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
99 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)Query 3:
SELECT * FROM ( SELECT studie_id, very_slow_function(studie_id) AS max_aktion_id
FROM studie
) max_aktion
WHERE max_aktion.max_aktion_id = 600
call count cpu elapsed disk query current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 18.69 18.84 0 19315 0 1
total 3 18.69 18.84 0 19315 0 1
Misses in library cache during parse: 0
Optimizer mode: ALL_ROWS
Parsing user id: 93 (TEST)
Rows Row Source Operation
1 INDEX FAST FULL SCAN STUDIE_IX (cr=19315 pr=0 pw=0 time=0 us cost=5536 size=165415 card=33083)(object id 79865)
Rows Execution Plan
0 SELECT STATEMENT MODE: ALL_ROWS
1 INDEX MODE: ANALYZED (FAST FULL SCAN) OF 'STUDIE_IX' (INDEX)And now:
Query 1 - 18.46 sec, 899 rows fetched, 19315 index entries scanned.
Query 2 - 18.86 sec, 99 rows fetched, 19315 index entries scanned.
Query 3 - 18.84 sec, 1 row fetched, 19315 index entries scanned. -
Execution time, elapsed time of an sql query
Can you please tell me how to get the execution time, elapsed time of an sql query
user8680248 wrote:
I am running query in the database
I would like to know how long the query take the time to completeWhy? That answer can be totally meaningless as the VERY SAME query on the VERY SAME data on the VERY SAME database in the VERY SAME Oracle session can and will show DIFFERENT execution times.
So why do you want to know a specific query's execution time? What do you expect that to tell you?
If you mean that you want to know how long an existing query being executed is still going to take - that's usually quite difficult to determine. Oracle does provide a view on so-called long operations. However, only certain factors of a query's execution will trigger that this query is a long operation - and only for those specific queries will there be long operation stats that provide an estimated completion time.
If your slow and long running query does not show in long operation, then Oracle does not consider it a long operation - it fails to meet the specific criteria and factors required as a long operation. This is not a bug or an error. Simply that your query does not meet the basic requirements to be viewed as a long operation.
Oracle however provides the developer with the means to create long operations (using PL/SQL). You need to know and do the following:
a) need to know how many units of work to do (e.g. how many fetches/loop iterations/rows your code will process)
b) need to know how many units of work thus far done
c) use the DBMS_APPLICATION_INFO package to create a long operation and continually update the operation with the number of work units thus far done
It is pretty easy to implement this in PL/SQL processing code (assuming requirements a and b can be met) - and provide long operation stats and estimated completion time for the DBA/operators/users of the database, waiting on your process to complete. -
Can the format of a SQL Statement modify the execution time of an SQL ....
Can the format of a SQL Statement modify the execution time of an SQL statement?
Thanks in advanceIt depends on:
1) What oracle version are you using
2) What do you mean for "format"
For example: if you're on Oracle9i and changing format means changing the order of the tables in the FROM clause and you're using Rule Based Optimizer then the execution plan and the execution time can be very different...
Max
[My Italian Oracle blog|http://oracleitalia.wordpress.com/2009/12/29/estrarre-i-dati-in-formato-xml-da-sql/] -
Loading (point) features takes MapViewer 20 times sql exec time?
I have a map which contains only one theme which shows 14500 point geometries stored in a table (accessed via a view). Rendering the map takes a long time, more than 22 secs. Looking at the log from MapViewer it seems like the sql execution time is not the problem, also in a sql editor the query is fast. Labeling and rendering is fast too. CPU is not very busy while rendering the map, memory usage is under 70 MB. The problem seems to be loading the features after executing the sql query.
This is the logging:
06/01/24 08:46:23 Tue Jan 24 08:46:23 CET 2006 DEBUG [oracle.sdovis.theme.pgtp] [ STOFFEN_INSTALLATIES ] sql exec time: 100ms, total time loading 14593 features: 21401ms.
06/01/24 08:56:32 Tue Jan 24 08:56:32 CET 2006 INFO [oracle.sdovis.DBMapMaker] **** time spent on loading features: 21221ms.
06/01/24 08:56:32 Tue Jan 24 08:56:32 CET 2006 FINEST [oracle.sdovis.RE] xfm: 0.0377536231884058 0.0 0.0 -0.0377536231884058 -2650.2018115942033 17432.848768115942
06/01/24 08:56:33 Tue Jan 24 08:56:33 CET 2006 DEBUG [oracle.sdovis.VectorRenderer] time to render theme STOFFEN_INSTALLATIES with 14593 styled features: 951ms
06/01/24 08:56:33 Tue Jan 24 08:56:33 CET 2006 DEBUG [oracle.sdovis.VectorRenderer] time to label theme STOFFEN_INSTALLATIES with 14593 styled features: 0ms
06/01/24 08:56:33 Tue Jan 24 08:56:33 CET 2006 INFO [oracle.sdovis.DBMapMaker] **** time spent on rendering: 951ms
06/01/24 08:56:33 Tue Jan 24 08:56:33 CET 2006 DEBUG [oracle.lbs.mapserver.core.MapperPool] freeMapper() begins...
06/01/24 08:56:33 Tue Jan 24 08:56:33 CET 2006 DEBUG [oracle.lbs.mapserver.core.RealWorker] [RealWorker] preparation time: 0ms
06/01/24 08:56:33 Tue Jan 24 08:56:33 CET 2006 DEBUG [oracle.lbs.mapserver.core.RealWorker] [RealWorker] querying/rendering time: 22182ms
06/01/24 08:56:33 Tue Jan 24 08:56:33 CET 2006 DEBUG [oracle.lbs.mapserver.core.RealWorker] [RealWorker] packing time: 60ms
06/01/24 08:56:33 Tue Jan 24 08:56:33 CET 2006 DEBUG [oracle.lbs.mapserver.core.RealWorker] [RealWorker] --------------- total time: 22242ms
22 seconds is too long for our application. Does anyone know what could be wrong and what I could do to improve this?
Thanks in advance,
Ida22 secs seems too long.
I tried something similar on old Sun Sparc (Ultra 60) machines. db on one Sun box, MV on another. Both on same local network.
SQL> select count(1) from openls_dir_businesses where country_subdivision='MD' ;
COUNT(1)
24638
No indexes, no other optimizations
Fetching and rendering 24638 points took 19 secs or so.
Fetch time 10 secs, render time 9 secs.
Tue Jan 24 15:09:01 EST 2006 INFO [oracle.sdovis.DBMapMaker] **** time spent on loading features: 10741ms.
Tue Jan 24 15:09:10 EST 2006 INFO [oracle.sdovis.DBMapMaker] **** time spent on rendering: 9083ms -
Hi,
I am trying to find the execution time of a SQL query.
How to do it?
Regards.
Ashish>I am trying to find the execution time of a SQL query.
How to do it?
Psuedo code:
time = SystemTime() -- get the current system time
RunSQL() -- run the SQL statement
print( SystemTime()-time ) -- displays the difference in time
Needless to say that this is utterly useless most of the time. The first time a query is run it may be subjected to a hard parse. The second time not. So the exact same SQL will show different execution times. This execution time measurement is useless as it does not tell you anything - except that there was a difference in time.
The first time a query runs it make do a lot of physical I/O to read the data from disk. The second time around, with the data in the db buffer cache, it makes use of logical I/O. There is a significant difference in the execution of the exact same SQL. Again, the measurement of execution is meaningless. It does not tell you anything. One number versus another number. Nothing meaningful to compare.
Fact. The very same SQL will have different execution times.
So what do you hope to gain from measuring it? -
Why the execution time increases with a while loop, but not with "Run continuously" ?
Hi all,
I have a serious time problem that I don't know how to solve because I don't know exactly where it comes from.
I command two RF switches via a DAQ card (NI USB-6008). Only one position at the same time can be selected on each switch. Basically, the VI created for this functionnality (by a co-worker) resets all the DAQ outputs, and then activates the desired ones. It has three inputs, two simp0le string controls, and an array of cluster, which contains the list of all the outputs and some informations to know what is connected (specific to my application).
I use this VI in a complex application, and I get some problems with the execution time, which increased each time I callled the VI, so I made a test VI (TimeTesting.vi) to figure out where the problem came from. In this special VI I record the execution time in a csv file to analyse then with excel.
After several tests, I found that if I run this test VI with the while loop, the execution time increases at each cycle, but if I remove the while loop and use the "Run continuously" funtionnality, the execution time remains the same. In my top level application I have while loops and events, and so the execution time increases too.
Could someone explain me why the execution time increases, and how can I avoid that? I attached my test VI and the necessary subVIs, as well as a picture of a graph which shows the execution time with a while loop and with the "run continuously".
Thanks a lot for your help!
Solved!
Go to Solution.
Attachments:
TimeTesting.zip 70 KB
Graph.PNG 20 KBjul7290 wrote:
Thank you very much for your help! I added the "Clear task" vi and now it works properly.
If you are still using the RUn Continuously you should stop. That is meant strictly for debugging. In fact, I can't even tell you the last time I ever used it. If you want your code to repeat you should use loops and control the behavior of the code.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Maybe you are looking for
-
How to turn this Java into something I can use in CF?
Hi - Following on from a recent post about how to strip our special characters from a string before insertion to the db I have found this Java code - my question is, how can I turn this into something I can use with CF? I think I need to use the cfsc
-
How to convert XMl file to XSD file
how to convert XMl file to XSD file ? i have a xml file format it has to be converted to xsd file through ABAP . Regards Anbu B
-
New-ish Macbook booting/running extremely slow after 10.6.3?
Hi all, I bought a refurbished Macbook in March 2010. A few days ago I installed the big updates along with 10.6.3 and everything was fine. I was then trying to play an .avi with VLC media player with some other programs open (Firefox, iTunes I think
-
Can you change sticky notes to another file type with OS X yosemite?
-
WORD Modification de la hauteur de ligne d'un tableau
Bonjour Je veux modifier la hauteur des lignes un tableau insérer dans un fichier word J'ai voulu reprendre en effectuant une copie du VI "Append Text Table to Report.VI" Ce VI est dans "NI_report.lvclass:Append Table to Report.vi" qui est en faite "