The document discusses database optimization techniques including right-sizing the database capacity, identifying unused tables and indexes to drop, archiving expired data to reduce table sizes, improving insert performance with direct-path inserts, rebuilding tables to increase block density, enabling table compression, and identifying unnecessary indexes. Specific examples are provided where these techniques reduced database sizes from 850GB to 550GB, dropped an unused 84GB table, reduced a table from 62GB to 5GB by deleting expired data, and rebuilt a table from 42GB to 2GB to improve block density.

1. The
biggest
loser
database
Paul
Guerin
Sydney
Conven1on
Centre
August
17
2011
The most comprehensive Oracle applications & technology content under one roof

2. Capacity
right-­‐sizing
to
achieve
business
outcomes.
THE
WEIGH
IN…….
The most comprehensive Oracle applications & technology content under one roof

3.
Size
=
850
GB
Total
loss
=
850
*
8
*
$38.50
$1/4m
over
2
years
=
$261,800
(over
2
years)
Size
2
years
later
=
550GB
=
180GB
+
2
years
of
growth
$$$
=
GB
*
num_en11es
*
$/GB
Star1ng
size
3
years
ago
=
730GB
0
200
400
600
800
1000
1200
1400
1600
1800
10/09/2007
24/09/2007
8/10/2007
22/10/2007
5/11/2007
19/11/2007
3/12/2007
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/2008
21/04/2008
5/05/2008
19/05/2008
2/06/2008
16/06/2008
30/06/2008
14/07/2008
28/07/2008
11/08/2008
25/08/2008
8/09/2008
22/09/2008
6/10/2008
20/10/2008
3/11/2008
17/11/2008
1/12/2008
15/12/2008
29/12/2008
12/01/2009
26/01/2009
9/02/2009
23/02/2009
9/03/2009
23/03/2009
6/04/2009
20/04/2009
4/05/2009
18/05/2009
1/06/2009
15/06/2009
29/06/2009
13/07/2009
27/07/2009
10/08/2009
24/08/2009
7/09/2009
21/09/2009
5/10/2009
19/10/2009
2/11/2009
16/11/2009
30/11/2009
14/12/2009
28/12/2009
11/01/2010
25/01/2010
8/02/2010
22/02/2010
8/03/2010
22/03/2010
5/04/2010
19/04/2010
3/05/2010
17/05/2010
31/05/2010
14/06/2010
28/06/2010
12/07/2010
26/07/2010
9/08/2010
23/08/2010
6/09/2010
20/09/2010
4/10/2010
18/10/2010
1/11/2010
15/11/2010
29/11/2010
13/12/2010
27/12/2010
10/01/2011
24/01/2011
7/02/2011
21/02/2011
7/03/2011
21/03/2011
4/04/2011
The most comprehensive Oracle applications & technology content under one roof

4.
rate…
Growth
rate
Now
12
GB/month….
Growth
rate
was
29
GB/month.
Less
than
half
the
previous
growth
0
200
400
600
800
1000
1200
1400
1600
1800
10/09/2007
24/09/2007
8/10/2007
22/10/2007
5/11/2007
19/11/2007
3/12/2007
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/2008
21/04/2008
5/05/2008
19/05/2008
2/06/2008
16/06/2008
30/06/2008
14/07/2008
28/07/2008
11/08/2008
25/08/2008
8/09/2008
22/09/2008
6/10/2008
20/10/2008
3/11/2008
17/11/2008
1/12/2008
15/12/2008
29/12/2008
12/01/2009
26/01/2009
9/02/2009
23/02/2009
9/03/2009
23/03/2009
6/04/2009
20/04/2009
4/05/2009
18/05/2009
1/06/2009
15/06/2009
29/06/2009
13/07/2009
27/07/2009
10/08/2009
24/08/2009
7/09/2009
21/09/2009
5/10/2009
19/10/2009
2/11/2009
16/11/2009
30/11/2009
14/12/2009
28/12/2009
11/01/2010
25/01/2010
8/02/2010
22/02/2010
8/03/2010
22/03/2010
5/04/2010
19/04/2010
3/05/2010
17/05/2010
31/05/2010
14/06/2010
28/06/2010
12/07/2010
26/07/2010
9/08/2010
23/08/2010
6/09/2010
20/09/2010
4/10/2010
18/10/2010
1/11/2010
15/11/2010
29/11/2010
13/12/2010
27/12/2010
10/01/2011
24/01/2011
7/02/2011
21/02/2011
7/03/2011
21/03/2011
4/04/2011
The most comprehensive Oracle applications & technology content under one roof

5. TABLE
WASTE
The most comprehensive Oracle applications & technology content under one roof

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
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.
The most comprehensive Oracle applications & technology content under one roof

7.
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.
The most comprehensive Oracle applications & technology content under one roof

8. 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.
The most comprehensive Oracle applications & technology content under one roof

9. 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).
The most comprehensive Oracle applications & technology content under one roof

10. INDEX
WASTE
The most comprehensive Oracle applications & technology content under one roof

11. 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.
The most comprehensive Oracle applications & technology content under one roof

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
The most comprehensive Oracle applications & technology content under one roof

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
Opportuni1es
–
change
the
operator
to
use
the
index,
or
drop
the
index
not
being
used.
The most comprehensive Oracle applications & technology content under one roof

14. 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
The most comprehensive Oracle applications & technology content under one roof

15. 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
The most comprehensive Oracle applications & technology content under one roof

16. 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.
The most comprehensive Oracle applications & technology content under one roof

17. NDX$PK(A,
B)
/*
primary
key
on
this
index
*/
NDX1(A,
B,
C)
/*
can
relocate
PK
to
this
index
*/
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.
The most comprehensive Oracle applications & technology content under one roof

18. NDX$PK(A,
B)
/*
primary
key
on
this
index
*/
NDX1(A,
B,
C)
/*
can
relocate
PK
to
this
index
*/
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.
The most comprehensive Oracle applications & technology content under one roof

19. 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>;
The most comprehensive Oracle applications & technology content under one roof

20.
Compressed
B-­‐tree
examples
FCASTDTL$FCASTID_DATETIME
-- 4.8GB compressed to 2.9GB
FCASTDTL$FCASTID_REVISION
-- 3.5GB compressed to 1.9GB
The most comprehensive Oracle applications & technology content under one roof

21. 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.
The most comprehensive Oracle applications & technology content under one roof

22. 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;
The most comprehensive Oracle applications & technology content under one roof

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

24. The
biggest
loser
database
eval.insync11.com.au
The most comprehensive Oracle applications & technology content under one roof