DB2 is a database server developed by IBM, running on Linux, Unix, and Windows (LUW). SAP calls this database type DB6.

It supports the relational DB model, also supports object-relational features and non-relational structures like JSON and XML.

Supported versions

The minimal supported version is 10.05.0004.

Storage setup

Use the transaction /DVD/SM_SETUP for Storage Management to set up storage.

For the storage type DB2 transparent storage (secondary database) SM_TRS_DB2, fill in the following configuration parameters:

DB Connection Name: Existing SAP Database Connection.
Connection mode: Only Open SQL connection mode (option O) is supported by the DB2 database.
Tablespace: Table space. For more information, see DB2 table spaces.
COLUMN-ORIENTED: If selected, the tables created using this storage are column-organized.
Compression: If selected, adaptive compression is used.
Read all clients: Read data from the database with all clients (relevant for Open SQL Connection mode).
Repeats: Number of repeated attempts to connect to the database if the connection fails.
Delay: Number of seconds to wait before the next attempt to connect if the connection fails.

For archiving and reporting – use columnar technology (DB2 Blu)

The customer must have a license for DB2 Blu.
System Sizing and configuration must be prepared to use Blu.
We recommend following the IBM recommendation, e.g. 64 GB RAM, 8 Cores for production systems; for low-use non-production systems, half the size may be sufficient.
The use of multiple tablespaces to spread data – if possible target a maximum of 1 TB per tablespace; start with 5-10 tablespaces and spread objects

For most space-efficient archiving – use BLOBs

The system sizing can normally be independent of the database size: 16 GB RAM, 4 CPU recommended.
The use of multiple tablespaces to spread data – if possible target a maximum of 1 TB per tablespace; start with 5-10 tablespaces and spread objects
For best performance create 3 tablespaces per SAP data class: data+index+LOB. The LOB tablespace must be created with a file system caching ON. For each tablespace, the use of multiple tablespace containers (8-16) is recommended to avoid file-level locking issues. At table creation time, the tablespaces must be correctly assigned to the table (tbspace, index_tbspace, long_tbspace from syscat.tables). A change is possible using admin_move_table.
The majority of data will be stored in the LOB tablespace in compressed LOB table columns. Due to the nature of the content, is DB2 log file compression NOT recommended. Previous experiences were showing 4x+ longer log arching times with log file compression on.
Table and index compression have typically no impact on this setup since LOBs are already compressed in SAP. It is recommended to keep compression flags off.

Tablespaces in DB2 are used to store data. It is technically useful to distribute data across many tablespaces for various reasons. As background: there are locking/latching mechanisms in place per tablespace, also at lower layers at the file level. On a high workload, but also for HADR, backup, and recovery, having many tablespaces can reduce the chance of contention.
Space extensions: to avoid high file-level fragmentation, the use of larger increase sizes is recommended, e.g. 128 MB per container (e.g. with 8 containers 1024 MB).
SAP is recommending very small tablespace extent sizes of two blocks. For tablespaces with a high amount of data, the use of a much larger extent size is recommended, e.g. 16 or larger.

(9) "For BLU Acceleration, a minimum of 8 cores or IFLs and 64 GB RAM is recommended for production use"

Require a minimum of 8 cores with at least 64 GB RAM
Memory requirements temporarily increase when the column compression dictionary is created.
For optimal load performance, additional cache memory is required to write column-organized data in extent-sized amounts, rather than one page at a time, thereby reducing I/O costs.