The biggest challenge in implementing a successful heterogeneous replication system is accommodating the unique characteristics of data servers that are supplied by different vendors. Regardless of the type or brand of a data server, there are issues that are specific to the data server’s role in the replication system. And when a single data server acts as both a primary data server and a replicate data server (bidirectional replication), there are still more issues to consider.
The following primary database issues must be addressed in a successful heterogeneous replication system:
The requirements of the Replication Agent and the intrusions and impacts of the Replication Agent on the data server. For example, some Replication Agents create and use database objects in the primary database to maintain a transaction log.
The access and permissions required in the data server for other replication system components. Both the primary Replication Server and the Replication Agent for a database must have user IDs and passwords defined in the database with appropriate permissions to access primary database objects.
The connectivity required to support communications between the data server and other replication system components. Replication Agents use either the native communication protocol of the data server, ODBC protocols, or JDBC protocols to communicate with the primary database. Replication Server may require a database gateway to communicate with a data server.
The specific limitations on replication from the particular data server. For example, some Replication Agents restrict the configuration options of some data servers. Replication Server may impose size limitations on some native datatypes in some databases.
How replication definitions stored in the RSSD are used by the Replication Agent for the particular data server. For example, both Replication Server and Replication Agents are case sensitive in identifying database object names, but some databases are not.
The datatype conversions that may be required when replicating transactions from one particular data server to another type of data server. For example, almost every type of data server has a unique way of representing temporal data. The TIMESTAMP datatype in one database may need to be “translated” to be stored as a datetime datatype in another database.
The replication system management issues specific to the particular data server. For example, different data servers allow different system management options.
For more information about specific primary database issues for specific databases, see “Primary data servers”.
The following replicate database issues must be addressed in a successful heterogeneous replication system:
The requirements of the DirectConnect database gateway for the particular database server. The DirectConnect access services must be configured to work with the replicate database server and Replication Server.
The access and permissions required in the data server for the replication system to apply transactions to the replicate database. Both the replicate Replication Server and the DirectConnect gateway for a database must have user IDs and passwords defined in the database, with appropriate permissions to access replicate database objects.
The connectivity required to support communication between the replicate data server and other replication system components. DirectConnect gateways use either the native communication protocol of a data server, or standard ODBC or JDBC protocols to communicate with a replicate database. Replication Server generally requires a database gateway to communicate with a non-Sybase data server.
In the case of DB2 Universal Database on OS/390,
Replication Server can use Sybase MainframeConnect for DB2 UDB to
connect directly to the mainframe in a “gatewayless” system.
This eliminates the need for a database gateway. Replication through
a gatewayless connection requires a TCP/IP connection to
the mainframe. For more information about DB2 for OS/390
gatewayless connections, see “DB2 Universal Database replicate data servers”, and the Sybase Open ServerConnect™ Installation
and Administration Guide.
The limitations on replication into the particular data server. For example, Replication Server imposes limitations on some native datatypes in some databases.
The intrusion and impact of the database objects required to support Replication Server operations. Replication Server requires two tables and may require some stored procedures to manage a replicate database.
The replication system management issues specific to the particular data server. For example, different data servers allow different system management options.
For more information about specific replicate database issues for specific databases, see “Replicate data servers”.
In a heterogeneous replication system, in which the primary and replicate data servers are different types, the data servers might not support the same character sets. In that case, replication system components must perform at least one character set conversion (from the primary data server’s character set to the replicate data server’s character set).
Even in a homogeneous replication system, in which both primary and replicate data servers are the same type, character set conversions might be required if replication system components reside on more than one type of platform.
Character set problems can produce data inconsistencies between the primary database and the replicate database. To avoid character set problems, you must either:
Use the same character set on all servers and platforms in the replication system, or
Use compatible character sets on all servers and platforms in the replication system, and configure replication system components to perform the appropriate character set conversions.
By default, the Java Virtual Machine (JVM) under which a Mirror Replication Agent instance runs, finds your system’s default character set. The type of character data that Mirror Replication Agent can handle is determined by the character set, also known as the encoding. Unless you want to override the default character set that the JVM finds on your system, you do not have to explicitly set the character set-related environment variable.
To support overriding the default character set, all of the executable scripts (or batch files) in the Mirror Replication Agent /bin directory refer to an environment variable named RA_JAVA_DFLT_CHARSET. You can set this environment variable to use the character set you want. However, the character set you specify must be the character set configured on the primary database. For a list of valid Java character sets, see Supported Encodings on the Internationalization page under Documentation for the J2SE 1.4.2 JDKhttp://java.sun.com/j2se/corejava/intl/index.jsp.
All Mirror Replication Agent instance RUN scripts also reference the RA_JAVA_DFLT_CHARSET environment variable.
If you are using Replication Server to replicate a number
of different character sets, you must configure it for UTF8.
You can override the system default character set by either:
Setting the value of a system variable named RA_JAVA_DFLT_CHARSET in your environment and using the ra utility to start the Mirror Replication Agent instance, or
Setting the value of the RA_JAVA_DFLT_CHARSET variable in the Mirror Replication Agent instance RUN script and using the RUN script to start the Mirror Replication Agent instance.
If you start a Mirror Replication Agent instance by invoking the ra utility, you can override the value of the RA_JAVA_DFLT_CHARSET system variable in your environment to specify the character set.
If you start a Mirror Replication Agent instance by invoking the instance RUN script (or batch file), you can edit the instance RUN script to specify the default value of RA_JAVA_DFLT_CHARSET and specify the character set you want to use.
For more information on setting and overriding the default character set, see Chapter 2, “Setup and Configuration” in the Sybase Replication Agent Administration Guide.
