Optimize the query
Hi all
I have a question and I would like to know how to optimize it. Please suggest. :-
select * from unity_list o where (exists ( select * from opp_date where opp_id = o.opp_id and date_type = 'FYIMSAT') and :maySubmitAnytime = 'Y') OR (:maySubmitAnytime = 'N' and not exists ( select * from em_preaward.opp_date where opp_id = o.opp_id and date_type = 'FYIMSAT')) OR :maySubmitAnytime IS NULL order by o.reviewed DESC, o.changed_ind DESC, o.opp_desc
Please suggest.
I have a question and I would like to know how to optimize it. Please suggest. :-
He returned lines of 5 billion in less than a microsecond. Why do you think he needs optimized?
Tags: Database
Similar Questions
-
How to optimize the query with a join of virtual tables
I'm working on a query that is get the data of virtual tables 2 and b
one is formed by the Union, all say 4 queries and b is formed by the Union, all say 3 queries
then these two virtual tables and b are joined on a column common and data are extracted from their part.
Problem is that there is about 1 minutes each in the two virtual tables has and b. If individual a and b queries virtual takes about 5 seconds to retrieve data
but the join on column takes about 25 seconds to retrieve data.
Can someone guide me how to optimize the recovery of joining 2 virtual tables having large data
Thank youPlease read these:
When your query takes too long
When your query takes too long...How to post a SQL tuning request
HOW to: Validate a query of SQL statement tuning - model showing -
steps to optimize the query on explain plan
Hello
Please find the described explain the plan of a query, and suggest me where and how can grant us the request.
{code}
-----------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | TempSpc | Cost (% CPU). Time |
-----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 352K | 60 M | | 17677 (12) | 00:03:33 |
| 1. TRANSFORMATION OF THE TEMPORARY TABLE. | | | | | |
| 2. LOAD SELECT ACE | SYS_TEMP_0FD9FCB72_F58FAD20 | | | | | |
| 3. VIEW | | 22G | 3684G | | 96 M (100) | 320:57:19 |
| 4. UNIQUE FATE | | 22G | 4837G | 436G | 96 M (1) | 320:57:19 |
| 5. CONCATENATION. | | | | | |
|* 6 | HASH JOIN | | 1792M | 392G | | 52682 (26) | 00:10:33 |
| 7. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
|* 8 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
|* 9 | HASH JOIN | | 1792M | 372G | 9320K | 43943 (16) | 00:08:48 |
| 10. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 11. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 12 | EXTERNAL RIGHT HASH JOIN | | 676K | 128 M | 19 M | 29255 (1) | 00:05:52 |
| 13. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 14 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 15 | HASH JOIN | | 195K | 34 M | 9240K | 24001 (1) | 00:04:49 |
| 16. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 17. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| * 18. OUTER HASH JOIN | | 114K | 17 M | 12 M | 21748 (1) | 00:04:21 |
| * 19. MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 20. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 21. TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 22. HASH JOIN | | 89 M | 19G | | 46498 (16) | 00:09:18 |
| 23. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 24. MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 25. HASH JOIN | | 89 M | 18G | 9320K | 43943 (16) | 00:08:48 |
| 26. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 27. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 28. EXTERNAL RIGHT HASH JOIN | | 676K | 128 M | 19 M | 29255 (1) | 00:05:52 |
| 29. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 30 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 31. HASH JOIN | | 195K | 34 M | 9240K | 24001 (1) | 00:04:49 |
| 32. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 33. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| * 34 | OUTER HASH JOIN | | 114K | 17 M | 12 M | 21748 (1) | 00:04:21 |
| * 35 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 36. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 37 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 38 | HASH JOIN | | 4480K | 1004M | | 46189 (15) | 00:09:15 |
| 39. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 40 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 41. HASH JOIN | | 4480K | 952 M | 9320K | 43943 (16) | 00:08:48 |
| 42. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 43. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 44 | EXTERNAL RIGHT HASH JOIN | | 676K | 128 M | 19 M | 29255 (1) | 00:05:52 |
| 45. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 46 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 47 | HASH JOIN | | 195K | 34 M | 9240K | 24001 (1) | 00:04:49 |
| 48. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 49. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| * 50 | OUTER HASH JOIN | | 114K | 17 M | 12 M | 21748 (1) | 00:04:21 |
| * 51 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 52. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 53 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 54 | OUTER HASH JOIN | | 224KO | 50 M | 14 M | 32597 (4) | 00:06:32 |
| * 55 | HASH JOIN | | 64775 | 13 M | 7696K | 28458 (5) | 00:05:42 |
| * 56 | OUTER HASH JOIN | | 37855. 7245K | 5416K | 26763 (5) | 00:05:22 |
| * 57 | HASH JOIN | | 37675 | 4966K | | 6436 (18) | 00:01:18 |
| 58. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 59 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 60 | HASH JOIN | | 37675 | 4525K | 9320K | 4206 (27) | 00:00:51 |
| 61. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 62. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 63. MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 64. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 65 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| 66. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 67. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| 68. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 69 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 70 | OUTER HASH JOIN | | 11201 | 2570K | | 23267 (6) | 00:04:40 |
| * 71 | HASH JOIN | | 3239 | 702K | | 20816 (6) | 00:04:10 |
| * 72 | OUTER HASH JOIN | | 1893 | 362K | | 19942 (7) | 00:04:00 |
| * 73 | HASH JOIN | | 1884 | 248K | | 6435 (18) | 00:01:18 |
| * 74 | HASH JOIN | | 1884 | 226K | 9320K | 4206 (27) | 00:00:51 |
| 75. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 76. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 77 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 78. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 79 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| 80. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 81 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| 82. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 53 M | MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| 84. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 85 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 86 | OUTER HASH JOIN | | 560. 128K | | 23267 (6) | 00:04:40 |
| * 87. HASH JOIN | | 162. 35964 | | 20816 (6) | 00:04:10 |
| * 88. OUTER HASH JOIN | | 95. 18620 | | 19942 (7) | 00:04:00 |
| * 89 | HASH JOIN | | 94. 12690 | | 6435 (18) | 00:01:18 |
| * 90 | HASH JOIN | | 94. 11562 | 9320K | 4206 (27) | 00:00:51 |
| 91. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 92. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 93 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 94. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 95 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| 96. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 97 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| 98. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 99. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| 100. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 101 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 102 | OUTER HASH JOIN | | 28. 6580. | 23267 (6) | 00:04:40 |
| * 103 | HASH JOIN | | 8. 1776 | | 20816 (6) | 00:04:10 |
| * 104 | OUTER HASH JOIN | | 5. 980. | 19942 (7) | 00:04:00 |
| * 105 | HASH JOIN | | 5. 675. | 6435 (18) | 00:01:18 |
| * 106 | HASH JOIN | | 5. 615 | 9320K | 4206 (27) | 00:00:51 |
| 107. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 108. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 109 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 110. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 111 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| 112. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 113 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| 114. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 115. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| 116. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 117 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 118 | OUTER HASH JOIN | | 1. 235. | 23267 (6) | 00:04:40 |
| * 119 | OUTER HASH JOIN | | 1. 174. | 9760 (12) | 00:01:58 |
| * 120 | HASH JOIN | | 1. 161. | 7309 (16) | 00:01:28 |
| * 121 | HASH JOIN | | 1. 135. | 6435 (18) | 00:01:18 |
| * 122 | HASH JOIN | | 1. 123 | 9320K | 4206 (27) | 00:00:51 |
| 123 | VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 124. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 125 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 126. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 127 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| 128. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 129. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| 130. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 131 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| 132. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 133 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 134 | OUTER HASH JOIN | | 1. 235. | 23267 (6) | 00:04:40 |
| * 135 | OUTER HASH JOIN | | 1. 174. | 9760 (12) | 00:01:58 |
| * 136 | HASH JOIN | | 1. 161. | 7309 (16) | 00:01:28 |
| * 137 | HASH JOIN | | 1. 135. | 6435 (18) | 00:01:18 |
| * 138 | HASH JOIN | | 1. 123 | 9320K | 4206 (27) | 00:00:51 |
| 139. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 140. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 141 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 142. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 143 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| 144. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 145. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| 146. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 147 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| 148. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 149 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 150 | OUTER HASH JOIN | | 1. 235. | 23267 (6) | 00:04:40 |
| * 151 | OUTER HASH JOIN | | 1. 174. | 9760 (12) | 00:01:58 |
| * 152 | HASH JOIN | | 1. 161. | 7309 (16) | 00:01:28 |
| * 153 | HASH JOIN | | 1. 135. | 6435 (18) | 00:01:18 |
| * 154 | HASH JOIN | | 1. 123 | 9320K | 4206 (27) | 00:00:51 |
| 155. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 156. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 157 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 158. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 159 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| 160. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 161. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| 162. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 163 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| 164. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 165 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 166 | OUTER HASH JOIN | | 1. 235. | 37689 (26) | 00:07:33 |
| * 167 | HASH JOIN | | 1. 222. | 35237 (28) | 00:07:03 |
| * 168 | HASH JOIN | | 1. 210 | | 33008 (29) | 00:06:37 |
| * 169 | HASH JOIN | | 9781. 1776K | | 22622 (1) | 00:04:32 |
| * 170 | FILTER | | | | | | |
| * 171 | OUTER HASH JOIN | | 5716 | 893K | 12 M | 21748 (1) | 00:04:21 |
| * 172 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1085 (2) | 00:00:14 |
| 173. VIEW | ABC_CDE_INDEX_AST_VW | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| * 174 | TABLE ACCESS FULL | ABC_CDE_INDEX_AST | 1898K | 110 M | | 13499 (1) | 00:02:42 |
| 175. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 176. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| * 177 | VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 178. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 179. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 180 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| 181. VIEW | ABC_CDE_INDEX_CHG_VW | 818K | 10 M | | 2448 (1) | 00:00:30 |
| * 182 | TABLE ACCESS FULL | ABC_CDE_INDEX_CHG | 818K | 10 M | | 2448 (1) | 00:00:30 |
| 183. LOAD SELECT ACE | SYS_TEMP_0FD9FCB73_F58FAD20 | | | | | |
| 184. VIEW | | 145K | 18 M | | 187 M (1) | 625:08:34 |
| 185. UNIQUE FATE | | 145K | 22 M | 1215G | 187 M (1) | 625:08:34 |
| * 186 | HASH JOIN | | 7487M | 1122G | | 274K (98) | 00:54:59 |
| 187. VIEW | STAG_MASTER_VW | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 188 | MAT_VIEW FULL ACCESS | STAG_MASTER_MV | 39985 | 468K | | 2229 (1) | 00:00:27 |
| * 189 | HASH JOIN | | 7487M | 1039G | 9320K | 245K (98) | 00:49:06 |
| 190. VIEW | STAG_MANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| 191. MAT_VIEW FULL ACCESS | STAG_AANAME_MV | 264K | 6208K | | 974 (1) | 00:00:12 |
| * 192 | HASH JOIN | | 248K | 29 M | 9240K | 2995 (1) | 00:00:36 |
| 193. VIEW | STAG_NAMADDS_VW | 248K | 6316K | | 872 (1) | 00:00:11 |
| 194. MAT_VIEW FULL ACCESS | STAG_NAMADDS_MV | 248K | 6316K | | 872 (1) | 00:00:11 |
| * 195 | MAT_VIEW FULL ACCESS | STAG_ANAME_MV | 113K | 10 M | | 1075 (1) | 00:00:13 |
| 196. UNIQUE FATE | | 352K | 60 M | 72 M | 17677 (12) | 00:03:33 |
| 197. UNION-ALL | | | | | | |
| * 198 | VIEW | | 352K | 60 M | | 1883 (1) | 00:00:23 |
| 199. TABLE ACCESS FULL | SYS_TEMP_1234_5678 | 352K | 60 M | | 1883 (1) | 00:00:23 |
| * 200 | FILTER | | | | | | |
| * 201 | OUTER HASH JOIN | | 1. 150. | 1982 (1) | 00:00:24 |
| * 202 | HASH JOIN | | 1. 142. | 97 (2) | 00:00:02 |
| 203. VIEW | | 11540 | 92320 | | 48 (0) | 00:00:01 |
| 204. TABLE ACCESS FULL | SYS_TEMP_3456_0987F0 | 11540 | 1 510 K | | 48 (0) | 00:00:01 |
| 205. VIEW | | 11540 | 1 510 K | | 48 (0) | 00:00:01 |
| 206. TABLE ACCESS FULL | SYS_TEMP_0987F0_3456 | 11540 | 1 510 K | | 48 (0) | 00:00:01 |
| 207. VIEW | | 352K | 2757K | | 1883 (1) | 00:00:23 |
| 208. TABLE ACCESS FULL | SYS_TEMP_09kjhn0_3456 | 352K | 60 M | | 1883 (1) | 00:00:23 |
-----------------------------------------------------------------------------------------------------------------------
{code}
Thank you.
Well, that was just a guess because you don't want to share the query, nor execution plan with actual cardinalities. The goal is probably to avoid the separate.
-
Optimize the query using SUBSTR
Hi, I wrote the following to get the string 'abc' in the following input strings
' 2010/abc' and
' 2010/inv/abc '.
I have to get the string ("abc") that is after the last ' / '.
In the entrance of the channels the ' / ' can be 1 or 2
So I tried the following
The Select query above is even working for the string "abc/2010/inv" (until the 2nd "/" only it works)select substr(substr('2010/abc',(instr('2010/abc','/',1,1)+1),length('2010/abc inst')), (instr(substr('2010/abc',(instr('2010/abc','/',1,1)+1),length('2010/abc inst')), '/',1,1)+1),length (substr('2010/abc',(instr('2010/abc','/',1,1)+1),length('2010/abc inst')))) str from dual
Could please minimize the above query, and which may even work you for same 3rd or 4th ' / '.
Thank youHello
Alternatively, you can use regexp if you want:
Scott@my10g SQL>l 1 with data as ( 2 select '2010/abc' str from dual 3 union all select 'inv/2010/abc' from dual 4 union all select 'inv/2010/inv/2010/abc' from dual 5 union all select 'abc' from dual 6 ) 7* select str, regexp_substr(str,'[^/]+$') sstr from data Scott@my10g SQL>/ STR SSTR --------------------- ---------- 2010/abc abc inv/2010/abc abc inv/2010/inv/2010/abc abc abc abcIt would be up to the end of the string from the last source / (or early if no / in the source string)
-
Question about the query optimizer
For a year during my database of the Conference the following table
with approximately 1.5 million entries were given. In addition, there were the following query:CREATE TABLE TASKS ( "ID" NUMBER NOT NULL ENABLE, "START_DATE" DATE, "END_DATE" DATE, "DESCRIPTION" VARCHAR2(50 BYTE) ) ;
And the Index:SELECT START_DATE, COUNT(START_DATE) FROM TASKS GROUP BY START_DATE ORDER BY START_DATE;
The main exercise was to speed up queries with indexes. Because all the data is available the optimizer ignores index and just have a full table scan.create index blub on Tasks (start_date asc);
Here the QEP:
Then we tried to compel him to make the index with this query:---------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 9343 | 74744 | 3423 (6)| 00:00:42 | | 1 | SORT GROUP BY | | 9343 | 74744 | 3423 (6)| 00:00:42 | | 2 | TABLE ACCESS FULL| TASKS | 1981K| 15M| 3276 (2)| 00:00:40 | ----------------------------------------------------------------------------
but again he ignored the index. The optimizer guide makes clear, that whenever you will use all the data in a table, it must do a full scan.ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_1; SELECT /* + INDEX (TASKS BLUB) */ START_DATE, COUNT(START_DATE) FROM TASKS GROUP BY START_DATE ORDER BY START_DATE;
So we fooled him doing a scan limited quick index with this query:
now, we got the following QEP:create or replace function bla return date deterministic is ret date; begin select MIN(start_date) into ret from Tasks; return ret; end bla; ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_1; SELECT /* + INDEX (TASKS BLUB) */ START_DATE, COUNT(START_DATE) FROM TASKS where start_date >= bla GROUP BY START_DATE ORDER BY START_DATE;
So he use the index.----------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ----------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 8 | 3 (0)| 00:00:01 | | 1 | SORT GROUP BY NOSORT| | 1 | 8 | 3 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | BLUB | 1 | 8 | 3 (0)| 00:00:01 | -----------------------------------------------------------------------------
Now to my two questions:
1. why should always do a full scan (because the response of optimizer documentation is a bit unsatisfactory)?
2. After looking at the difference between the costs (FS: 3276 IR: 3) and the time, the system needs (FS: 9.6 s IR: 4.45) why the optimizer refused the plan clearly better?
Thanks in advance,
Kai Gödde
Published by: Kai Gödde on May 30, 2011 18:54
Published by: Kai Gödde on May 30, 2011 18:56The reason for which Oracle is full of sweeping the table corresponding to your request:
SELECT START_DATE, COUNT(START_DATE) FROM TASKS GROUP BY START_DATE ORDER BY START_DATE;and using the index for:
SELECT /* + INDEX (TASKS BLUB) */ START_DATE, COUNT(START_DATE) FROM TASKS where start_date >= bla GROUP BY START_DATE ORDER BY START_DATE;has to do with the (possible) null values in the table. Note that the query with a predicate on start_date would have probably used the index even without suspicion.
The optimizer does not know that there is a start_date value in each row of the table and the group by expression will include NULL values, but because you count start_date (meaning count of non-null of the expression values) the count himself will be null. For example:
SQL> with t as ( 2 select trunc(sysdate) dt from dual union all 3 select trunc(sysdate) dt from dual union all 4 select trunc(sysdate-1) dt from dual union all 5 select trunc(sysdate-1) dt from dual union all 6 select to_date(null) from dual) 7 select dt, count(dt) from t 8 group by dt; DT COUNT(DT) ----------- ---------- 0 29-MAY-2011 2 30-MAY-2011 2Because Oracle does not create an index entry for a line with all null values in the index key, the optimizer is forced full analysis of the table to make sure that it returns all rows. In the query with a predicate on start_date the optimizer knows that no matter what start_date > blah must be non-null.
To make your first query to use an index, you must declare either start_date as not null (which implies that it is a mandatory field), or if there may be values NULL, but you care not to add a like predicate:
where start_date is not null);John
-
Need help in the optimization of the query with the Group and joins by clause
I'm having the problem by running the following query... It takes a lot of time. To simplify, I added the two tables FILE_STATUS = stores the file load details and COMM table Board table job showing records treated successfully and which was communicated to the other system real. Records with status = T is trasnmitted to another system and traansactions with P is waiting.
Here's the query I wrote to give me the details of the file that has been loaded into the system. He reads the table of State and the commission files to display the name of the file, total records loaded, total at the table of the commission and the number of records which has finally been passed successfully loaded (Status = T) with other systems.CREATE TABLE FILE_STATUS (FILE_ID VARCHAR2(14), FILE_NAME VARCHAR2(20), CARR_CD VARCHAR2(5), TOT_REC NUMBER, TOT_SUCC NUMBER); CREATE TABLE COMM (SRC_FILE_ID VARCHAR2(14), REC_ID NUMBER, STATUS CHAR(1)); INSERT INTO FILE_STATUS VALUES ('12345678', 'CM_LIBM.TXT', 'LIBM', 5, 4); INSERT INTO FILE_STATUS VALUES ('12345679', 'CM_HIPNT.TXT', 'HIPNT', 4, 0); INSERT INTO COMM VALUES ('12345678', 1, 'T'); INSERT INTO COMM VALUES ('12345678', 3, 'T'); INSERT INTO COMM VALUES ('12345678', 4, 'P'); INSERT INTO COMM VALUES ('12345678', 5, 'P'); COMMIT;
In production, this request has several joins and takes a long time to deal with... the main culprit for me is the join on the COMM table to count the number of number of transactions sent. Please can you give me tips to optimize this query to get results faster? What I need to delete the Group and use the partition or something else. Help, please!SELECT FS.CARR_CD ,FS.FILE_NAME ,FS.FILE_ID ,FS.TOT_REC ,FS.TOT_SUCC ,NVL(C.TOT_TRANS, 0) TOT_TRANS FROM FILE_STATUS FS LEFT JOIN ( SELECT SRC_FILE_ID, COUNT(*) TOT_TRANS FROM COMM WHERE STATUS = 'T' GROUP BY SRC_FILE_ID ) C ON C.SRC_FILE_ID = FS.FILE_ID WHERE FILE_ID = '12345678';Don't know if it will be faster based on the information provided, but analytical functions offer an alternative approach;
select carr_cd, file_name, file_id, tot_rec, tot_succ, tot_trans from (select fs.carr_cd, fs.file_name, fs.file_id, fs.tot_rec, fs.tot_succ, count(case when c.status = 'T' then 1 else null end) over(partition by c.src_file_id) tot_trans, row_number() over(partition by c.src_file_id order by null) rn from file_status fs left join comm c on c.src_file_id = fs.file_id where file_id = '12345678') where rn = 1; CARR_CD FILE_NAME FILE_ID TOT_REC TOT_SUCC TOT_TRANS ------- -------------------- -------------- ---------- ---------- ---------- LIBM CM_LIBM.TXT 12345678 5 4 2 -
Rewrite the query to improve the performance and the optimized below cost.
Oracle 10g.
----------------------
Query
UPDATE FACETS_CUSTOM. MMR_DTL
SET
CAPITN_PRCS_IND = 2,
FIL_RUN_DT = Current_fil_run_dt,
ROW_UPDT_DT = dta_cltn_end_dttm
WHERE CAPITN_PRCS_IND = 5
AND HSPC_IND = 'Y '.
AND EXISTS (SELECT 1
OF FACETS_STAGE. CRME_FUND_DTL_STG STG_CRME
WHERE STG_CRME. MBR_CK = MMR_DTL. MBRSHP_CK
AND MMR_DTL. PMT_MSA_STRT_DT BETWEEN STG_CRME. ERN_FROM_DT AND STG_CRME. ERN_THRU_DT
AND STG_CRME. FUND_ID IN ('AAB1', '1AA2', '1BA2', 'AAB2', '1AA3', '1BA3', ' 1 B 80 ', ' 1 HAS 80 '))
AND EXISTS (SELECT 1
OF FACETS_CUSTOM. FCTS_TMS_MBRID_XWLK XWLK
WHERE XWLK. MBR_CK = MMR_DTL. MBRSHP_CK
AND MMR_DTL. PMT_MSA_STRT_DT BETWEEN XWLK. HSPC_EVNT_EFF_DT AND XWLK. HSPC_EVNT_TERM_DT);
Explain the plan of the query
-----------------------------------------------
Hash value of plan: 3109991485
-------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |
-------------------------------------------------------------------------------------------------------
| 0 | UPDATE STATEMENT. | 1. 148. 12431 (2) | 00:02:30 |
| 1. UPDATE | MMR_DTL | | | | |
| 2. SEMI NESTED LOOPS. | 1. 148. 12431 (2) | 00:02:30 |
|* 3 | HASH JOIN RIGHT SEMI | | 49. 5488. 12375 (2) | 00:02:29 |
| 4. TABLE ACCESS FULL | FCTS_TMS_MBRID_XWLK | 6494 | 64940 | 24 (0) | 00:00:01 |
|* 5 | TABLE ACCESS FULL | MMR_DTL | 304K | 29 M | 12347 (2) | 00:02:29 |
|* 6 | TABLE ACCESS BY INDEX ROWID | CRME_FUND_DTL_STG | 1. 36. 5 (0) | 00:00:01 |
|* 7 | INDEX RANGE SCAN | IE1_CRME_FUND_DTL_STG | 8. | 1 (0) | 00:00:01 |
-------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
3 - access("XWLK".") MBR_CK "=" MMR_DTL. " ("' MBRSHP_CK")
filter ("XWLK". "HSPC_EVNT_EFF_DT" < = INTERNAL_FUNCTION ("MMR_DTL". " PMT_MSA_STRT_DT') AND
'XWLK '. "" HSPC_EVNT_TERM_DT "> = INTERNAL_FUNCTION ("MMR_DTL". "PMT_MSA_STRT_DT")) "
5 - filter("CAPITN_PRCS_IND"=5 AND "HSPC_IND"='Y')
6 filter (("STG_CRME". "FUND_ID" = "1 HAS 80 ' OR 'STG_CRME'." " FUND_ID "="1AA2"OR"
'STG_CRME '. "FUND_ID"= '1AA3' OR 'STG_CRME'. "FUND_ID" = "1 B 80 ' OR 'STG_CRME'. '. "FUND_ID" = "1BA2" OR "
'STG_CRME '. "FUND_ID"= "1BA3" OR "STG_CRME". "FUND_ID"= "AAB1" OR "STG_CRME". ("FUND_ID"="AAB2") AND
'STG_CRME '. "" ERN_FROM_DT "< = INTERNAL_FUNCTION ("MMR_DTL". "PMT_MSA_STRT_DT") AND "
'STG_CRME '. "" ERN_THRU_DT "> = INTERNAL_FUNCTION ("MMR_DTL". "PMT_MSA_STRT_DT")) "
7 - access("STG_CRME".") MBR_CK "=" MMR_DTL. " ("' MBRSHP_CK")
I could not optimize this query for best performance and optimized the cost... Can someone guide me on this.
Thank you
DS
You think you're going to lines updates 85K, Oracle think it will update a line.
At the time where the existence of the first test runs that oracle think already up to 49 lines, which is probably why he uses the loop join nested for the second test. (In your version of Oracle, the subquery introduced existence a very bad assumption (small) on the amount of data will survive).
It is possible that you will get better performance if you hint Oracle using a hash join for testing the existence - and you might want to think what test will eliminate most of the data and that we can first force.
Having said that, however, note that MMR_DTL research is a considerable fraction of the cost of the query - and an analysis is an easy thing for Oracle cost properly - if, despite your comments on update a column with a clue to this topic, you will find that the query can be more effective if you use an index. This is more likely to be the case if data ' WHERE CAPITN_PRCS_IND = 5 AND HSPC_IND = 'Y' "is well grouped (perhaps the latest data added to the table).". " You could then reduce the cost of maintaining this index by creating an index based on a feature that indexes only the lines where the predicate are both true so that the 2 update deletes the index entries and allows the index remain as thin as possible.
Concerning
Jonathan Lewis
-
Hello
I have a query like this:
Merge into the table st1
using (select * from (select pk, value, diff_value, m_date, row_number () over (PARTITION pk ORDER BY diff_value) rnk)
from (select distinct / * + Full (t1) full (t2) * / t1.pk, t2.m_date)
, Case when (t1.m_date = t2.m_date) then "CORRESPONDENCE".
When (t2.m_date BETWEEN t1.m_date-1 and t1.m_date + 1) then ' MATCHED WITH +/-1gg.
When (t2.m_date BETWEEN t1.m_date-2 and t1.m_date + 2) then "MATCHED WITH +/-2 days.
else "
end value_match
Case when (t1.m_date = t2.m_date) then 0
Where (t2.m_date BETWEEN t1.m_date + 1 and t1.m_date - 1) then 1
Where (t2.m_date BETWEEN t1.m_date + 1 and t1.m_date - 1) then 2
else "
end diff_value
of table t2, t1 table
where t1.value is null
and t1.id = t2.id)
where value_match is not null)
where rnk = 1) s
on (st1.pk = s.pk)
WHEN MATCHED THEN
Update set st1.value = s.value_match, st1.diff_value = s.diff_value, st1.up_date = s.m_date
where st1.value is null.
Explain the plan:
Table1 a record 3Million and table 2 has 1 million records.
I used gather stats before you run this query and 'Full' trick, even in this case, he is running for 45 minutes.
Please suggest the best solution to optimize this query.
Thanks in advance.
Remove the tips.
No need for the separate.
Get the diff by ceil (abs(t2.m_date-t1.m_date)) and the filter for that where value_diff<>
Assing the statement ".. MATCHED" lately in the update clause.
Maybe give exactly to your needs with a small example may be the query may be getting more simplified or not what you want it to do.
-
How we force a query to use transparently a hint, even if the index is not given in the query as a query rewriting.
For example:
If the user runs a query select deptno, avg (sal) from emp group by deptno;
We want the optimizer to use a hint of result_cache with this request, and it should be transparent to the user.
Query should be rewritten to seamlessly
Select / * + result_cache * / deptno, avg (sal)
WCP
Group of deptno;
How can this feature we make? Please advice.
I checked the possibility of SPM and contours, but it is not clear if this rewrite is possible here.
Thank you and best regards,
Vikas Krishna
Surely dbms_advanced_rewrite is designed for this situation?
-
Should I wait until the end of the execution time of the query for the execution plan?
Hello Experts,
I want to see the execution plan of the query below. However, it takes more than 3 hours. Should I wait all the time to see the execution plan?
Note: EXPLAIN PLAN for does not work. (I mean that I do not see the actual line number, etc. with EXPLAIN the PLAN of market)
You can see the output of the execution plan when I canceled the execution after 1 minute.
My first question is: what should I do to see the execution plan for queries running out of time time?
2nd question: when I cancel the query during execution in order to see the execution plan, will I see the specific plan of execution or erroneous values? Because the first execution plan seems inaccurate, what do you think?
question 3: why EXPLAIN the PLAN for the clause does not work? Also, should I use EXPLAIN the PLAN of the clause to this scenerio? Can I see the result of running for long time without her queries?
Thnaks for your help.
Oracle Database 11 g Enterprise Edition Release 11.2.0.2.0 - 64 bit Production
PL/SQL Release 11.2.0.2.0 - Production
CORE Production 11.2.0.2.0
AMT for Linux: Version 11.2.0.2.0 - Production
NLSRTL Version 11.2.0.2.0 - Production
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price
of custinvoicejour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) = substr (nls_lower (t.dataareaid), 1, 7) and
substr (nls_lower (J.INVOICEID), 1: 25) = substr (nls_lower (t.INVOICEID), 1: 25)
where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM = 29457
and substr (nls_lower (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in
(select IT. Drmpos.avtr_seg_cust_campend ACCOUNTNUM this where THIS. CAMPAIGN = '201406' and THIS. SEGMENT_LEVEL in (', 'E'))
and J.AVAWARDSALES > 190
and substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406'
"and J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 ';
SQL_ID, dznya6x7st0t8, number of children 0
-------------------------------------
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT,.
J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price of
CustInvoiceJour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) =
substr (nls_lower (t.DataAreaId), 1, 7) and
= substr (nls_lower (J.INVOICEID), 1: 25)
substr (nls_lower (t.INVOICEID), 1: 25) where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM =
29457 and substr (nls_lower, (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in (select CE. ACCOUNTNUM of
drmpos.avtr_seg_cust_campend this where THIS. CAMPAIGN = '201406' and
IT. SEGMENT_LEVEL in (', 'E')) and J.AVAWARDSALES > 190 and
substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406' and
"J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 '.
Hash value of plan: 2002317666
--------------------------------------------------------------------------------------------------------------------------------------------------------------
| ID | Operation | Name | Begins | E - lines. A - lines. A - time | Pads | Bed | OMem | 1Mem | Used Mem.
--------------------------------------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1. | 0 | 00:00:00.01 | 0 | 0 | | | |
|* 1 | HASH JOIN | | 1. 3956. 0 | 00:00:00.01 | 0 | 0 | 2254K | 1061K | 2190K (0) |
|* 2 | HASH JOIN | | 1. 87. 16676. 00:00:01.64 | 227K | 3552. 3109K | 1106K | 4111K (0) |
|* 3 | TABLE ACCESS BY INDEX ROWID | CUSTINVOICEJOUR | 1. 1155 | 31889 | 00:00:01.16 | 223KO | 15. | | |
|* 4 | INDEX RANGE SCAN | I_062INVOICEDATEORDERTYPEIDX | 1. 4943 | 134K | 00:00:00.83 | 45440 | 0 | | | |
| 5. SIMPLE LIST OF PARTITION. | 1. 82360 | 173K | 00:00:00.08 | 3809 | 3537 | | | |
|* 6 | TABLE ACCESS FULL | AVTR_SEG_CUST_CAMPEND | 1. 82360 | 173K | 00:00:00.06 | 3809 | 3537 | | | |
| 7. TABLE ACCESS BY INDEX ROWID | CUSTINVOICETRANS | 1. 4560 | 0 | 00:00:00.01 | 0 | 0 | | | |
|* 8 | INDEX RANGE SCAN | I_064INVLINENUMCAMPAIGNOFPRICE | 1. 4560 | 0 | 00:00:00.01 | 0 | 0 | | | |
--------------------------------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
1 - access("J".") "SYS_NC00299$"="T". "' SYS_NC00165$ ' AND SUBSTR (NLS_LOWER ('J'. "" "" REFFACTURE")(, 1, 25) = SUBSTR (NLS_LOWER ("T"." "" "REFFACTURE")(, 1, 25)).
2 - access("J".") INVOICEACCOUNT '= SYS_OP_C2C ("EC". ". ACCOUNTNUM'))
3 - filter("J".") AVAWARDSALES"> 190)
4 - access("J".") SYS_NC00299$ "= U ' 201"AND "J". INVOICEDATE"> = TO_DATE(' 2014-06-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND
"J"." SYS_NC00307$ "= U ' 201406"AND "J". INVOICEDATE"< = TO_DATE (' 2014-06-13 00:00:00 ',' syyyy-mm-dd hh24:mi:ss')))
filter ((' J'. "INVOICEDATE' > = 'J' AND TO_DATE(' 2014-06-04 00:00:00', 'syyyy-mm-dd hh24:mi:ss') '." " SYS_NC00307$ "= U '201406' AND"
"J"." INVOICEDATE"< = TO_DATE (' 2014-06-13 00:00:00 ',' syyyy-mm-dd hh24:mi:ss'))))
6 filter (("CE". "SEGMENT_LEVEL" = A "OR"THIS"." SEGMENT_LEVEL "=" E"))
8 - access("T".") SYS_NC00165$ "= U ' 201"AND "T". AVBROCHURELINENUM "= 29457)
filter ("T". ("AVBROCHURELINENUM" = 29457)
EXPLAIN PLAN FOR
Select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * / J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE, (T.LINEAMOUNT + T.LINEAMOUNTTAX) price
of custinvoicejour j join custinvoicetrans t on
substr (nls_lower (j.DataAreaId), 1, 7) = substr (nls_lower (t.dataareaid), 1, 7) and
substr (nls_lower (J.INVOICEID), 1: 25) = substr (nls_lower (t.INVOICEID), 1: 25)
where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM = 29457
and substr (nls_lower (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in
(select IT. Drmpos.avtr_seg_cust_campend ACCOUNTNUM this where THIS. CAMPAIGN = '201406' and THIS. SEGMENT_LEVEL in (', 'E'))
and J.AVAWARDSALES > 190
and substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406'
"and J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 ';
SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR);
SELECT * FROM table (DBMS_XPLAN. DISPLAY_CURSOR ('7h1nbzqjgwsp7', 2));
SQL_ID, 7h1nbzqjgwsp7, number of children 2
EXPLAIN PLAN for select / * + GATHER_PLAN_STATISTICS NO_PARALLEL * /.
J.INVOICEACCOUNT, J.INVOICEID, J.INVOICEDATE,
(T.LINEAMOUNT + T.LINEAMOUNTTAX) join price j custinvoicejour
CustInvoiceTrans t on substr (nls_lower (j.dataareaid), 1, 7) =
substr (nls_lower (t.DataAreaId), 1, 7) and
= substr (nls_lower (J.INVOICEID), 1: 25)
substr (nls_lower (t.INVOICEID), 1: 25) where
substr (nls_lower (T.DATAAREAID), 1, 7) = '201' and T.AVBROCHURELINENUM =
29457 and substr (nls_lower, (j.dataareaid), 1, 7) = '201' and
J.INVOICEACCOUNT in (select CE. ACCOUNTNUM of
drmpos.avtr_seg_cust_campend this where THIS. CAMPAIGN = '201406' and
IT. SEGMENT_LEVEL in (', 'E')) and J.AVAWARDSALES > 190 and
substr (nls_lower (J.AVBILLINGCAMPAIGN), 1, 13) = '201406' and
"J.INVOICEDATE between ' 04.06.2014' and ' 13.06.2014 '.
NOTE: cannot fetch SQL_ID plan: 7h1nbzqjgwsp7, CHILD_NUMBER: 2
Check the value of SQL_ID and CHILD_NUMBER;
It could also be that the plan is no longer in the cursor cache (check v$ sql_plan)
NightWing wrote:
Randolf,
I don't understand. What you hear from the above statement that you mean A-lines and E will be incorrect, but the ratio between them remain the same. Therefore, you can deduct the bad things by comparing the differences.
Thus, A-lines always give a wrong result for cancellation of queries, isn't it?
Charlie,
I think that Martin gave a good explanation. Here's another example that hopefully makes more obvious things:
17:56:55 SQL >-things go very wrong here with a small buffer cache
17:56:55 SQL >-T2 lines are badly scattered when you access through T1. FK
17:56:55 SQL >--
17:56:55 SQL >-"Small job" approach would have been a good idea
17:56:55 SQL >-if the estimate of 100 iterations of the loop was correct!
17:56:55 SQL > select
17:56:55 (t2.attr2) count 2
17:56:55 3 of
17:56:55 4 t1
17:56:55 5, t2
17:56:55 6 where
17:56:55 7 /*------------------*/
17:56:55 8 trunc (t1.attr1) = 1
17:56:55 9 and trunc (t1.attr2) = 1
17:56:55 10 / *-* /.
17:56:55 11 and t1.fk = t2.id
17:56:55 12.
T1
*
ERROR on line 4:
ORA-01013: user has requested the cancellation of the current operation
Elapsed time: 00:04:58.30
18:01:53 SQL >
18:01:53 SQL > @xplan_extended_display_cursor ' ' ' ' 'ALLSTATS LAST + COST.
18:01:53 SQL > set echo off verify off termout off
SQL_ID, 353msax56jvvp, number of children 0
-------------------------------------
SELECT count (t2.attr2) from t1, t2 where
/ / *-* trunc (t1.attr1) = 1 and
trunc (T1.attr2) = 1 / *-* / and t1.fk = t2.id
Hash value of plan: 2900488714
------------------------------------------------------------------------------------------------------------------------------------
| ID | The NEST | DSB | Operation | Name | Begins | E - lines. Cost (% CPU). A - lines. A - time | Pads | Bed |
------------------------------------------------------------------------------------------------------------------------------------
| 0 | | 7. SELECT STATEMENT | | 1. | 4999 (100) | 0 | 00:00:00.01 | 0 | 0 |
| 1. 0 | 8 2 GLOBAL TRI | | 1. 1. | 0 | 00:00:00.01 | 0 | 0 |
| 2. 1. 5. NESTED LOOPS | | 1. | | 57516 | 00:04:58.26 | 173K | 30770 |
| 3. 2. 3. NESTED LOOPS | | 1. 100. 4999 (1) | 57516 | 00:00:21.06 | 116K | 3632.
|* 4 | 3. 1. TABLE ACCESS FULL | T1 | 1. 100. 4799 (1) | 57516 | 00:00:00.19 | 1008 | 1087 |
|* 5 | 3. 2. INDEX UNIQUE SCAN | T2_IDX | 57516 | 1. 1 (0) | 57516 | 00:00:20.82 | 115K | 2545 |
| 8 2 2 | 4. TABLE ACCESS BY INDEX ROWID | T2 | 57516 | 1. 2 (0) | 57516 | 00:04:37.14 | 57516 | 27138 |
------------------------------------------------------------------------------------------------------------------------------------
Information of predicates (identified by the operation identity card):
---------------------------------------------------
4 filter ((TRUNC ('T1'. "ATTR1") = 1 AND TRUNC ('T1'. " ATTR2') = 1))
5 - access("T1".") FK '= 'T2'.' (ID')
You say here that I canceled a query after about 5 minutes, and looking at the statistics of content (RowSource) I can already say the following:
1. the estimation of cardinality of T1 is far - the optimizer estimated 100 lines, but it actually generated more than 57000 lines when the query was cancelled. If this definitely seems like a candidate at the origin of the problems
2. the query has spent most of the time in search of random table T2
So while it is true that I don't know final A-lines of this cancelled query information, I can still say a lot of this and begin to deal with the problems identified so far.
Randolf
-
Is there a way to reduce or optimize the following question... ?
select e.year,e.ename,s.misal,e1.ename,s.masal from (select ename,to_char(hiredate,'YYYY') year,sal from emp) e join (select ename,to_char(hiredate,'YYYY') year,sal from emp) e1 on e.year=e1.year join (select to_char(hiredate,'YYYY') year,min(sal) misal,max(sal) masal from emp group by to_char(hiredate,'YYYY')) s on s.misal=e.sal and s.year=e.year and s.masal=e1.sal and s.year=e1.year order by 1;Hello
Here's one way:
WITH got_rnk AS ( SELECT EXTRACT (YEAR FROM hiredate) AS year , ename , sal , RANK () OVER ( PARTITION BY EXTRACT (YEAR FROM hiredate) ORDER BY sal ) AS l_rank , RANK () OVER ( PARTITION BY EXTRACT (YEAR FROM hiredate) ORDER BY sal DESC ) AS h_rank FROM emp ) SELECT l.year , l.ename, l.sal , h.ename, h.sal FROM got_rnk l JOIN got_rnk h ON l.year = h.year WHERE l.l_rank = 1 AND h.h_rank = 1 ORDER BY l.year ;As Rama Krishna, I would use the GRADE (or DENSE_RANK) to get the maximum and minimum values for each year. As long as you're intested in only the highest 1 and 1 lower sal in each year, no matter if you use RANK and DENSE_RANK.
I think Rama Krishna failed in your duty to indicate the highest and lowest for each year, side by side on the same line. It helps if you post the desired results. For example, here are the results I get, using the table scott.emp:` YEAR ENAME SAL ENAME SAL ---------- ---------- ---------- ---------- ---------- 1980 SMITH 800 SMITH 800 1981 JAMES 950 KING 5000 1982 MILLER 1300 MILLER 1300 1987 ADAMS 1100 SCOTT 3000Make sure that you have a good reason for each subsidiary request that you use. In the query that you posted, for example, there is a good reason for the subquery s: you need a 'table' which has a riow annually, containing the two sal the highest and lowest of the year. This information is not available in the emp; It must be derived from the emp. But what is the reason for e and e1 subqueries? What they produce that is not already in emp? Why don't you simply use emp in both cases?
-
Hello
As part of the optimization of performance,
I want to find the query using pid is there any display.
And the level of the os I received SUPERIOR command, using OS level pid can we find the query? HELLP me...
Thank you
Srini...Srini says:
HelloAs part of the optimization of performance,
I want to find the query using pid is there any display.
And the level of the os I received SUPERIOR command, using OS level pid can we find the query? HELLP me...
Thank you
Srini...As
SQL>select s.sql_id,ss.sql_text from v$session s,v$process p,v$sqlarea ss where s.PADDR=p.ADDR and s.sql_id=ss.sql_id and p.SPID=18985;Where
p.SPID = 18985 is your process id of the operating system. -
Hello
I have a fast running query (3 seconds).
If I try to run it on the test environment, it takes about 2 minutes (!)
I see in both environments explain plan is the same and therefore are used. I also tried to rebuild indexes and tables that looked quite fragmented in test, but the result is always the same. If our test environment is slower and with lower performance? What else could I check? (Oracle worms is 8.1.7)
Thank you!812809 wrote:
steps to follow:
1. If candidate columns has index or notSometimes and index can cause a query slow down rather than speed upward, especially if a person has created too many indexes on a table and the optimizer not to find one that is suitable for use.
2. go to explain the plan and search for the query is not to fall into the category of the full Table Scan
Full scan of the table isn't always a bad thing. They are sometimes faster than using the index. It depends on.
-
Slow index by using the query. Fast with full table Scan.
Salvation;
(Thanks for the links)
Here's my question correctly formatted.
The query:
Works on 32 seconds!SELECT count(1) from ehgeoconstru ec where ec.TYPE='BAR' AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) and deathdate is null and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'
Same query, but with an extra where clause:
This is 400 seconds.SELECT count(1) from ehgeoconstru ec where ec.TYPE='BAR' and ( (ec.contextVersion = 'REALWORLD') --- ADDED HERE AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) ) and deathdate is null and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText'
It should return data from a table, given the conditions.
The database version is Oracle9i Release 9.2.0.7.0
These are the parameters relevant for the optimizer:
Here is the output of the PLAN to EXPLAIN for the first quick query:SQL> show parameter optimizer NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ optimizer_dynamic_sampling integer 1 optimizer_features_enable string 9.2.0 optimizer_index_caching integer 99 optimizer_index_cost_adj integer 10 optimizer_max_permutations integer 2000 optimizer_mode string CHOOSE SQL>
Here is the output of the EXPLAIN of PLAN for slow queries:PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | -------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | | 1 | SORT AGGREGATE | | | | | |* 2 | TABLE ACCESS FULL | EHCONS | | | | -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- 2 - filter(SUBSTR("EC"."strgfd",1,8)<>'[CIMText' AND "EC"."DEATHDATE" IS NULL AND "EC"."BIRTHDATE"<=TO_DATE('2009-10-06 11:52:12', 'yyyy -mm-dd hh24:mi:ss') AND "EC"."TYPE"='BAR') Note: rule based optimization
The TKPROF output for this slow statement is:PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- | | | 1 | SORT AGGREGATE | | | | | |* 2 | TABLE ACCESS BY INDEX ROWID| ehgeoconstru | | | | |* 3 | INDEX RANGE SCAN | ehgeoconstru_VSN | | | | PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - filter(SUBSTR("EC"."strgfd",1,8)<>'[CIMText' AND "EC"."DEATHDATE" IS NULL AND "EC"."TYPE"='BAR') PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------- 3 - access("EC"."CONTEXTVERSION"='REALWORLD' AND "EC"."BIRTHDATE"<=TO_DATE('2 009-10-06 11:52:12', 'yyyy-mm-dd hh24:mi:ss')) filter("EC"."BIRTHDATE"<=TO_DATE('2009-10-06 11:52:12', 'yyyy-mm-dd hh24: mi:ss')) Note: rule based optimization
Published by: PauloSMO on November 17, 2009 04:21TKPROF: Release 9.2.0.7.0 - Production on Tue Nov 17 14:46:32 2009 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Trace file: gen_ora_3120.trc Sort options: prsela exeela fchela ******************************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call ******************************************************************************** SELECT count(1) from ehgeoconstru ec where ec.TYPE='BAR' and ( (ec.contextVersion = 'REALWORLD') AND ( ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') ) ) and deathdate is null and substr(ec.strgfd, 1, length('[CIMText')) <> '[CIMText' 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 2 0.00 538.12 162221 1355323 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 4 0.00 538.12 162221 1355323 0 1 Misses in library cache during parse: 0 Optimizer goal: CHOOSE Parsing user id: 153 Rows Row Source Operation ------- --------------------------------------------------- 1 SORT AGGREGATE 27747 TABLE ACCESS BY INDEX ROWID OBJ#(73959) 2134955 INDEX RANGE SCAN OBJ#(73962) (object id 73962) ******************************************************************************** alter session set sql_trace=true call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 0 0.00 0.00 0 0 0 0 Execute 1 0.00 0.02 0 0 0 0 Fetch 0 0.00 0.00 0 0 0 0 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 1 0.00 0.02 0 0 0 0 Misses in library cache during parse: 0 Misses in library cache during execute: 1 Optimizer goal: CHOOSE Parsing user id: 153 ******************************************************************************** OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.00 0 0 0 0 Execute 2 0.00 0.02 0 0 0 0 Fetch 2 0.00 538.12 162221 1355323 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 5 0.00 538.15 162221 1355323 0 1 Misses in library cache during parse: 0 Misses in library cache during execute: 1 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: gen_ora_3120.trc Trace file compatibility: 9.02.00 Sort options: prsela exeela fchela 2 sessions 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. 94 lines in trace file.
Published by: PauloSMO on November 17, 2009 07:07
Published by: PauloSMO on November 17, 2009 07:38 - title changed to be more correct.Although your optimizer_mode is choosing, it seems that there are no statistics collected on ehgeoconstru. The absence of estimated costs and estimated row counts of each of the stages of the plan and the "Note: optimization based on rules" at the end of these two plans would tend to confirm this.
Optimizer_mode choose means that if statistics are collected then it will use the CBO, but if no statistic is present in any of the tables in the query, the optimizer to rule will be used. The RBO tends to be happy in the best of the index case. I guess the index ehgeoconstru_VSN contextversion as the main column and also includes the date of birth.
You can either gather statistics on the table (if all other tables have statistics) using dbms_stats.gather_table_stats, or suggest the query to use a full scan instead of index. Another solution would be to apply a function or an operation against the contextversion to prevent the use of the index. something like this:
SELECT COUNT(*) FROM ehgeoconstru ec WHERE ec.type='BAR' and ec.contextVersion||'' = 'REALWORLD' ec.birthDate <= TO_DATE('2009-10-06 11:52:12', 'YYYY-MM-DD HH24:MI:SS') and deathdate is null and SUBSTR(ec.strgfd, 1, LENGTH('[CIMText')) <> '[CIMText'or maybe UPPER (ec.contextVersion) so that would not change the rows returned.
John
-
Hi guys,.
I searched a lot on the "query block" on google, but dosent find any satisfactory article that will explain basic concept to me.
I would like to know about the parameter query block that we specified when using indicators of query optimization in oracle.
How can they be used? where we can find them?
any suggestions?
Thanks and greetings
VDVkrant,
You did exactly the same thing that is asked of me all the time. What is the purpose of this indication in a simple query that I have to show you all the time. The answer is nothing, makes complex things however. But but but, in a very complex query, where there is a cross reference of the sections of different query is required, this trick will be useful to give a name to the underlying query.
>
Select / * + dept_id full (@qb d) QB_NAME (qb)
of db.dept d;can we say its just alias?
>
Yes, any. Give an official name to the query. In this query, Department table will be available with FTS.
HTH
Aman...
Maybe you are looking for
-
Is it safe/simple to remove and re-add the account Mail in Internet accounts?
I've dealt with this for months and months, and it drives me crazy. I have my email from Comcast (IMAP) account as my email account (accessible via Macbook Pro running El Capitan and my iPad), and whenever I turn the e-mail or the computer wake from
-
My Sony Handycam DCR-TRV950 flashes a yellow icon, C:31:23 and will not record or play.
A year ago, the camera suddenly started flashing and beeps a yellow icon in the middle of the screen. C:31:23 flashes in the upper right corner above the minutes from the end. The camcorder will not record or play. If I remove and reseat or change th
-
tired of hearing my xoom telling me what I'm typing the keyboard or the name of the web page I visit is there a way to disable the voice, if not, it will be possible to do it in 3.2 3.1 or later
-
DCR-SR85 is not recognized by Win7 64-bit
I have a DCR-SR85 camcorder and currently a Win - 7 64-bit computer. DCR-SR85 have the USB port and the AV/R. When I connect the camcorder to my computer with the USB cable, it automatically displays a menu for USB (HDD) CONNECTION, connect USB (MEDI
-
Cursor is transparant when, in a text box in a Web page or a word document
When using microsoft word or by typing in a website as I do now when I move my mouse on the text box or on the page in a word in the document and the capital I symbol icon (text selection), it rises in turn the same color as the white of the screen j