1. The biggest loser database Paul Guerin Sydney Convention Centre August 17 2011

2. The weigh in……. Capacity right-sizing to achieve business outcomes.

3. Size Starting size 3 years ago = 730GB Size 2 years later = 550GB Total loss = 180GB + 2 years of growth = 850 GB $$$ = GB * num_entities * $/GB = 850 * 8 * $38.50 = $261,800 (over 2 years) $1/4m over 2 years

4. Growth rate Growth rate was 29 GB/month. Now 12 GB/month…. Less than half the previous growth rate…

5. Table waste

6. Unused tables Check for tables that are not used any more Suspect tables may be named: *old, *bkp, etc. Monitor the table for DML activity. v$segment_statistics Analyse the stored procedures for dependencies. dba_source Setup an audit of the table. AUDIT select, insert, delete, update ON <schema.object> Example: A table and its indexes (84GB in total) were identified as unused and dropped.

7. Tables in use may contain data that has expired. Question: “Do we really need 10 years of data in this table?” Answer: “No, we only need the last 3 months.” If required, archive data using the data pump query clause. expdp hr QUERY=employees:"WHERE dte < sysdate-100" Example: Deleted from a 62GB table then rebuilt to 5GB.

8. Direct-path inserts Potential performance benefits to inserting above the HWM. INSERT /*+ append */ INTO … SELECT * FROM …; Potential problem: Inserts always above the HWM, but deletes are always below the HWM. Low block density results as deleted space is not reused in a direct-path insert. Example: A low block density table rebuilt from 42GB to 2GB.

9. Table compression OLTP compression (licence required) Conventional compression ALTER TABLE <schema.tablename> NOLOGGING COMPRESS; INSERT /*+ APPEND */ INTO <schema.tablename> SELECT * FROM …..; Tips: Order low cardinality columns first. Order columns with many nulls last (otherwise costs 1 byte per null).

10. Index waste

11. Index waste: Many index configurations are possible. Often not well understood by developers and DBAs. Many SQL statements to consider makes analysis laborious. Large potential for index waste and poor DML performance. Start looking for waste by analysing the existing indexes.

12. SQL statements decide which indexes are used An index on this predicate will not use an index: WHERE x NOT IN (0,1); An index on this predicate may use an index: WHERE x <0 OR (x>0 AND x<1) OR x >1; -- equivalent

13. An index on this predicate will not use an index: WHERE SUBSTR(y, 1, 10) LIKE '610233997600'; An index on this predicate may use an index: WHERE y LIKE '6102339976__'; -- equivalent Opportunities – change the operator to use the index, or drop the index not being used.

14. Unused indexes hh_agg_bucket$bckt(bucket) -- 7.5GB hh_agg_bucket$cntrv(cont_id, rev) -- 6.4GB hh_agg_bucket$exe(execution_number) -- 4.7GB Analysis & testing No evidence of statements referencing bucket, cont_id, rev. No indexes on foreign keys No column transivity on join statements Found useful access paths only on the 3rd index. Freed 13.9GB by dropping the unused indexes

15. Redundant indexes SITE$NDX1(datetm, siteid) -- 32GB SITE$NDX2(siteid, datetm) -- 34GB Proposition – Only 1 index used for the access path Analysis & testing – Found only used access path on SITE$NDX2. Dropped SITE$NDX1 to free 32GB

16. NDX$PK(A, B) /* primary key on this index */ NDX1(A, B, C) /* can relocate PK to this index */ Proposition A: If SQL statements reference A & B only NDX$PK more efficient than NDX1 NDX1 redundant.

17. NDX$PK(A, B) /* primary key on this index */ NDX1(A, B, C) /* can relocate PK to this index */ Proposition B: If SQL statements reference A, B, and C (via FFIS or FIS) NDX1 more efficient than NDX$PK. NDX$PK redundant, so put PK on NDX1.

18. NDX$PK(A, B) /* primary key on this index */ NDX1(A, B, C) /* can relocate PK to this index */ Proposition C: If SQL statements reference A, B, and C (and FFIS + FIS not present) NDX1 redundant as C doesn’t make the index more unique. Keep NDX$PK.

19. B-tree compression B-tree indexes can be compressed Low cardinality keys Potential performance benefits for FFIS, FIS, and IRS. ANALYZE INDEX <schema.indexname> VALIDATE STRUCTURE; SELECT name, partition_name, opt_cmpr_count, opt_cmpr_pctsave FROM INDEX_STATS; ALTER INDEX <schema.indexname> REBUILD COMPRESS <#prefix columns>;

20. Compressed B-tree examples FCASTDTL$FCASTID_DATETIME -- 4.8GB compressed to 2.9GB FCASTDTL$FCASTID_REVISION -- 3.5GB compressed to 1.9GB

21. Bitmap indexes - already compressed For extreme compression; use bitmap indexes Best for single column low cardinality keys. No cluster factor. Potential performance benefits for FIS. Good for SQLs that aggregate, but few updates and deletes. CREATE BITMAP INDEX <schema.indexname> ON …; Bitmap compression ratio is in the order of 100:1, so a 5GB b-tree may compress to a 0.05GB bitmap.

22. Last resort - rebuild Rebuilding is not as effective as eliminating…. -- Determine the amount of deleted space inside an index ANALYZE INDEX <schema.indexname> VALIDATE STRUCTURE; -- % of Btree that is deleted. SELECT DECODE(LF_ROWS,0,NULL,ROUND(DEL_LF_ROWS/LF_ROWS*100,1)) FROM INDEX_STATS;

23. Business outcomes Business outcomes from capacity right-sizing Better database scalability Leads to performance improvements. Lower storage footprint Equates to lower costs. ($1/4m over 2 years) Growth rate reductions are sustainable. Compared to index rebuilding which is often performed over and over again. Good diets - cut the fat, not the muscle

24. The biggest loser database eval.insync11.com.au