CASE STUDY 02 AUTHOR JP Vijaykumar jp_vijaykumar [ @ ] yahoo [ .

] com DATE August 14th 2011 TASK: Tune a long running report. This report is taking about 1 hour per execution and the business wants the repo rt to complete within 30 mts. DESCRIPTION: The report is three pages long, contains 161 lines of code written in ANSI SQL. About 28 tables/views are accessed inside the report. Out of the 28 tables/views , one particular view is accessed 7 times inside the report. This particular view is created on 6 large tables. The number of rows in the tables/views accessed in the report range from 500 - 2 0 million. In the report, sum, max functions and group by, order by clauses are used On som e of the largest tables. The report also uses left outer joins on some of the largest tab les. EXPLAIN PLAN: An explain plan on the sql report generates about 340 lines output, performing f ull table scans on some of the largest tables. TUNING STRATEGY: The original sql query and its explain plan output can not be published here, as it violates the laws of confidentiality and proprietory code. The complexity of the code can only be experienced, by accessing the voluminous data and executing a test run. AVOIDING THE TRAP: In the production db, I do not have the privileges to execute the following comm ands: alter system flush shared_pool; alter system flush buffer_cache; During my testing of the sql query, with different options/hints/constructs, I c an not claim any reduction in the execution time of the report runs, as performance gai n, without flushing the buffers between subsequent report executions. The first report execution takes about an hour, and all the subsequent report ex ecutions will complete in few minutes, as the earlier query was already parsed and availa ble in

the shared_pool and most of the required data from the tables for the report is readily available in the buffer_cache. I chose to test the report tuning task in a similar environment, where I had the privileges to flush the shared_pool and buffer_cache. I flushed the buffers after each test run of the report. STEPS FOLLOWED: 01 Re-written the sql report from ANSI SQL into Oracle SQL 02 Introduced the following constructs: 01 Wrote inline views. --To explore and force the driving sequence of data sets. 02 Used hints to force the use of indexes. --Not much help, most of the large tables are performing full ta blescans. --The execution times did not come down much. 03 Created three new indexes on the largest tables, to better access the required data efficiently. Also to take advantage of the specific literals use d in the report, and improve the data access time. --The sql report completed in 37 minutes time. Still I see full tablescans on some of the largest tables. --REMEMBER - Over indexing will kill the performance in OLTP app lications. 04 Created a materialized view on the view, which was accessed 7 times i n the sql report. This paid huge dividend. As a view is only a definition store d in the data dictionary, executed everytime, the view is selected. The materi alized view is a prebuilt table, keeps the required data ready for the sql r eport. A complete refresh of the materialized view took about 8 - 10 seconds . --The report executed in about 8 - 11 minutes. --FOR YOUR COMPARISON AND ANALYSIS, PLS FIND THE EXECUTION TIMES, PARTIAL AUTOTR ACE OUTPUT AND TKPROF OUTPUT ON THE ORIGINAL REPORT AND THE TUNED REPORT: --EXECUTION TIME OF THE ORIGINAL SQL REPORT ( WITHOUT NEW INDEXES/ MATERIALIZED VIEW/ HINTS) COUNT(1) ---------1802284 Elapsed: 01:04:02.83 --PARTIAL AUTO TRACE OUTPUT OF THE ORIGINAL SQL REPORT ( WITHOUT NEW INDEXES/ MATERIALIZED VIEW/ HINTS) Statistics ---------------------------------------------------------16669 recursive calls 14 db block gets 96327064 consistent gets 2284572 physical reads

3288 518 6259 2 235 1 1

redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

--PARTIAL TKPROF OUTPUT OF THE ORIGINAL SQL REPORT'S SESSION TRACE ( WITHOUT NEW INDEXES/ MATERIALIZED VIEW/ HINTS) call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------Parse 1 0.01 0.00 0 0 0 0 Execute 1 2.82 2.81 7 183 0 0 Fetch 2 2539.15 3749.32 1874465 81558704 4 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------total 4 2541.98 3752.14 1874472 81558887 4 1 Misses in library cache during parse: 1 Misses in library cache during execute: 1 Optimizer mode: ALL_ROWS Parsing user id: 120 Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- -----------SQL*Net message to client 2 0.00 0.00 db file sequential read 990920 0.67 1424.97 db file scattered read 16407 0.21 42.35 direct path write temp 41454 0.39 12.36 os thread startup 12 0.20 1.71 PX Deq: Join ACK 10 0.00 0.02 PX Deq Credit: send blkd 25 0.00 0.01 PX Deq Credit: need buffer 34 0.00 0.01 PX qref latch 6 0.00 0.00 PX Deq: Parse Reply 17 1.95 6.33 PX Deq: Execute Reply 36 1.34 4.11 PX Deq: Signal ACK 33 0.04 0.10 direct path read temp 41749 0.14 9.32 latch free 7 0.03 0.11 enq: PS - contention 6 0.00 0.00 SQL*Net message from client 2 362.72 362.72 ******************************************************************************** --EXECUTION TIME OF THE TUNED SQL REPORT ( WITH THREE NEW INDEXES/ MATERIALIZED VIEW/ HINTS) COUNT(1) ---------1802284 Elapsed: 00:11:35.45 --PARTIAL AUTO TRACE OUTPUT OF THE TUNED SQL REPORT'S SESSION TRACE ( WITH THREE NEW INDEXES/ MATERIALIZED VIEW/ HINTS) Statistics ---------------------------------------------------------11689 recursive calls 13 db block gets

40169648 484659 2780 518 8580 2 245 2 1

consistent gets physical reads redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client SQL*Net roundtrips to/from client sorts (memory) sorts (disk) rows processed

--PARTIAL TKPROF OUTPUT OF THE TUNED SQL REPORT'S SESSION TRACE ( WITH THREE NEW INDEXES/ MATERIALIZED VIEW/ HINTS) call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------Parse 1 0.00 0.00 0 0 0 0 Execute 1 3.14 5.78 214 2034 8 0 Fetch 2 126.37 673.12 122085 3860890 3 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------total 4 129.51 678.91 122299 3862924 11 1 Misses in library cache during parse: 1 Misses in library cache during execute: 1 Optimizer mode: ALL_ROWS Parsing user id: 120 Elapsed times include waiting on following events: Event waited on Times Max. Wait Total Waited ---------------------------------------- Waited ---------- -----------db file sequential read 57308 0.03 4.43 PX Deq: Join ACK 6 0.03 0.04 PX Deq Credit: send blkd 37 0.01 0.02 PX Deq Credit: need buffer 20 0.04 0.04 PX qref latch 1 0.00 0.00 PX Deq: Parse Reply 15 1.96 2.33 SQL*Net message to client 2 0.00 0.00 PX Deq: Execute Reply 449 1.96 545.65 db file scattered read 3439 0.06 6.86 os thread startup 5 0.22 0.63 PX Deq: Signal ACK 31 0.05 0.16 direct path write temp 1 0.00 0.00 direct path read temp 343 0.00 0.02 enq: PS - contention 4 0.00 0.00 SQL*Net message from client 2 236.86 236.93 --PLS COMPARE VARIOUS STATS FOR THE EVENTS FROM AUTO TRACE OUTPUT AND TKPROF OUTPUT OF THE ORIGINAL QUERY AND TUNED QUERY. NOTICE THE REDUCTION IN 'physical reads','consistent gets' FROM AUTO TRACEL OU TPUT BETWEEN ORIGINAL AND TUNED QUERIES. NOTICE THE REDUCTION IN 'db file sequential read','db file scattered read', 'direct path write temp','direct path read temp' FROM TKPROF OUTPUT BETWEEN ORIGINAL AND TUNED QUERIES. ******************************************************************************** LESSONS LEARNED: 01 Choose the right column order for creating indexes. 02 Choose multi column indexes against single column indexes. 03 Avoid using views on large tables in your report. If possible access the base

tables, against the views. 04 The end goal is reduction in execution time of the report. THE END RESULT IS STUNNINGLY IMPRESSIVE: -- COUNT(1)---------- 1802284 Elapsed: 01:04:02.83 ORIGINAL REPORT -- COUNT(1)---------- 1802284 Elapsed: 00:11:35.45 TUNED REPORT WITH THREE NE W INDEXES AND A MATERIALIZED VIEW --NOTE: THE ORIGINAL QUERY AND TUNED QUERY WERE EXECUTED ON THE SAME DATABASE RUNING ON ORACLE 10.2.0.4 WITH THE SAME INIT.ORA SETTINGS. REFERENCES: http://www.ordba.net/CaseStudies/CaseStudy1.htm http://www.dbasupport.com/oracle/ora10g/TuneProcedure.shtml