Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Developer day v2

239 views

Published on

Developer day, Indexing, Storage parameters, Performance tuning, locks, latches

Published in: Software
  • Be the first to comment

  • Be the first to like this

Developer day v2

  1. 1. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Performance Optimization User Group Performance Tuning Day Oracle Confidential – Internal/Restricted/Highly Restricted Vivek Sharma Technologist – Core Technology & Cloud Asia Pacific Blog : viveklsharma.wordpress.com Twitter : @vivek_oracle
  2. 2. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 2 The Technical Observations & Views here are my own and not necessarily those of Oracle or its affiliates. These are purely based on my understanding, learning and resolution of various customer issues. Disclaimer
  3. 3. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Agenda for the Day • Database Concepts for Performance • Locks & Latches • Cursor Concepts & Sharing of Cursors • Parsing and Optimization • Indexes – Some Myths and Misconceptions • Oracle Optimizer – Important Statistics • Discussions (In-between Sessions & Breaks) Oracle Confidential – Internal/Restricted/Highly Restricted
  4. 4. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Before We Start… • What is the fastest way to Query a Row ? Oracle Confidential – Internal/Restricted/Highly Restricted • What is Bind Variable Peeking ? • What is the relationship between Parent Cursor & Child Cursor ? Answer to SOME of these during the DAY • What is the difference between Redo & Undo ? • What is IniTrans & MaxTrans ? • How many of you believe that db file scattered read can also be seen with Index Scans ? • How many of you believe that db file sequential read can also be seen with Full Scans ? • What is the difference between Memory_Target & SGA_Target ? • Which is better ? Index Scans or Full Scans ? • To read 100% of the rows, Full Scans or Index Scans ?
  5. 5. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Performance – Four Root Causes (Most Common) • Database is not being Used as it was Designed to be Used – DB Architect / Developers are Not-Aware of Database features – Application is as-is portable on all available Databases • Application Architecture / Code Design is Sub-Optimal – Solution Architect / DB Architect / Developers are not Database savvy – Developers use Shortcut Route to implement a solution • There is a Sub-Optimal algorithm in the Database – It could be a BUG causing issues – A feature improves a bottleneck but causes a side-effect • Human Error – Human tend to forget things under pressure (18c – Autonomous Database  ) Oracle Confidential – Internal/Restricted/Highly Restricted
  6. 6. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Why Concept ? • Database Architecture – Memory Structures – Background / Server Processes • Database Objects • SQL & PL/SQL • Database Tools & Features • Optimizer & Critical Inputs to Optimizer • New Features / Features Deprecated Oracle Confidential – Internal/Restricted/Highly Restricted
  7. 7. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | At High Level (In the order of priority) • Know your Database • Know your Development Tool • Know your Data • Know your Application • Know your Developers  Oracle Confidential – Internal/Restricted/Highly Restricted A Mantra for a Successful Development Project “Don’t treat Database as a Black Box”
  8. 8. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Architecture (Just Enough Diagram) Oracle Confidential – Internal/Restricted/Highly Restricted User or App Server Oracle Server Process Network Or Local Shared Pool Log Buffer Buffer Cache Shared Global Area - SGA LGWR DBWR Disk Reads Redo Logs Commits / Rollbacks
  9. 9. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Redo & Undo • Redo – Replay a Transaction – Flushed from SGA to On-Disk Logs • Undo – Opposite of Redo – Put back the Data – as it was – Critical for Read Consistency Oracle Confidential – Internal/Restricted/Highly Restricted Not an Overhead, but Generate as minimal as possible
  10. 10. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Maintaining Concurrency Seq 1 (User 1) Seq 2 (User 2) Seq 3 (User 1) Seq 4 (User 2) update stocks set qty = qty - 100 where prod_id = ‘A’; update stocks set qty = qty - 10 where prod_id = ‘B’; update stocks set qty = qty - 75 where prod_id = ‘B’; update stocks set qty = qty - 50 where prod_id = ‘A’; Success Success Locked Deadlock Readers do not block Readers / Writers Writers do not block Readers / Writers Writer block Writers ONLY at ROW level
  11. 11. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Maintaining Concurrency (contd..) • Locks – Application Enforced  Row Level Lock (TX Contention)  Ora-00060 (Deadlock) – Oracle Enforced  ITL (Lock Mode 6)  Bitmap (Lock Mode 4)  Duplicate Unique / Primary Key (Lock Mode 4)  TM Contention Oracle Confidential – Internal/Restricted/Highly Restricted Except for ITL, others are Application Issue itl.sql
  12. 12. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Question Time • Is Initrans a Block Level or a Table Level Parameter ? • What is the default value of Initrans for a Table ? • What is the default value of Initrans for an Index ? • Maximum number of Transaction an Oracle Block can accommodate ? Oracle Confidential – Internal/Restricted/Highly Restricted itl.sql Database Block Size 8192 Variable Header 48 Bytes ITL 24 Bytes 8192 – 48 8144 50% of 8144 4072 4072/24 169
  13. 13. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | ITL Allocation Process Diagram Oracle Confidential – Internal/Restricted/Highly Restricted
  14. 14. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | • Table Level Lock • Primary Cause – Update to a Primary Key (A Bad Idea) – Un-indexed Foreign Keys User 1 (11:57:50) Updates update emp set empno=:b1, ename=:b2, ename=:b3, job=:b4, mgr=:b5, hiredate=:b6, sal=:b7, comm=:b8, deptno=:b9 where rowid=:rowid; User 2 (11:57:51) Updates update dept set deptno=:b1, dname=:b2, loc=:b3 where rowid=:rowid; TM Contention
  15. 15. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | • Delete’s are cascaded to Child Table User 1 (11:57:50) Deletes delete from dept where deptno=10; User 2 (11:57:51) Deletes delete from dept where deptno=20; What is “On Delete Cascade” Constraint ? • User 2 Waits for “TM Contention” • Primary Cause – Deleting a Primary Key – Un-indexed Foreign Keys Idea is not to create Indexes on all the Foreign Keys Know your Application / Know your Queries
  16. 16. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | TM Contention • Table Level Lock • Primary Cause – Update to a Primary Key (A Bad Idea) – Unindexed Foreign Keys • Tools that UPDATE every column • Solution (Quantify Pros & Cons) – Update only Relevant Columns (No Primary Keys) – Index Foreign Keys Another example of “Know your Development Tool”
  17. 17. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | The Shared Pool • Objective – to read as much as from Memory • Stores Parsed version of SQL’s / PL/SQL’s • Split into various components – Library Cache, Dictionary Cache and many more… • LRU Algorithm • Protected by Latches / Mutexes (Mutual Exclusive Locks) • Contention : Frequent Allocation / De-Allocation of Memory • Contention : Frequent Loading of Cursors Sharing of SQL’s key to effective Shared Pool Utilization Maintain Coding Standards
  18. 18. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Query Processing Syntax / Semantics Checks Sharable Parent Cursor Available ? Execute Store Parent Cursor in Library Cache Query Transformation / Execution Plans Store child Cursor in Library Cache Sharable Child Cursor Available ? N N Y Y Soft Parse Hard Parse
  19. 19. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Sharing of SQL’s / Effective Memory Utilization • Literals v/s Bind Variables select empno, ename, sal from emp where empno=7369; select empno, ename, sal from emp where empno=7521; select empno, ename, sal from emp where empno=7902; select empno, ename, sal from emp where empno=:b1; Problem mpc.sql select sql_id, sql_text, executions, version_count, sharable_mem, force_matching_signature, plan_hash_value from v$sqlarea where sql_text like 'select empno, ename, sal from emp where empno%'; SQL_ID SQL_TEXT EXECUTIONS VERSION_COUNT SHARABLE_MEM FORCE_MATCHING_SIGNATURE PLAN_HASH_VALUE ------------- ---------------------------------- ---------- ------------- ------------ ------------------------ --------------- dyqfcpyqwd9zk select empno, ename, sal from emp 3 1 27554 7320676830101929156 2949544139 where empno=:b1 gzbpcx3suxjk3 select empno, ename, sal from emp 1 1 23419 5733699794739066958 2949544139 where empno=7902 0h7y2gqzrxubu select empno, ename, sal from emp 1 1 23419 5733699794739066958 2949544139 where empno=7369 5ptzb4hqxb1wv select empno, ename, sal from emp 1 1 23419 5733699794739066958 2949544139 where empno=7521
  20. 20. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Coding Standard (Multiple Parent Cursors) Parent (select ename from emp where empno=:b1) Child Parent (select dname from dept where deptno=:b2) Child Parent (SELECT ENAME FROM EMP WHERE EMPNO=:B1) Child Parent (select ename from emp e where empno=:b1) Child A Parent requires at least one Child Cursor Obvious Problem
  21. 21. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Coding Standard (Multiple Child Cursors) Child 0 (Schema X) Child 1 (Schema Y) Child 2 (Schema X OICA=10) Child 3 (Schema X different bind length) Parent (select * from emp where ename=:b1) Obvious – but a problem Problem My Blog “Authorization Check Failed ! Multiple Child Cursors..” Dec 2013 mcc.sql
  22. 22. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Bind Graduation Bind Name Bind Length Graduate to Child Number :b1 10 32 1 :b1 30 32 1 :b1 40 128 2 :b1 80 128 2 :b1 140 2000 3 :b1 2040 4000 4 select empno, ename, sal from emp where empno=:b1; Identify cause of Multiple Child Cursors v$sql_shared_cursor Pre 12c
  23. 23. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Sharing of SQL • Why ? – For Performance Reason – Scalability – Effective Resource Utilization (Memory / CPU) • • How ? – Implement Bind (only when required) – Maintain Coding Standard test_bind.sql
  24. 24. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Production Downtime (real life example) Snap Id Snap Time Sessions Curs/Sess --------- ------------------- -------- --------- Begin Snap: 24222 18-Apr-14 11:30:27 401 74.5 End Snap: 24223 18-Apr-14 12:30:16 783 86.0 Elapsed: 59.81 (mins) DB Time: 1,133.51 (mins) Cache Sizes ~~~~~~~~~~~ Begin End ---------- ---------- Buffer Cache: 23,552M 23,552M Std Block Size: 8K Shared Pool Size: 12,288M 12,288M Log Buffer: 15,112K Load Profile ~~~~~~~~~~~~ Per Second Per Transaction --------------- --------------- Redo size: 859,548.86 25,693.53 Logical reads: 154,690.90 4,624.00 Block changes: 3,634.57 108.64 Physical reads: 1,515.71 45.31 Physical writes: 296.98 8.88 User calls: 2,817.43 84.22 Parses: 2,842.89 84.98 Hard parses: 156.49 4.68 Sorts: 664.11 19.85 Logons: 0.97 0.03 Executes: 6,454.01 192.92 Transactions: 33.45 19 Active 5.5%
  25. 25. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Production Downtime (real life example) Top 5 Timed Events Avg %Total ~~~~~~~~~~~~~~~~~~ wait Call Event Waits Time (s) (ms) Time Wait Class ------------------------------ ------------ ----------- ------ ------ ---------- db file sequential read 4,874,348 35,300 7 51.9 User I/O CPU time 22,056 32.4 ARCH wait on SENDREQ 2,787 13,399 4808 19.7 Network gc cr block busy 238,851 2,833 12 4.2 Cluster gcs log flush sync 1,017,044 2,672 3 3.9 Other ------------------------------------------------------------- Instance Activity Stats DB/Inst: IIMSP/IIMSP2 Snaps: 24222-24223 Statistic Total per Second per Trans -------------------------------- ------------------ -------------- ------------- parse count (failures) 357,665 99.7 3.0 parse count (hard) 561,605 156.5 4.7 parse count (total) 10,202,613 2,842.9 85.0 64% Failures Fix High Hard Parse Failures = Unwanted Work Fix Hard Parses
  26. 26. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 26 Client / Application Handle Server Process Memory Private SQL Area SGA Library Cache Shared SQL Area Cursor Concepts • Private SQL Area – Parsed SQL Statement – Session Specific Information • Shared SQL Area – Parsed SQL Statement – Execution Plan PGA SGA scc.sql Locks
  27. 27. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 27 Session Cached Cursors • Avoids Soft Parse – Better Concurrency • Maintains Direct Address to the Memory Object • Locks the Object to avoid flushing out • Reduces the Contention on Library Cache Latches & Locks & Mutexes • Cursors are cached after – 3 Executions within a Session or – 2 Executions within a Session, if already Hard Parsed by other Session • Defaults to 50 – Refrain from setting to a very high value – Monitor parse count (total), parse count (hard), session cache cursor hits
  28. 28. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | The Buffer Cache • Objective – to read as much as from Memory • Caches Data Blocks to eliminate Disk I/O’s • Blocks are either Dirty or Clean • LRU Algorithm, Mid Point Insertion & Touch Count (TCH) • Protected by Latches to maintain LRU and TCH • Contention : Unwanted I/O’s • Contention : High Concurrency on a Block Logical Reads are Faster than Disk Reads Logical Reads consume CPU Effective Utilization of Cache – Optimizing I/O’s
  29. 29. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Question time… • Outer Query select get_dname(deptno) deptno, ename, sal from emp where deptno in (10,20); • Query in GET_DNAME function select dname from dept where deptno=:b1; test_scalar.sql Blog on “Cache Buffers Chains Latch Contention…” May 2010 Scalar Subqueries, DETERMINISTIC, RESULT_CACHE • Assuming, 200 rows are fetched by Outer Query What would be the total number of executions of the Function ?
  30. 30. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 30 Readers do not block Readers / Writers Writers do not block Readers / Writers Writer block Writers ONLY at ROW level Data Layer v/s Cache Layer Readers MUST block Writers Single Writer MUST block All Operations • For Data Layer – Protected by Locks & Enqueues • For Cache Layer (Raw Memory) – Protected by Latches & Mutexes
  31. 31. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Waits (to name a few) • db file sequential read • db file scattered read • read by other session • direct path read • Latch / Mutexes Eliminating Waits critical for Response Sensitive Application Single Block Reads Multi Block Reads Block Level Contention Bypass Cache / Smart Scans Concurrency
  32. 32. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Row Migration row_migration.sql Higher Value means Impact of Migrated Rows, Chained Rows, >255 Columns • Impact due to Additional HOP (Additional I/O) • Impact Index Scans Index Block Table Block Index Block Table Block Table Blockv/s Check for table fetch continued row
  33. 33. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Question In terms of performance – Is there any difference between these queries ? select a1, a10 from a where rowid=:rowid; Additional LIO’s due to Intra-Block Chaining Table A Rows 10000 Blocks 100 Columns 300 select a1, a200 from a where rowid=:rowid; select a1, a300 from a where rowid=:rowid; Intra_block.sql I/O’s (300 Columns) I/O’s (600 Columns) 1 to 45 = 7 I/O’s 1 to 90 = 7 I/O’s 46 to 300 = 8 I/O’s 91 to 345 = 8 I/O’s 346 onwards = 9 I/O’s
  34. 34. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Which Query is better ? Ensure Rewrite is functionally Correct Don’t Rely on Optimizer Transformation • Table T1 with Billions of Rows and an Index on C4 • Table T2 with Millions of Rows and Index T2_IDX(A,B) select t1.c1, t1.c2, (select t2.c3 from t2 where t2.a = t1.a and t2.b = t1.b) c3 from t1 Where t1.c4='AIOUG' select t1.c1, t1.c2, (select func(t2,a,b) from dual) c3 from t1 where t1.c4='AIOUG' select t1.c1, t1.c2, t2.c3 from t1, t2 where t1.c4='AIOUG' and t1.a = t2.a and t1.b = t2.b (+) (+) • Assuming the Predicate on T1 fetches only 1 Row • Assuming the Predicate on T1 fetches 100,000 Rows qt_scalar.sql
  35. 35. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Explain Plan - Bind Variables Trap ep.sql Use Run Time Plan, using dbms_xplan.display_cursor • Bind with Explain Plan has two problems – Bind Variables are declared as VARCHAR2 (Default Behavior) – Plan Generation does not peek into Bind Variable • Plan, may or may not match (Not Reliable) • AUTOTRACE has similar problem
  36. 36. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Bind Peeking • Introduced in 9i • Hard Parse, as if Bind is a Literal • Appropriate plan based on Bind Value • 9i & 10g, Hard Parse Bind Value Wins • 11g – Adaptive Cursor Sharing • Plan Upgraded, post subsequent execution • Bad Query Performance, at least Once bp.sql How do you take care of a High Performance Application ? Solution : Use Bind, only when required. BIND_AWARE hint.
  37. 37. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Indexes not being Used (Real Life Example) INST_ID SQL_ID SQL_TEXT EXECUTIONS BUFFER_GETS -------- ------------- ---------------------------------------- ---------- ----------- 1 1kfxns3m02pu3 select distinct TXT_ADDRESS_LINE_1 , TXT 28 1213546962 _ADDRESS_LINE_2 , TXT_APARTMENT , TXT_ST REET , TXT_CITYDISTRICT , TXT_AREAVILLAG E , TXT_STATE , NUM_PINCODE from genmst_ location a, Risk_headers b where a.NUM_L OCATION_CD = b.location_code and a.num_l ocation_cd = (SELECT location_code FROM risk_headers WHERE reference_num = :"SYS _B_0" AND reference_date = TO_DATE (:"SY S_B_1", :"SYS_B_2") and POLICY_RISK_SERI AL = :"SYS_B_3") Enter value for table: RISK_HEADERS OWNER NUM_ROWS BLOCKS ---------- ---------- ---------- INS 14844896 846555 select distinct TXT_ADDRESS_LINE_1, TXT_ADDRESS_LINE_2, TXT_APARTMENT, TXT_STREET , TXT_CITYDISTRICT , TXT_AREAVILLAGE , TXT_STATE , NUM_PINCODE From genmst_location a, Risk_headers b where to_a.NUM_LOCATION_CD = b.location_code and a.num_location_cd = (SELECT location_code FROM INS.risk_headers WHERE reference_num = '201412200014630’ AND reference_date = TO_DATE('20/12/2014','DD/MM/YYYY’) and POLICY_RISK_SERIAL = 1)
  38. 38. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Indexes not being Used (Real Life Example) -------------------------------------------------------------- | Id | Operation | Name | -------------------------------------------------------------- | 0 | SELECT STATEMENT | | | 1 | HASH UNIQUE | | | 2 | NESTED LOOPS | | | 3 | TABLE ACCESS BY INDEX ROWID | GENMST_LOCATION | |* 4 | INDEX UNIQUE SCAN | PK_GENMST_LOCATION | | 5 | TABLE ACCESS BY INDEX ROWID| RISK_HEADERS | |* 6 | INDEX UNIQUE SCAN | PK_RISK_HEADERS | |* 7 | TABLE ACCESS FULL | RISK_HEADERS | -------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 4 - access("A"."NUM_LOCATION_CD"=TO_NUMBER()) 6 - access("REFERENCE_NUM"=TO_NUMBER(:SYS_B_0) AND "REFERENCE_DATE"=TO_DATE(:SYS_B_1,:SYS_B_2) AND "POLICY_RISK_SERIAL"=:SYS_B_3) 7 - filter("A"."NUM_LOCATION_CD"=TO_NUMBER("B"."LOCATION_CODE")) select distinct TXT_ADDRESS_LINE_1, TXT_ADDRESS_LINE_2, TXT_APARTMENT, TXT_STREET , TXT_CITYDISTRICT , TXT_AREAVILLAGE , TXT_STATE , NUM_PINCODE From genmst_location a, Risk_headers b where to_a.NUM_LOCATION_CD = b.location_code and a.num_location_cd = (SELECT location_code FROM INS.risk_headers WHERE reference_num = '201412200014630’ AND reference_date = TO_DATE('20/12/2014','DD/MM/YYYY’) and POLICY_RISK_SERIAL = 1)
  39. 39. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Indexes not being Used (Real Life Example) select distinct TXT_ADDRESS_LINE_1, TXT_ADDRESS_LINE_2, TXT_APARTMENT, TXT_STREET , TXT_CITYDISTRICT , TXT_AREAVILLAGE , TXT_STATE , NUM_PINCODE From genmst_location a, Risk_headers b where to_char(to_a.NUM_LOCATION_CD) = b.location_code and a.num_location_cd = (SELECT location_code FROM INS.risk_headers WHERE reference_num = '201412200014630’ AND reference_date = TO_DATE('20/12/2014','DD/MM/YYYY’) and POLICY_RISK_SERIAL = 1) Datatype Mismatch – Should be taken care during Design Phase
  40. 40. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Select the Best Index 1. SELECT C FROM T1 WHERE A=:B1; 2. SELECT C, D FROM T1 WHERE A=:B1 AND B=:B2; a. Index on (A) b. Index on (B,A) c. Index on (A,B) Both the Queries Only 2nd Query Both the Queries pc.sql What will be the Impact of Index C on 1st Query ? SQL Performance Analyzer – Proactive Performance Analysis
  41. 41. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Select the Best Index 1. SELECT * FROM T1 WHERE OBJECT_ID=100; 2. SELECT * FROM T1 WHERE TEMPORARY=‘Y’ AND OBJECT_ID=100; 3. SELECT * FROM T1 WHERE TEMPORARY=‘Y’; a. Index on (OBJECT_ID) b. Index on (OBJECT_ID, TEMPORARY) c. Index on (TEMPORARY, OBJECT_ID) SKIP SCAN requires a Low Cardinality Column as a Leading Column Num_Rows 90410 Object_id Num_Distinct => 90410 Temporary Num_Distinct => 2
  42. 42. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Index Myths & Misconceptions I have to come across a scenerio where Index Rebuild actually Resolved Performance Issues • Index Rebuild – To make it more Efficient or Small – Not always True – In case the Index is Shrinked, it can introduce Block Level Contention – Index tend to get into their Original Shape (Pre-Rebuild) – Improving CF of an Index may Impact CF of another Index – Statistics : branch node splits / leaf node splits & leaf node 90-10 splits – Exception : Rebuilding an Index to convert from Reverse to NoReverse or vice versa ir.sql
  43. 43. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Understanding Block Split (50-50) • 50-50 Split caused by – Updates / Inserts of a Non-Largest Value into a Leaf Block Update table set value=‘GOA’ where value=‘BAA’; OR insert into table values (‘GOA’) AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY
  44. 44. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | • 50-50 Split caused by – Updates / Inserts of a Non-Largest Value into a Leaf Block Update table set value=‘GOA’ where value=‘BAA’; OR insert into table values (‘GOA’) AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY DELETE INSERT Understanding Block Split (50-50)
  45. 45. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | • 50-50 Split caused by – Updates / Inserts of a Non-Largest Value into a Leaf Block Update table set value=‘GOA’ where value=‘BAA’; OR insert into table values (‘GOA’) AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY DELETE Understanding Block Split (50-50)
  46. 46. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | • 50-50 Split caused by – Updates / Inserts of a Non-Largest Value into a Leaf Block Update table set value=‘GOA’ where value=‘BAA’; OR insert into table values (‘GOA’) AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY DELETE Understanding Block Split (50-50)
  47. 47. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | • 50-50 Split caused by – Updates / Inserts of a Non-Largest Value into a Leaf Block Update table set value=‘GOA’ where value=‘BAA’; OR insert into table values (‘GOA’) AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY DELETE Understanding Block Split (50-50)
  48. 48. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | • 50-50 Split caused by – Updates / Inserts of a Non-Largest Value into a Leaf Block Update table set value=‘GOA’ where value=‘BAA’; OR insert into table values (‘GOA’) AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN EAZ LMN OAK ODL KAY AAA AAC AAD BAA BCC CAB CDA CDE CEA CEB DAA DAD DAY FAA EAN OAK ODL KAY DELETE EAZ GOA LMN INSERT Understanding Block Split (50-50)
  49. 49. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Understanding Block Split (90-10) • 90-10 Split caused by – Monotonically Increasing Value (Date-Time/Sequences) insert into table values (32); 1 2 3 4 5 6 8 9 11 12 14 15 16 18 19 20 21 22 23 24 25 27 28 29 30 1 2 3 4 5 6 8 9 11 12 14 15 16 18 19 20 21 22 23 24 25 27 28 29 30 INSERT
  50. 50. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Understanding Block Split (90-10) • 90-10 Split caused by – Monotonically Increasing Value (Date-Time/Sequences) insert into table values (32); 1 2 3 4 5 6 8 9 11 12 14 15 16 18 19 20 21 22 23 24 25 27 28 29 30 1 2 3 4 5 6 8 9 11 12 14 15 16 18 19 20 21 22 23 24 25 27 28 29 30 32 New Block Allocated Inserted
  51. 51. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Indexing Guidelines Guideline Reasoning Create as many, but try to keep the number minimum. Indexes increase Performance, but also consume disk space and processing resources. Test First to determine Quantifiable Benefits Same as above. Also, an Index to optimize one query can impact other queries. Use the correct type of Index Correct Index usage maximizes performance Use Btree Indexes in OLTP Btree Indexes are suitable for OLTP as the data is frequently updated Use Bitmap Indexes in Data warehouse environments Bitmap Indexes are suitable for Data warehouses as the data is rarely manipulated Check for the Column Ordering based on Application / Query pattern Avoid Redundant Indexes Don’t Rebuild Indexes unless you have a solid reason Rebuilding can cause concurrency issues Monitor your Indexes and drop indexes that aren’t used Doing this frees up space and improves DML Before Dropping an index, consider marking them Invisible This allows you to better determine if there are any performance impact before you drop these.
  52. 52. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | • Requirement – Sales Tax Report • Join Financial Year Table to Invoices Table • DB Version 8174 v/s Now 52 Previous Year Finance Table (20 GB) Current Year Finance Table (5 GB) Invoices Table (100 GB) Invoices Table (100 GB) UNION ALL Issue : UAT – 5 Minutes Prod – 60+ Minutes 2 Scans of 100 GB Optimizer Evolution…(An Example)
  53. 53. Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Modification - Rewritten for a Single Scan of Invoices 53 Now, optimizer does it for us by way of a Query Transformation Join Factorization Previous Year Finance Table (20 GB) Current Year Finance Table (5 GB) Invoices Table (100 GB) UNION ALL Benefit : < 1 Minute Optimizer Evolution…(An Example)

×