When you start a heartbeat, you must enter a user ID and password. The user ID must have authority to create the heartbeat table in the primary database. The user ID and password must also be added to the Replication Server and given create object permission.
The heterogeneous database specific function strings, user-defined datatypes (UDDs), and any necessary class-level translations should be loaded into the Replication Server RSSD.
For example, before setting up a heartbeat between Adaptive Server and Informix, run the following Replication Server scripts against the Replication Server RSSD:
hds_informix_funcstrings.sql
hds_informix_udds.sql
hds_clt_ase_to_informix.sql
hds_clt_informix_to_ase.sql
Because function-string values are cached, you must
restart the Replication Server for the new settings to take effect.
Database connections for non-Sybase data servers are composed of two parts:
The data server name, which will be the name of a Sybase DirectConnect service
The database name
For more information, see “Database connections”.
For Oracle and Informix, the database name is arbitrary, although it must match the value of the Replication Agent rs_source_db configuration parameter.
For Microsoft SQL Server, the database name refers to an actual database, similar to Adaptive Server.
When starting a heartbeat with a Microsoft SQL Server primary database, you should not use the sa user ID. The owner of tables created by sa is dbo. The heartbeat table is created, but RSM Server looks for a table owned by sa and does not find it. You can add dbo as a Replication Server user ID with create object permission, however, and use that user ID to start the heartbeat.
For DB2 Universal Database, the database name is also the name of an actual database, but the concept of a database in DB2 is different than it is for Adaptive Server. The heartbeat table is created in the database that is named in the database connection for DB2, so the user ID used to start the heartbeat must have CREATE TABLE permission in that database.
For example, if the database connection is DB2_directconnect.my_database, the CREATE TABLE command is sent to DB2 through the DirectConnect gateway in the form:
CREATE TABLE RSM_HEARTBEAT (...)
IN DATABASE MY_DATABASE
The user ID used to start the heartbeat is the owner of the heartbeat table. The Maintenance User ID defined on that connection, however, owns the RS_LASTCOMMIT table in DB2. This table is read by RSM Server to determine latency when DB2 is the replicate database. The Maintenance User ID is retrieved automatically from the Replication Server, so there is no need to specify it when you want to check latency. Checking latency does not require a user ID because no tables are created or modified.
You must specify the time difference between the RSM Server and a non-Sybase data server to get meaningful latency values. You can enter this value under the Monitoring tab of the data server’s Properties dialog box. If the non-Sybase data server's clock time is ahead of the RSM Server time clock, enter the difference in seconds as a positive number. Otherwise, enter the difference as a negative number. Remember to take into account time zone differences, if any.
