SQL performance improvement
Hi All,
This is a continuation of the below given link (which died unanswered)
Row to column - SQL performance improvement
I was working on some logic and came up with an SQL posted below:
SELECT *
FROM
(SELECT NULL no_of_cols,
NULL brand_name,
NULL model,
NULL make,
NULL assetno,
NULL RACNO,
NULL branch,
LTRIM (SUBSTR (SYS_CONNECT_BY_PATH (b, ' | '), 2), ' | ' ) config_det,
NULL status,
NULL code
FROM
(SELECT 1 sno,
mst.prod_id,
prod_name b,
DENSE_RANK () OVER (ORDER BY hierarchy_key, mst.prod_id) rn
FROM appl_common_cat_mst,
appl_prod_cat_map MAP,
appl_common_prod_mst mst
WHERE ID = cat_id
AND MAP.prod_id = mst.prod_id
AND ID = 3
WHERE CONNECT_BY_ISLEAF = 1
START WITH rn = 1
CONNECT BY PRIOR rn = rn - 1
AND PRIOR sno = sno
UNION
SELECT DISTINCT rn no_of_cols,
model,
brand_name,
make,
assetno,
RACNO,
br_name branch,
LTRIM (SUBSTR (SYS_CONNECT_BY_PATH ((NVL (inv_descr, '-') ), ' | ' ), 2 ), ' | ' ) config_det,
sts,
code
FROM
(SELECT model,
br_name,
make,
brand_name,
assetno,
RACNO,
PROD_ID,
INV#,
ASSET_GRP,
LTRIM(SYS_CONNECT_BY_PATH(inv_descr, ', '),', ') inv_descr,
RN,
STS,
CODE ,
CNT
FROM
(SELECT ROW_NUMBER() OVER (PARTITION BY ASSETNO, ASSET_GRP, RN ORDER BY ASSETNO, ASSET_GRP, RN) INV_RN,
T1.*
FROM
(SELECT model,
MAX (br_name) OVER (PARTITION BY listofprod.assetno ORDER BY listofprod.assetno)br_name,
make,
brand_name,
listofprod.assetno,
MAX (racno) OVER (PARTITION BY listofprod.assetno ORDER BY listofprod.assetno) racno,
listofprod.prod_id,
inv#,
asset_grp,
inv_descr,
DENSE_RANK () OVER (PARTITION BY listofprod.assetno ORDER BY hierarchy_key, listofprod.prod_id) rn,
STS,
CODE ,
COUNT(inv_descr) over (partition BY asset_grp, code,listofprod.assetno order by asset_grp, code,listofprod.assetno) cnt
FROM
(SELECT brand_name,
inv_hdr.model,
inv_hdr.make,
asset_hdr.assetno,
racno,
inv_hdr.inv#,
inv_hdr.prod_id,
DBMS_LOB.SUBSTR (INV_DESCR, 4000, 1 ) INV_DESCR,
br_name
FROM APPL_ASSET_HDR_ACTL ASSET_HDR,
APPL_INVENTORY_HDR_ACTL INV_HDR,
appl_branch_mst brch_mst
WHERE inv_hdr.assetno = asset_hdr.assetno
AND ASSET_HDR.CAT_ID = 3
AND branch_code = br_code
AND BRANCH_CODE = 'MU'
) CONFIG,
(SELECT DISTINCT assetno,
listofprod.prod_id,
asset_grp,
sts,
code,
hierarchy_key
FROM
(SELECT DISTINCT asset_hdr.assetno,
asset_hdr.cat_id asset_grp,
inv_hdr.prod_id,
cmn_mst.VALUE sts,
cmn_mst.code code
FROM appl_asset_hdr_actl asset_hdr,
appl_inventory_hdr_actl inv_hdr,
appl_common_mst cmn_mst
WHERE inv_hdr.assetno = asset_hdr.assetno
AND asset_hdr.cat_id = 3
AND inv_hdr.current_sts = cmn_mst.code
) config,
(SELECT mst.prod_id,
hierarchy_key
FROM appl_common_cat_mst,
appl_prod_cat_map MAP,
appl_common_prod_mst mst
WHERE ID = cat_id
AND MAP.prod_id = mst.prod_id
AND ID = 3
) listofprod
ORDER BY assetno,
hierarchy_key,
LISTOFPROD.PROD_ID
) LISTOFPROD
WHERE CONFIG.ASSETNO (+)= LISTOFPROD.ASSETNO
AND CONFIG.PROD_ID (+) = LISTOFPROD.PROD_ID
)T1
)T2
WHERE connect_by_isleaf = 1
AND CNT <> 0
CONNECT BY prior INV_RN = INV_RN -1
AND PRIOR assetno = assetno
AND prior ASSET_GRP = ASSET_GRP
AND PRIOR RN = RN
START WITH INV_RN = 1
)X
WHERE connect_by_isleaf = 1
AND cnt <> 0
START WITH RN = 1
CONNECT BY PRIOR rn = rn - 1
AND PRIOR assetno = assetno
AND prior ASSET_GRP = ASSET_GRP
ORDER BY 1 ASC nulls FIRST
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
"CORE 11.2.0.1.0 Production"
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - ProductionWhich works perfectly on one machine (which is a win XP, c2d, 3gb ram machine), it gives result in less than 2 seconds . The result of
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);is
Plan hash value: 2219017987
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
| 0 | SELECT STATEMENT | | 685 | 1505K| | 2170 (16)| 00:00:27 |
| 1 | VIEW | | 685 | 1505K| | 2170 (16)| 00:00:27 |
| 2 | SORT UNIQUE | | 685 | 1416K| 3656K| 1863 (100)| 00:00:23 |
| 3 | UNION-ALL | | | | | | |
|* 4 | FILTER | | | | | | |
|* 5 | CONNECT BY WITH FILTERING | | | | | | |
|* 6 | FILTER | | | | | | |
| 7 | COUNT | | | | | | |
| 8 | VIEW | | 2 | 86 | | 5 (20)| 00:00:01 |
| 9 | WINDOW SORT | | 2 | 40 | | 5 (20)| 00:00:01 |
| 10 | NESTED LOOPS | | 2 | 40 | | 4 (0)| 00:00:01 |
| 11 | NESTED LOOPS | | 2 | 16 | | 2 (0)| 00:00:01 |
|* 12 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
| 13 | TABLE ACCESS BY INDEX ROWID | APPL_PROD_CAT_MAP | 2 | 12 | | 2 (0)| 00:00:01 |
|* 14 | INDEX RANGE SCAN | PK_PROD_MAP | 2 | | | 1 (0)| 00:00:01 |
| 15 | TABLE ACCESS BY INDEX ROWID | APPL_COMMON_PROD_MST | 1 | 12 | | 1 (0)| 00:00:01 |
|* 16 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | | | 0 (0)| 00:00:01 |
|* 17 | HASH JOIN | | | | | | |
| 18 | CONNECT BY PUMP | | | | | | |
| 19 | COUNT | | | | | | |
| 20 | VIEW | | 2 | 86 | | 5 (20)| 00:00:01 |
| 21 | WINDOW SORT | | 2 | 40 | | 5 (20)| 00:00:01 |
| 22 | NESTED LOOPS | | 2 | 40 | | 4 (0)| 00:00:01 |
| 23 | NESTED LOOPS | | 2 | 16 | | 2 (0)| 00:00:01 |
|* 24 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
| 25 | TABLE ACCESS BY INDEX ROWID | APPL_PROD_CAT_MAP | 2 | 12 | | 2 (0)| 00:00:01 |
|* 26 | INDEX RANGE SCAN | PK_PROD_MAP | 2 | | | 1 (0)| 00:00:01 |
| 27 | TABLE ACCESS BY INDEX ROWID | APPL_COMMON_PROD_MST | 1 | 12 | | 1 (0)| 00:00:01 |
|* 28 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | | | 0 (0)| 00:00:01 |
| 29 | COUNT | | | | | | |
| 30 | VIEW | | 2 | 86 | | 5 (20)| 00:00:01 |
| 31 | WINDOW SORT | | 2 | 40 | | 5 (20)| 00:00:01 |
| 32 | NESTED LOOPS | | 2 | 40 | | 4 (0)| 00:00:01 |
| 33 | NESTED LOOPS | | 2 | 16 | | 2 (0)| 00:00:01 |
|* 34 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
| 35 | TABLE ACCESS BY INDEX ROWID | APPL_PROD_CAT_MAP | 2 | 12 | | 2 (0)| 00:00:01 |
|* 36 | INDEX RANGE SCAN | PK_PROD_MAP | 2 | | | 1 (0)| 00:00:01 |
| 37 | TABLE ACCESS BY INDEX ROWID | APPL_COMMON_PROD_MST | 1 | 12 | | 1 (0)| 00:00:01 |
|* 38 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | | | 0 (0)| 00:00:01 |
|* 39 | FILTER | | | | | | |
|* 40 | CONNECT BY WITH FILTERING | | | | | | |
|* 41 | FILTER | | | | | | |
| 42 | COUNT | | | | | | |
| 43 | VIEW | | 683 | 1416K| | 1550 (2)| 00:00:19 |
|* 44 | FILTER | | | | | | |
|* 45 | CONNECT BY WITH FILTERING | | | | | | |
|* 46 | FILTER | | | | | | |
| 47 | COUNT | | | | | | |
| 48 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 49 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 50 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 51 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 52 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 53 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|* 54 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 55 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 56 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|* 57 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 58 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|* 59 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 60 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|* 61 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 62 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|* 63 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|* 64 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 65 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|* 66 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 67 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 68 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 69 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|* 70 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|* 71 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|* 72 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 73 | TABLE ACCESS BY INDEX ROWID| APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|* 74 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
|* 75 | HASH JOIN | | | | | | |
| 76 | CONNECT BY PUMP | | | | | | |
| 77 | COUNT | | | | | | |
| 78 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 79 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 80 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 81 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 82 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 83 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|* 84 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 85 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 86 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|* 87 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 88 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|* 89 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 90 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|* 91 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 92 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|* 93 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|* 94 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 95 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|* 96 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 97 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 98 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 99 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|*100 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|*101 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|*102 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 103 | TABLE ACCESS BY INDEX ROWID| APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|*104 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
| 105 | COUNT | | | | | | |
| 106 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 107 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 108 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 109 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 110 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 111 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|*112 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 113 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 114 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|*115 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 116 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|*117 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 118 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|*119 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 120 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|*121 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|*122 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 123 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|*124 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 125 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 126 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 127 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|*128 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|*129 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|*130 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 131 | TABLE ACCESS BY INDEX ROWID | APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|*132 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
|*133 | HASH JOIN | | | | | | |
| 134 | CONNECT BY PUMP | | | | | | |
| 135 | COUNT | | | | | | |
| 136 | VIEW | | 683 | 1416K| | 1550 (2)| 00:00:19 |
|*137 | FILTER | | | | | | |
|*138 | CONNECT BY WITH FILTERING | | | | | | |
|*139 | FILTER | | | | | | |
| 140 | COUNT | | | | | | |
| 141 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 142 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 143 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 144 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 145 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 146 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|*147 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 148 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 149 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|*150 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 151 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|*152 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 153 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|*154 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 155 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|*156 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|*157 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 158 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|*159 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 160 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 161 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 162 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|*163 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|*164 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|*165 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 166 | TABLE ACCESS BY INDEX ROWID| APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|*167 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
|*168 | HASH JOIN | | | | | | |
| 169 | CONNECT BY PUMP | | | | | | |
| 170 | COUNT | | | | | | |
| 171 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 172 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 173 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 174 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 175 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 176 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|*177 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 178 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 179 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|*180 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 181 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|*182 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 183 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|*184 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 185 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|*186 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|*187 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 188 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
|*189 | INDEX UNIQUE SCAN | SYS_C005409 | 1 | 2 | | 0 (0)| 00:00:01 |
| 190 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 17094 | 116K| | 84 (2)| 00:00:02 |
| 191 | VIEW | | 145 | 309K| | 128 (3)| 00:00:02 |
| 192 | NESTED LOOPS | | 145 | 18560 | | 128 (3)| 00:00:02 |
|*193 | HASH JOIN | | 145 | 17255 | | 127 (3)| 00:00:02 |
|*194 | TABLE ACCESS FULL | APPL_ASSET_HDR_ACTL | 102 | 2346 | | 42 (3)| 00:00:01 |
|*195 | TABLE ACCESS FULL | APPL_INVENTORY_HDR_ACTL | 5698 | 534K| | 85 (3)| 00:00:02 |
| 196 | TABLE ACCESS BY INDEX ROWID| APPL_BRANCH_MST | 1 | 9 | | 1 (0)| 00:00:01 |
|*197 | INDEX UNIQUE SCAN | PK_BRHCD | 1 | | | 0 (0)| 00:00:01 |
| 198 | COUNT | | | | | | |
| 199 | VIEW | | 683 | 1527K| | 1550 (2)| 00:00:19 |
| 200 | WINDOW SORT | | 683 | 1518K| 3656K| 1550 (2)| 00:00:19 |
| 201 | VIEW | | 683 | 1518K| | 1221 (2)| 00:00:15 |
| 202 | WINDOW BUFFER | | 683 | 1536K| | 1221 (2)| 00:00:15 |
| 203 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
| 204 | WINDOW SORT | | 683 | 1536K| 3656K| 1221 (2)| 00:00:15 |
|*205 | HASH JOIN OUTER | | 683 | 1536K| | 228 (4)| 00:00:03 |
| 206 | VIEW | | 683 | 79228 | | 99 (6)| 00:00:02 |
| 207 | SORT UNIQUE | | 683 | 26637 | | 98 (5)| 00:00:02 |
|*208 | HASH JOIN | | 683 | 26637 | | 97 (4)| 00:00:02 |
| 209 | TABLE ACCESS FULL | APPL_COMMON_MST | 17 | 289 | | 3 (0)| 00:00:01 |
|*210 | HASH JOIN | | 683 | 15026 | | 94 (4)| 00:00:02 |
| 211 | NESTED LOOPS | | 228 | 3420 | | 9 (12)| 00:00:01 |
|*212 | HASH JOIN | | 228 | 2964 | | 9 (12)| 00:00:01 |
| 213 | NESTED LOOPS | | 102 | 714 | | 5 (0)| 00:00:01 |
|*214 | INDEX UNIQUE SCAN | SYS_C005404 | 1 | 2 | | 0 (0)| 00:00:01 |
|*215 | INDEX FAST FULL SCAN | INDX_AST_HDR_ACTL_CAT_ID | 102 | 510 | | 5 (0)| 00:00:01 |
| 216 | TABLE ACCESS FULL | APPL_PROD_CAT_MAP | 150 | 900 | | 3 (0)| 00:00:01 |
Similar Messages
-
How can I improve below SQL performance.
Hi,
How can I improve below SQL performance. This SQL consumes CPU and occures wait events. It is running every 10 seconds. When I look at the session information from Enterprise Manager I can see that "Histogram for Wait Event: PX Deq Credit: send blkd"
I created some indexes. I heard that the indexes are not used when there is a NULL but when I checked the xecution plan It uses index.
SELECT i.ID
FROM EXPRESS.invoices i
WHERE i.nbr IS NOT NULL
AND i.EXTRACT_BATCH IS NULL
AND i.SUB_TYPE='COD'
Explain Plan from Toad
SELECT STATEMENT CHOOSECost: 77 Bytes: 6,98 Cardinality: 349
4 PX COORDINATOR
3 PX SEND QC (RANDOM) SYS.:TQ10000 Cost: 77 Bytes: 6,98 Cardinality: 349
2 PX BLOCK ITERATOR Cost: 77 Bytes: 6,98 Cardinality: 349
1 INDEX FAST FULL SCAN INDEX EXPRESS.INVC_TRANS_INDX Cost: 77 Bytes: 6,98 Cardinality: 349
Execution Plan from Sqlplus
| Id | Operation | Name | Rows | Bytes | Cost | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 349 | 6980 | 77 | | | |
| 1 | PX COORDINATOR | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 349 | 6980 | 77 | Q1,00 | P->S | QC (RAND) |
| 3 | PX BLOCK ITERATOR | | 349 | 6980 | 77 | Q1,00 | PCWC | |
|* 4 | INDEX FAST FULL SCAN| INVC_TRANS_INDX | 349 | 6980 | 77 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
4 - filter("I"."NBR" IS NOT NULL AND "I"."EXTRACT_BATCH" IS NULL AND "I"."SUB_TYPE"='COD')
Note
- 'PLAN_TABLE' is old version
- cpu costing is off (consider enabling it)
Statistics
141 recursive calls
0 db block gets
5568 consistent gets
0 physical reads
0 redo size
319 bytes sent via SQL*Net to client
458 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00
Redo NoWait %: 100.00
Buffer Hit %: 99.70
In-memory Sort %: 100.00
Library Hit %: 99.81
Soft Parse %: 99.77
Execute to Parse %: 63.56
Latch Hit %: 90.07
Parse CPU to Parse Elapsd %: 0.81
% Non-Parse CPU: 98.88
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
latch: library cache 12,626 16,757 1,327 62.6 Concurrency
CPU time 5,712 21.Mar
latch: session allocation 1,848,987 1,99 1 07.Nis Other
PX Deq Credit: send blkd 1,242,265 981 1 03.Tem Other
PX qref latch 1,405,819 726 1 02.Tem Other
The database version is 10.2.0.1 but we haven't installed the patch 10.2.0.5. yet.
I am waiting your comments.
Thanks in advanceWelcome to the forum.
I created some indexes. I heard that the indexes are not used when there is a NULL but when I checked the xecution plan It uses index. What columns are indexed?
And what do:
select i.sub_type
, count(*)
from express.invoices i
where i.nbr is not null
and i.extract_batch is null
group by i.sub_type; and
select i.sub_type
, count(*)
from express.invoices i
group by i.sub_type; return?
Also, try use the {noformat}{noformat} tag when posting examples/execution plans etc.
See: HOW TO: Post a SQL statement tuning request - template posting for more tuning instructions.
It'll make a big difference:
SELECT i.ID
FROM EXPRESS.invoices i
WHERE i.nbr IS NOT NULL
AND i.EXTRACT_BATCH IS NULL
AND i.SUB_TYPE='COD'
Explain Plan from Toad
SELECT STATEMENT CHOOSECost: 77 Bytes: 6,98 Cardinality: 349
4 PX COORDINATOR
3 PX SEND QC (RANDOM) SYS.:TQ10000 Cost: 77 Bytes: 6,98 Cardinality: 349
2 PX BLOCK ITERATOR Cost: 77 Bytes: 6,98 Cardinality: 349
1 INDEX FAST FULL SCAN INDEX EXPRESS.INVC_TRANS_INDX Cost: 77 Bytes: 6,98 Cardinality: 349
Execution Plan from Sqlplus
| Id | Operation | Name | Rows | Bytes | Cost | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 349 | 6980 | 77 | | | |
| 1 | PX COORDINATOR | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10000 | 349 | 6980 | 77 | Q1,00 | P->S | QC (RAND) |
| 3 | PX BLOCK ITERATOR | | 349 | 6980 | 77 | Q1,00 | PCWC | |
|* 4 | INDEX FAST FULL SCAN| INVC_TRANS_INDX | 349 | 6980 | 77 | Q1,00 | PCWP | |
Predicate Information (identified by operation id):
4 - filter("I"."NBR" IS NOT NULL AND "I"."EXTRACT_BATCH" IS NULL AND "I"."SUB_TYPE"='COD')
Note
- 'PLAN_TABLE' is old version
- cpu costing is off (consider enabling it)
Statistics
141 recursive calls
0 db block gets
5568 consistent gets
0 physical reads
0 redo size
319 bytes sent via SQL*Net to client
458 bytes received via SQL*Net from client
1 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
0 rows processed
Instance Efficiency Percentages (Target 100%)
Buffer Nowait %: 100.00
Redo NoWait %: 100.00
Buffer Hit %: 99.70
In-memory Sort %: 100.00
Library Hit %: 99.81
Soft Parse %: 99.77
Execute to Parse %: 63.56
Latch Hit %: 90.07
Parse CPU to Parse Elapsd %: 0.81
% Non-Parse CPU: 98.88
Top 5 Timed Events
Event Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
latch: library cache 12,626 16,757 1,327 62.6 Concurrency
CPU time 5,712 21.Mar
latch: session allocation 1,848,987 1,99 1 07.Nis Other
PX Deq Credit: send blkd 1,242,265 981 1 03.Tem Other
PX qref latch 1,405,819 726 1 02.Tem Other -
How to improve my pls/sql performance tunning skills
Hi All , I would like to learn more about pl/sql performance tunning , where or how can i get more knowledge in this area ?
Is there any tutorials which can help me to understand the Explain plan, Dbms_Profiler, Dbms_Advisor more etc ........Thanks . BcjExplain plan
http://www.psoug.org/reference/explain_plan.html
DBMS_PROFILER (10g)
http://www.psoug.org/reference/dbms_profiler.html
DBMS_HPROF (11g)
http://www.psoug.org/reference/dbms_hprof.html
DBMS_ADVISOR
http://www.psoug.org/reference/dbms_advisor.html
DBMS_MONITOR
http://www.psoug.org/reference/dbms_monitor.html
DBMS_SUPPORT
http://www.psoug.org/reference/dbms_support.html
DBMS_TRACE
http://www.psoug.org/reference/dbms_trace.html
DBMS_SQLTUNE
http://www.psoug.org/reference/dbms_sqltune.html -
Index to Improve SQL Performance
Please provide a link to information about how to use an Index to enhance SQL performance with Oracle 10g database.
user8973820 wrote:
I would like information regarding the use of clustered versus non-clustered indexes.The documentation is your friend :)
[Overview of Indexed Clusters|http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/tablecls.htm#CFABHBAG]
[Indexes and Index-Organized Tables|http://download.oracle.com/docs/cd/E11882_01/server.112/e10713/indexiot.htm#BABHJAJF]
HTH! -
Tabular Model Performance Improvements
Hi !
We have a bulitv tabular model inline which has a fact table and 2 dimension tables .The performance of SSRS report is very slow and we have bottle neck in deciding SSRS as reporting tool.
Can you help us on performance improvements with Tabular Inline
Regards,Hi Bhadri,
As Sorna said, it hard to give you the detail tips to improve the tabular model performance according the limited information. Here are some useful link about performance Tuning of Tabular Models in SQL Server 2012 Analysis Services, please refer to the
link below.
http://msdn.microsoft.com/en-us/library/dn393915.aspx
If this is not what you want, please elaborate the detail information, so that we can make further analysis.
Regards,
Charlie Liao
TechNet Community Support -
Help needed in SQL performance - Using CASE in SQL statement versus 2 query
Hi,
I have a requirement to find count from a bunch of tables.
The SQL I have gives the count of all members.
I have created 2 queries to find count of active and inactive members.
The key difference is only the active dates.
Each query takes 20 seconds to execute.
I modified the SQL to use CASE statement in the SELECT.
So after the data is fetched the CASE statement will evaluate the active date and gives 2 counts (active and inactive)
Is it advisable to use this approach. Will CASE improve SQL performance ? I have to justify this.
Please let me know your thoughts.
Thanks,
JHi,
If it can be done in single SQL do it in single SQL.
You said:
Will CASE improve SQL performance There can be both cases to prove if the performance is better or worse.
In your case you should tell us how it is.
Regards,
Bhushan -
Hi,
I am responsible for a large, computation-intensive PL/SQL program that performs some batch processing on a large number of records.
I am trying to improve the performance of this program and have a couple of questions that I am hoping this forum can answer.
I am running Oracle 11.1.0.7 on Windows.
1. How does compiling with DEBUG information affect performance?
I found that my program units (packages, procedures, object types, etc) run significantly slower if they are compiled with debug information
I am trying to understand why this is so. Does debug information instrument the code and result in more code that needs to be executed?
Does adding debug information prevent compiler optimizations? both?
The reason I ask this question is to understand if it is valid to compare the performance of two different implementations if they are both compiled with debug information. For example, if one approach is 20% faster when compiled with debug information, is it safe to assume that it will also be 20% faster in production (without debug information)? Or, as I expect, does the presence of debug information change the performance profile of the code?
2. What is the best way to measure how long a PL/SQL program takes?
I want to compare to approaches, such as using a VARRAY vs. a TABLE variable. I have been doing this by creating two test procedures that performs the same task using the two approaches I want to evalulate.
How should I measure the time an approach takes so that it is not affected by other activity on my system? I have tried using CPU time (dbms_utility.get_cpu_time) and elapsed time. CPU time seems to be much
more consistent between runs, however, I am concerned that CPU time might not reflect all the time the process takes.
(I am aware of the profiler and have used that as well, however, I am at the point where profiling is providing diminishing returns).
3. I tried recompiling my entire system to be native compiled but to my great surprise, did not notice any measurable difference in performance!
I compiled all specification and bodies in all schemas to be native compiled. Can anyone explain why native compilation would not result in a significant performance improvement on a process that seems to be CPU-bound when it is running? Are there any other settings or additional steps that need to be performed for native compilation to be effective?
Thank you,
EricYes, debug must add instrumentation. I think that is the point of it. Whether it lowers the compiler optimisation level I don't know (I haven't read anywhere that it does) but surely if you stepping through code manually to debug it then you don't care.
I don't know of a way to measure pure CPU time independently of other system activity. One common approach is to write a test program that repeats your sample code a large enough number of times for a pattern to emerge. To find how much time individual components contribute, dbms_profiler can be quite helpful (most conveniently via a button press in IDEs such as PL/SQL Developer, but it can also be invoked from the command line.)
It is strange that no native compilation appears to make no difference. Are you sure everything is actually using it? e.g. is it shown as natively compiled in ALL_PLSQL_OBJECT_SETTINGS?
I would not expect a PL/SQL VARRAY variable to perform any differently to a nested table one - I expect they have an identical internal implementation. The difference is that VARRAYs have much reduced functionality and a normally unhelpful limit setting.
Edited by: William Robertson on Nov 6, 2008 11:49 PM -
Performance improvement in OBIEE 11.1.1.5
Hi all,
In OBIEE 11.1.1.5 reports takes long time to load , Kindly provide me some performance improvement guides.
Thanks,
Haree.Hi Haree,
Steps to improve the performance.
1. implement caching mechanism
2. use aggregates
3. use aggregate navigation
4. limit the number of initialisation blocks
5. turn off logging
6. carry out calculations in database
7. use materialized views if possible
8. use database hints
9. alter the NQSONFIG.ini parameters
Note:calculate all the aggregates in the Repository it self and Create a Fast Refresh for MV(Materialized views).
and you can also do one thing you can schedule an IBOT to run the report every 1 hour or some thing so that the report data will be cached and when the user runs the report the BI Server extracts the data from Cache
This is the latest version for OBIEE11g.
http://blogs.oracle.com/pa/resource/Oracle_OBIEE_Tuning_Guide.pdf
Report level:
1. Enable cache -- change nqsconfig instead of NO change to YES.
2. GO--> Physical layer --> right click table--> properties --> check cacheable.
3. Try to implement Aggregate mechanism.
4.Create Index/Partition in Database level.
There are multiple other ways to fine tune reports from OBIEE side itself:
1) You can check for your measures granularity in reports and have level base measures created in RPD using OBIEE utility.
http://www.rittmanmead.com/2007/10/using-the-obiee-aggregate-persistence-wizard/
This will pick your aggr tables and not detailed tables.
2) You can use Caching Seeding options. Using ibot or Using NQCMD command utility
http://www.artofbi.com/index.php/2010/03/obiee-ibots-obi-caching-strategy-with-seeding-cache/
http://satyaobieesolutions.blogspot.in/2012/07/different-to-manage-cache-in-obiee-one.html
OR
http://hiteshbiblog.blogspot.com/2010/08/obiee-schedule-purge-and-re-build-of.html
Using one of the above 2 methods, you can fine tune your reports and reduce the query time.
Also, on a safer side, just take the physical SQL from log and run it directly on DB to see the time taken and check for the explain plan with the help of a DBA.
Hope this help's
Thanks,
Satya
Edited by: Satya Ranki Reddy on Aug 12, 2012 7:39 PM
Edited by: Satya Ranki Reddy on Aug 12, 2012 8:12 PM
Edited by: Satya Ranki Reddy on Aug 12, 2012 8:20 PM -
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. -
[sql performance] inline view , group by , max, join
Hi. everyone.
I have a question with regard to "group by" inline view ,
max value, join, and sql performance.
I will give you simple table definitions in order for you
to understand my intention.
Table A (parent)
C1
C2
C3
Table B (child)
C1
C2
C3
C4 number type(sequence number)
1. c1, c2, c3 are the key columns of tabla A.
2. c1, c2, c3, c4 are the key columns of table B.
3. table A is the parent table of Table B.
4. c4 column of table b is the serial number.
(c4 increases from 1 by "1" regarding every (c1,c2,c3)
the following is the simple example of the sql query.
select .................................
from table_a,
(select c1, c2, c3, max(c4)
from table_b
group by c1, c2, c3) table_c
where table_a.c1 = table_c.c1
and table_a.c2 = table_c.c2
and table_a.c3 = table_c.c3
The real query is not simple as above. More tables come
after "the from clause".
Table A and table B are big tables, which have more than
100,000,000 rows.
The response time of this sql is very very slow
as everyone can expect.
Are there any solutions or sql-tips about the late response-time?
I am considering adding a new column into "Table B" in
order to identify the row, which has max serial number.
At this point, I am not sure adding a column is a good
thing in terms of every aspect.
I will be waiting for your advice and every response
will be appreciated even if it is not the solution.
Have a good day.
HO.
Message was edited by:
user507290For such big sources check that
1) you use full scans, hash joins or at least merge joins
2) you scan your source data as less as possible. In the best case each necessary table only once (for example not using exists clause to effectively scan all table via index scan).
3) how much time you are spending on sorts and hash joins (either from v$session_longops directly or some tool that visualises this info). If you are using workarea_size_policy = auto, probably you can switch to manual for this particular select and adjust sort_area_size and hash_area_size big enough to do as less as possible sorts on disk
4) if you have enough free resources i.e. big box probably you can consider using some parallelism
5) if your full scans are taking big time check what is your db_file_multiblock_read_count, probably increasing it for this select will give some gain.
6) run trace and check on what are you waiting for
7) most probably your problem is IO bound so probably you can do something from OS side to make IO faster
8) if your query now is optimized as much as you can, disks are running as mad and you are using all RAM then probably it is the most you can get out of your box :)
9) if nothing helps then you can start thinking about precalculations either using your idea about derived column or some materialized views.
10) I hope you have a test box and at least point (9) do firstly on it and see whether it helps.
Gints Plivna
http://www.gplivna.eu -
No of columns in a table and SQL performance
How does the table size effects sql performance?
I am comparing 2 tables , with same number of rows(54 million rows) ,
table1(columns a,b,c,d,e,f..) has 40 columns
table2 (columns (a,b,c,d)
SQL uses columns a,b.
SQL using table2 runs in 1 sec.
SQL using table1 runs in 30 min.
Can any one please let me know how the table size , number of columns in table efects the performance of SQL's?
Thanks
jeevan.user600431 wrote:
This is a general question. I just want to compare table with more columns and table with less columns with same number of rows .
I am finding that table with less columns is good in performance , than the table with more columns.
Assuming there are no row chains , will there be any difference in performance with the number of columns in a table.Jeevan,
the question is not how many columns your table has, but how large your table segment is. If your query runs a full table scan it has to read through the whole table segment, so in that case the size of the table matters.
A table having more columns potentially has a larger row size than a table with less columns but this is not a general rule. Think of large columns, e.g. varchar2 columns, think of blank (NULL) columns and you can easily end up with a table consisting of a single column taking up more space per row than a table with 200 columns consisting only of varchar2(1) columns.
Check the DBA/ALL/USER_SEGMENTS view to determine the size of your two table segments. If you gather statistics on the tables then the dictionary will contain information about the average row size.
If your query is using indexes then the size of the table won't affect the query performance significantly in many cases.
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/ -
DS 5.2 P4 performance improvement
We have +/- 300,000 users that regularly authenticate using our DS. The user ou is divided in ou=internal (20,000 ids) and ou=external (280,000) uids. Approximately 85-90% percent of the traffic happens on the internal ou. The question is: Could I get any performance improvement by separating the internal branch into its own suffix/database? Would running two databases adversely affect the performance instead? We see performance impacts when big searches are performed on the ou=external branch. Would the separation isolate the issue, or those searches will most likely affect the DS as a whole?
Thanks for your help!
Enrique.Thank you for the info. Are u a Sun guy - do you work
for sun?Yes I am. I'm the Architect for Directory Server Enterprise Edition 6.0. Previously I worked on all DS 5 releases (mostly on Replication).
You are getting the Dukes!Thanks.
Ludovic. -
Performance improvement in a function module
Hi All,
I am using SAP 6.0 version. I have a function module to retrive the PO's . for just 10,000 records its taking long time.
Can any one sugguest the ways to improve the performance.
Thanks in advance.Moderator message - Welcome to SCN.
But
Moderator message - Please see Please Read before Posting in the Performance and Tuning Forum before posting
Just 10,000 records? The first rule in performance improvement is to reduce the amount of selected data. If you cannot do that, it's going to take time.
I wouldn't bother with a BAPI for so many records. Write some custom code to get only the data you need.
Tob -
Pls help me to modify the query for performance improvement
Hi,
I have the below initialization
DECLARE @Active bit =1 ;
Declare @id int
SELECT @Active=CASE WHEN id=@id and [Rank] ='Good' then 0 else 1 END FROM dbo.Students
I have to change this query in such a way that the conditions id=@id and [Rank] ='Good' should go to the where condition of the query. In that case, how can i use Case statement to retrieve 1 or 0? Can you please help me to modify this initialization?I dont understand your query...May be below? or provide us sample data and your output...
SELECT * FROM dbo.students
where @Active=CASE
WHEN id=@id and rank ='Good' then 0 else 1 END
But, I doubt you will have performance improvement here?
Do you have index on id?
If you are looking for getting the data for @ID with rank ='Good' then use the below:Make sure, you have index on id,rank combination.
SELECT * FROM dbo.students
where id=@id
and rank ='Good' -
SQL PERFORMANCE SQL ANALYZER of 11g
I am using 11g on Windows 2000, I want run SQL PERFORMANCE ANALYZER to see the impact of parameter change on some sql’s. Currently, I am using it in a test environment, but eventually I want to apply t to production environment.
Let us say I want to see the effect of different values db_file_muntilbock_readcount.
When I run this in my database, will the values changed impact only the session where I am running sol performance analyzer, or will it impact any other sessions, which are accessing the same database instance. I think, it impacts only the session where SQL Performance analyzer is being run, but want to make sure that is the case?
Appreciate your feedback.I think, it impacts only the session where
SQL Performance analyzer is being run, but want to
make sure that is the case?The database instance is part of a larger 'system' which includes a fixed set of physical resources. Your session, and every other session, work within the constraints of those resources. When you change the current SQL statement, you will be moving the balance between those resources.
For example, a disk can only respond to one access request at a time. A memory location can be used for one piece of data at a time. A DB cache buffer can only reflect one block at a time. There are a lot of 'points of serialization'.
Although the major impact should be on the current session, there will be some impact on every other session in the system.
BY the way, there is an 'edit' button available to you for every post you create. As a courtesy, you could edit the title of the duplicate and let us know it is indeed a duplicate - or you could edit that other thread to ask that other question you were going to ask.
Maybe you are looking for
-
Migrating Oracle 10.2.0.4 to another site
Hi Gurus, I´ll need to migrate an ORACLE Database to Another site (1000 miles away) and i need to know, what's the best practice to do that. I need to copy the entire database to a new server whith the minimum downtime and risk while the source datab
-
Create Process Instance via DB insert?
I would like to have a DB insert kick off a process instance. I am an ALBPM novice, but I'm guessing the solution would involve a DB insert trigger (Oracle) and a PAPI ProcessServiceSession.createProcessInstance() call. Does anyone know how to put it
-
How can I get imail to work better with exchange?
I am having problems keeping my email working in imail using exchange settings
-
I have some static queries, where nothing changes, they just need to be re-run first thing monday morning. I would like to learn the best way to automate this ? I am on Oracle 11G Enterprise, and am just an end-user, no Admin privilages. I have SQL*P
-
Frequent Spotlight Crashes Despite Reindex
When opening the Spotlight Search Window I pretty often see a spinning beach ball, followed by a crash of Spotlight several seconds later. If I then retry the search once or twice it will eventually work. I reindexed all my external drives as well as