In Sync11 Presentation The Biggest Loser


Published on

Published in: Technology, Sports
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

In Sync11 Presentation The Biggest Loser

  1. 1. The biggest loser database<br />Paul Guerin<br />Sydney Convention Centre<br />August 17 2011<br />
  2. 2. The weigh in…….<br />Capacity right-sizing to achieve business outcomes.<br />
  3. 3. Size<br />Starting size 3 years ago = 730GB<br />Size 2 years later = 550GB<br />Total loss<br />= 180GB + 2 years of growth<br />= 850 GB<br />$$$ = GB * num_entities * $/GB<br />= 850 * 8 * $38.50<br />= $261,800 (over 2 years)<br />$1/4m over 2 years<br />
  4. 4. Growth rate<br />Growth rate was 29 GB/month.<br />Now 12 GB/month….<br />Less than half the previous growth rate…<br />
  5. 5. Table waste<br />
  6. 6. Unused tables<br />Check for tables that are not used any more<br />Suspect tables may be named: *old, *bkp, etc.<br />Monitor the table for DML activity.<br />v$segment_statistics<br />Analyse the stored procedures for dependencies.<br />dba_source<br />Setup an audit of the table.<br />AUDIT select, insert, delete, update ON <schema.object><br />Example: A table and its indexes (84GB in total) were identified as unused and dropped.<br />
  7. 7. Tables in use may contain data that has expired.<br />Question:<br />“Do we really need 10 years of data in this table?”<br />Answer:<br />“No, we only need the last 3 months.”<br />If required, archive data using the data pump query clause.<br />expdp hr QUERY=employees:"WHERE dte < sysdate-100"<br />Example: Deleted from a 62GB table then rebuilt to 5GB.<br />
  8. 8. Direct-path inserts<br />Potential performance benefits to inserting above the HWM.<br />INSERT /*+ append */ INTO … <br />SELECT * FROM …;<br />Potential problem:<br />Inserts always above the HWM, but deletes are always below the HWM.<br />Low block density results as deleted space is not reused in a direct-path insert.<br />Example: A low block density table rebuilt from 42GB to 2GB.<br />
  9. 9. Table compression<br />OLTP compression (licence required)<br />Conventional compression<br />ALTER TABLE <schema.tablename> NOLOGGING COMPRESS;<br />INSERT /*+ APPEND */ INTO <schema.tablename><br />SELECT * FROM …..;<br />Tips:<br />Order low cardinality columns first.<br />Order columns with many nulls last (otherwise costs 1 byte per null).<br />
  10. 10. Index waste<br />
  11. 11. Index waste:<br />Many index configurations are possible.<br />Often not well understood by developers and DBAs.<br />Many SQL statements to consider makes analysis laborious.<br />Large potential for index waste and poor DML performance.<br />Start looking for waste by analysing the existing indexes.<br />
  12. 12. SQL statements decide which indexes are used<br />An index on this predicate will not use an index:<br />WHERE x NOT IN (0,1);<br />An index on this predicate may use an index:<br />WHERE x <0 OR (x>0 AND x<1) OR x >1;<br /> -- equivalent<br />
  13. 13. An index on this predicate will not use an index:<br />WHERE SUBSTR(y, 1, 10) LIKE '610233997600';<br />An index on this predicate may use an index:<br />WHERE y LIKE '6102339976__'; -- equivalent<br />Opportunities – change the operator to use the index, or drop the index not being used.<br />
  14. 14. Unused indexes<br />hh_agg_bucket$bckt(bucket) -- 7.5GB<br />hh_agg_bucket$cntrv(cont_id, rev) -- 6.4GB<br />hh_agg_bucket$exe(execution_number) -- 4.7GB<br />Analysis & testing<br />No evidence of statements referencing bucket, cont_id, rev.<br />No indexes on foreign keys<br />No column transivity on join statements<br />Found useful access paths only on the 3rd index.<br />Freed 13.9GB by dropping the unused indexes<br />
  15. 15. Redundant indexes<br />SITE$NDX1(datetm, siteid) -- 32GB<br />SITE$NDX2(siteid, datetm) -- 34GB<br />Proposition – Only 1 index used for the access path<br />Analysis & testing – Found only used access path on SITE$NDX2.<br />Dropped SITE$NDX1 to free 32GB<br />
  16. 16. NDX$PK(A, B) /* primary key on this index */<br />NDX1(A, B, C) /* can relocate PK to this index */<br />Proposition A:<br />If SQL statements reference A & B only<br />NDX$PK more efficient than NDX1<br />NDX1 redundant.<br />
  17. 17. NDX$PK(A, B) /* primary key on this index */<br />NDX1(A, B, C) /* can relocate PK to this index */<br />Proposition B:<br />If SQL statements reference A, B, and C (via FFIS or FIS)<br />NDX1 more efficient than NDX$PK.<br />NDX$PK redundant, so put PK on NDX1.<br />
  18. 18. NDX$PK(A, B) /* primary key on this index */<br />NDX1(A, B, C) /* can relocate PK to this index */<br />Proposition C:<br />If SQL statements reference A, B, and C (and FFIS + FIS not present)<br />NDX1 redundant as C doesn’t make the index more unique.<br />Keep NDX$PK.<br />
  19. 19. B-tree compression<br />B-tree indexes can be compressed<br />Low cardinality keys<br />Potential performance benefits for FFIS, FIS, and IRS.<br />ANALYZE INDEX <schema.indexname> VALIDATE STRUCTURE;<br />SELECT name, partition_name, opt_cmpr_count, opt_cmpr_pctsave FROM INDEX_STATS;<br />ALTER INDEX <schema.indexname> REBUILD COMPRESS <#prefix columns>;<br />
  20. 20. Compressed B-tree examples<br />FCASTDTL$FCASTID_DATETIME<br />-- 4.8GB compressed to 2.9GB<br />FCASTDTL$FCASTID_REVISION<br />-- 3.5GB compressed to 1.9GB<br />
  21. 21. Bitmap indexes - already compressed<br />For extreme compression; use bitmap indexes<br />Best for single column low cardinality keys.<br />No cluster factor.<br />Potential performance benefits for FIS.<br />Good for SQLs that aggregate, but few updates and deletes.<br />CREATE BITMAP INDEX <schema.indexname> ON …;<br />Bitmap compression ratio is in the order of 100:1, so a 5GB b-tree may compress to a 0.05GB bitmap.<br />
  22. 22. Last resort - rebuild<br />Rebuilding is not as effective as eliminating….<br />-- Determine the amount of deleted space inside an index<br />ANALYZE INDEX <schema.indexname> VALIDATE STRUCTURE;<br />-- % of Btree that is deleted.<br />SELECT DECODE(LF_ROWS,0,NULL,ROUND(DEL_LF_ROWS/LF_ROWS*100,1)) <br />FROM INDEX_STATS;<br />
  23. 23. Business outcomes<br />Business outcomes from capacity right-sizing<br />Better database scalability<br />Leads to performance improvements.<br />Lower storage footprint<br />Equates to lower costs. ($1/4m over 2 years)<br />Growth rate reductions are sustainable.<br />Compared to index rebuilding which is often performed over and over again.<br />Good diets - cut the fat, not the muscle<br />
  24. 24. The biggest loser database<br /><br />