An Oracle White Paper

February 2009

Document version 1.0

Oracle Partitioning for SAP

 Oracle White Paper—Oracle Partitioning for SAP

Preface................................................................................................ 1
Requirements...................................................................................... 1
Partitions – SAP-related notes ............................................................ 2
Partitions – What do you have to change on the ABAP side? ............ 2
Partitions – When does it make sense to partition your data? ............ 3
Partitions – Types ............................................................................... 4
Partitions – Leading zero issue with SAP ........................................... 6
Partitions – How to ensure valid ranges.............................................. 6
Partitions – Cost-based optimizer ....................................................... 8
Partitions - Indexes ............................................................................. 9
Partitions – Merge and split operations ............................................. 10
Partitions – Advantages for you ........................................................ 11
Partitions – Roadmap........................................................................ 11
 Oracle White Paper—Oracle Partitioning for SAP

Preface
This paper provides
an overview of Oracle
This document explains how Oracle partitions are used in the SAP environment.
partitions in the SAP Partitions have been available and used outside the SAP environment for a long time.
environment SAP began using partitions for their data warehouse solutions starting with BI 2.0. In
“standard” NetWeaver configurations, partitions are only used for certain customer sites.

Requirements
To use Oracle partitions, you need to have the “Oracle Partition Option” licensed. During
the standard SAP/Oracle installation process, the Partitioning option is always installed
(see also OSS note #859841 – Uninstall of Oracle Partitioning software option).

As mentioned above, SAP BW/BI has been using Partitions for many years. With
“standard” SAP, partitions can be used as of 4.6C – service pack 48. From this version
on, the SAP data dictionary is able to handle partitioned tables. If using older releases,
you were able to set up partitioned tables on the database side, but if you wanted to
apply changes to such a table, the partitioning setup might have been erased.

1
 Oracle White Paper—Oracle Partitioning for SAP

Partitions – basic idea

In the SAP/Oracle environment large or very large databases are common. But compared with a
typical large database (e.g. video, pictures, climatic, ...), SAP databases are also used for mission-
critical (OLTP) applications. Additional concepts are needed for these large or very large
databases to ensure performance, scalability and advanced administration.
Partitions allow us to break down the relation between a segment and a tablespace from 1:1, 1:n,
n:1 or n:n . With partitions, a segment can have many “sub-segments” (=partitions) and these
“sub-segments” can be distributed across various tablespaces. These “sub-segments” can also be
processed individually in many areas (e.g. shrink, reorganization, drop, ...).

Partitions – SAP-related notes

Additional information about Oracle Partitioning and SAP can be found in the following notes:
#742243 - General table partitioning as of SAP_BASIS 46C
#105047 - Support for Oracle functions in the SAP environment (#34)
#722188 - FAQ: Oracle Partitioning

Partitions – What do you have to change on the ABAP side?

Partitions are transparent to the application layer. Everything is handled on the database side.
Therefore, if you decide to partition a table, you don’t need to change your ABAP programs
in any way.

2
 Oracle White Paper—Oracle Partitioning for SAP

Partitions – When does it make sense to partition your data?

The answer to this question is “it depends”. Below you will find a few examples of cases where
setting up partitions would make a lot of sense, for very different reasons.

First example:

A manufacturing customer with independent plants and independent products in each plant. It is
therefore possible that each plant has its own special reports. For internal cost reasons each plant
is charged internally for the amount of space used.

Solution:

Partition the related data on a plant basis and separate it into different tablespaces (SAP column
“werks”). This can be done using “LIST partitioning”.

Second example: SAP IS-U customers:

IS-U customers typically have exceptionally large tables (DFKKxx, DBERCHZ1). Such tables
are becoming highly critical for handling as well as for performance reasons. It is usually the case
that only the last few weeks/months contain critical data.

Solution:

Partition based on ranges (e.g. FKKBELEG) and each range has approx. one million rows
(=same amount of data in each partition).

3
 Oracle White Paper—Oracle Partitioning for SAP

Third example:

Retail customers typically have such a high throughput within their SD tables, that permanent
archiving is carried out. This deletes data and the empty space produced is reused very quickly.
Typically not all data is archived so some data remains in the table blocks. This may result in a
drop in SGA efficiency.

Solution:

Partition based on ranges (e.g. VBELN). Because SAP typically increments such ranges (NRIV),
a new SD document will always be assigned a higher number. If archiving now takes place,
“OLD” data (blocks) will not be affected and new data will only be placed in the new partitions. In
addition, if archiving is undertaken, the now empty (or almost empty) “old” partitions can be
merged and the space will be returned to the tablespace

Partitions – Types
Oracle supports different types of partitions, including sub-partitions. SAP does not support sub-
partitions; all “simple” partitions are supported

Range partitions:

As the name suggests, range partitions cover ranges. These ranges are typically
ranges of numbers. Example:

create table test_part

(t1 number, t2 varchar2(10))

partition by range (t1)

(partition p_1 values less than (4000) tablespace psappart1,

partition p_2 values less than (8000) tablespace psappart2,

partition p_3 values less than (20000) tablespace psappart3);

4
 Oracle White Paper—Oracle Partitioning for SAP

List partitions:

create table test_part_list

( mandt varchar2(3), bukrs varchar2(4),

belnr varchar2(10), gjahr varchar2(4),

text varchar2(100))

partition by list (gjahr)

(Partition test_part1 values ('2001','2002') tablespace psappart1,

Partition test_part2 values ('2003','2004') tablespace psappart1,

Partition test_part3 values ('2005‘,’2006’) tablespace psappart1,

Partition test_part4 values ('2007') tablespace psappart2,

Partition test_part5 values ('2008') tablespace psappart2);

Hash partitions:

create table test_part_hash

( mandt varchar2(3), bukrs varchar2(4),

belnr varchar2(10), gjahr varchar2(4),

text varchar2(100))

partition by HASH (belnr)

partitions 4

store in (psappart1, psappart2)

5
 Oracle White Paper—Oracle Partitioning for SAP

Partitions – Leading zero issue with SAP

In the SAP environment, you must remember that internally SAP uses character fields with
leading “zero” values as number fields. Therefore, if you plan to set up range partitions in such
fields (virtually all NRIV ranges), your partition setup must reflect this.

Example for an IS-U table (DFKKOP):

...

PARTITION BY RANGE

("OPBEL")

PARTITION "DFKKOP_P01_00001" VALUES LESS THAN ('010000100000'),

PARTITION "DFKKOP_P01_00002" VALUES LESS THAN ('010000200000'),

PARTITION "DFKKOP_P01_00003" VALUES LESS THAN ('010000300000'),

PARTITION "DFKKOP_P01_00004" VALUES LESS THAN ('010000400000'),

PARTITION "DFKKOP_P01_00005" VALUES LESS THAN ('010000500000'),

...

Partitions – How to ensure valid ranges

Often development teams do not work closely with the administration team. In such cases (e.g.
when a new plant is being set up), values that you have not listed in your partition definition
might be inserted. If this happens, an error will be displayed:
ORA-14400: inserted partition key does not map to any partition
Note: This error is not caused by the database. This error will be displayed if the partition setup
is not correct. Such errors result in major problems for a mission-critical system like SAP.
Therefore, you need to ensure that every partition setup has a “safety net”. To ensure that no
issues with “out of range” values occur, you should always create a “left-over” partition.

6
 Oracle White Paper—Oracle Partitioning for SAP

Examples:

Range partitions:

create table test_part

(t1 number, t2 varchar2(10))

partition by range (t1)

(partition p_1 values less than (4000) tablespace psappart1,

partition p_2 values less than (8000) tablespace psappart2,

partition p_max values less than (MAXVALUE));

List partitions:

create table test_part_list

( mandt varchar2(3), bukrs varchar2(4),

belnr varchar2(10), gjahr varchar2(4),

text varchar2(100))

partition by list (gjahr)

(Partition test_part1 values ('2001','2002') tablespace psappart1,

Partition test_part2 values ('2003','2004') tablespace psappart2,

Partition test_part3 values ('2005’,’2006’) tablespace psappar2,

Partition test_part4 values ('2007') tablespace psappart3,

Partition test_part5 values ('2008') tablespace psappart4,

Partition test_part_rest values (DEFAULT));

7
 Oracle White Paper—Oracle Partitioning for SAP

Partitions – Cost-based optimizer

One of the key features of partitions is related to the CBO and is called “partition pruning”. With
“partition pruning”, the optimizer is aware (even with bound variables) that a partitioned table is
being accessed. Only the partitions needed are accessed during run time .

Example:
SQL> explain plan for select * from test_part where t1 = :a0
Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
----------------------------------------------------------
| Id | Operation | Name |
----------------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | PARTITION RANGE SINGLE | |
| 2 | TABLE ACCESS BY LOCAL INDEX ROWID| TEST_PART |
|* 3 | INDEX RANGE SCAN | I_TEST_PART |
----------------------------------------------------------

SQL> explain plan for select * from test_part_list where gjahr='2004';

Explained.

SQL> select * from table(dbms_xplan.display);

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------
| Id | Operation | Name | Rows| Pstart| Pstop |
---------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | |
| 1 | PARTITION LIST SINGLE| | 1 | KEY | KEY |
|* 2 | TABLE ACCESS FULL | TEST_PART_LIST | 1 | 2 | 2 |
----------------------------------------------------------------------

Instead of a “real” full table scan, only the second partition (see example above) is used.

8
 Oracle White Paper—Oracle Partitioning for SAP

Partitions - Indexes
The topics discussed so far relate to tables, but what about indexes? Can or should we partition
indexes too?
In most cases, your partition key for range partitions will be one of the columns of the primary
key and we would therefore recommend partitioning the index in the same way. But can we use
setup partitioning for secondary columns such as a sales region while the table is partitioned based
on a different column, e.g. VBELN.
An index which follows table partitioning is called a “local index”. Here we distinguish between a
“prefixed” (first column of the index is the partition key) and a “non-prefixed” (partition key is
part of the primary key) index.
create index i_test_part

on test_part (t1)

local

(partition i_p1 tablespace psapindpart1,

partition i_p2 tablespace psapindpart2,

partition i_p3) tablespace psapindpart3;

But, as mentioned above, you can also create partitioned indexes based on columns
which are not part of the partition key for the table. Such indexes are called
“global partitioned indexes”.
These indexes are typically created for performance reasons (special reports). They can also be
processed using parallel query if un-partitioned indexes could not be processed in parallel (for
range scans).

Please note:

If you define “global indexes”, these indexes need to be maintained if you perform specific
operations for your table (create a new partition, drop a partition, merge/split partitions, …).
If your global indexes are not updated during these operations, they will become unusable.
Since 10g, the CBO does not take into account “unusable” indexes (parameter
skip_unusable_indexes = true), but performance problems may occur until you rebuild indexes
which are in a usable state (“update indexes” clause). In addition, as of 10g you can also specify
the “update indexes” clause for partition maintenance commands and this will also update your
global indexes.

9
 Oracle White Paper—Oracle Partitioning for SAP

Partitions – Merge and split operations

To optimize partition administration, Oracle also permits the merging and splitting of partitions.
This gives you unique opportunities for optimizing space. For example, after archiving
operations you can just merge the empty or almost empty partitions and the space will be
returned to the tablespace. As of 10g, with the “update indexes” clause, you can also ensure that
secondary indexes are not invalidated.
If your development has suddenly loaded much more data than you expected, you can also split
partitions.

Examples:

ALTER TABLE SAPR3."EDIDS" SPLIT PARTITION

EDIDS_P01_MAX AT ('0000000466600001') INTO

(PARTITION EDIDS_P01_00031,

PARTITION EDIDS_P01_MAX)

UPDATE INDEXES PARALLEL 8;

ALTER TABLE "SAPR3"."EDIDS" MERGE PARTITIONS

"EDIDS_P01_00079","EDIDS_P01_00080"

INTO PARTITION "EDIDS_P01_00080"

UPDATE INDEXES PARALLEL 8

10
 Oracle White Paper—Oracle Partitioning for SAP

Partitions – Advantages for you

As usual with every new feature you will plan to implement, you have to ask: “how do I benefit
from using partitions compared with a non-partitioned environment?”
Advantages:
• Better use of the SGA
• Better reuse of Oracle blocks
• Better space usage in general
• Faster insert operations (depending on method used)
• Easy space management after e.g. SAP archiving
• Much smaller segment units
• Effective use of parallel query
• Less time needed for maintenance operations

Partitions – Roadmap
• Identification of possible partitioning candidates with a direct or indirect time dependency, a
good “LIST” candidate or just distribute your data (hash partitions) to prevent table/index hot
blocks
• Start with simple tables (only primary index)
• Do not forget the “left-over” partition
• Implement scripts for administrating partitions (spare partitions, split, merge, drop)
• Implement more complex tables with secondary indexes
• Do not forget to test your implementation

11
Oracle Partitioning for SAP
February 2009
Author: Juergen Kirschner
Contributing Authors: Stephan Buehne,
Hanno Bresch
Copyright © 2009, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and
the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
Oracle Corporation
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
World Headquarters
fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are
500 Oracle Parkway
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any
Redwood Shores, CA 94065
means, electronic or mechanical, for any purpose, without our prior written permission.
U.S.A.

Worldwide Inquiries: Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective
Phone: +1.650.506.7000 owners.
Fax: +1.650.506.7200
oracle.com 0209