4Preparing for Implementation on the DB2 Host
Preparing for Implementation on the DB2 Host
This chapter is intended primarily for the z/OS system programmer and DBA who must prepare for the Siebel Schema installation on the DB2 host. It contains the following topics:
About System Connectivity Architecture
Siebel Business Applications communicate with DB2 for z/OS through IBM DB2 Connect middleware. For a list of the supported versions of DB2 Connect, see Siebel System Requirements and Supported Platforms on Oracle Technology Network.
The four editions of DB2 Connect are:
DB2 Connect Enterprise Edition (EE). Supports database connectivity for users running Siebel Web Client when communicating with the Siebel Server. This edition is installed on a midtier server, such as a Siebel Server computer.
DB2 Connect Application Server Edition (ASE). Provides the functionality of DB2 Connect Enterprise Edition but is licensed and priced differently.
DB2 Connect Unlimited Edition (UE). Provides the functionality of DB2 Connect Enterprise Edition but is priced differently.
DB2 Connect Personal Edition (PE). Supports database connectivity for an individual user running Siebel Developer Web Client on a workstation. This edition is installed on a user’s local workstation.
DB2 Connect EE, ASE, or UE can reside either on the same computer as the Siebel Server or on common connection gateway computers. (Do not confuse the concept of a gateway computer with the Siebel Gateway.) DB2 Connect EE, ASE or UE broker the connections to DB2 for multiple database clients. For information on DB2 Connect configurations, see the following table.
Siebel Servers and Siebel Developer Web Clients communicate with DB2 Connect through TCP/IP. (DB2 Connect also supports communication through SNA, but SNA currently does not support connection pooling. For this reason, it is recommended that you use TCP/IP.) For instructions on installing TCP/IP, refer to the vendor documentation on the IBM Web site.
About Connecting to the Database Using DB2 Connect
You install the Siebel Schema on DB2 for z/OS using the Database Configuration Wizard which resides on a client Siebel Server. For a description of the installation process, see Installing the Siebel Database on the DB2 Host. After installation, you execute SQL on the DB2 for z/OS host.
Configuration Options for DB2 Connect
When using DB2 Connect, your configuration options depend on whether you are deploying Siebel Business Applications on a Web Client or on a Developer Web Client, as shown in the following table.
Table DB2 Connect Configurations
| DB2 Connect Edition | Siebel Business Applications Deployed on | Install and Run DB2 Connect on |
|---|---|---|
Enterprise Edition (EE, ASE or UE) |
Siebel Web Client |
Siebel Server computer or another computer on midtier. |
Enterprise Edition (EE, ASE or UE) |
Siebel Developer Web Client |
Any computer on midtier. |
Personal Edition (PE) |
Siebel Developer Web Client |
Each workstation. |
The following figure illustrates some of the configurations possible with DB2 Connect Personal Edition (PE) and DB2 Connect Enterprise Edition (EE). DB2 Connect PE runs on the workstation only; DB2 Connect EE can run on the same computer as the Siebel Server or on a different computer. The configuration you choose largely depends on the types of Siebel clients your enterprise supports.
For detailed information about DB2 Connect, refer to the IBM documentation.
About the Required IBM Fix Packs
After you have installed DB2 Connect, install any relevant IBM Fix Packs. To find out which IBM Fix Pack you need to use, refer to Siebel System Requirements and Supported Platforms on Oracle Technology Network or the vendor documentation.
Refer to IBM documentation for installing the Fix Pack for your environment.
You can verify the currently installed version of DB2 Connect and the IBM Fix Pack by running the command db2level from the DB2 Command Window. In a UNIX environment, this command is run from a UNIX shell after sourcing the appropriate db2profile. Make a note of the information and compare the Informational tokens from the output against Siebel System Requirements and Supported Platforms on Oracle Technology Network.
In addition to IBM Fix Pack information, the Siebel System Requirements and Supported Platforms on Oracle Technology Network contains any other installation requirements.
Process of Setting Up DB2 Connect
The process of setting up DB2 Connect involves the following tasks:
Configure DB2 Connect to support the Web clients used in your environment:
Configuring DB2 Connect EE, ASE or UE to Support Siebel Web Client
This task is a step in Process of Setting Up DB2 Connect.
Using DB2 Connect EE, ASE or UE to support the Siebel Web Client involves:
A Siebel Server, running Application Object Managers to support the Siebel Web Client. In some cases, DB2 Connect EE is also installed on this computer.
Optionally, an additional computer on which you install DB2 Connect EE, to act as a gateway to the database.
DB2 for z/OS.
Individual workstations running Siebel Web Client.
This approach is illustrated in the middle and lower parts of the previous figure.
Perform the following steps to configure DB2 Connect EE for a server computer.
To connect to DB2 using DB2 Connect EE
Using vendor instructions, install DB2 Connect EE on a server computer.
The DB2 Connect EE Server computer functions as a DB2 server, with protocol support for DB2 for z/OS.
You can also add DB2 Connect to an existing server on which DB2 is already installed.
On the DB2 Connect computer, upgrade DB2 Connect to the appropriate Fix Pack.
For further information, see About the Required IBM Fix Packs.
On the DB2 Connect EE Server computer, catalog your DB2 for z/OS database, as appropriate, using the DB2 Client Configuration Assistant or the DB2 Command Line Processor.
After installation, use a standard DB2 client to access the DB2 Connect EE Server.
Configuring DB2 Connect EE, ASE or UE to Support Siebel Developer Web Client
This task is a step in Process of Setting Up DB2 Connect.
Using DB2 Connect EE to support the Siebel Developer Web Client involves:
A computer on which you install DB2 Connect EE, to act as a gateway to the database. This computer can be a Siebel Server computer or a separate computer.
DB2 for z/OS.
A Siebel Developer Web Client workstation.
This configuration enables a high volume of concurrent network transactions between the Siebel Developer Web Client and the DB2 Connect EE Server computer. This approach combines elements from the middle and lower configuration options shown in the following figure.
To connect to DB2 using DB2 Connect EE
Using vendor instructions, install DB2 Connect EE on a gateway computer.
The DB2 Connect EE Server computer functions as a DB2 server, with protocol support for DB2 for z/OS.
On the DB2 Connect EE Server, upgrade DB2 Connect EE to the appropriate Fix Pack.
For further information, see About the Required IBM Fix Packs.
On the DB2 Connect EE Server computer, catalog your DB2 for z/OS database, as appropriate, using the DB2 Client Configuration Assistant or the DB2 Command Line Processor.
After installation, use a standard DB2 client to access the DB2 Connect EE Server.
Configuring DB2 Connect PE to Support Siebel Developer Web Client
This task is a step in Process of Setting Up DB2 Connect.
Using DB2 Connect PE to support the Siebel Developer Web Client involves:
A Siebel Developer Web Client workstation on which you install DB2 Connect Personal Edition (PE), to act as a gateway to the database.
DB2 for z/OS.
With this approach, a user on a Siebel Developer Web Client connects directly to DB2, as shown in the upper part of the previous figure.
To connect to DB2 using DB2 Connect PE
Install DB2 Connect PE on the Siebel Developer Web Client workstation computer.
On the computer, upgrade DB2 Connect PE to the appropriate Fix Pack.
For further information, see About the Required IBM Fix Packs.
If you previously installed a DB2 Connect run-time client, the DB2 Connect installer upgrade adds only the functionality required for the existing client. (This is also the case if you have a DB2 server or SDK installed on your workstation.)
On the workstation computer, catalog your z/OS databases as appropriate, using the DB2 Client Configuration Assistant or the DB2 Command Line Processor.
After installation, use a standard DB2 client to access DB2 Connect.
Performing Postinstallation Tasks for DB2 Connect
This task is a step in Process of Setting Up DB2 Connect.
After installing DB2 Connect, applying the necessary IBM Fix Pack, and setting up the network connectivity (TCP/IP and FTP) from the DB2 Connect server to the mainframe, there are a number of additional steps you must perform to use DB2 Connect with Siebel Business Applications. These steps include:
Defining a Database Alias and Testing a Connection
This topic describes how to define a database alias and test a connection.
When you create a connection to DB2 on z/OS, the connection is defined with a database alias that has the appropriate connection information for your database. This alias is the connect string that you specify when you install the Siebel Server. Record the connect string in the copy you made of Deployment Planning Worksheet
To define your database alias, use the DB2 Configuration Assistant or the DB2 Command Line Processor. For information on setting values in the db2cli.ini file and for using the DB2 Configuration Assistant or Command Line Processor, refer to the relevant IBM documentation.
TXNISOLATION parameter to the database alias entry in the db2cli.ini file, and set it to have a value of 1.
Testing the Database Connection in a Windows Environment
Use the following procedure to test the database connection in a Windows environment.
To test the database connection on the Windows platform
To ensure that you can connect to the database alias that you have defined, you can use either the DB2 Configuration Assistant, or the DB2 Command Window or Command Line Processor.
To use the DB2 Configuration Assistant method, start the utility, highlight the database alias that you created, and right-click.
Select the Test Connection option.
Enter an authorized user ID and password, and select ODBC and CLI as the test parameters.
Click Test Connection.
The following message indicates a successful connection:
CLI connection tested successfully. ODBC connection tested successfully.
Alternatively, you can use the DB2 Command Window or the DB2 Command Line Processor to test the database connection by typing the following, then pressing Enter:
DB2 connect to database_alias user database_userID using database_password
where:
database_aliasis the database alias you created using DB2
database_userID and database_password are an authorized user ID and its associated password on the DB2 host.
If the connection is successful, database connection information appears.
Testing the Database Connection in a UNIX Environment
Use the following procedure to test the database connection in a UNIX environment.
To test the database connection on the UNIX platform
Open a UNIX shell.
Go to the SIEBSRVR_ROOT directory, that is, the directory in which the Siebel Server is installed.
Enter the following command:
DB2 connect to database_alias user database_userID using database_password
where:
database_alias is the database alias you created using DB2
database_userID and database_password are an authorized user ID and its associated password on the DB2 host.
If your connection is valid, database connection information appears.
Binding the DB2 Connect Packages
To enable ODBC to point to DB2, bind the CLI/ODBC Support packages. DB2 Connect is installed with bnd files that bind to the host server. You can bind these packages using the default collection ID, or you can create a new collection ID for these packages. The Bind options are as listed:
Use DB2 Configuration Assistant's BIND option to bind the packages. Highlight the dbalias, right-click, and choose the BIND option from the pop-up dialog.
Issue explicit BIND commands. Refer to the relevant IBM documentation for further details on the BIND command.
Make sure that the authid has sufficient authority to bind these packages (BINDADD).
Configuring DB2 Connect
This task is a step in Process of Setting Up DB2 Connect.
DB2 Connect configuration parameters allow you to specify some of the ways DB2 Connect works, for example, pooling and thread reuse. These configuration changes vary depending upon site-specific details and whether the Enterprise or Personal version of DB2 Connect is installed. Changes to these parameters change the database manager configuration file. For information on changing the database manager configuration parameters, refer to the appropriate IBM documentation.
DB2 Connect configuration tasks include the following:
Setting the DB2CONNECT_IN_APP_PROCESS Environment Variable
The DB2 Connect system environment variable, DB2CONNECT_IN_APP_PROCESS, determines whether or not DB2 Connect clients running on a DB2 Connect EE server must run within an agent. When this variable is set to NO, local clients have to run within an agent. The default value for the DB2CONNECT_IN_APP_PROCESS variable is YES.
You can use DB2 Connect simply as a means of allowing a Siebel application to connect to the Siebel database on the z/OS host. Alternatively, you can implement the following features of z/OS provided by DB2 Connect with Siebel Business Applications:
Connection load balancing across Sysplex members
Connection pooling
Connection concentration
To enable these features when DB2 Connect is located with your Siebel Business Applications, you must set the DB2 environment variable, DB2CONNECT_IN_APP_PROCESS, to NO.
For additional information on DB2 Connect features and the DB2CONNECT_IN_APP_PROCESS variable, refer to the relevant IBM documentation. For additional information on connection concentration, see Setting DB2 Connect EE Configuration Options. For additional information on server clustering for the Siebel database, see the topic on server clustering in Siebel Deployment Planning Guide.
Setting the DB2CONNECT_ENABLE_EURO_CODEPAGE Environment Variable
The DB2 Connect system environment variable, DB2CONNECT_ENABLE_EURO_CODEPAGE, determines whether or not support for the euro symbol is implemented. The default value of this variable is NO. To ensure the euro symbol is implemented correctly on the z/OS host, set this variable to YES.
When you set the DB2CONNECT_ENABLE_EURO_CODEPAGE parameter to YES, the Unicode code page on the DB2 Connect client computer is mapped to a comparable CCSID which includes support for the euro symbol. It is recommended that you set the value of this variable to YES on all DB2 Connect computers used to connect to the Siebel database on the z/OS host. For additional information on the DB2CONNECT_ENABLE_EURO_CODEPAGE environment variable, see the relevant IBM documentation.
Setting DB2 Connect EE Configuration Options
The DB2 Connect EE product is a server version that allows multiple users to connect to DB2 on the z/OS host. Because it is a server, you must complete additional configuration steps:
You must specify whether or not to enable connection concentration.
For information on connection concentration, see About Connection Concentration.
You must define the maximum number of concurrent users.
For information on specifying the number of concurrent users allowed, see Setting the MAXAGENTS Parameter Value.
About Connection Concentration
Connection concentration provides additional workload balancing opportunities for DB2 Data Sharing by allowing connections to be rebalanced across DB2 Data Sharing members at the commit phase, instead of only at the time of initial connection. This dynamic rebalancing of connections across members can be beneficial after a planned or unplanned outage to DB2.
The default settings for the configuration parameters that control connection concentration are:
Priority of agents (AGENTPRI) is SYSTEM.
Maximum number of existing agents (MAXAGENTS) is 100. MAXAGENTS is the maximum number of worker agents. This value represents the maximum number of concurrent connections to DB2 for z/OS.
Agent pool size (NUM_POOLAGENTS) is 50 (calculated). NUM_POOLAGENTS is the maximum number of idle pool agents. This value represents the number of concurrent connections to DB2 for z/OS. Setting this parameter to 0 disables connection pooling.
Initial number of agents in pool (NUM_INITAGENTS) is 0.
Maximum number of coordinating agents (MAX_COORDAGENTS) is equal to (MAXAGENTS minus NUM_INITAGENTS).
Maximum number of concurrent coordinating agents (MAXCAGENTS) is equal to MAX_COORDAGENTS.
Maximum number of client connections (MAX_CONNECTIONS) is equal to the value of MAX_COORDAGENTS. When MAX_CONNECTIONS is equal to MAX_COORDAGENTS, Connection Concentration is not enabled.
Enabling Connection Concentration
The following procedure describes how to enable connection concentration.
To enable Connection Concentration
Set the value of the maximum number of client connections so that MAX_CONNECTIONS is greater than MAX_COORDAGENTS (MAX_CONNECTIONS equals MAX_COORDAGENTS plus 1).
Setting MAX_CONNECTIONS to equal MAX_COORDAGENTS plus1 enables the Connection Concentration dynamic rebalancing capabilities and still allows the transaction pooling to be handled by Siebel pooling.
Note: If you enable Connection Concentration, you must first set the value for the maximum number of agents (MAXAGENTS) parameter; this value determines the value of other parameters. Set the value of the MAXAGENTS parameter as appropriate for your site; this value varies according to the memory available and the number of server connections expected.
Setting the MAXAGENTS Parameter Value
If you do not want to enable connection concentration, and if you have not made any adjustments to the connection concentration parameters, then the only configuration to do is to set the number of MAXAGENTS to the number of concurrent connections to DB2 that you expect will be required. To set this number, issue an update dbm cfg using statement. For more information on updating the database manager configuration, see the vendor documentation on the IBM Web site.
If you are using Siebel connection pooling (and it is recommended that you do), the value you choose for MAXAGENTS determines the value you specify for the MaxSharedDbConns parameter value. Further, it determines the value you specify for the MAXDBATS parameter on the z/OS host. For more information about this feature, see Database Connection Pooling.
Tuning DB2 Connect by Increasing the I/O Block Size
The RQRIOBLK database manager configuration parameter specifies the maximum size of the client I/O blocks used to store the results of queries sent by a database client to a remote database.
To ensure that database queries which return large blocks of data do not cause DB2 Connect users to experience long response times, you can change the value of the client RQRIOBLK database manager configuration parameter.
The default value for the RQRIOBLK parameter on DB2 Connect is 32 KB and the maximum size is 65 KB. DB2 for z/OS can support up to 10MB cursor blocks so you can increase the value of the RQRIOBLK parameter to 65 KB and so improve performance.
To change the DB2 Connect I/O block size (RQRIOBLK) value
Using the Command Line Processor, change the RQRIOBLK size by typing the following:
DB2 UPDATE DBM CFG USING RQRIOBLK 65535
About Setting Up the DB2 Subsystem
In setting up the DB2 subsystem in preparation for deploying a Siebel application on DB2 for z/OS, you must perform a number of tasks, and consider a number of factors, including the following:
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.
About Unicode Character Conversions on z/OS
Unicode provides an industry-standard, universal, character-encoding standard. Since Release 7.5, Siebel Business Applications have supported the Unicode character set. On the z/OS platform, Siebel Business Applications support the Unicode character set on all versions of DB2 for z/OS, New Function Mode and later releases.
On DB2 for z/OS, character conversions from Unicode code pages to ASCII and EBCDIC code pages are performed by the z/OS Unicode Services; these conversions are required if Siebel Business Applications are to function correctly. For information on setting up the z/OS Unicode Services, see the IBM document z/OS Support for Unicode: Using Unicode Services on the IBM z/OS information center Web site at
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp
Considerations in Choosing the Database CCSID
The current Siebel release supports ASCII- and EBCDIC-based coded character set IDs (CCSIDs) for all versions of DB2 for z/OS, and Unicode character set IDs on all versions of DB2 for z/OS, New Function Mode and later releases. The database CCSID you use determines a number of factors, for example, the sort order used in list applets.
Review Siebel Release Notes on My Oracle Support for information about known restrictions; for example, the following features are not supported on databases with EBCDIC code pages:
Web Client migration
Siebel Data Warehouse
Siebel Dun and Bradstreet server components
You must run development databases with ASCII or Unicode code pages, because databases with EBCDIC code pages do not support the following procedures in a development environment upgrade:
Merging prior configuration changes into a new custom configuration repository (for upgrades only)
Publishing a new Siebel Runtime Repository
You can use an ASCII-, an EBCDIC-, or a Unicode-based CCSID to create your Siebel Schema, but, if you mainly use single-byte character sets, it is recommended that you use ASCII or EBCDIC CCSIDs to minimize storage space requirements. Review the following recommendations:
Use an ASCII-based encoding scheme to reduce the overhead required for character conversion. Character conversion is performed by Distributed Relational Database Architecture (DRDA), between the database and the midtier ASCII servers.
Use a Unicode-based encoding scheme if you require a character set that includes many characters that do not fit well in the ASCII or EBCDIC character set, for example, double-byte character sets for Chinese, Japanese, and Korean characters.
You can partition table spaces on a database with either an ASCII, an EBCDIC or a Unicode code page, so that limit keys reflect the sort sequence difference between ASCII, EBCDIC and Unicode. For more information, see Configuring the Siebel Database Layout.
About Setting the CCSID
Configure the CCSIDs on the DB2 installation panel, DSNTIPF. The APPLICATION ENCODING field allows you to specify the default application encoding scheme. The value of the DEF ENCODING SCHEME field on the same panel determines whether the default format in which data is stored on DB2 is ASCII, EBCDIC, or Unicode.
About Data Distribution Facility and Workload Manager
The Data Distribution Facility (DDF) is a component of DB2 that provides a connection between your DB2 subsystem and remote clients and systems. Specifically, it communicates with DB2 Connect for remote application access. You must configure and activate DDF before you install Siebel Business Applications. DDF setup is described in the vendor documentation on the IBM Web site.
Workload Manager (WLM) is an integrated component of z/OS that manages system resources across z/OS subsystems. You must configure WLM for use with DDF threads and Siebel application stored procedures and user-defined functions (UDFs).
In relation to DB2, WLM manages incoming requests for DB2 stored procedures and UDFs, and allocates resources to process them. If you do not have WLM installed and configured, you cannot use Siebel components that require stored procedures and UDFs. Stored procedures are used with EIM (when UPDATE STATISTICS is set to TRUE) and the Siebel Upgrade application component. UDFs are used with EIM Export and currency aggregations. For information on setting up WLM, see the vendor documentation on the IBM Web site.
DSNZPARM Parameter Settings for Siebel Business Applications
To run your Siebel Business Applications, you must set the values of some of the DSNZPARM parameters to required settings; other DSNZPARM parameter values are recommended to improve the performance of your Siebel Business Applications. This topic describes both the recommended and the required DSNZPARM parameter settings.
You can configure some DSNZPARM parameters online, but to configure other parameters, you must shut down DB2. For information on the parameters that can be updated online, refer to the vendor documentation on the IBM Web site.
The following table lists the required and recommended DSNZPARM parameter settings.
Table Recommended Database Manager Configuration Parameters (DSNZPARM)
| Parameter | Explanation | Setting | Required or Recommended |
|---|---|---|---|
DSN6SPRM |
|||
|
Turns on dynamic statement caching. |
|
Required |
|
Turns off parallelism for dynamic statements. |
|
Required |
|
Compresses storage on a regular basis. Set this value to |
|
Recommended |
|
Allows predicate evaluation on uncommitted data. |
|
Recommended |
MAXKEEPD |
The total number of prepared, dynamic SQL statements that can be saved past a commit point by applications that run with the KEEPDYNAMIC(YES) bind option. |
0 | Recommended |
|
Allows small tables to use indexes. |
|
Recommended |
|
Number of locks for each user. It is recommended that the DBA monitors and sets this value. If you experience persistent locking problems, consider setting the parameter to During Incremental Repository Merge, Oracle recommends setting the parameter to 0 (unlimited number of locks). For more information about Incremental Repository Merge, see Siebel Database Upgrade Guide. |
|
Recommended |
|
Allows update of partitioning keys. |
|
Required if using partitioning |
|
Allows index-only access of varying-length characters. Set this value to |
|
Required |
DSN6SYSP |
|||
|
Avoids frequent checkpoints in a high-update environment. It is recommended that DBAs monitor and set this value for between 10 and 20 minutes. |
500,000 |
Recommended |
|
Maximum number of concurrent remote connections. It is recommended that the DBA monitors and set this value. |
|
Recommended |
|
Allows DB2 Connect to receive more complete error messages. Allows you to change passwords from DB2 Connect. |
|
Required |
LOBVALA |
Specifies the maximum amount of storage, in KB, assigned to each user for storing large object (LOB) values in the subsystem. If the value specified for this parameter is too low, the job that imports seed data during the Siebel database installation process can fail. |
48,000 |
Recommended |
LOBVALS |
Specifies the maximum amount of memory, in MB, assigned to each subsystem for storing LOB values. |
24,000 |
Recommended |
|
Maximum number of database threads (DBAT). It is recommended that the DBA monitors and set this value. |
|
Recommended |
DSN6FAC |
|||
|
Allows a greater number of remote threads without affecting storage. Enables DDF thread pooling. |
|
Recommended |
|
Number of seconds before an idle thread is canceled. Prevents long-running threads from holding resources. The DBA should monitor and set this value. |
|
Recommended |
|
Number of seconds an inactive thread remains in the DDF pool. The DBA should monitor and set this value. |
120 |
Recommended |
PADIX Considerations
The PADIX parameter determines whether or not new indexes are padded by default. If you specify YES, a new index is padded unless the NOT PADDED option is specified on the CREATE INDEX statement. The IBM default value for this parameter is YES. If you do not want new indexes to be padded by default, you must specify NO for this parameter.
In some Siebel implementations, setting the PADIX parameter to NO has been found to lead to performance improvements and savings in disk space; it also allows for index-only access to data. If you do set PADIX to NO, ensure that you carefully monitor the impact of doing so in your environment.
NUMLKUS Considerations
If a resource-unavailable error occurs, because the value set for the NUMLKUS parameter has been exceeded while performing a Siebel operation, increase the NUMLKUS parameter value.
NUMLKUS parameter value is important when running large EIM batches and during the use of Siebel Remote for the initial database extract. If this value is too small, EIM runs or the database extract can fail.
If EIM fails because the value specified for the NUMLKUS parameter has been exceeded, take one of the following actions:
Reduce the size of the batch.
Increase the value of
NUMLKUS.
IDTHTOIN Considerations
The IDTHTOIN DSNZPARM recommended setting is 600. (The parameter is specified in seconds.) Monitor this value in your installation to ensure that it is set properly. The IDTHTOIN parameter time- outs active threads that have been idle (no network traffic) for more than 600 seconds. (This time is the recommended value; your value might differ.)
The events that can occur when an active thread times out include:
The thread is not returned to the DB2 Connect thread pool for reuse.
When the client or component tries to reuse the DB2 Connect thread, the thread is not available. The client or component has to issue a full Connect to continue processing the work.
If the component or client cannot issue a full Connect, the client receives a SQL30081N SQLCODE. An example of an error message you might receive if the component or client cannot reconnect is:
[IBM][CLI Driver][DB2] SQL30081N A communication error has been detected. Communication protocol being used: "TCP/IP". Communication API being used: "SOCKETS". Location where the error was detected: "". Communication function detecting the error: "recv". Protocol specific error code(s): "*", "*", "0". SQLSTATE=08001
Another consideration to bear in mind when specifying a value for the IDTHTOIN parameter is that connection pooling on the ODBC driver must be turned off. Using connection pooling with the driver is not certified with Siebel CRM version 8 releases.
Estimating the Storage Space Required
The space needed by DB2 varies, depending on the total number and types of users supported. Consult the IBM DB2 for z/OS technical documentation for more information on these requirements.
The minimum DB2 storage space required for a typical Innovation Pack 2017 installation on DB2 for z/OS (installation of repository tables and seed data but with no user data loaded into the base tables) is between 5 GB and 20 GB, depending on the DEFINE parameter setting specified when the database objects were created.
If database objects are created with the DEFINE parameter set to YES, a DB2 catalog entry is created for the object and a data set is allocated for the object. If database objects are created with the DEFINE parameter set to NO, only a DB2 catalog entry is created for the object, so less space is required. Siebel Business Applications ship all table space and index schema definitions with the DEFINE NO option as the default. Therefore, no physical data sets are created until data is actually inserted into the table space.
The minimum space you require varies depending on the Siebel functionality you implement and the amount and nature of data supporting it. The process for making accurate database size calculations is complex, involving many variables. Use the following guidelines to assist you:
Determine the total number and types of users of Siebel Business Applications (for example, 500 sales representatives and 75 sales managers).
Determine the Siebel functionality that you will implement and the entities required to support them. Typically, the largest entities are:
Accounts
Activities
Contacts
Forecasts
Opportunities
Service Requests
Estimate the average number of entities for each user (for example, 100 accounts for each sales representative) and calculate an estimated total number of records for each entity for your total user base.
Calculate the average record size for each entity and multiply by the total number of records using standard sizing procedures for your specific database and the Siebel Schema definition. Typically, these entities span multiple physical tables, all of which must be included in the row size calculation. This calculation determines the estimated data sizes for the largest entities.
Add extra space for the storage of other Siebel data. A rough guideline for this amount is one-half the storage required.
Allow for a margin of error in your total size calculation.
Factor growth rates into your total size calculation.
A Siebel database that uses a Unicode encoding format will generally require more space than one that uses an ASCII or EBCDIC encoding format. For further information on the space requirements for Siebel Unicode databases, see About Migrating a Siebel Database to Unicode Format.
Allocating Space for Buffer Pools and Storage Groups
The following example illustrates how you can alter space for buffer pools, in preparation for installing the Siebel Schema, using a group ID.
ALTER BUFFERPOOL (BP32K1) VPSIZE (4000)
GRANT USE OF BUFFERPOOL BP32K1 TO PUBLIC;
The following example illustrates how you can allocate space and access to storage groups using a group ID.
CREATE STOGROUP SIEBEL VOLUMES ('*') VCAT SIEBEL;
GRANT USE OF STOGROUP SIEBEL TO PUBLIC;
Estimating the Number of Database Objects You Need
Oracle ships over 4,000 tables and 21,000 indexes. The number of objects created in the Siebel Schema is determined by the Siebel product line you purchase. The number of objects determines how much space you must allocate. It is up to you to determine which of the objects shipped might actually be required for your deployment, based on your business needs.