Partitioning WWWH

What, When, Why & How

Arup Nanda
arup.blogspot.com

Who am I
Oracle DBA for 14
years and counting
z Speak at
conferences, write
articles, 4 books
z Brought up the Global
Database Group at
Starwood Hotels, in
White Plains, NY
z

Partitioning What, When, Why and How by Arup Nanda

About this Session

z

This is not an introduction to partitioning

z Will

not cover syntax

What type of partitioning

z When to use partitioning
z Why partition something
z How to use partitioning to overcome
common challenges
z Caveats and traps to watch out for
z A complete case study to show how
decisions are made
z

Partitioning What, When, Why and How by Arup Nanda

Index Blocks Too Hot to Handle

Consider an index on
RES_ID, or CK_ID a
monotonically increasing
number
z It may make a handful of
leaf blocks experience
severe contention
z This hot area shifts as the
access patterns change
z

Partitioning What, When, Why and How by Arup Nanda

10
9

11
12
13
14

Hash Partitioned Index

z

Index Can be hash-partitioned, regardless of the

partitioning status of the table
create index IN_RES_01 on RES (RES_ID) global
partition by hash (RES_ID)
partitions 8

z
z
z

Table RES is un-partitioned; while index is partitioned.

This creates multiple segments for the same index,
forcing index blocks to be spread on many branches
Can be rebuilt:
alter index IN_RES_01 rebuild partition <PartName>;

Can be moved, renamed, etc.

Partitioning What, When, Why and How by Arup Nanda

When
z

Overlap between Logical Modeling and Physical

Design
Logical

z
z

Physical

Last part of logical design and first part of

physical design
When should partitioning be used
z

Partition
Design

In almost all the time for large tables

There is no advantage in partitioning small

tables, right?
z

Wrong. In some cases small tables benefit too

Partitioning What, When, Why and How by Arup Nanda

Why? Common Reasons

z

Easier Administration:
z Smaller

chunks are more manageable

z Rebuilding indexes partition-by-partition
z Data updates, does not need counters
z

Performance:
z full

table scans are actually partition scans

z Partitions can be joined to other partitions
z Latching

Partitioning What, When, Why and How by Arup Nanda

More Important Causes

z

Data Purging
z DELETEs

are expensive REDO and UNDO

z Partition drops are practically free
z Local indexes need not be rebuilt
z

Archival
z Usual

approach: insert into archival table

select * from main table
z Partition exchange
z Local indexes need not be rebuilt

Partitioning What, When, Why and How by Arup Nanda

Materialized Views Refreshes

z

Partition Exchange
z Create

a temp table
z Create Indexes, etc.
Temp
z When done, issue:
Table
alter table T1 exchange
partition sp11 with
table tmp1;
z Data in TMP1 is available

sp11

sp12 sp13
partition p1

sp21

sp22
partition p2

sp31

sp32 sp33
partition p3

sp41
partition p4
Table
Partitioning What, When, Why and How by Arup Nanda

Backup Efficiency
z

When a tablespace is read-only, it does

not change and needs only one backup
z RMAN

can skip it in backup

z Very useful in DW databases
z Reduces CPU cycles and disk space
z

A tablespace can be read only when all

partitions in them can be so

SQL> alter tablespace Y08M09 read only;

Partitioning What, When, Why and How by Arup Nanda

10

Data Transfer
z

Traditional Approach
insert into target select *
from source@dblink

Transportable Tablespace

Partitioning What, When, Why and How by Arup Nanda

Source

Target

TST
TS1

it read only
z Copy the file
z "Plug in" the file as a new
tablespace into the target
database
z Can also be cross-platform

TST
TS1

z Make

11

Information Lifecycle Management

z

When data is accessed less frequently,

that can be moved to a slower and
cheaper storage, e.g. from DMX to
SATA
Two options:
1. Create a tablespace ARC_TS on
cheaper disks
ALTER TABLE TableName MOVE
PARTITION Y07M08
TABLESPACE ARC_TS;

Fast
Disk

Slow
Disk

TS1

ARC_TS

Reads will be allowed; but not writes

2.

ASM Approach

ALTER DISKGROUP DROP DISK

ADD DISK
Fully available

Partitioning What, When, Why and How by Arup Nanda

12

How to Decide
z
z

First, decide on the objectives of partitioning.

Multiple objectives possible
Objectives
z
z
z
z
z
z
z

Data Purging
Data Archival
Performance
Improving Backups
Data Movement
Ease of Administration
Different Type of Storage

Assign priorities
to each of these
objectives

Partitioning What, When, Why and How by Arup Nanda

13

Global-vs-Local Index
z
z

Whenever possible, use local index

In Primary Key (or Unique) Indexes:
z
z

If not, try to include the column in PKs

z

If part column is a part of the PK local is possible

and should be used
e.g. RES table. PK (RES_DT, RES_ID) and part
key is (RES_DT)
E.g. if RES_ID was the PK of RES, can you make it
(RES_DT, RES_ID)?

Ask some hard design questions

z

Do you really need a PK constraint in the DW?

Partitioning What, When, Why and How by Arup Nanda

14

Case Study
Large Hotel Company
z Fictitious; any resemblance to real or
fictional entities is purely coincidental
z

Partitioning What, When, Why and How by Arup Nanda

15

Background
Hotel reservations made for future dates
z When guests check out, the CHECKOUTS
table is populated
z RESERVATIONS has RES_DT
z

z Is

always in future (up to three years)

CHECKOUTS has CK_DT

z Is

always present or past.

Partitioning What, When, Why and How by Arup Nanda

16

Thought Process
Q: How will the tables be purged?
z A: Reservations are deleted 3 months after they
z

are past. They are not deleted when cancelled.

z Checkouts are deleted after 18 months.
z

Decision:
z Since

the deletion strategy is based on time,

Range Partitioning is the choice with one
partition per month.

Partitioning What, When, Why and How by Arup Nanda

17

Column
Since deletion is based on RES_DT and
CK_DT, those columns were chosen as
partitioning key for the respective tables
z Scripts:
z

create table reservations ()

partition by range (res_dt) (
partition Y08M02 values less than
(to_date('2008-03-01','yyyy-mm-dd')),
partition PMAX values less than
(MAXVALUE)
)
Partitioning What, When, Why and How by Arup Nanda

18

Access Patterns
z

Q: Will checkouts within last 18 months be

uniformly accessed?
z A:

No. Data <= 3 months is heavily accessed.

4-9 months is light; 9+ is rarely accessed.

Decision:
z Use

Information Lifecycle Management to

save storage cost.

Partitioning What, When, Why and How by Arup Nanda

19

Access Types
z

Q: Is it possible that data in past months

can change?
z A:

Yes, within 3 months to make adjustments.

Q: How likely that it will change?

z A:

Infrequent; but it does happen. 3+ months:

very rare.

Q: How about Reservations?

z A:

They can change any time for the future.

Decision: Make partitions read only.

Partitioning What, When, Why and How by Arup Nanda

20

Partitioning 1st Pass

RESERVATIONS
RES_ID
UPD_DT
Part RES_DT
GST_IDFK

CHECKOUTS
CK_ID
Part CK_DT
UPD_DT
FOLIO_ID FK

GUESTS
FOLIOS
GST_ID
GST_NAME

FOLIO_ID
Part FOLIO_DT
RES_ID

TRANSACTIONS
FOLIO_ID
TRAN_ID
Part TRANS_DT

No FOLIO_DT column
Partitioning What, When, Why and How by Arup Nanda

21

Column Add for Partitioning

RESERVATIONS
RES_ID
UPD_DT
Part RES_DT
GST_IDFK

CHECKOUTS
CK_ID
Part CK_DT
UPD_DT
FOLIO_ID FK

GUESTS
FOLIOS
GST_ID
GST_NAME

FOLIO_ID
Part FOLIO_DT
RES_ID

TRANSACTIONS
FOLIO_ID
TRAN_ID
TRANS_DT
Part FOLIO_DT

FOLIO_DT column
added
Partitioning was
What, When,
Why and How by Arup Nanda

22

Problem
Purge on CHECKOUTS, FOLIOS and
TRANSACTIONS is based on CK_DT, not
FOLIO_DT
z FOLIO_DT is the date of creation of the
record; CK_DT is updated date
z The difference could be months; so,
purging can't be done on FOLIO_DT
z Solution: Partitioning Key = CK_DT
z Add CK_DT to other tables
z

Partitioning What, When, Why and How by Arup Nanda

23

2nd Pass
RESERVATIONS
RES_ID
UPD_DT
Part RES_DT
GST_IDFK

CHECKOUTS
CK_ID
Part CK_DT
UPD_DT
FOLIO_ID FK

CK_DT column
was added

GUESTS
FOLIO
GST_ID
GST_NAME

FOLIO_ID
FOLIO_DT
RES_ID FK
Part CK_DT

TRANSACTIONS
FOLIO_ID FK
TRAN_ID
TRANS_DT
Part CK_DT

Partitioning What, When, Why and How by Arup Nanda

24

Problems after 2nd Pass

z

#1 FOLIOS records created at Check-in

z CK_DT

is updated at Check-out; the record

may move to a different partition
z Decision = Acceptable
z

#2 CK_DT will not be known at Check-in;

so value will be NULL. Which partition?
z Decision

= not NULL; set to tentative date

z against Relational Database Puritan Design

Partitioning What, When, Why and How by Arup Nanda

25

Problems, cont..
z

#3: TRANS table may have many rows;

updating CK_DT may impact negatively
z Decision:

Remove CK_DT from TRANS

z Partition on TRANS_DT
z Fact: TRANS_DT <= CK_DT
z So, when partition SEP08 of CHECKOUTS is
dropped, SEP08 partition of TRANSACTIONS
can be dropped too
z Just because part columns are different,
purge does not have to different.
Partitioning What, When, Why and How by Arup Nanda

26

3rd Pass
RESERVATIONS
RES_ID
UPD_DT
Part RES_DT
GST_IDFK

CHECKOUTS
CK_ID
CK_DT
UPD_DT
FOLIO_ID FK
Part CK_DT

GUESTS
FOLIO
GST_ID
GST_NAME

FOLIO_ID
FOLIO_DT
RES_ID FK
Part CK_DT

TRANSACTIONS
FOLIO_ID FK
TRAN_ID
Part TRANS_DT

Partitioning What, When, Why and How by Arup Nanda

CK_DT column
was removed 27

Scenario #1
z

Reservation made on Aug 31st for Sep 30th

checking out tentatively on Oct 1st
z Records

Created:

Table
Part Key UPD_DT Partition
RESERVATIONS 09/30
08/31 SEP08
z Guest
FOLIOS

checks in on 9/30
10/01

z Checks out on Oct

CHECKOUTS
10/02
TRANSACTIONS 10/02

09/30

OCT08

2nd:
10/02
10/02

OCT08
OCT08

Partitioning What, When, Why and How by Arup Nanda

28

CK_DT in RES?
z

New Thought:
z Why

not partition RESERVATIONS table by

CK_DT as well?

CK_DT column not present in RES

z But

can be calculated; since we know the

number of days of stay.

Tentative Checkout Date column added

Partitioning What, When, Why and How by Arup Nanda

29

4th Pass

CK_DT
column
added

RESERVATIONS
CHECKOUTS
RES_ID
UPD_DT
PartCK_DT
RES_DT
GST_IDFK

CK_ID
CK_DT
UPD_DT
FOLIO_ID FK
Part CK_DT

GUESTS
FOLIO
GST_ID
GST_NAME

FOLIO_ID
FOLIO_DT
RES_ID FK
Part CK_DT

TRANSACTIONS
FOLIO_ID FK
TRAN_ID
Part TRANS_DT

Partitioning What, When, Why and How by Arup Nanda

30

Scenario #1 Modified
z

Reservation made on Aug 31st for Sep 30th

checking out tentatively on Oct 1st
z Records

Created:

Table
Part Key UPD_DT Partition
RESERVATIONS 10/01
08/31 OCT08
New record
z Guest
FOLIOS

checks in on 9/30
10/01

z Checks out on Oct

CHECKOUTS
10/02
TRANSACTIONS 10/02
RESERVATIONS 10/02

09/30

OCT08

2nd:
10/02
10/02
10/02

OCT08
OCT08
OCT08

Partitioning What, When, Why and How by Arup Nanda

New record
New record
Update

31

Scenario #2
z

Guest checks out on Nov 1st, instead of Oct 1st:

z Records

Created:

Table
Part Key UPD_DT Partition
RESERVATIONS 10/01
08/31 OCT08
New record
z Guest
FOLIOS

checks in on 9/30
10/01

z Checks out on Nov

CHECKOUTS
11/01
TRANSACTIONS 11/01
RESERVATIONS 11/01
FOLIOS
11/01

09/30

OCT08

New record

1st:
11/01
11/01
11/01
11/01

NOV08
NOV08
NOV08
NOV08

Partitioning What, When, Why and How by Arup Nanda

New record
Row Migration
Row Migration
32

New Column for Partitioning

Added a column CK_DT
z Two Options for Populating:
z

z Apps

populate it (possible since this is still in

design)
z Apps

will have to change

z Guaranteed logic
z Triggers

populate (retrofitting partitioning after

the apps are written)
z No

change to apps
z No guarantee of logic

Partitioning What, When, Why and How by Arup Nanda

33

11g Reference Partitions

No need to have a create table trans (
trans_id number not null,
new column
folio_id number not null,
trans_date date not null,
z Partitions are
amt
number,
defined on Foreign
constraint fk_trans_01
Keys, which follow
foreign key (folio_id)
references folios
the parent's
)
partitioning scheme. partition by reference
(fk_trans_01);
z One of the most
useful innovations in
11g
z

Partitioning What, When, Why and How by Arup Nanda

34

Non-Range Cases
z

GUESTS table is unique:

z 500

million+ records
z No purge requirement
z No logical grouping of data. GUEST_ID is just
a meaningless number
z All dependent tables are accessed
concurrently, e.g. GUESTS and ADDRESSES
are joined by GUEST_ID
z

No meaningful range partitions possible

Partitioning What, When, Why and How by Arup Nanda

35

Hash Partitions
GUESTS table is hash partitioned on
GUEST_ID
z Number of Parts: in such a way that each
partition holds 2 million records
z Number of partitions must be a power of 2.
So 256 was chosen.
z All dependent tables like ADDRESSES
were also partitioned by hash (guest_id)
z

Partitioning What, When, Why and How by Arup Nanda

36

Hotels Tables
HOTELS table holds the names of the
hotels
z Several dependent tables exist
DESCRIPTIONS, AMENITIES, etc. all
joined to HOTELS by HOTEL_ID
z Partitioning by LIST?
z

Partitioning What, When, Why and How by Arup Nanda

37

Hotels Table Partitioning

z

Requirements:
z Very

small
z No regular purging needs
z Mostly static; akin to reference data
z Can't be read only; since programs update
them regularly.
z

Decision: No partitioning

Partitioning What, When, Why and How by Arup Nanda

38

Tablespace Decisions
z

Partitions of a table can go to

z Individual

tablespaces
z The same tablespace
z

How do you decide?

many tablespaces too many datafiles
longer checkpoints

z Too

Partitioning What, When, Why and How by Arup Nanda

39

Individual Tablespaces
Tablespaces named in line with partitions,
e.g. RES0809 holds partition Y08M09 of
RESERVATION table.
z Easy to make the tablespace READ ONLY
z Easy to backup backup only once
z Easy to ILM
z

Move datafiles to lower cost disks

ALTER DATABASE DATAFILE
'/high_cost/' RENAME TO
'/low_cost/';
Partitioning What, When, Why and How by Arup Nanda

40

Combined Solution
z

Create a tablespace for each period

z TS0809

for Sep '08

Contains partitions Y08M09 for all tables

RESERVATIONS, CHECKOUTS,
z Partitions of the same period for all the
tables are usually marked read only
z

z If

not possible, then this approach fails

Partitioning What, When, Why and How by Arup Nanda

41

Final Design
nt
rre th
Cu on
M

F2.dbf
F1.dbf

Tablespace TS0807
Y08M07
Y08M08
Y08M09
RESERVATIONS

Y08M07
Tablespace TS0808
Y08M08

Y08M07
Y08M08

Y08M09

Y08M09

CHECKOUTS

TRANSACTIONS

F1.dbf
F3.dbf
F4.dbf

F1.dbf
F5.dbf
F6.dbf

Partitioning What, When, Why and How by Arup Nanda

42

Backup
backed up
only once

READ
ONLY

F2.dbf
F1.dbf

Tablespace TS0807
Y08M07
Y08M08
Y08M09
nt
e
RESERVATIONS
rr th
u
C on
M

Y08M07
Tablespace TS0808
Y08M08

Y08M07
Y08M08

Y08M09

Y08M09

CHECKOUTS

TRANSACTIONS

F1.dbf
F3.dbf
F4.dbf

F1.dbf
F5.dbf
F6.dbf

Partitioning What, When, Why and How by Arup Nanda

43

ILM
slowest
medium
F2.dbf
F1.dbf

Tablespace TS0807
Y08M07
Y08M08
Y08M09
nt
e
RESERVATIONS
rr t h
u
C on
M

Y08M07
Tablespace TS0808
Y08M08

Y08M07
Y08M08

Y08M09

Y08M09

CHECKOUTS

TRANSACTIONS
fastest

Partitioning What, When, Why and How by Arup Nanda

F1.dbf
F3.dbf
F4.dbf

F1.dbf
F5.dbf
F6.dbf
44

Partitioning Tips
List the objectives of partitioning, in the
order of priority
z Try to make the same partitioning for all
related tables
z Try to introduce new columns
z Avoid Global Indexes
z

Partitioning What, When, Why and How by Arup Nanda

45

Tips for Choosing Part Key

Changeable columns do not automatically
mean they are not good for part key
z If partition ranges are wide enough, row
movement is less likely
z Row movement may not be that terrible,
compared to the benefits
z

Partitioning What, When, Why and How by Arup Nanda

46

blog: arup.blogspot.com
Partitioning What, When, Why and How by Arup Nanda

47