SAP on DB2 Universal Database for OS/390 and z/OS: Multiple Components in One Database (MCOD)

Chapter 1. MCOD in a DB2 UDB for OS/390 and z/OS environment 5

Database servers support schema. Tables with the same name but different

schema can coexist in a database server. In the case of DB2, the schema is also

called creator.

Using a one-to-one relationship between the database user and the database

schema, each SAP component uses its own schema by accessing the database

server with a unique dedicated database user. By that, all objects (in the case of

DB2: stogroups, database, tablespaces, tables, indexes, and triggers) are clearly

associated with only one SAP component. For table T100, this relationship is

depicted in Figure 1-1.

Figure 1-1 MCOD: Database user and schema

1.2.2 DB2-specific modifications

For the implementation of MCOD, SAP only requires a different schema for each

component. In addition to that, some DB2-specific modifications are necessary

(for example, to handle data storage). These enhancements are listed in the

following sections.

Schema

Older SAP applications use the schema SAPR3 when accessing the database

server. With the introduction of MCOD, the schema can now be specified during

the installation procedure:

򐂰 For applications based on SAP Basis Release 4.6C/D, the default is still

SAPR3. However, the default can be overwritten during the installation

process (see 3.3.1, “SAP Basis Releases 4.6C and 4.6D” on page 33).

򐂰 For SAP Basis Releases 6.10 and later, the default is value is SAP<SID>.

6 SAP on DB2 UDB for OS/390 and z/OS: Multiple Components in One Database (MCOD)

All DB2 objects belonging to one SAP component must have the same creator

(the one specified during the installation). Besides tables, views, and indexes,

this also includes stogroups, databases, and tablespaces.

Note that all SAP applications check whether the creator of a stogroup,

tablespace, or database is correct before using it for the creation of a new

database object.

Environment and profile setting

New variables on the application server are introduced to specify the schema:

򐂰 Most SAP applications and all stand-alone tools (for example, tp and R3trans)

use the environment variable DBS_DB2_SCHEMA.

򐂰 In addition, some SAP applications retrieve the information from the instance

profile, where it is specified using profile parameter dbs/db2/schema.

Stogroups

Each component has its own set of stogroups:

򐂰 If the creator associated with the SAP component is SAPR3, the traditional

naming is applied for stogroups (for example, SAPBTD and SAPSTI).

򐂰 Otherwise, the first three characters are substituted with the SAP System ID.

For example, if the SAP System ID is PRD, the stogroups will be named

PRDBTD, PRDSTI, and so forth.

VCAT name

The VCAT name is specified during the installation procedure and subsequently

used as an attribute when creating the stogroups. It should be chosen differently

from the DB2 system data (catalog, directory, and so forth) and each other SAP

component in the MCOD installation. Then, the VCAT can be used to easily

identify SAP components on a data set level, because it forms the high-level

qualifier (HLQ) of the data sets created by DB2.

Storage Management Subsystem (SMS) access control system (ACS) routines

and storage groups can be adapted to allow each component to reside on its

own pool of volumes to assist storage management. Alternatively, any

combination of sharing or isolation is possible through SMS settings.

This is only possible by specifying unique VCATs when installing or merging into

an MCOD environment and, therefore, is highly recommended by SAP and IBM

(see 2.1.1, “Keep things as separate as possible” on page 16).