rs_ticket

A stored procedure in the primary database that monitors Replication Server performance, module heartbeat, replication health and table-level quiesce.

Syntax

rs_ticket h1 [, h2 [, h3 [, h4]]]

Parameters

h1 [, h2 [, h3 [, h4]]] – Header information in short varchar strings.

Examples

Example 1 – Executes rs_ticket at regular intervals:
```
Exec rs_ticket 'heartbeat', 'beat-sequence-number'
```
Example 2 – To measure performance, execute the following from the primary database:
```
Exec rs_ticket 'start'
Execute replication benchmarks
Exec rs_ticket 'stop'
```

Usage

The rs_ticket stored procedure has a ticket version number V=2 and a ticket size of 1024 bytes.
If your application understands only version 1 ticket, call rs_ticket_v1 to generate ticket in version 1 format. The rs_ticket_v1 syntax is:
```
rs_ticket_v1 h1 [, h2 [, h3 [, h4]]]
```
rs_ticket executes the following command:
```
rs_marker 'rs_ticket rs_ticket_param'
```
To avoid issuing wrongly formatted rs_marker and to enforce the rs_ticket_param standard, you should invoke rs_ticket instead of rs_marker. If you call rs_marker directly and form an incorrect rs_marker subcommand, the Replication Server refuses the rs_marker and shuts down the RepAgent connection. In this case, you must skip rs_marker from the transaction log, which may cause data loss.
The Replication Server EXEC, DIST, RSI, and DSI modules parse and process rs_ticket subcommand:
- When EXEC processes rs_ticket, it appends a timestamp, and then the total bytes received from RepAgent after rs_ticket_param. An EXEC timestamp takes the form ''EXEC(spid)=mm/dd/yy hh:mm:ss.ddd''. The byte information is ''B(spid)=ddd''. EXEC writes rs_ticket back to inbound queue.
- When DIST processes rs_ticket, it appends another timestamp to rs_ticket_param. A DIST timestamp takes the form ''DIST(spid)=mm/dd/yy hh:mm:ss.ddd''.
- When RSI processes rs_ticket, it appends yet another timestamp to rs_ticket_param. An RSI timestamp takes the form ''RSI(spid)=mm/dd/yy hh:mm:ss.ddd''.
- When DSI processes rs_ticket, it appends yet another timestamp to rs_ticket_param. A DSI timestamp takes the form ''DSI(spid)=mm/dd/yy hh:mm:ss.ddd''.
There are no subscriptions for rs_ticket. DIST does not send rs_ticket to DSI unless there is at least one subscription from the replicate site.
rs_ticket is lightweight and nonintrusive and can be used in test environments as well as production environments.
rs_ticket lets you know, without quiescing the Replication Server, when the data has been completely flushed out of replication path.
The movement of rs_ticket is tracked by the EXEC, DIST, RSI, and DSI threads through RSTicket counter. Each thread has one RSTicket counter which is increased by one whenever the corresponding thread receives rs_ticket. This counter is never reset.

You can monitor the module that rs_ticket has reached by sampling the RSTicket counters. RMS or other Replication Server monitoring tool uses these counters to produce EXEC, DIST, RSI, and DSI heartbeat.

You can also monitor the health of the replication path by sending an rs_ticket at primary and checking the RSTicket counters. If RSTicket counter of a module is not increasing, it shows that replication path at this stage is broken.
You must not mark rs_ticket for replication.
Use rs_ticket only when Replication Server is 15.0 or higher.