Find it. Fix it. Real-World SQL Tuning Cases with Karen Morton

1. Find It. Fix it. Real-‐World SQL Tuning Cases Karen Morton Infrastructure Principal Director Accenture Enkitec Group

2. karenmorton.blogspot.com @karen_morton karen.r.morton@accenture.com

3. Which is easier for you? Find it? Fix it?

4. A4? Hit! Miss. D7?

5. AWR

6. OEM Top AcKvity / Top SQL

7. Users

8. Now what ?

9. Once you ﬁnd a problem, how do you ﬁx it?

10. The 5 Whys Originally developed by Toyota Corpora<on and made widely known by Jeﬀ Bezos of Amazon.

11. Basic concept… Ask why repeatedly unKl you get to the single root cause for a problem.

12. The Jeﬀ Bezos Story Why did the associate damage his thumb? Because his thumb got caught in the conveyor. Why did his thumb get caught in the conveyor? Because he was chasing his bag, which was on a running conveyor. Why did he chase his bag? Because he placed his bag on the conveyor, but it then turned-‐on by surprise. Why was his bag on the conveyor? Because he used the conveyor as a table. Why did he use his bag as a table? Because he not been trained to not do so. SoluKon: Provide a work table *and* safety training.

13. Case Study #1

14. Hi Karen, I have a statement in a vendor supplied procedure that is hanging for days and I wondered if you could take a look at it. The sql monitor report is below along with a formaded copy of the statement. A copy of the procedure is adached along with the output of your st-‐all script for each of the tables involved. We can add hints, indexes and refresh staKsKcs but we can’t change the logic of the programs supplied by the vendor. I’ve already tried refreshing staKsKcs but it didn’t help. I’ll keep digging but if you see something that would help please let me know. Thanks Joe

15. 71 hours 42 minutes 18 seconds Global Information -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ Status : EXECUTING Instance ID : 2 Session : ....... (1189:1901) SQL ID : 678sypyw3yb8s SQL Execution ID : 33554442 Execution Started : 08/23/2014 16:04:31 First Refresh Time : 08/23/2014 16:04:34 Last Refresh Time : 08/26/2014 15:46:49 Duration : 258139s Module/Action : ....... Service : ....... Program : ....... PLSQL Entry Ids (Object/Subprogram) : 228587,1 PLSQL Current Ids (Object/Subprogram) : 228587,1

16. UPDATE F_SCHED_APPT_STATS STGSTAT SET (column-‐list) = (SELECT SUM,COUNT for bunch of columns . . . FROM PAT_ENC PENC INNER JOIN PAT_ENC_APPT AVIEW ON AVIEW.PAT_ENC_CSN_ID = PENC.PAT_ENC_CSN_ID INNER JOIN PAT_ENC_ES_AUD_ACT MACT ON (PENC.PAT_ENC_CSN_ID = MACT.PAT_ENC_CSN_ID AND MACT.LINE = 1) LEFT OUTER JOIN PAT_ENC_ES_AUD_ACT CLACT ON (PENC.PAT_ENC_CSN_ID = CLACT.PAT_ENC_CSN_ID AND CLACT.ES_AUDIT_ACTION_C = 4) LEFT OUTER JOIN PAT_ENC PERESCHED ON (PERESCHED.APPT_SERIAL_NO = PENC.APPT_SERIAL_NO AND PERESCHED.PAT_ENC_CSN_ID <> PENC.PAT_ENC_CSN_ID AND PERESCHED.APPT_STATUS_C <> 3) LEFT OUTER JOIN V_ZC_CANCEL_REASON ZCCAN ON PENC.CANCEL_REASON_C = ZCCAN.CANCEL_REASON_C WHERE PENC.CONTACT_DATE = STGSTAT.STATISTICS_DATE AND AVIEW.DEPARTMENT_ID = STGSTAT.DEPARTMENT_ID AND AVIEW.PROV_ID = STGSTAT.PROV_ID)

17. ==========================================================================================================================! | Id | Operation | Name | Rows | Execs | Rows | Activity |! | | | | (Estim) | | (Actual) | (%) |! ==========================================================================================================================! | 0 | UPDATE STATEMENT | | | 1 | | |! | 1 | UPDATE | F_SCHED_APPT_STATS | | 1 | 0 | |! | -> 2 | TABLE ACCESS STORAGE FULL | F_SCHED_APPT_STATS | 1 | 1 | 878 | |! | 3 | TABLE ACCESS BY INDEX ROWID | PAT_PCP | 1 | 1673 | 850 | 0.02 |! | 4 | INDEX RANGE SCAN | PK_PAT_PCP | 13 | 1673 | 19966 | 0.06 |! | 5 | SORT AGGREGATE | | 1 | 97 | 97 | |! | 6 | FILTER | | | 97 | 8713 | |! | 7 | BITMAP CONVERSION TO ROWIDS | | 1494 | 96 | 8713 | |! | 8 | BITMAP INDEX RANGE SCAN | EIX_CALENDAR_WEEKEND | | 96 | 8713 | |! | 9 | SORT AGGREGATE | | 1 | 298 | 298 | |! | 10 | FILTER | | | 298 | 224 | |! | 11 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT_HOLIDAY | 1 | 295 | 224 | |! | 12 | INDEX RANGE SCAN | PK_DEPARTMENT_HOLIDAY | 1 | 295 | 224 | |! | 13 | SORT AGGREGATE | | 1 | 878 | 877 | |! | 14 | NESTED LOOPS | | | 878 | 1981 | |! | 15 | NESTED LOOPS | | 2 | 878 | 1981 | |! | 16 | NESTED LOOPS OUTER | | 1 | 878 | 1990 | |! | 17 | NESTED LOOPS OUTER | | 1 | 878 | 1990 | |! | 18 | NESTED LOOPS OUTER | | 1 | 878 | 1988 | |! | 19 | NESTED LOOPS | | 1 | 878 | 1988 | |! | 20 | VIEW | | 1 | 878 | 1988 | |! | 21 | SORT GROUP BY | | 1 | 878 | 1988 | |! | 22 | TABLE ACCESS BY GLOBAL INDEX ROWID | PAT_ENC_APPT | 1 | 878 | 1988 | 13.37 |! | -> 23 | INDEX FULL SCAN | PK_PAT_ENC_APPT | 7M | 878 | 4G | 85.91 |! | 24 | TABLE ACCESS BY GLOBAL INDEX ROWID | PAT_ENC | 1 | 1988 | 1988 | |! | 25 | INDEX UNIQUE SCAN | PK_PAT_ENC | 1 | 1988 | 1988 | |! | 26 | VIEW PUSHED PREDICATE | V_ZC_CANCEL_REASON | 1 | 1988 | 306 | |! | 27 | INDEX UNIQUE SCAN | PK_ZC_CANCEL_REASON | 1 | 1988 | 306 | |! | 28 | TABLE ACCESS BY GLOBAL INDEX ROWID | PAT_ENC | 1 | 1988 | 206 | |! | 29 | INDEX RANGE SCAN | EIX_PAT_ENC_001 | 5 | 1988 | 2590 | 0.14 |! | 30 | TABLE ACCESS BY INDEX ROWID | PAT_ENC_ES_AUD_ACT | 1 | 1990 | 305 | 0.05 |! | 31 | INDEX RANGE SCAN | PK_PAT_ENC_ES_AUD_ACT | 4 | 1990 | 4014 | 0.45 |! | -> 32 | INDEX UNIQUE SCAN | PK_PAT_ENC_ES_AUD_ACT | 1 | 1991 | 1981 | |! | 33 | TABLE ACCESS BY INDEX ROWID | PAT_ENC_ES_AUD_ACT | 2 | 1981 | 1981 | |! ==========================================================================================================================!

18. Find it?

19. Fix it?

21. ================================================= TABLE STATISTICS ================================================= Owner : clr Table name : pat_enc_appt Partitioned : yes Last analyzed : 08/24/2014 19:26:37 Sample size : 145986286 Degree : 1 # Rows : 145986286 # Blocks : 1257720 Empty Blocks : 0 Avg Space : 0 Avg Row Length: 59 Monitoring? : yes

22. ====================================================================== INDEX INFORMATION ====================================================================== DISTINCT INDEX_NAME COLUMN_NAME(S) KEYS -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ eix_pat_enc_appt_coda contact_date 17058 eix_penc_appt_provdep prov_id, department_id 38460 eix_penc_prov_id prov_id 38460 pk_pat_enc_appt pat_enc_csn_id, line 146535236

24. =============================================== TABLE STATISTICS =============================================== Owner : c_stage Table name : f_sched_appt_stats Partitioned : no Last analyzed : 08/23/2014 15:53:52 Sample size : 0 Degree : 1 # Rows : 0 # Blocks : 20 Empty Blocks : 0 Avg Space : 0 Avg Row Length: 0 Monitoring? : yes

26. What would you do? Rewrite the query? Modify, drop or create an index? Gather staKsKcs? Change parKKoning scheme? Rebuild tables? Rebuild indexes?

27. ---------------------------------------------------------------------------------------------! | Id | Operation | Name | New | Old |! ---------------------------------------------------------------------------------------------! | 0 | UPDATE STATEMENT | | 2271 | | ! | 1 | UPDATE | F_SCHED_APPT_STATS | | | ! | 2 | TABLE ACCESS STORAGE FULL | F_SCHED_APPT_STATS | 2271 | 1 | ! | 3 | TABLE ACCESS BY INDEX ROWID | PAT_PCP | 1 | 1 | ! | 4 | INDEX RANGE SCAN | PAT_PCP_PAID | 6 | 13 | PK_PAT_PCP! | 5 | SORT AGGREGATE | | 1 | 1 | ! | 6 | FILTER | | | | ! | 7 | BITMAP CONVERSION TO ROWIDS | | 165 | 1494 | ! | 8 | BITMAP INDEX RANGE SCAN | EIX_CALENDAR_WEEKEND | | | ! | 9 | SORT AGGREGATE | | 1 | 1 | ! | 10 | FILTER | | | | ! | 11 | TABLE ACCESS BY INDEX ROWID | DEPARTMENT_HOLIDAY | 1 | 1 | ! | 12 | INDEX RANGE SCAN | PK_DEPARTMENT_HOLIDAY | 1 | 1 | ! | 13 | SORT AGGREGATE | | 1 | 1 | ! | 14 | NESTED LOOPS | | | | ! | 15 | NESTED LOOPS | | 2 | 2 | ! | 16 | NESTED LOOPS OUTER | | 1 | 1 | ! | 17 | NESTED LOOPS OUTER | | 1 | 1 | ! | 18 | NESTED LOOPS OUTER | | 1 | 1 | ! | 19 | NESTED LOOPS | | 1 | 1 | ! | 20 | VIEW | | 1 | 1 | ! | 21 | SORT GROUP BY | | 1 | 1 | ! | 22 | TABLE ACCESS BY GLOBAL INDEX ROWID| PAT_ENC_APPT | 1 | 1 | ! | 23 | INDEX RANGE SCAN | EIX_PENC_APPT_PROVDEP | 3 | 7M | INDEX FULL SCAN | PK_PAT_ENC_APPT! | 24 | TABLE ACCESS BY GLOBAL INDEX ROWID | PAT_ENC | 1 | 1 |! | 25 | INDEX UNIQUE SCAN | PK_PAT_ENC | 1 | 1 |! | 26 | VIEW PUSHED PREDICATE | V_ZC_CANCEL_REASON | 1 | 1 |! | 27 | INDEX UNIQUE SCAN | PK_ZC_CANCEL_REASON | 1 | 1 |! | 28 | TABLE ACCESS BY GLOBAL INDEX ROWID | PAT_ENC | 1 | 1 |! | 29 | INDEX RANGE SCAN | EIX_PAT_ENC_001 | 4 | 5 |! | 30 | TABLE ACCESS BY INDEX ROWID | PAT_ENC_ES_AUD_ACT | 1 | 1 |! | 31 | INDEX RANGE SCAN | PK_PAT_ENC_ES_AUD_ACT | 3 | 4 |! | 32 | INDEX UNIQUE SCAN | PK_PAT_ENC_ES_AUD_ACT | 1 | 1 |! | 33 | TABLE ACCESS BY INDEX ROWID | PAT_ENC_ES_AUD_ACT | 1 | 2 |! ---------------------------------------------------------------------------------------------! Afer collecKng stats on F_SCHED_APPT_STATS… 9 seconds!

28. Fix it?

29. Case Study #2

30. During a health-‐check analysis, Top SQL by both execuKons and Kme per execuKon was evaluated. One of the key ﬁndings related to the Top SQL was that opKmizer staKsKcs had not been collected in over 4 years. Many plans were subopKmal due to underesKmated cardinaliKes that led to improper join type and join order choices. In addiKon, Oracle had been upgraded twice during that Kme also exposing some poorly formulated SQL that would beneﬁt from rewrites.

31. SELECT DISTINCT MAP_CODE, MAP_CLASS, GET_MAX_AUD_OID('MAP_CLASS', MAP_CLASS_OID) as AUD_MAP_CLASS_OID, MAP_CODE_OID, GET_MAX_AUD_OID('MAP_CODE', MAP_CODE_OID) as AUD_MAP_CODE_OID, CONTEXT_NM FROM VWMAPCODES WHERE MAP_CODE = UPPER(:B2 ) AND SPONSOR_OID LIKE :B1 Query

32. SELECT d.destination_nm, mc.map_code, mc.oid map_code_oid, md.map_class_oid, cl.map_class, spg.sponsor_oid, con.context_nm FROM map_code mc, map_code_data md, sponsor_product_cfg spc, sponsor_product_grp spg, destination d, map_class cl, map_code_context con, sponsor_prod_destination spd WHERE mc.oid = md.map_code_oid AND cl.oid = md.map_class_oid AND spc.oid = spd.sponsor_product_cfg_oid AND spc.sponsor_product_grp_oid = spg.oid AND spd.destination_oid = d.oid AND mc.oid = d.map_code_oid AND con.oid(+) = md.map_code_context_oid GROUP BY d.destination_nm, mc.map_code, mc.oid, md.map_class_oid, cl.map_class, spg.sponsor_oid, con.context_nm View

33. =====================================================================================================================! | Id | Operation | Name | Rows | Execs | Rows | Activity |! | | | | (Estim) | | (Actual) | (%) |! =====================================================================================================================! | 0 | SELECT STATEMENT | | | 1 | 4 | |! | 1 | HASH UNIQUE | | 3512 | 1 | 4 | |! | 2 | HASH GROUP BY | | 3512 | 1 | 146K | 0.29 |! | 3 | NESTED LOOPS | | 3512 | 1 | 1M | |! | 4 | NESTED LOOPS | | 3512 | 1 | 1M | 0.29 |! | 5 | NESTED LOOPS | | 3512 | 1 | 1M | |! | 6 | NESTED LOOPS | | 3512 | 1 | 1M | |! | 7 | NESTED LOOPS OUTER | | 1 | 1 | 4 | |! | 8 | NESTED LOOPS | | 1 | 1 | 4 | |! | 9 | NESTED LOOPS | | 1 | 1 | 4 | |! | 10 | NESTED LOOPS | | 1 | 1 | 1 | |! | 11 | TABLE ACCESS BY INDEX ROWID | MAP_CODE | 1 | 1 | 1 | |! | 12 | INDEX UNIQUE SCAN | MAP_CODE_MC_IDX | 1 | 1 | 1 | |! | 13 | TABLE ACCESS BY INDEX ROWID | DESTINATION | 1 | 1 | 1 | |! | 14 | INDEX UNIQUE SCAN | DESTINATION_MAP_CODE_UK | 1 | 1 | 1 | |! | 15 | TABLE ACCESS BY INDEX ROWID | MAP_CODE_DATA | 1 | 1 | 4 | |! | 16 | INDEX RANGE SCAN | MAP_CODE_DATA_MAP_CODE_IDX | 2 | 1 | 4 | |! | 17 | TABLE ACCESS BY INDEX ROWID | MAP_CLASS | 1 | 4 | 4 | |! | 18 | INDEX UNIQUE SCAN | MAP_CLASS_PK | 1 | 4 | 4 | |! | 19 | TABLE ACCESS BY INDEX ROWID | MAP_CODE_CONTEXT | 1 | 4 | 4 | |! | 20 | INDEX UNIQUE SCAN | MAP_CODE_CONTEXT_PK | 1 | 4 | 4 | |! | 21 | TABLE ACCESS BY INDEX ROWID | SPONSOR_PROD_DESTINATION | 5045 | 4 | 1M | 10.03 |! | 22 | INDEX RANGE SCAN | IDX_SPD_DEST | 6167 | 4 | 1M | 2.29 |! | 23 | TABLE ACCESS BY INDEX ROWID | SPONSOR_PRODUCT_CFG | 1 | 1M | 1M | 57.31 |! | 24 | INDEX UNIQUE SCAN | PK_SPONSOR_PRODUCT_CFG | 1 | 1M | 1M | 10.60 |! | 25 | INDEX UNIQUE SCAN | PK_SPONSOR_PRODUCT_GRP | 1 | 1M | 1M | 7.16 |! | 26 | TABLE ACCESS BY INDEX ROWID | SPONSOR_PRODUCT_GRP | 1 | 1M | 1M | 12.03 |! =====================================================================================================================! 5 minutes 49 seconds LIO = 7M+ PIO = 140K+

34. Find it?

35. Fix it?

36. SELECT DISTINCT MAP_CODE, MAP_CLASS, GET_MAX_AUD_OID('MAP_CLASS', MAP_CLASS_OID) as AUD_MAP_CLASS_OID, MAP_CODE_OID, GET_MAX_AUD_OID('MAP_CODE', MAP_CODE_OID) as AUD_MAP_CODE_OID, CONTEXT_NM FROM VWMAPCODES WHERE MAP_CODE = UPPER(:B2 ) AND SPONSOR_OID LIKE :B1 Query

37. SELECT d.destination_nm, mc.map_code, mc.oid map_code_oid, md.map_class_oid, cl.map_class, spg.sponsor_oid, con.context_nm FROM map_code mc, map_code_data md, sponsor_product_cfg spc, sponsor_product_grp spg, destination d, map_class cl, map_code_context con, sponsor_prod_destination spd WHERE mc.oid = md.map_code_oid AND cl.oid = md.map_class_oid AND spc.oid = spd.sponsor_product_cfg_oid AND spc.sponsor_product_grp_oid = spg.oid AND spd.destination_oid = d.oid AND mc.oid = d.map_code_oid AND con.oid(+) = md.map_code_context_oid GROUP BY d.destination_nm, mc.map_code, mc.oid, md.map_class_oid, cl.map_class, spg.sponsor_oid, con.context_nm View

38. Plan HV Execs Min Max -‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐ -‐-‐-‐-‐-‐-‐-‐-‐-‐ 3543794116 15,051 1.62 1,286.92 AWR revealed one plan with varying response Kmes from 1.62 to 1,286.92 seconds. Longer Kmes were associated with higher PIO.

39. Why does the query need column-‐list funcKon calls? Are they part of the problem? Why use a single view? Does one view serve both predicates opKmally? Are there any restricKons on the LIKE ﬁlter? (0,1,2,3,n characters required?) Why is there such a big deviaKon in the response Kmes?

40. =====================================================================================================================! | Id | Operation | Name | Rows | Execs | Rows | Activity |! | | | | (Estim) | | (Actual) | (%) |! =====================================================================================================================! | 0 | SELECT STATEMENT | | | 1 | 4 | |! | 1 | HASH UNIQUE | | 3512 | 1 | 4 | |! | 2 | HASH GROUP BY | | 3512 | 1 | 146K | 0.29 |! | 3 | NESTED LOOPS | | 3512 | 1 | 1M | |! | 4 | NESTED LOOPS | | 3512 | 1 | 1M | 0.29 |! | 5 | NESTED LOOPS | | 3512 | 1 | 1M | |! | 6 | NESTED LOOPS | | 3512 | 1 | 1M | |! | 7 | NESTED LOOPS OUTER | | 1 | 1 | 4 | |! | 8 | NESTED LOOPS | | 1 | 1 | 4 | |! | 9 | NESTED LOOPS | | 1 | 1 | 4 | |! | 10 | NESTED LOOPS | | 1 | 1 | 1 | |! | 11 | TABLE ACCESS BY INDEX ROWID | MAP_CODE | 1 | 1 | 1 | |! | 12 | INDEX UNIQUE SCAN | MAP_CODE_MC_IDX | 1 | 1 | 1 | |! | 13 | TABLE ACCESS BY INDEX ROWID | DESTINATION | 1 | 1 | 1 | |! | 14 | INDEX UNIQUE SCAN | DESTINATION_MAP_CODE_UK | 1 | 1 | 1 | |! | 15 | TABLE ACCESS BY INDEX ROWID | MAP_CODE_DATA | 1 | 1 | 4 | |! | 16 | INDEX RANGE SCAN | MAP_CODE_DATA_MAP_CODE_IDX | 2 | 1 | 4 | |! | 17 | TABLE ACCESS BY INDEX ROWID | MAP_CLASS | 1 | 4 | 4 | |! | 18 | INDEX UNIQUE SCAN | MAP_CLASS_PK | 1 | 4 | 4 | |! | 19 | TABLE ACCESS BY INDEX ROWID | MAP_CODE_CONTEXT | 1 | 4 | 4 | |! | 20 | INDEX UNIQUE SCAN | MAP_CODE_CONTEXT_PK | 1 | 4 | 4 | |! | 21 | TABLE ACCESS BY INDEX ROWID | SPONSOR_PROD_DESTINATION | 5045 | 4 | 1M | 10.03 |! | 22 | INDEX RANGE SCAN | IDX_SPD_DEST | 6167 | 4 | 1M | 2.29 |! | 23 | TABLE ACCESS BY INDEX ROWID | SPONSOR_PRODUCT_CFG | 1 | 1M | 1M | 57.31 |! | 24 | INDEX UNIQUE SCAN | PK_SPONSOR_PRODUCT_CFG | 1 | 1M | 1M | 10.60 |! | 25 | INDEX UNIQUE SCAN | PK_SPONSOR_PRODUCT_GRP | 1 | 1M | 1M | 7.16 |! | 26 | TABLE ACCESS BY INDEX ROWID | SPONSOR_PRODUCT_GRP | 1 | 1M | 1M | 12.03 |! =====================================================================================================================! 5 minutes 49 seconds LIO = 7M+ PIO = 140K+

41. Why *not* use speciﬁc SQL for speciﬁc predicates? Why use a view at all? Why acquire 1M+ rows only to throw them all away?

42. select distinct mc.map_code, cl.map_class, con.context_nm from map_code mc join map_code_data md on mc.oid = md.map_code_oid join map_class cl on cl.oid = md.map_class_oid join destination d on mc.oid = d.map_code_oid left join map_code_context con on con.oid = md.map_code_context_oid where mc.map_code = :B1 ; Query 1

43. ---------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | ---------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 4 |00:00:00.02 | 21 | 3 | | 1 | HASH UNIQUE | | 1 | 1 | 4 |00:00:00.02 | 21 | 3 | | 2 | NESTED LOOPS OUTER | | 1 | 1 | 4 |00:00:00.02 | 21 | 3 | | 3 | NESTED LOOPS | | 1 | 1 | 4 |00:00:00.02 | 15 | 3 | | 4 | NESTED LOOPS | | 1 | 1 | 4 |00:00:00.01 | 9 | 2 | | 5 | NESTED LOOPS | | 1 | 1 | 1 |00:00:00.01 | 5 | 0 | | 6 | TABLE ACCESS BY INDEX ROWID| MAP_CODE | 1 | 1 | 1 |00:00:00.01 | 3 | 0 | |* 7 | INDEX UNIQUE SCAN | MAP_CODE_MC_IDX | 1 | 1 | 1 |00:00:00.01 | 2 | 0 | |* 8 | INDEX UNIQUE SCAN | DESTINATION_MAP_CODE_UK | 1 | 1 | 1 |00:00:00.01 | 2 | 0 | | 9 | TABLE ACCESS BY INDEX ROWID | MAP_CODE_DATA | 1 | 1 | 4 |00:00:00.01 | 4 | 2 | |* 10 | INDEX RANGE SCAN | MAP_CODE_DATA_MAP_CODE_IDX | 1 | 2 | 4 |00:00:00.01 | 2 | 2 | | 11 | TABLE ACCESS BY INDEX ROWID | MAP_CLASS | 4 | 1 | 4 |00:00:00.01 | 6 | 1 | |* 12 | INDEX UNIQUE SCAN | MAP_CLASS_PK | 4 | 1 | 4 |00:00:00.01 | 2 | 1 | | 13 | TABLE ACCESS BY INDEX ROWID | MAP_CODE_CONTEXT | 4 | 1 | 4 |00:00:00.01 | 6 | 0 | |* 14 | INDEX UNIQUE SCAN | MAP_CODE_CONTEXT_PK | 4 | 1 | 4 |00:00:00.01 | 2 | 0 | ---------------------------------------------------------------------------------------------------------------------------------- .02 seconds LIO = 21 PIO = 3

44. select distinct mc.map_code, cl.map_class, con.context_nm from map_code mc join map_code_data md on mc.oid = md.map_code_oid join map_class cl on cl.oid = md.map_class_oid join destination d on mc.oid = d.map_code_oid join sponsor_prod_destination spd on spd.destination_oid = d.oid join sponsor_product_cfg spc on spc.oid = spd.sponsor_product_cfg_oid join sponsor_product_grp spg on spc.sponsor_product_grp_oid = spg.oid left join map_code_context con on con.oid = md.map_code_context_oid where mc.map_code = :B1 and sponsor_oid = :B2 ; Query 2

45. ---------------------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | ---------------------------------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 4 |00:00.21 | 904 | 25 | | 1 | HASH UNIQUE | | 1 | 1 | 4 |00:00.21 | 904 | 25 | | 2 | NESTED LOOPS OUTER | | 1 | 1 | 188 |00:00.21 | 904 | 25 | | 3 | NESTED LOOPS | | 1 | 1 | 188 |00:00.21 | 712 | 25 | | 4 | NESTED LOOPS | | 1 | 5 | 188 |00:00.10 | 370 | 11 | |* 5 | HASH JOIN | | 1 | 5 | 188 |00:00.03 | 52 | 2 | |* 6 | HASH JOIN | | 1 | 6 | 188 |00:00.02 | 46 | 2 | | 7 | NESTED LOOPS | | 1 | 7 | 47 |00:00.02 | 31 | 2 | | 8 | NESTED LOOPS | | 1 | 1 | 1 |00:00.01 | 6 | 0 | | 9 | TABLE ACCESS BY INDEX ROWID| MAP_CODE | 1 | 1 | 1 |00:00.01 | 3 | 0 | |* 10 | INDEX UNIQUE SCAN | MAP_CODE_MC_IDX | 1 | 1 | 1 |00:00.01 | 2 | 0 | | 11 | TABLE ACCESS BY INDEX ROWID| DESTINATION | 1 | 1 | 1 |00:00.01 | 3 | 0 | |* 12 | INDEX UNIQUE SCAN | DESTINATION_MAP_CODE_UK | 1 | 1 | 1 |00:00.01 | 2 | 0 | | 13 | TABLE ACCESS BY INDEX ROWID | SPONSOR_PRODUCT_GRP | 1 | 7 | 47 |00:00.02 | 25 | 2 | |* 14 | INDEX RANGE SCAN | SPONSOR_PRODUCT_GRP_SPONSOR | 1 | 7 | 47 |00:00.02 | 3 | 2 | | 15 | TABLE ACCESS FULL | MAP_CODE_DATA | 1 | 715 | 715 |00:00.01 | 15 | 0 | | 16 | TABLE ACCESS FULL | MAP_CLASS | 1 | 189 | 189 |00:00.01 | 6 | 0 | |* 17 | INDEX RANGE SCAN | IDX_SPC_SPG_PP_OID | 188 | 1 | 188 |00:00.07 | 318 | 9 | |* 18 | INDEX UNIQUE SCAN | SPONSOR_PROD_DEST_SD_UK | 188 | 1 | 188 |00:00.11 | 342 | 14 | | 19 | TABLE ACCESS BY INDEX ROWID | MAP_CODE_CONTEXT | 188 | 1 | 188 |00:00.01 | 192 | 0 | |* 20 | INDEX UNIQUE SCAN | MAP_CODE_CONTEXT_PK | 188 | 1 | 188 |00:00.01 | 4 | 0 | ---------------------------------------------------------------------------------------------------------------------------------- .21 seconds LIO = 904 PIO = 25

46. Fix it?

47. 2 Cases. 2 Very Diﬀerent SoluKons.

48. 1 StaKsKcs. 2 Prac<cal SQL constructs.

49. Don't limit yourself. Just because something worked once doesn't mean it's the best choice for another case.

50. Find it. 5 Whys. Evaluate SoluKon(s). Fix it!

51. Thank You!

Find it. Fix it. Real-World SQL Tuning Cases with Karen Morton

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (9)

Similar to Find it. Fix it. Real-World SQL Tuning Cases with Karen Morton

Similar to Find it. Fix it. Real-World SQL Tuning Cases with Karen Morton (20)

More from Embarcadero Technologies

More from Embarcadero Technologies (20)

Recently uploaded

Recently uploaded (20)

Find it. Fix it. Real-World SQL Tuning Cases with Karen Morton