1. Implementing Siebel Business Applications on DB2 for z/OS
  2. Advantages of Using a Separate DB2 Subsystem

Advantages of Using a Separate DB2 Subsystem

Production deployments of Siebel CRM can be in both separate and shared DB2 subsystems. However, setting up a separate subsystem for Siebel CRM is preferable, particularly for larger deployments, for the following reasons:

  • DSNZPARM optimization. The DSNZPARMs used with Siebel CRM are optimized for the Siebel CRM applications, but might not be optimal for use with other applications. It is recommended, but not required, that you run Siebel CRM applications on its own subsystem.

  • OLTP and OLAP characteristics. Siebel CRM possesses the characteristics of both OLTP and OLAP applications. However, most other vendors’ applications have the characteristics of either one or the other.

  • System catalog locking during Siebel database recovery. Siebel CRM defines one table space for each database so system catalog locking during Siebel database recovery is not a problem. However, if you use database layouts with multiple table spaces for each database, recovery of the Siebel Schema might affect other applications on a shared DB2 subsystem if the system catalog becomes locked during the recovery process. Because recovery typically requires the restoration of all Siebel table spaces, locking could last many hours.

Even though a separate DB2 subsystem is preferable for implementing Siebel CRM, there are numerous successful Siebel CRM deployments in shared DB2 subsystems.