Back
Next
Done
Cancel
Back
Next
Done
Cancel
Transaction Monitor (TP) page
Do not use a TP monitor
Use the TP monitor named below
Do not use a TP monitor.
Select this option if the application involved in the multisite update does not support a TP Monitor.
Use the TP monitor named below.
Select this option if the application involved in the multisite update does support a transaction processor (TP) monitor. To facilitate an efficient online transaction processing (OLTP) environment, a transaction processor (TP) monitor normally preallocates a number of server processes at startup, and then schedules and reuses them among the user transactions. This saves on the amount of system resources by allowing more concurrent users to be supported with a smaller number of server processes.
Protocol page
TCP/IP
SNA
TCP/IP
Select this option if you intend to use TCP/IP to connect to a host or AS/400 database.
See the Installation and Configuration Supplement for more information about setting up TCP/IP.
SNA
Select this option if you intend to use SNA to connect to a host or AS/400 database or you intend to use SNA to connect from a host or AS/400 client.
See the Installation and Configuration Supplement for more information about setting up SNA.
Selecting a Protocol
You need to know what types of database servers will be involved in the multisite update and the protocols these systems use to communicate. The Configure Multisite Update SmartGuide allows multisite updates between DB2 clients and servers, specifically DB2 clients and LAN-based or host and AS/400 database servers, or between host or AS/400 database clients and LAN-based servers.
Host or AS/400 database clients can involve any LAN-based server within a multisite update. However, this access must be through a DB2 Universal Database Enterprise Edition (EE) Server, DB2 Universal Database Enterprise Extended Edition (EEE) Server or DB2 Connect (EE) Enterprise Edition Server on AIX, OS/2, or Windows NT. SNA must be the protocol used for communication between the host or AS/400 database client and the DB2 Universal Database EE, DB2 Universal Database EEE or DB2 Connect EE for AIX, OS/2, or Windows NT server. Any supported DB2 Universal Database protocol can be used between the DB2 Universal Database EE, DB2 Universal Database EEE or DB2 Connect EE AIX, OS/2, NT server and the LAN-based server which contains the target database. However, TCP/IP must be available. TCP/IP will be used in the event transaction resynchronization is required between the DB2 Universal Database EE, DB2 Universal Database EEE or DB2 Connect EE for AIX, OS/2 or NT server and the server that contains the database.
The supported SNA stacks in a multisite update environment are:
Transaction Manager (TM) Database
Use the first database your application connects to
(1ST_CONN)
Use a cataloged database
Use the first database your application connects to
(1ST_CONN)
Select this option if you want to use the first database to which your application connects.
If the keyword 1ST_CONN is defined for the TM_DATABASE parameter, the first database to which the application connects in the transaction will be used as the transaction manager (TM) database.
The DB2 transaction manager (TM) assigns identifiers to transactions, monitors their progress, and assumes responsibility for transaction success or failure. The information about a transaction is stored in the designated TM database.
Use a Cataloged database
Use this option to select a cataloged database.
Cataloging a database is necessary to enable access to remote databases.
Before a client application can access a remote database, the database must be cataloged on the server node and on any client nodes that will connect to it.
Server Environment page
Specify the types of database servers involved in the
multisite update.
Is TCP/IP the only protocol used between servers
involved in the multisite update? If you are not sure, select No
Specify the types of database servers involved in the multisite
update:
Is TCP/IP the only protocol used between servers involved in the
multisite update? If you are not sure, select No
Sync-Point Manager page
Sync-point manager name (SPM_NAME)
Log file size (SPM_LOG_FILE_SZ)
Log path (SPM_LOG_PATH)
Maximum number of resync agents(SPM_MAX_RESYNC)
Sync-point manager name (SPM_NAME)
This parameter or field identifies the name of the sync-point manager (SPM) for the given instance. This field is pre-filled with the machine's TCP/IP hostname. If TCP/IP is not available on the machine, this field is blank. If you have redefined the machine's TCP/IP hostname, then this new value pre-fills this field.
If SNA is used for communication between the host or AS/400 and the DB2 Connect or DB2 LAN-based server, then this field contains a local (Logical Unit) LU alias. You must ensure that your host or AS/400 can communicate with an LU by this name. If you are required to use a specific LU, then type the LU alias of that LU over the prefilled value.
| Note: | This LU will be created and or verified by DB2 Connect or DB2 Universal Database. |
If TCP/IP is used for communication between DB2 Connect and DB2 for OS/390 Version 5 or later then this field contains a unique name within your network. If you know that the prefilled value conflicts with another DB2 Connect instance (on this or any other workstation) then change the value to be unique.
| Note: | Multisite update using TCP/IP is only supported by DB2 Connect workstations accessing DB2 for OS/390 Version 5 or later servers. |
Log file size (SPM_LOG_FILE_SZ)
The sync-point manager log file size should be large enough to maintain performance, but small enough to prevent wasted space. The size required depends on the number of transactions using protected conversations, and how often COMMIT or ROLLBACK is issued.
This field contains a default value. Optionally, you can adjust this value, by entering a log file size in the field.
Log path (SPM_LOG_PATH)
This parameter specifies the directory where the Sync Point Manager (SPM) logs are written. By default, the logs are written to the sqllib/spmlog directory, which, in a high-volume transaction environment, can cause an I/O bottleneck. Use this parameter to have the SPM log files placed on a faster disk than the current sqllib/spmlog directory. This allows for better concurrency among the SPM agents.
Maximum number of resync agents (SPM_MAX_RESYNC)
This parameter identifies the number of agents that can simultaneously perform resync operations. The default is 20, and the allowable range is 10 to 256.
Accept the default value or enter a value in the allowable range.
