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.

In Sync11 Presentation The Biggest Loser

  • Login to see the comments

  • Be the first to like this

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 />