Administration Guide

Other Configuration Considerations in Any Environment

You should consider the values of the following configuration parameters when you are setting up your environment. For additional information about setting these parameters, also refer to the DB2 Connect User's Guide.

Figure 48. Configuration Considerations

• The following are database manager configuration parameters:
  • tm_database

    The tm_database database manager configuration parameter identifies the name of the Transaction Manager (TM) database for each DB2 instance.

  • spm_name

    The spm_name database manager configuration parameter identifies the name of the DB2 Syncpoint Manager (SPM) instance to the database manager. It is defined in the system database directory and, if remote, in the node directory.

    For resynchronization to be successful, the name must be unique across your network.

  • resyn_interval

    The resync_interval database manager configuration parameter identifies the time interval in seconds for which the DB2 Transaction Manager (TM) database manager, DB2 server database manger, and the DB2 Syncpoint Manager (SPM) should retry the recovery of any outstanding indoubt transactions.

  • spm_log_file_sz

    The spm_log_file_sz database manager configuration parameter identifies the SPM log file size in 4K pages.

  • spm_max_resync

    The spm_max_resync database manager configuration parameter identifies the number of agents that can simultaneously perform resync operations.

  • spm_log_path

    The spm_log_path database manager configuration parameter identifies the log path for the SPM log files.

• The following are database configuration parameters:
  • maxappls

    The maxappls database configuration parameter specifies the maximum number of active applications allowed.

    The value of this parameter must be equal to or greater than the sum of the connected applications plus the number of these same applications which may be concurrently in the process of completing a two-phase commit or rollback. This sum should then have added to it the anticipated number of indoubt transactions which might exist at any one time. See Recovering from Problems During Two-Phase Commit for more information on indoubt transactions.

    As a result, if you have an environment like the one just described, you may need to increase the value of the maxappls parameter. Increasing the value helps ensure that all processes can be accommodated.

  • autorestart

    This database configuration parameter specifies whether the RESTART DATABASE routine will be invoked automatically when needed. The default is yes (that is, enabled).

    A database containing indoubt transactions will require the RESTART DATABASE command/routine to be invoked in order to start up. If the autorestart option is not enabled, when the last connection to the database is dropped, the next connection will fail and require an explicit RESTART DATABASE again. This condition will exist until the indoubt transaction has been removed either by the transaction manager's resync operation, or through a heuristic operation performed by the administrator. When the RESTART DATABASE is issued, a message will be displayed if there are any indoubt transactions in the database. The administrator can then use the LIST INDOUBT TRANSACTION command and other command line processor commands to find out information about those indoubt transactions.

Refer to Administration Guide, Performance for more information on these configuration parameters.

Note:

Before installing either a fixpack for, or a new version of DB2, you should ensure that no indoubt transactions exist with any host or AS/400 server. Use the LIST DRDA INDOUBT TRANSACTION command to determine if any indoubt transactions exist.

Host or AS/400 Applications Which Access a DB2 Universal Database Server in a Multisite Update

In this situation, SNA connectivity is the only type supported. The DB2 Syncpoint Manager is required in order to permit multisite update. DB2 Universal Database does not support multisite update from host or AS/400 database clients using TCP/IP connectivity.

The database server which is being accessed from the host or AS/400 database client does not have to be local to the workstation which has the DB2 Syncpoint Manager. The host or AS/400 database client could connect to a DB2 UDB server using the DB2 Syncpoint Manager workstation as an interim gateway. This allows you to isolate the DB2 Syncpoint Manager workstation in a secure environment while the actual DB2 UDB Servers are remote in your organization. This also permits DB2 Common Server V2 database to be involved in multisite updates originating from host or AS/400 database clients.

The steps are as follows:

• On the workstation which has the DB2 Syncpoint Manager:

  1. Install DB2 Universal Database Enterprise Edition or Enterprise Edition - Extended in order to provide multisite update support with host or AS/400 database clients.

  2. Create a database instance on the same system. For example, you can use the default instance DB2, or use the following command to create a new instance:

        db2icrt myinstance
     

  3. Supply licensing information as required.

  4. Ensure that the registry value db2comm includes the value APPC.

  5. Configure SNA communications as required.

     The configuration will be easier if the SPM_NAME value is the same as the LU name, and the SPM uses the same LU as the DB2 Connect workstation.

     On an AIX system, the SPM_NAME value must be same as the names of:

     1. The transaction program (TP) profile used by the SPM.

     2. The local side information profile used by the SPM.

     3. The SPM instance name on application requesters.

  6. Determine the value to be specified for the SPM_NAME database manager configuration parameter, and optionally values for the SPM_LOG_FILE_SZ and SPM_MAX_RESYNC database manager configuration parameters if the defaults are not appropriate for your situation.

  7. Update SPM_NAME on the DB2 Universal Database server. For example, you can use the following command:

        update database manager configuration using spm_name SPMNAME
     

  8. Configure communications as required for this DB2 workstation to connect to remote DB2 UDB servers, if any.

  9. Configure communications as required for remote DB2 UDB Servers to connect to this DB2 Syncpoint Manager workstation.

  10. Stop and restart the database manager on the DB2 Universal Database server to start the SPM for the first time.

      You should be able to connect to the remote DB2 UDB servers from this DB2 Syncpoint Manager workstation.

• On Each Remote DB2 UDB Server which will be accessed by the Host or AS/400 Database Client

  The database administrator must also perform the following steps at each remote system where a DB2 UDB Server will be accessed by a host or AS/400 database client.

  The remote DB2 UDB Server must have its communications support configured so that the remote DB2 Syncpoint manager can connect to it AND so that this DB2 UDB Server can connect to the remote DB2 Syncpoint Manager.

  1. Configure communications as required for the remote DB2 Syncpoint Manager (SPM) workstation to connect to this DB2 UDB Server.

  2. Catalog the database directory entry for the remote DB2 Syncpoint Manager instance, and catalog the node entry for the location of the SPM. For example:

        catalog tcpip node SPMNODE remote SERVERD server db1inst1c
        db2 catalog database SPMNAME as SPMNAME at node SPMNODE
     

     The Database alias name must be the same as the actual database name.

     You should be able to connect to the SPM from the DB2 Client.

  3. Stop and restart the database manager on the application requester.

[ DB2 List of Books | Search the DB2 Books ]