Databse & Technology 2 _ Paul Guerin _ The biggest looser database - a boot camp case study.pdf

The most comprehensive Oracle applications & technology content under one roof The most comprehensive Oracle applications & technology content under one roof

The biggest loser database

Paul Guerin

Sydney Conven1on Centre August 17 2011

The most comprehensive Oracle applications & technology content under one roof

THE WEIGH IN……. Capacity right-‐sizing to achieve business outcomes.


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

200

400

600

800

1000

1200

1400

1600

1800

10/0

9/20

07

24/0

9/20

07

8/10

/200

7 22

/10/

2007

5/

11/2

007

19/1

1/20

07

3/12

/200

7 17

/12/

2007

31

/12/

2007

14

/01/

2008

28

/01/

2008

11

/02/

2008

25

/02/

2008

10

/03/

2008

24

/03/

2008

7/

04/2

008

21/0

4/20

08

5/05

/200

8 19

/05/

2008

2/

06/2

008

16/0

6/20

08

30/0

6/20

08

14/0

7/20

08

28/0

7/20

08

11/0

8/20

08

25/0

8/20

08

8/09

/200

8 22

/09/

2008

6/

10/2

008

20/1

0/20

08

3/11

/200

8 17

/11/

2008

1/

12/2

008

15/1

2/20

08

29/1

2/20

08

12/0

1/20

09

26/0

1/20

09

9/02

/200

9 23

/02/

2009

9/

03/2

009

23/0

3/20

09

6/04

/200

9 20

/04/

2009

4/

05/2

009

18/0

5/20

09

1/06

/200

9 15

/06/

2009

29

/06/

2009

13

/07/

2009

27

/07/

2009

10

/08/

2009

24

/08/

2009

7/

09/2

009

21/0

9/20

09

5/10

/200

9 19

/10/

2009

2/

11/2

009

16/1

1/20

09

30/1

1/20

09

14/1

2/20

09

28/1

2/20

09

11/0

1/20

10

25/0

1/20

10

8/02

/201

0 22

/02/

2010

8/

03/2

010

22/0

3/20

10

5/04

/201

0 19

/04/

2010

3/

05/2

010

17/0

5/20

10

31/0

5/20

10

14/0

6/20

10

28/0

6/20

10

12/0

7/20

10

26/0

7/20

10

9/08

/201

0 23

/08/

2010

6/

09/2

010

20/0

9/20

10

4/10

/201

0 18

/10/

2010

1/

11/2

010

15/1

1/20

10

29/1

1/20

10

13/1

2/20

10

27/1

2/20

10

10/0

1/20

11

24/0

1/20

11

7/02

/201

1 21

/02/

2011

7/

03/2

011

21/0

3/20

11

4/04

/201

1


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

0

200

400

600

800

1000

1200

1400

1600

1800

10/0

9/20

07

24/0

9/20

07

8/10

/200

7 22

/10/

2007

5/

11/2

007

19/1

1/20

07

3/12

/200

7 17

/12/

2007

31

/12/

2007

14

/01/

2008

28

/01/

2008

11

/02/

2008

25

/02/

2008

10

/03/

2008

24

/03/

2008

7/

04/2

008

21/0

4/20

08

5/05

/200

8 19

/05/

2008

2/

06/2

008

16/0

6/20

08

30/0

6/20

08

14/0

7/20

08

28/0

7/20

08

11/0

8/20

08

25/0

8/20

08

8/09

/200

8 22

/09/

2008

6/

10/2

008

20/1

0/20

08

3/11

/200

8 17

/11/

2008

1/

12/2

008

15/1

2/20

08

29/1

2/20

08

12/0

1/20

09

26/0

1/20

09

9/02

/200

9 23

/02/

2009

9/

03/2

009

23/0

3/20

09

6/04

/200

9 20

/04/

2009

4/

05/2

009

18/0

5/20

09

1/06

/200

9 15

/06/

2009

29

/06/

2009

13

/07/

2009

27

/07/

2009

10

/08/

2009

24

/08/

2009

7/

09/2

009

21/0

9/20

09

5/10

/200

9 19

/10/

2009

2/

11/2

009

16/1

1/20

09

30/1

1/20

09

14/1

2/20

09

28/1

2/20

09

11/0

1/20

10

25/0

1/20

10

8/02

/201

0 22

/02/

2010

8/

03/2

010

22/0

3/20

10

5/04

/201

0 19

/04/

2010

3/

05/2

010

17/0

5/20

10

31/0

5/20

10

14/0

6/20

10

28/0

6/20

10

12/0

7/20

10

26/0

7/20

10

9/08

/201

0 23

/08/

2010

6/

09/2

010

20/0

9/20

10

4/10

/201

0 18

/10/

2010

1/

11/2

010

15/1

1/20

10

29/1

1/20

10

13/1

2/20

10

27/1

2/20

10

10/0

1/20

11

24/0

1/20

11

7/02

/201

1 21

/02/

2011

7/

03/2

011

21/0

3/20

11

4/04

/201

1


TABLE WASTE


Unused tables Check for tables that are not used any more

–  Suspect tables may be named: *old, *bkp, etc. –  Monitor the table for DML ac1vity.

•  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 iden1fied as unused and dropped.


Tables in use may contain data that has expired. Ques1on:

“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.


Direct-‐path inserts Poten1al performance benefits to inser1ng above the HWM. INSERT /*+ append */ INTO … SELECT * FROM …;

Poten&al 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.


Table compression •  OLTP compression (licence required) •  Conven1onal 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).


INDEX WASTE


Index waste: – Many index configura1ons are possible. – Oien not well understood by developers and DBAs. – Many SQL statements to consider makes analysis laborious.

–  Large poten1al for index waste and poor DML performance.

Start looking for waste by analysing the exis1ng indexes.


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


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

Opportuni1es – change the operator to use the index, or drop the index not being used.


Unused indexes

hh_agg_bucket$bckt(bucket) -‐-‐ 7.5GB hh_agg_bucket$cntrv(cont_id, rev) -‐-‐ 6.4GB hh_agg_bucket$exe(execu1on_number) -‐-‐ 4.7GB Analysis & tes1ng –  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


Redundant indexes

SITE$NDX1(datetm, siteid) -‐-‐ 32GB SITE$NDX2(siteid, datetm) -‐-‐ 34GB

Proposi1on – Only 1 index used for the access path Analysis & tes1ng – Found only used access path on SITE$NDX2.

Dropped SITE$NDX1 to free 32GB


NDX$PK(A, B) /* primary key on this index */ NDX1(A, B, C) /* can relocate PK to this index */

Proposi1on A: –  If SQL statements reference A & B only

•  NDX$PK more efficient than NDX1 •  NDX1 redundant.



Proposi1on 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.



Proposi1on 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.


B-‐tree compression B-‐tree indexes can be compressed

–  Low cardinality keys –  Poten1al 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>;


Compressed B-‐tree examples

FCASTDTL$FCASTID_DATETIME

-- 4.8GB compressed to 2.9GB

FCASTDTL$FCASTID_REVISION -- 3.5GB compressed to 1.9GB


Bitmap indexes -‐ already compressed For extreme compression; use bitmap indexes

–  Best for single column low cardinality keys. –  No cluster factor. –  Poten1al performance benefits for FIS. –  Good for SQLs that aggregate, but few updates and deletes.

CREATE BITMAP INDEX <schema.indexname> ON …; Bitmap compression ra1o is in the order of 100:1, so a 5GB b-‐tree may

compress to a 0.05GB bitmap.


Last resort -‐ rebuild Rebuilding is not as effec1ve as elimina1ng…. -- 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;


Business outcomes

Business outcomes from capacity right-‐sizing –  Beuer database scalability

•  Leads to performance improvements. –  Lower storage footprint

•  Equates to lower costs. ($1/4m over 2 years) – Growth rate reduc1ons are sustainable.

•  Compared to index rebuilding which is oien performed over and over again.

Good diets -‐ cut the fat, not the muscle

The most comprehensive Oracle applications & technology content under one roof The most comprehensive Oracle applications & technology content under one roof

The biggest loser database

eval.insync11.com.au