This section describes the primary database issues and considerations specific to the DB2 Universal Database server on an OS/390 platform in a Sybase replication system.
As a primary data server, DB2 interacts with the Replication Agent for DB2 UDB for OS/390 (Replication Agent for DB2 UDB).
The Replication Agent identifies and transfers information about data-changing operations or transactions from a DB2 primary data server to a primary Replication Server.
The Replication Agent interacts with the primary Replication Server and with the RSSD of the primary Replication Server, if so configured.
This book describes how to use Replication Agent for
DB2 UDB for OS/390 version 12.6. If you have a different
version of Replication Agent for DB2 UDB, refer to the appropriate
documentation for that product.
Two user IDs must be created in DB2 to facilitate its operation as a primary data server:
LTMADMIN user – a TSO user, optionally named LTMADMIN, to:
Install, start, and stop the Replication Agent for DB2 UDB
Manage the Replication Agent system tables on DB2
The LTMADMIN user must have ALTER TABLE authority on any DB2 table to be marked for replication. This user ID issues an ALTER TABLE DATA CAPTURE CHANGES command on a primary table that is marked for replication.
The LTMADMIN user must have READ permission on the DB2 log files.
Replication Server Maintenance User – the user ID specified in the Replication Server create connection command for the primary database.
Any updates applied to the primary database by the Maintenance User are ignored for replication, unless the value of the LTM for MVS LTM_process_maint_uid_trans configuration parameter is Y.
LTM for MVS is a component of Replcation Agent for DB2
and the other component is the DB2 log reader.
Because the Maintenance User ID may be a user ID that can perform updates on DB2, it must conform to OS/390 user ID restrictions.
The performance and operation of DB2 primary data servers in a Sybase replication system might be affected as follows:
The DB2 transaction log is affected in the following ways:
Replication requires a before and after image of each row that is changed. When you mark a primary table for replication, the table is altered with the DATA CAPTURE CHANGES clause. As the number of tables marked for replication increases, so does the DASD space requirement for the DB2 active log data sets.
Using Replication Agent for DB2 UDB increases the amount of data stored in DB2 logs. The size of the increase depends on the number, type, and size of the primary tables, and the types of transactions replicated. For example, update transactions require both before and after images, and they include all of the columns in a row, even if those columns do not change. For more detailed information, see the Replication Agent for DB2 UDB for OS/390 documentation.
Two Replication Agent system tables are created in the DB2 primary database when the Replication Agent is installed:
LTMOBJECTS contains a row for each primary table marked for replication. Its size depends on the number of tables marked for replication.
LTMLASTCOMMIT stores information about the most recent replicated transaction successfully committed in the replicate database. The size changes according to the number of primaries that are replicated into DB2, when it is a replicate database.
Unless the DB2 primary database also serves as a replicate
database (in bidirectional replication), you can remove the LTMLASTCOMMIT table from
the primary database.
Each Replication Agent for DB2 UDB started task can process only one DB2 log. Replicating transactions from multiple DB2 subsystems (or from multiple data-sharing members in a data-sharing environment) requires one Replication Agent-started task for each DB2 subsystem (or data-sharing member).
The following DB2 utilities may jeopardize replication integrity if they are executed:
LOAD LOG NO
RECOVER
REORG with RECOVER
The DB2 LOAD LOG YES utility is supported
in Replication Agent for DB2 UDB.
Replication Agent for DB2 UDB requires the following to connect to a DB2 primary data server in an OS/390 environment:
A valid user ID (the LTADMIN user identified earlier) must be defined to OS/390 and granted permission to the correct DB2 packages. The Replication Agent for DB2 UDB uses this user ID to log in to DB2. This user ID must have the following permissions:
CREATE authority for the Replication Agent for DB2 UDB system tables
ALTER TABLE authority on all tables marked for replication
READ authority on the DB2 log data sets
Replication Agent for DB2 UDB jobs must have their JCL modified to execute with the correct accounting, user_id, DB2 logs, and DB2 subsystem libraries identified.
Replication Agent for DB2 UDB requires the following to connect to the primary Replication Server:
To support a TCP/IP connection between the Replication Agent and the primary Replication Server, you must provide the OS/390 system with information about the Sybase servers and TCP/IP host addresses in your replication system. You do this by editing the SYGWHOST macro, located in the XCPHPING member in the hlq.JCL data set.
The SYGWHOST macro does the following:
Serves as a directory containing network addresses and other information that controls how the Replication Agent connects to other servers
Configures the Open Client component of LTM for MVS to use the MVS TCP/IP protocol for a connection between the Replication Agent and the primary Replication Server
You must create a SYGWHOST macro
entry for each primary Replication Server that receives transactions
from a DB2 subsystem in the OS/390 system, and also for
any RSSDs that Replication Agents for DB2 are configured to use.
You can define any number of Replication Servers in the SYGWHOST macro.
The values of the following LTM for MVS configuration parameters must be set as described so that the Replication Agent for DB2 UDB can connect to the primary Replication Server:
Communications_Protocol – must be set to IBMTCP for connectivity to the Replication Server.
RS – the name of the host machine on which the primary Replication Server resides.
RS_user – the user ID that the Replication Agent uses to log in to the primary Replication Server. This user ID must be defined and granted connect source permission in the Replication Server.
The RS_user should not be
identical to the Maintenance User ID specified in the Replication
Server create connection command for the primary
database.
RS_pw – the password for the user ID that the Replication Agent uses to log in to the primary Replication Server.
RS_source_db – the logical database name of the primary database specified in the Replication Server database connection. Sybase recommends using the DB2 subsystem or group name.
RS_source_ds – the MVS system that contains the DB2 primary database. This value can be arbitrary, as long as it matches the data_server value specified in the Replication Server create connection command for the primary database.
The Replication Agent for DB2 UDB is a mainframe OS/390 application. It consist of two tasks that run simultaneously in a single OS/390 address space:
Sybase Log Extract – continuously scans the DB2 active and archive logs for data-changing operations on primary tables.
LTM for MVS – receives replicated transactions from Sybase Log Extract, converts them to Log Transfer Language (LTL), and then sends them to the primary Replication Server.
One Replication Agent for DB2 UDB started task is required for each DB2 log from which transactions will be replicated.
All Replication Agent installation and configuration issues are described in the Replication Agent for DB2 UDB Installation Guide for OS/390. However, the following items may need further attention in a heterogeneous replication system:
All configuration parameter values in the LTM for MVS configuration file are case sensitive. Be careful when specifying the values of the RS_source_ds and RS_source_db parameters, as the Replication Server is also case sensitive. If the same case is not used in both Replication Agent and Replication Server parameters, the connection does not succeed.
The LTM for MVS LTM_process_maint_uid_trans configuration parameter controls whether the Replication Agent sends transactions performed by the Maintenance User to the primary Replication Server. The Maintenance User ID is defined in the Replication Server create connection command for the primary database.
In a bidirectional replication environment (replicating both into and out of the same DB2 region), the value of the LTM_process_maint_uid_trans parameter should be set to N. If it is not, transactions replicated to another site could return to be applied at the originating site, creating an endless loop.
Replication Agent for DB2 UDB requires the following to connect to the Replication Server System Database (RSSD) of the primary Replication Server:
If you set the value of the LTM for MVS Use_repdef configuration parameter to Y, you must provide values in the SYGWHOST macro for the data server that contains the RSSD for the primary Replication Server.
The values of the following LTM for MVS configuration parameters must be set as described so the Replication Agent can connect to the RSSD of the primary Replication Server:
RSSD_server – the name of the host machine for the data server that contains the RSSD.
RSSD_database – the database name of the RSSD.
RSSD_user – the user ID that the Replication Agent uses to log in to the RSSD. This user ID must be defined and granted select permission in the RSSD.
RSSD_pw – the password for the user ID that the Replication Agent uses to log in to the RSSD.
The LTM for MVS Use_repdef configuration parameter controls whether the Replication Agent sends Log Transfer Language (LTL) that contains only the columns specified in a replication definition, or all of the columns in the DB2 primary table.
When the value of the Use_repdef parameter is set to N, the Replication Agent sends LTL with data for all of the columns in the DB2 primary table. When the value of the Use_repdef parameter is set to Y, the Replication Agent sends LTL with data for only the columns specified in the replication definition.
By sending data for only the columns needed for the replication definition, network traffic is reduced, which can improve performance.
If you set the value of Use_repdef to Y, you can use other LTM for MVS parameters, such as Minimal_cols and Suppress_col_names, to enhance Replication Agent performance. See the Replication Agent for DB2 UDB Installation Guide for OS/390 for more information.
The LTM for MVS Date_in_char configuration parameter controls whether the Replication Agent sends values in DB2 DATE columns as default CHAR(10) character strings, or converts them to the Sybase datetime format.
In general, if the value of the Date_in_char parameter is set to N, all of the corresponding datatypes in replication definitions for DATE columns must specify the Sybase datetime datatype.
See the Replication Agent for DB2 UDB for OS/390 User’s and Troubleshooting Guide for a complete description of the Date_in_char parameter. See the Replication Server Administration Guide for a complete description of UDDs and their use.
If you use any date- or time-related UDDs in a replication
definition, Sybase recommends that you configure the Replication
Agent to send data to the Replication Server in the format that
is native to the primary database. Sybase prefers to not have
the Replication Agent perform any datatype translations.
In general, the Replication Agent for DB2 UDB should not perform datatype translations. However, when all of the replicate data servers require the same translation, to save processing time, it is probably better to perform the translation once at the Replication Agent, rather than at each replicate database DSI.
Replication Manager (RM) does not manage or monitor the Replication Agent for DB2 UDB for OS/390.
