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

Advantages of Using a Separate DB2 Subsystem

Production deployments of Siebel Business Applications can be in both separate and shared DB2 subsystems. However, setting up a separate subsystem for Siebel Business 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 Business Applications, but might not be optimal for use with other applications. It is recommended, but not required, that you run Siebel Business Applications on their own subsystem.
• OLTP and OLAP characteristics. Siebel Business Applications possess 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. Since Siebel 7.7, Siebel Business Applications define 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 Business Applications, there are numerous successful Siebel deployments in shared DB2 subsystems.