Db2 Architecture, Subsystems, and Installation/Migration
This domain tests how a Db2 12 subsystem is assembled and how it is installed, migrated, and advanced to a new function level.
Core architecture
- A Db2 subsystem runs in several z/OS address spaces: MSTR for system services, logging, and restart; DBM1 for buffer pools, EDM pool, and SQL work; DIST for DDF; IRLM for locks; and SSPE for stored procedures. Data sharing adds coupling-facility structures.
- ZPARMs are assembled from macros such as DSN6SPRM, DSN6SYSP, DSN6GRP, and DSN6LOGP; DSNHDECP supplies application defaults.
- Db2 12 uses function levels instead of a single NFM switch. A subsystem starts in CM, then a function level is activated. Catalog migration is a one-way step for the duration; fallback needs a fallback SPE and careful planning.
Installation and migration
- The installation and catalog migration jobs change the subsystem. Migrate data sharing members in the correct order and activate a function level only after every member is ready.
- Rebind packages after migration; old packages can fail or take poor access paths.
Worked example
A group runs V11 and must move to Db2 12 with minimal outage. The DBA installs the Db2 12 code, migrates the catalog on one member, starts the other members at CM, rebinds critical packages, and then activates V12R1M500. Reasoning: catalog migration must happen before function-level activation, and packages must be rebound because catalog and directory structures changed.
Traps
- Activating a function level before all members and utilities are ready is hard to undo.
- DBM1 virtual storage must be assessed before large buffer pool increases.
- Forgetting package rebinds can produce failures or plan regressions.