Implementing Siebel Business Applications on DB2 UDB for z/OS > Preparing for Implementation on the DB2 Host > Setting Up the DB2 Subsystem >

Advantages of Using a Separate DB2 Subsystem

Siebel Systems supports production deployments of Siebel Business Applications in both separate and shared DB2 subsystems. However, setting up a separate subsystem for Siebel applications is preferable, particularly for larger deployments, for the following reasons:

• DSNZPARM optimization. The DSNZPARMs used with Siebel Business Applications are optimized for the Siebel application, but might not be optimal for use with non-Siebel applications. It is recommended, but not required, that you run the Siebel Business Application on its own subsystem.
• OLTP and OLAP characteristics. Siebel applications possess the characteristics of both an OLTP and OLAP application. However, most other vendors' applications have the characteristics of either one or the other.
• DB2 maintenance requirements. Siebel Business Applications requires the application of a number of maintenance activities that are documented in an informational APAR that can be located on IBM's Web site.

  CAUTION:  It is crucial that you apply all maintenance releases in an informational APAR to the subsystem that you set up. Otherwise, operating anomalies and unpredictable behavior might occur.

• System catalog locking during Siebel Database recovery. With the Siebel 7.7x approach of defining one table space per database, this is not a problem. However, if you use database layouts with multiple table spaces per 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 Business Applications, there are numerous successful Siebel deployments in shared DB2 subsystems.