Using DB2 for Linux, Windows, and

UNIX Table Partitioning in SAP

Systems

Applies to:
SAP NetWeaver AS ABAP on IBM DB2 for Linux, UNIX, and Windows. For more information, visit the
Landscape Design and Architecture homepage.

Summary
Most database systems offer specific “data organization schemes” that can be used to influence the physical
representation of the table data on disk. DB2 for Linux, UNIX, and Windows offers three such schemes:
Database Partitioning (DPF), Multi-Dimensional Clustering (MDC) and – since DB2 9.1 – table partitioning.
This article explains how you can apply table partitioning for tables in an SAP system.

Author: Johannes Heinrich

Company: SAP AG
Created on: 2. November 2009

Author Bio
Johannes Heinrich works as a senior developer in the IBM DB2 for Linux, UNIX, and Windows development
team at SAP. He holds a degree in Computer Science from the University of Kaiserslautern, Germany and is
a IBM Certified DBA for DB2 9 on Linux, UNIX, and Windows.
He can be reached at johannes.heinrich@sap.com .

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 1
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Table of Contents
Introduction ................................................................................................................................................... 3
Table Partitioning with DB2 for Linux, UNIX, and Windows ............................................................................ 4
Table Partitioning Functionality .................................................................................................................. 4
Syntax Considerations ............................................................................................................................... 5
Catalog Views for Table Partitioning .......................................................................................................... 6
Use of Table Partitioning in SAP Systems ..................................................................................................... 7
Range-Partitioned Tables and the SAP Data Dictionary ............................................................................. 7
Creating Range-Partitioned Tables in the ABAP DDIC ............................................................................... 7
Table Partitioning Examples ...................................................................................................................... 9
Tablespace Considerations ..................................................................................................................... 12
Limitations ............................................................................................................................................... 13
Reverting to a Nonpartitioned Table ......................................................................................................... 13
Combining Table Partitioning with other Data Organization Schemes....................................................... 14
Other Ways for Creating Range-Partitioned Tables .................................................................................. 15
Related Content .......................................................................................................................................... 16
Appendix A: Report to fill the CUSTOMERS table with random data ............................................................ 17
Copyright .................................................................................................................................................... 19

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 2
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Introduction
Recent database systems use special techniques to improve the performance of SQL statements and
ensure scalability when working with (very) large databases. One of the ideas behind these techniques is it
to store the database data in a way so that a fast access even on large tables can be achieved. Storing the
data in such an optimized way becomes especially important in data warehouse environments like SAP
NetWeaver BW.
DB2 for Linux, UNIX, and Windows offers the following three data organization schemes to optimize data
access in large databases:
 The Database Partitioning Feature (DPF), aimed primarily at large data warehouse installations,
allows the partitioning of the database into multiple partitions. Table data is distributed to different
partitions based on a distribution key. Partitions can reside on the same server (shared everything),
utilizing the multi-processor capabilities of that server, or spawn different machines (shared nothing).
As DB2‟s optimizer is DPF-aware, the primary advantage of this setup is that the incoming workload
can be processed in parallel by all partitions, each working on their own set of data. This can speed
up the execution of SQL statements tremendously. DPF is often used with SAP NetWeaver BW.
 Multi-Dimensional Clustering (MDC) is a way of physically clustering table data. MDC uses blocks,
consisting of a consecutive set of disk pages, and block indexes for fast block access. The data is
organized along an ordered set of one or more columns, the so called dimensions. All records which
share the same dimension value are stored in at least one block. The primary advantage of MDC is
the improved performance of data warehouse-like queries along the dimensions. MDC is also often
used with SAP NetWeaver BW on DB2 for Linux, UNIX, and Windows.
 Table partitioning, also known as range partitioning, is a new feature of DB2 V9.1. Here, a (large)
table is split into (data) partitions (also known as ranges) based on a partitioning key. Every partition
constitutes an own storage object and can be detached from (roll-out) or attached to (roll-in) the table
with minimal effort. Again, query performance may improve because DB2 only scans partitions that
are relevant to the query (data partition elimination).
Currently, SAP applications do not use range-partitioned tables. This article discusses how tables of the SAP
database can be optionally partitioned after the SAP system installation. For more information about the
other data organization schemes (DPF and MDC), see the articles on the “SAP Business Intelligence with
IBM DB2 for LUW” page in the SAP Developer Network (SDN).

Note: The data organization schemes mentioned above can be combined.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 3
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Table Partitioning with DB2 for Linux, UNIX, and Windows

Table Partitioning Functionality

Probably the most interesting aspect of range-partitioned tables is that a single partition can be converted to
a table and a table can be added to a range-partitioned table. This becomes clearer if we look at the
operations that are allowed on range-partitioned tables:
 A partition can be detached (roll-out) from a range-partitioned table via the ALTER TABLE ...
DETACH PARTITION <partition-name> INTO <new-table> statement. Afterwards the detached
partition appears as a new table with table name <new-table>. No data movement and consequently
no logging is required for this operation.
 Likewise, an existing table can be attached (roll-in) to a range-partitioned table via ALTER TABLE ...
ATTACH PARTITION <partition-name> if it is compatible with the partitioned table (i.e. has the same
table definition). An ATTACH operation must be followed by an integrity check (via the SET
INTEGRITY statement) so that referential constraints can be checked and global indexes – if they
exists (more an global and local indexes later) - can be updated by the database manager.
 Finally, it is possible to add new empty partitions with the ALTER TABLE ... ADD PARTITION
<partition-name> statement. Afterwards, data can be loaded into this new partition.
Another feature of range-partitioned tables is the flexible assignment of tablespaces to the partitions. The
regular data and the large object data of each partition can be placed in a separate tablespace. This does
not only allow that a table grows beyond the maximum size limits of a tablespace, it makes it also possible to
perform operations like BACKUP and RESTORE on partition-level. To perform a REORG on a single
partition, the partition must be detached first and attached again after the REORG.
Another interesting aspect of partitioned tables is how the indexes are organized to deal with the partitions.
In DB2 V9.1 and DB2 V9.5 only global indexes (also known as nonpartitioned indexes) are possible: every
index on a partitioned table is a single storage object. This is by the way a difference to normal tables where
all indexes are placed in a single storage object. As a result, global indexes can be placed in different
tablespace. If global indexes are defined on a range-partitioned table, roll-in and roll-out operations require
an update of the global indexes. For a roll-out, this update is performed asynchronously (“asynchronous
index cleanup”), in case of a roll-in the SET INTEGRITY statement as mentioned above performs the
necessary actions.
DB2 9.7 offers local (also known as partitioned) indexes on range-partitioned tables. Here, the index is split
into index partitions according to the table partitions. As a result, roll-in and roll-out operations offer improved
performance because they do not need to perform index updates. Furthermore, partition elimination for
queries provides better results as the local indexes are smaller than a global index. With DB2 9.7 local
indexes are the default.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 4
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Syntax Considerations
Table partitions are defined in the partitioning-clause of the CREATE TABLE statement. Since the table
partitioning syntax is rather complex and has many options, we start with the following basic example.

CREATE TABLE sales(sale_date DATE, customer INT, …)

PARTITION BY RANGE(sale_date) (1)
(PART Q1 STARTING ‘1/1/2005’ ENDING ‘3/31/2005’ INCLUSIVE, (2)
PART Q2 STARTING ‘4/1/2005’ ENDING ‘6/30/2005, INCLUSIVE,
PART Q3 STARTING ‘7/1/2005’ ENDING ‘9/30/2005’ INCLUSIVE,
PART Q4 STARTING ‘10/1/2005’ ENDING ’12/31/2005’ INCLUSIVE)

The partitioning-clause starts in line (1) with the keywords PARTITIONG BY RANGE (RANGE is optional and
can be omitted). The following term in braces is the so called partition expression. In our example, the
partitioning of table sales is based on the values in the sales_date column.

Note: In most cases you might want to use a time-based column type like DATE, TYPE and TIMESTAMP as partition
expression. Table partitions are often organized along years, months, weeks or something similar.

Optionally you can specify after every column in the partition expression where records that contain an SQL
NULL value in this field are stored. NULLS LAST (this is the default) means that these records belong to the
last (highest) partition, NULLS FIRST means that they belong to the first (lowest) partition. A partition
expression can consist of up to 16 columns.
After the partition expression the single partitions must be specified. Following the PART (or PARTITION)
keyword you can specify a name for each partition. If you do not specify a name DB2 will generate a name
automatically (PART0, PART1, PART2 ...). Next you need to indicate the boundaries of every partition.
Assuming that the table above contains only data from the year 2005, the table is partitioned into the four
quarters of 2005. You can use the keywords INCLUSIVE and EXCLUSIVE to specify that the boundary
values should be included in or excluded from the respective data partition.
The second example (below) shows that the upper boundary of a partition (the ending-clause) can be left
out. In this case DB2 automatically calculates the upper partition boundary. Also, you can use the keywords
MINVALUE (see line (1)) and MAXVALUE to define open-ended partitions. In our example, all records in the
sales table that have a sale_date lower than 1/1/2005 are stored in the first partition.

CREATE TABLE sales(sale_date DATE, customer INT, …)

PARTITION BY RANGE(sale_date)
(STARTING MINVALUE, (1)
STARTING ‘1/1/2005’,
STARTING ‘4/1/2005’,
STARTING ‘7/1/2005’,
STARTING ‘10/1/2005’ ENDING ’12/31/2005’);

The example also shows that you can omit partition names.
The next example shows how you can map the partitions to different tablespaces.

CREATE TABLE sales(sale_date DATE, customer INT, …)

PARTITION BY RANGE(sale_date)
(STARTING ‘1/1/2005’ IN rpartd1 INDEX in rparti1 LONG IN rpartl1,
STARTING ‘4/1/2005’ IN rpartd2 INDEX in rparti2 LONG IN rpartl2,
STARTING ‘7/1/2005’ IN rpartd3 INDEX in rparti3 LONG IN rpartl3,
STARTING ‘10/1/2005’ ENDING ’12/31/2005’
IN rpartd4 INDEX in rparti4 LONG IN rpartl4)

Here, the regular table data, the indexes and the large object data (assuming there are long- or LOB-
columns in table sale_date) are stored in a separate tablespace for each partition. Partition 1, for example,
uses tablespace rpartd1 for its regular data, tablespace rparti1 for its local indexes and tablespace rpartl1 for

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 5
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

its large object data. To place a global index in a specific tablespace, you can use the INDEX IN addition of
the CREATE INDEX statement that has been available since DB2 V9.1.
All the examples above use the so called long form for the definition of the partitions. There is also a short
form where DB2 itself calculates the partition boundaries if the partition expression consists of a date, a time-
based or a numerical column. This is shown in our next example:
CREATE TABLE sales(sale_date DATE, customer INT, …)
PARTITION BY RANGE(sale_date)
(STARTING MINVALUE ENDING ’1/1/2005’,
STARTING ‘1/1/2005’ ENDING ’12/31/2005’ EVERY 3 MONTHS)

Again the table data is partitioned into the four quarters of 2005. Besides EVERY <constant> MONTHS you
can use EVERY <constant> YEARS, DAYS, HOURS, MINUTES and so on. This way you can create many
partitions with just a few lines in the CREATE TABLE statement.
You can find a good overview about the various table partition options up to DB2 V9.5 in “Table Partitioning
and Large Tablespaces in DB2 VIPER”.

Catalog Views for Table Partitioning

The partitioning of tables is reflected in DB2‟s system catalog. Beginning with DB2 V9.1 the new views
SYSCAT.DATAPARTITIONEXPRESSION and SYSCAT.DATAPARTITIONS are available. The
DATAPARTITIONEXPRESSION view contains one or more entries for every partitioned table which describe
the partition expression. In contrast, SYSCAT.DATAPARTIONS contains at least one entry for every table.
Nonpartitioned tables are also listed here as having one partition that is named “PART0”. For partitioned
tables there is an entry for every partition which describes all the partition details. To check programmatically
or on the command line if a table is partitioned or not, you need to query
SYSCAT.DATAPARTITIONEXPRESSIONS and find out if there is an entry for the table in question.
Another way to get information about partitioned tables is the DESCRIBE DATA PARTITIONS FOR TABLE
<tab> { SHOW DETAIL } command which gives partition details from the SYSCAT.DATAPARTITIONS
catalog view. To find out the size of the partitions you need to use the SYSIBMADM.ADMINTABINFO
administrative view or the corresponding ADMIN_GET_TAB_INFO table function. They return logical and
physical size information for every data partition as identified by their IDs in column DATA_PARTITION_ID.
This partition ID is also used in SYSCAT.DATAPARTITIONS.
The fact that every partition can be assigned to another tablespace has further implications for the system
catalog; I‟m going to discuss this in the next section.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 6
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Use of Table Partitioning in SAP Systems

Range-Partitioned Tables and the SAP Data Dictionary
If you intend to use DB2 range partitioning in an SAP system the SAP data dictionary (DDIC) must be made
aware of range partitioning. Otherwise the following issues arise:
 Any structural change to a table that cannot be handled by database means (that is, by the ALTER
TABLE statement) will trigger a so-called “conversion” in the SAP data dictionary. Examples for such
structural changes are column drop or column rename operations. Table modifications that do not
result in a conversion are adding a field to a table, changing the default value of a field (since
1
SAP_BASIS 7.10) and extending the length of a field of type VARCHAR . Other structural changes
of a table result in a conversion that involves dropping and recreating the table and its indexes and
other dependent objects (like views). For details on the conversion process see “Conversion
Process” in the SAP Library. Without the appropriate data dictionary patches in place any conversion
of a range partitioned table will result in loss of the range partitioning which means that after the
conversion the table will no longer be range partitioned.
 For range partitioned tables, the field TBSPACE in SYSCAT.TABLES is SQL NULL. From the DB
perspective this makes sense as every partition can be located in a different tablespace. However,
the data dictionary currently expects such an entry for all tables. As a result invalid DDL statements
can be created by the DDIC for range-partitioned tables.
To overcome these problems, changes are available for the ABAP data dictionary in SAP_BASIS 6.40 and
higher. For details on the availability and the required Support Packages for these changes please refer to
SAP Note 1379362. With these modifications in place the ABAP DDIC is aware of range-partitioned tables
and avoids the occurrence of the problems mentioned above.

Note: At the time of writing, the dictionary of the AS Java (the Java DDIC) does not support range-partitioned tables.
Problems can occur if the structure of a range-partitioned table is changed and if database specific parameters are
used.

Creating Range-Partitioned Tables in the ABAP DDIC

To convert a nonpartitioned table to a range-partitioned table, the conversion process of the ABAP DDIC
(mentioned above) can be used. To demonstrate this we use the CUSTOMERS table with a slight
modification. This table belongs to the ABAP example objects and is available in every ABAP system. To
have at least one column of type INTEGER in this table, the field POSTCODE is changed in the ABAP DDIC
(SE11) to the predefined DDIC type INT4. This change is again a good example for a conversion. To perform
it proceed as follows:
 Call SAP transaction SE11 and edit the table CUSTOMERS.
 Change the data type of the column POSTCODE from CHAR(10) to the predefined DDIC type INT4
by choosing the “Predefined Type” pushbutton.
 Save and activate the table. A message like “Structure change at field level (convert table
CUSTOMERS)” appears.
 From the “Utilities” menu, choose “Database Object → Database Utility”. You are redirected to SAP
transaction SE14, the database utility.
 From the “Extras” menu, choose “Force Conversion” and accept the message box. As a result the
conversion is performed.
Afterwards your CUSTOMERS table should look like this in SE11:

1
Note that DB2 supports more structure changes with the ALTER TABLE command, but the other changes
place the table in a REORG_PENDING state that can currently not be handled by the ABAP data dictionary.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 7
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

You can use the simple ABAP report ZJOFILLCUSTOMERS from appendix A to fill the CUSTOMER table
with some data.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 8
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Table Partitioning Examples

For DB2, you can add specific storage parameters (like table compression, MDC, database partitioning) to
the CREATE TABLE statement by using the so called OPTIONS mechanism. In SE14→<enter table
name>→Edit→Storage Parameters→For new Creation, you can enter additional clauses. Theses clauses
will simply be added to the CREATE TABLE or CREATE INDEX statements that are going to be assembled
by the ABAP DDIC. If the changes that are mentioned in SAP Note 1379362 are in place you can use this
mechanism also to define range-partitioned tables.
To activate range partitioning for an existing table that contains data, proceed as follows:
 Call SAP transaction SE14, enter the table name and choose Edit.
 Choose Storage Parameters and For new Creation.
 A popup appears. Select “Current database parameters” (this is the default) and press Enter.
 Place the cursor on the OPTIONS line of the table and press Shift+F5 (“Insert parameter values”)
several times.
 Enter the partitioning clause in the empty OPTIONS lines. The following is an example for the
CUSTOMERS table:

 Choose Save (Ctrl-S).

 Go back one screen (F3).
 From the menu, choose Extras → Force conversion and Yes.

Note: Before you perform these steps on a real application table in a production system you should test it with an
(empty) copy of the table.
Note: If the conversion fails, you can correct the syntax of the storage parameters and continue with the conversion.
Note: The procedure above describes how to run a conversion in dialog mode. For large tables that contain a lot of
records you need to run the conversion in batch mode (see Scheduling Jobs for Mass Processing in the SAP
Library). During the conversion the table is not accessible for applications. For an alternative procedure where the
table remains accessible to applications see section “Other Ways for Creating Range-Partitioned Tables”.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 9
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Note: The date and time types of the ABAP DDIC (DATS and TIMS) are mapped to VARCHAR on the database.
Therefore, the short syntax form of the partitioning clause (e.g. ...EVERY 3 MONTHS...) cannot be used here. To
perform a monthly partitioning of a table with a DATS field you could use for example the following partition clause:

CREATE TABLE BALHDR(…)

PARTITION BY (ALDATE)
( STARTING „20080100‟,
STARTING „20080200‟,
…
STARTING „20081100‟ ENDING „20081200‟)

The short syntax is still possible for numerical fields.

If you entered the partitioning clause in correct syntax, you should see the message “Request for
CUSTOMERS executed successfully” in the status bar. To see the CREATE TABLE statement that was
actually assembled by the ABAP DDIC, go to the data dictionary (SAP transaction SE11), enter the table
name and F7 and choose Utilities → Activation Log from the menu. If you expand the log (F5) you can see
all statements that were generated during the conversion.
Another way to check is to go to SE14 again and look at the storage parameters of the table. This will now
look as follows on a system with DB2 9.7:

Storage
|
|-- Table
| |
| |-----TABLESPACE DD6#STABD
| |-----INDEXSPACE DD6#STABD
| |-----LONGSPACE DD6#STABD
| |-----LOCKSIZE ROW
| |-----OPTIONS PARTITION BY RANGE
| |-----OPTIONS (
| |-----OPTIONS POSTCODE
| |-----OPTIONS )
| |-----OPTIONS (
| |-----OPTIONS PARTITION "PLZ0"
| |-----OPTIONS STARTING(MINVALUE)
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS ENDING(10000)
| |-----OPTIONS EXCLUSIVE
| |-----OPTIONS IN "DD6#STABD"
| |-----OPTIONS INDEX IN "DD6#STABD"
| |-----OPTIONS LONG IN "DD6#STABD",
| |-----OPTIONS PARTITION "PLZ1"
| |-----OPTIONS STARTING(10000)
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS ENDING(20000)
| |-----OPTIONS EXCLUSIVE
| |-----OPTIONS IN "DD6#STABD"
| |-----OPTIONS INDEX IN "DD6#STABD"
| |-----OPTIONS LONG IN "DD6#STABD",
...
| |-----OPTIONS PARTITION "PLZ9"
| |-----OPTIONS STARTING(90000)
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS ENDING(MAXVALUE)

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 10
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

| |-----OPTIONS INCLUSIVE
| |-----OPTIONS IN "DD6#STABD"
| |-----OPTIONS INDEX IN "DD6#STABD"
| |-----OPTIONS LONG IN "DD6#STABD"
| ------OPTIONS )

Note: The ABAP DDIC always reconstructs the full syntax of the partition clause. In the example above, a shorter syntax
was used that did not specify the end of the ranges (as already mentioned, in this case the end of the ranges is
automatically calculated by DB2). In the result shown in SE14 after the conversion, the start and the end of each
range is explicitly specified.

Here is another example which uses multiple partition expressions and different tablespaces for the
partitions:

After the conversion the storage parameters look like this:

Storage
|
|-- Table
| |
| |-----TABLESPACE DD6#RD1
| |-----INDEXSPACE DD6#RI1
| |-----LONGSPACE DD6#RL1
| |-----LOCKSIZE ROW
| |-----OPTIONS PARTITION BY RANGE
| |-----OPTIONS (
| |-----OPTIONS POSTCODE NULLS FIRST,
| |-----OPTIONS DISCOUNT
| |-----OPTIONS )
| |-----OPTIONS (
| |-----OPTIONS PARTITION "PLZLOWER"
| |-----OPTIONS STARTING(0,'0')
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS ENDING(49999,'999')
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS IN "DD6#RD1"

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 11
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

| |-----OPTIONS INDEX IN "DD6#RI1"

| |-----OPTIONS LONG IN "DD6#RL1",
| |-----OPTIONS PARTITION "PLZUPPER"
| |-----OPTIONS STARTING(50000,'0')
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS ENDING(99999,'999')
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS IN "DD6#RD2"
| |-----OPTIONS INDEX IN "DD6#RI2"
| |-----OPTIONS LONG IN "DD6#RL2"
| ------OPTIONS )

Note: All tablespaces mentioned in the storage parameters must belong to the same database partition group.

Tablespace Considerations
To circumvent the problem that the CREATE TABLE template in the ABAP DDIC requires values in the
tablespace-clauses, tablespace setting for partitioned tables are handled as follows.
In the CREATE TABLESPACE statement the same tablespace settings as for nonpartitioned tables (derived
from the data class) are maintained. This means that even all partitioned tables are defined with the ...IN
<data-tbsp> INDEX IN <index-tbsp> LONG IN <long-tbsp> clause. However, these settings are overwritten
in the definition of the partitions of the CREATE TABLE statement and/or in the CREATE INDEX statement.
For the data and long tablespaces this is achieved by including the ..IN <data_tbsp> and LONG IN
<long_tbsp> clause in the definition of every partition.
In the example above, tablespace DD6#STABD is initially defined as the tablespace for the regular and the
large object data. However, this is overwritten so that partition PLZlower uses the tablespaces DD6#RD1
and DD6#RL1 and PLZupper uses DD6#RD2 and DD6#RL2. After the conversion, the tablespace settings of
the first partition are used to fill the tablespace options of the CRETE TABLE statement. You can see this
also in the example above, the storage parameter list shows that DD6#RD1, DD6#RI1 and DD6#RL1 are
used as TABLESPACE, INDEXSPACE and LONGSPACE.
Regarding the index tablespaces, we must distinguish between global and local indexes. The tablespace
placement of global indexes is defined in the CREATE INDEX statement in the <IN tablespace> clause. This,
again, overwrites the INDEX IN clause of the CREATE TABLE statement. The following is an example how
the storage parameters of a global index are displayed in SAP transaction SE14:

For local indexes, available with DB2 9.7, the INDEX IN clause in every partition definition is used to define
in which tablespace every local index is placed. In the example above, the local indexes of partition
PLZlower are placed in tablespace DD6#RI1 and the local indexes of partition PLZupper are placed in
DD6#RI2. If the SAP system runs on DB2 9.7, the ABAP DDIC checks for every index of a partitioned table if
it is local or global. If it is global, the …NOT PARTITIONED… clause is automatically generated for the
CREATE INDEX statement.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 12
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Limitations
The OPTIONS mechanism in SAP transaction SE14 has a shortcoming: an OPTION line can contain only up
to 79 characters. Therefore, the following additional limitations apply for range-partitioned tables in SAP
systems:
 Every partition expression (“POSTCODE” in the example above) can only grow up to 79 characters.
Note that the partition expression can be followed by a NULLS FIRST and a comma (in case of
multiple partition expressions) on the same line.
 The name of a partition can only grow up to 67 characters.
 The definition of the start value of a partition can have a maximum of 68 characters.
 The definition of the end value of a partition can have a maximum of 70 characters.
 The name of a tablespace is restricted in general in all SAP system by 30 characters.

Note: Exceeding one of these limits results in the error message “Error when determining storage parameters” in the
ABAP DDIC log.

Reverting to a Nonpartitioned Table

You can revert a range-partitioned table back to a nonpartitioned table by proceeding as follows:

 Call SE14, enter the table name and choose Edit

 Choose Storage Parameter and For new Creation
 A popup appears. Select “Computed from technical settings” and press Enter
 Save the parameters
 Go back one screen (F3) and trigger a conversion (Extras → Force Conversion from the menu)

Afterwards the table is a normal nonpartitioned SAP table.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 13
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Combining Table Partitioning with other Data Organization Schemes

Range partitioning can be of course combined with the other storage parameters that are supported by the
ABAP DDIC. The following example combines the range partitioning from the last example with a MDC
clause and enables row compression for the table:

The result looks as follows:

Storage
|
|-- Table
| |
| |-----TABLESPACE DD6#RD1
| |-----INDEXSPACE DD6#RI1
| |-----LONGSPACE DD6#RL1
| |-----LOCKSIZE ROW
| |-----OPTIONS ORGANIZE BY DIMENSIONS (
| |-----OPTIONS "NAME" ,
| |-----OPTIONS "POSTCODE"
| |-----OPTIONS )
| |-----OPTIONS PARTITION BY RANGE
| |-----OPTIONS (
| |-----OPTIONS POSTCODE NULLS FIRST,
| |-----OPTIONS DISCOUNT
| |-----OPTIONS )
| |-----OPTIONS (
| |-----OPTIONS PARTITION "PLZLOWER"
| |-----OPTIONS STARTING(0,'0')
| |-----OPTIONS INCLUSIVE

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 14
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

| |-----OPTIONS ENDING(49999,'999')
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS IN "DD6#RD1"
| |-----OPTIONS INDEX IN "DD6#RI1"
| |-----OPTIONS LONG IN "DD6#RL1",
| |-----OPTIONS PARTITION "PLZUPPER"
| |-----OPTIONS STARTING(50000,'0')
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS ENDING(99999,'999')
| |-----OPTIONS INCLUSIVE
| |-----OPTIONS IN "DD6#RD2"
| |-----OPTIONS INDEX IN "DD6#RI2"
| |-----OPTIONS LONG IN "DD6#RL2"
| |-----OPTIONS )
| ------OPTIONS COMPRESS YES

Other Ways for Creating Range-Partitioned Tables

Using the conversion procedure of the ABAP DDIC might not be acceptable for large tables with many
records. A DDIC conversion takes the table “offline”; it is not accessible for the SAP applications during the
process.
As a better alternative, you can use the DB6CONV report in version 5.0 or higher to partition an existing
table that contains data. This report, originally intended to move tables from one tablespace to another,
provides an option to perform this move while the table remains accessible (online table move). Also, you do
not have to specify target tablespaces that are different from the source tablespaces.
To partition a table online using DB6CONV, enter the partitioning clause for the table in SE14 like in the
examples above (SE14 → Storage Parameter → For new Creation → <enter partition clause> → Save), but
don‟t perform a conversion. Instead, start the report DB6CONV and perform an online table move.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 15
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Related Content
SDN Page SAP on DB2 for Linux, UNIX, and Windows
SDN Page SAP Business Intelligence with IBM DB2 for LUW
IBM Presentation Table Partitioning and Large Tablespaces in DB2 VIPER
IBM Redbook Database Partitioning, Table Partitioning, and MDC for DB2 9
For more information, visit the Landscape Design and Architecture homepage.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 16
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Appendix A: Report to fill the CUSTOMERS table with random data

REPORT zjofillcustomers.

DATA: wa_custentry TYPE customers.

DATA: rand_string TYPE string.
DATA: rand_num TYPE i.
DATA: counter TYPE i.
DATA: rest TYPE i.

PARAMETERS: num_recs TYPE i.

PARAMETERS: commit TYPE i DEFAULT 50.
PARAMETERS: del_data(1) TYPE c DEFAULT 'X'.

IF ( del_data EQ 'X' ).
CALL FUNCTION 'DB_TRUNCATE_TABLE'
EXPORTING
tabname = 'CUSTOMERS'.
ENDIF.

DO num_recs TIMES.
wa_custentry-id = wa_custentry-id + 1.
counter = counter + 1.

CALL FUNCTION 'GENERAL_GET_RANDOM_STRING'

EXPORTING
number_chars = 25
IMPORTING
random_string = rand_string.

WRITE rand_string TO wa_custentry-name.

CALL FUNCTION 'GENERAL_GET_RANDOM_INT'

EXPORTING
range = 99999
IMPORTING
random = rand_num.

wa_custentry-postcode = rand_num.

CALL FUNCTION 'GENERAL_GET_RANDOM_STRING'

EXPORTING
number_chars = 25
IMPORTING
random_string = rand_string.

WRITE rand_string TO wa_custentry-city.

CALL FUNCTION 'GENERAL_GET_RANDOM_INT'

EXPORTING
range = 9
IMPORTING
random = rand_num.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 17
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

IF ( rand_num < 5 ).
wa_custentry-custtype = 'B'.
ELSE.
wa_custentry-custtype = 'P'.
ENDIF.

CALL FUNCTION 'GENERAL_GET_RANDOM_INT'

EXPORTING
range = 999
IMPORTING
random = rand_num.

WRITE rand_num TO wa_custentry-discount LEFT-JUSTIFIED NO-GAP NO-GROUPING.

CALL FUNCTION 'GENERAL_GET_RANDOM_INT'

EXPORTING
range = 100000000
IMPORTING
random = rand_num.

WRITE rand_num TO wa_custentry-telephone LEFT-JUSTIFIED NO-GAP NO-GROUPING.

INSERT into customers values wa_custentry.

rest = counter MOD commit.
IF ( rest EQ 0 ).
COMMIT WORK.
ENDIF.

ENDDO.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 18
 Using DB2 for Linux, Windows, and UNIX Table Partitioning in SAP Systems

Copyright
© Copyright 2009 SAP AG. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG.
The information contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9,
iSeries, pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Serv er,
PowerVM, Power Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes,
BladeCenter, System Storage, GPFS, HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX,
Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.
Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.
Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems
Incorporated in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of
Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts
Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by
Netscape.
SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned
herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.
Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and
other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered
trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.
All other product and service names mentioned are the trademarks of their respective companies. Data contained in this docume nt
serves informational purposes only. National product specifications may vary.
These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("S AP
Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the
express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an
additional warranty.

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BOC - boc.sap.com

© 2009 SAP AG 19