Show TOC

rs_ticketLocate this document in the navigation structure

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. SAP® Control Center for Replication or other SAP 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 SAP Replication Server is 15.0 or higher.

Related Information