How to Troubleshoot Apps for the Modern Connected Worker
Databse & Technology 2 _ Paul Guerin _ The biggest looser database - a boot camp case study.pdf
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
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
