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.
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.
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).

Get SAP on DB2 Universal Database for OS/390 and z/OS: Multiple Components in One Database (MCOD) now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.