start heartbeat

Sets up and starts a heartbeat process from a specified primary connection to a specified replicate connection.

Syntax

start heartbeat from pds.pdb to rds.rdb
	[set interval [to] hb_interval]
	[set maximum rows [to] max_rows]
	[do not load rs_ticket_report]

pds.pdb – The name of the primary data server and database. The name must be associated with an existing primary connection.
rds.rdb – The name of the replicate data server and database. The name must be associated with an existing primary and replicate, or replicate-only connection.
hb_interval – The interval in seconds that the RMS executes the rs_ticket command. The default is 60 seconds.
max_rows – The maximum number of rows that the rms_ticket_history table can contain. The RMS tests the size of the table at every heartbeat interval. If the size is greater then max_rows, the RMS removes the oldest entries. The RMS deletes 10% of the max_row size rows in the table. The default is 5000 rows.
do not load rs_ticket_report – If this flag is included, the RMS does not load the rs_ticket_report and you can provide a custom stored procedure instead. You must provide an rs_ticket_report procedure that loads the rms_ticket_history table with the required information.

Example 1 – Sets up and starts the heartbeat process, then executes the rs_ticket procedure every 60 seconds; limits the rms_ticket_history table to 5000 rows:
```
start heartbeat
      from inventory_pds.vendor to inventory_dss.vendor
```

To set up the heartbeat, the RMS uses the user name that was provided when the server was added to the domain. The user names must have the correct permissions to create the table and stored procedure at the replicate database, configure the DSI at the replicate Replication Server, and execute the rs_ticket stored procedure at the primary database.
The RMS can create only one heartbeat between a primary and replicate database. The RMS generates an error if a heartbeat already exists.
The RMS does not delete an rms_ticket_history table if one already exists, but assumes that another heartbeat from a different primary database is already executing.
The RMS assumes that the replicate database is set-up to receive data from the Replication Server and it neither checks for subscriptions nor generates a new one. Replication Server version must be at least 12.6.
The Replication Server requires that the replicate database must have at least one subscription against a table, stored procedure, or database before the replicate Replication Server sends the rs_ticket information. The subscription does not have to be against any specific table or stored procedure. In case there is no subscription, rs_ticket functions in a warm-standby environment.