Implications of a second Db2 subsystem

The primary consideration in planning for a second Db2 subsystem is its purpose. Using a second subsystem has a substantial impact on your environment.

Second Db2 subsystems are not uncommon; organizations use a second Db2 subsystem to:

  • Run separate service levels or releases of the code. This can provide more extensive testing of preventive service or a new Db2 release before use with a production system. Separate levels or releases of Db2 on the same system must have separate libraries.
  • Separate test and production activities. This setup can improve Db2 performance and availability for production.

    For example, suppose the processor that runs your production subsystem fails. If your test subsystem is on another processor, you can stop the test subsystem and start the production subsystem on that processor. This only works if the requisite Db2 data sets are on shared storage devices and you have used global resource serialization (GRS) (or an equivalent) to protect the production Db2 data sets.

  • Prevent access by one class of users to certain data. If this is your primary purpose, reconsider the Db2 authorization scheme.
  • Run an application that requires different subsystem parameter settings from other applications or other environments.
  • Isolate an application from other applications.

The table below lists other implications of a second Db2 subsystem.

Table 1. Considerations for installing a second Db2 subsystem
Considerations Decisions that you need to make
Libraries A single, shared library or separate libraries
RACF® protection Resource and ID for the two subsystems
Db2 logging BSDS, active, and archive log space requirements
Database space requirements Db2 directory, Db2 catalog, and user data
Performance Processor and main storage use
Distributed data facility requirements
  • Location names, logical unit names, and network passwords must be coordinated with remote Db2 subsystems
  • In a non-data sharing environment, each Db2 subsystem needs a unique TCP/IP port and resync port.
Common service area (CSA) requirement Db2 and the IRLM
Shared storage devices Giving different names to active and archive log data sets, or including those data sets in the GRS inclusion list
ERLY code Choose a level of ERLY code that is appropriate for all Db2 subsystems.

Each subsystem must have a separate prefix.SDSNEXIT library. Sharing the prefix.SDSNSAMP library requires coordination to avoid overlaying parameter members.