Dr. Stephan Bühne · Number range table • Number range ... Advantages SAP range partitioning ... more • Database buffer cache is unloaded, because of well clustered data

Dr. Stephan BühneSenior Principal Technical

ConsultantSAP Solution Center Walldorf

Managing Large Databases:

Partitioning methods for SAP R/3

Contents

• Why to partition?• List partitioning• Hash Partitioning• Range partitioning• SAP integration with NRIV• Logical subpartitioning

DatabaseLarge DatabaseVery Large Database

Growing database

Database

Continuous Data flow

Database challenges

l Database growthl Continuous data flow (Data in/ data out) needs

archivingl Follow up actions: Table and/ or index

reorganisationsl Performance degradations as a result of data

growth and shotgun effect after archiving

„Shotgun“ effect in the tablespace

100,'ABCDE','...100,'ABCDE','...100,'AHJDE','...100,'TZWER','...100,'FDGDE','...100,'DFGGV','...100,'AGFHG,'...100,'ADFGS','...100,'ARETW','...100,'ATZUTR','...

Table rows to insert

# of blocks needed

Before archiving

After archiving

„Shotgun“ effect in the buffer cache

Before archiving

After archiving

Hitratio 100%

Hitratio 50%

Buffer Cache

Query IO dependencyRun Time

Buffer Cache File system

Break down database by building up partitions

Partition Partition Partition Partition Partition




Advantages Partitioning

l Better performance by reducing data set sizel PQ can be usedl Stabilize performancel Avoid or reduce reorganisationsl Easy to administerl Support SAP archiving

Contents

• Partitioning methods • List partitioning• Hash Partitioning• Range partitioning• SAP integration with NRIV• Logical subpartitioning

Customer specific partitioning = List Partitioning

Customer Customer Customer Customer Customer




Table partitions

100,20051129200,20051129100,20051129600,20051129600,20051129200,20051130200,20051130200,20051130600,20051130100,20051130100,20051201600,20051202200,20051203200,20051204600,20051205600,20051205100,20051206100,20051206600,20051207100,20051207100,20051208

Non-partitioned table100,20051129100,20051129100,20051129100,20051129100,20051129100,20051130

200,20051201200,20051202200,20051203200,20051204200,20051205

Partitioned Table

PartitionClient 100

600,20051201600,20051202600,20051203600,20051204600,20051205600,20051205600,20051206600,20051206

PartitionClient 200

PartitionClient 600

Properties of partitions

100,20051129100,20051129100,20051129100,20051129100,20051129100,20051130

200,20051201200,20051202200,20051203200,20051204200,20051205

600,20051201600,20051202600,20051203600,20051204600,20051205600,20051205600,20051206600,20051206

l Partitioning can be used within SAP R/3 l No change to application is neededl Table definition becomes a „Logical“ object

definitionl Data is stored in partitionsl Partitions are separate storage objectsl Partitions can be handled separatelyl Table reorganisations can be done on partition

levell Indexes will be equi-partitioned to the tablel Index partitions can be reorganised on

partition level

TableIndex

Data distribution within the databaseTable partitions Tablespaces Datafiles

100,20051129100,20051129100,20051129100,20051129100,20051129100,20051130

PSAP100

200,20051201200,20051202200,20051203200,20051204200,20051205

PSAP200

600,20051201600,20051202600,20051203600,20051204600,20051205600,20051205600,20051206600,20051206

PSAP600

Managing single partitions

100,20051129100,20051129100,20051129100,20051129100,20051129100,20051130

200,20051201200,20051202200,20051203200,20051204200,20051205

TablePartitionsClient 100

600,20051201600,20051202600,20051203600,20051204600,20051205600,20051205600,20051206600,20051206



Index 0 Index 1 Index 2

Index-Partitions Client 200



IndexClient 100 Index

Client 100Index

Client 100


Client 200Index

Client 200


Client 600Index

Client 600

Customer specific list partitioning

• Customer runs 30 different plants• Each plant is discrete from all others• Approx. 10 – 20 tables could be partitioned• For the tables in question no obvious range

partition key was found• Driving key for customer are always the plant

based distribution• So we decided to implement a list

partitioning based on the plants

SQL: Partition pruningSELECT * from sapl0p."/BSHM/FA_EVLG" WHERE"CLIENT" = :A0 AND "FABDATE" BETWEEN :A1 AND :A2 AND "ORDERTYPE" = :A3 AND "POSNUM" = :A4 AND "PLANT" = :A5 AND "MVTYPE" = :A6 AND "COMPR" = :A7 AND "INDICATORAD" = :A8 AND "INDICATORDEL" =:A9;

SELECT * FROM sapl0p."RESB" WHERE "MANDT" = :A0 AND "MATNR" = :A1 AND "WERKS" = :A2 AND "XLOEK" = :A3 AND "KZEAR" = :A4 AND "LGNUM" = :A5 AND "LGTYP" = :A6 AND "LGPLA" = :A7;

SELECT * FROM sapl0p."/BSHM/FA_EVLG" WHERE "CLIENT" = :A0 AND "DATECREATE" BETWEEN :A1 AND :A2 AND "PLANT" = :A3 AND "COMPR" IN ( :A4 , :A5, :A6 , :A7 , :A8 );

List partitioning by plant

100,5501,...100,5501,...100,5501,...100,5501,...100,5501,...100,5501,...

100,5502,...100,5502,...100,5502,...100,5502,...100,5502,...

Plant '5501'

100,5503,...100,5503,...100,5503,...100,5503,...100,5503,...100,5503,...100,5503,...100,5503,...

Plant '5502'

Plant '5503'

Index 0 Index 1 Index 2

All indexes are defined locally

Index Index Index

Index100,5502,... Index Index

Client 200

IndexPlant 5503

Index Index

TablePartitions

Performance results

Zeile 10 Zeile 11 Zeile 12 Zeile 13

00:00:00

00:00:43

00:01:26

00:02:10

00:02:53

00:03:36

00:04:19

00:05:02

00:05:46

Results List-Partitioning

Summary List Partitioning

l Useful for building up a customized partitioning for application specific needs

l Static partitioning, needs no ongoing administration (add/ delete partitions), but adaption for new introduced values is possible

l Can help to reduce downtime for reorganisations and to increase transparency

l Archiving can benefit from it, but tables are not reorganisation free

Contents


Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Application

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Random

Unspecific partitioning = Hash Partitioning

Partitioning by Hash

100,FDSKLJO100,POWIRSD100,VHGFAPO100,2123HHO100,FDSKLJO100,FDSKERT100,FDSKLJO100,JKSDFHD100,FDQLPO100,FDSKLGO100,KJDSHFI100KJSDFHJB100,FDSKLJO100,DSKJFSD100,MLKJEOI100,FDSKLGO100,RTSNCVI100,MCVBNV100,WERIONC100,KJSDFHO100,CVSDFED100,.........

Non-partitioned table100,FDSKLJO100,FDSKLJO100,FDSKLJO100KJSDFHJB100,FDSKLJO100,MCVBNV100,WERIONC

100,POWIRSD100,JKSDFHD100,FDQLPO100,FDSKLGO100,FDSKLGO100,RTSNCVI100,KJSDFHO

Partitioned Table

Hash Partition 1

100,VHGFAPO100,2123HHO100,FDSKERT100,DSKJFSD100,DSKJFSD100,MLKJEOI100,CVSDFED

Hash Partition 2

Hash Partition n

Summary Hash-Partitioning

l Can be used, if neither List nor Range partitioning is possible to reduce table contention

l Allows to use PQ-access on indexes (can increase performance)

l Can help to reduce downtime for reorganisations

l Do not create reorganisation free tables

Contents


Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

Time

SAP specific partitioning = Range Partitioning

Time Partitioning

200601

200602

200603

200604

200605

200606

200607

2006....

200806

200807

200808

200809

200810

200811

200812

200901

Archiving job deleting old data

Single partition access on recent data

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Index-partition

Table partitions

100,20051129100,20051129100,20051129100,20051129100,20051129100,20051130100,20051130100,20051130100,20051130100,20051130100,20051201100,20051202100,20051203100,20051204100,20051205100,20051205100,20051206100,20051206100,20051207100,20051207100,20051208

Non-partitioned table100,20051129100,20051129100,20051129100,20051129100,20051129100,20051130100,20051130100,20051130100,20051130100,20051130

100,20051201100,20051202100,20051203100,20051204100,20051205100,20051205100,20051206100,20051206100,20051207100,20051207100,20051208

Partitioned Table

November

December

Partitioning by Date

Number ranges in NRIV

Partitioning Keys

time...... 2005/02

2005/03

2005/04

2005/05

2005/06

2005/07

2005/08 ......

1.000.000

2.000.000

3000.000

4.000.000

Number range table• Number range table generates UNIQUE, INCREASING

numbers over time. • Each part of the application has its own number range object• Within one number range objects there can be multiple

entries• Entries can be year independent and year dependent• Table is client dependent• SAP transaction “SNRO” can be used to monitor the number

range table.

Number ranges in NRIV

Logical Sub-Partitioning challenges

• Each number range for a given number range object must be handled independently from all others in the same table

• It must be possible to add new partitions on demand dynamically to a number range, without invalidating table or index partitions

• It must be possible to remove old partitions from a number range, without invalidating table or index partitions

=> Logical sub-partitioning

Logical Sub-Partitioning

• Implementing partitioning starts with table analysis based on the defined NRIV entries for the number range object

• For each defined number range, a logical sub-partition range definition will be created

• Each logical sub-partition ends with a Max-Partition, defined with:

(High-Value + 1)

based on the „TONUMBER“ field of NRIV for this number range

• This Max-Partition is used to split new empty partitions for the underlying number range

• Uses the feature „FAST PARTITION SPLIT“ in Oracle

Logical Sub-Partitioning

Number Range 46

Number Range 55

Number Range 60

l P46_00001

l P46_00002

l P46_..........

l P46_MAX

l P55_00001

l P55_00002

l P55_..........

l P55_MAX

l P60_00001

l P60_00002

l P60_..........

l P60_MAX

<Tabelle>_MAXVALUE

Logical Subpartitioning: Table structure

l EKKO_P46_00001 values less than '100', '4600100000'


l EKKO_P46_MAX values less than '100', '4700000000'










l EKKO_MAXVALUE values less than 'MAXVALUE'

Performance results

1 2 3 4 5 6 7 8

00:00:00

01:12:00

02:24:00

03:36:00

04:48:00

06:00:00

07:12:00

Laufzeiten

03:15:15

00:49:28

Queries

Lauf

zeit

Advantages SAP range partitioning• No need to reorganize the Primary index or the table any

more• Database buffer cache is unloaded, because of well clustered

data• Faster archiving, because only smaller partitions must be

scanned and no effect on the index quality• No index reorganisations on local indexes, because delete

operations affect only non-productive partitions• Index and table will be reorganized automatically with the

partition administration• Single partitions can be reorganized instead of the whole

table

Contact: [email protected]

Documents

Dr. Stephan Bühne · Number range table • Number range ... Advantages SAP range partitioning ... more • Database buffer cache is unloaded, because of well clustered data