Show TOC

sysadmin issue_ticketLocate this document in the navigation structure

Injects an rs_ticket marker into an inbound or an outbound queue.

Syntax
sysadmin issue_ticket {,<q_number>} |{,<ds_name>, <db_name>},[<,q_type>], <h1> [, <h2> [, <h3> [, <h4>]]] [,<v>]
Parameters
ds_name

Name of the data server on which the database resides.

db_name

Name of the database.

q_number

Identifies the stable queue.

q_type
Identifies the stable queue type. Values are 0 for outbound queues and 1 for inbound queues. q_type is optional, if it is not specified, then the default queue type is inbound queue.
h1,h2,h3

Each parameter contains from 1– 10 characters; these parameters must follow the database identifier naming convention since the parameters are used as identifiers, in any way you see fit. The header parameter must not start with a number and must not be a reserved word. If number is chosen to be a header parameter, it must be within quotes. For example, ‘1’.

h4

Contains from 1– 50 characters. Like h1, h2, and h3, you can use this parameter as an identifier in any way you see fit.

v

Identifies the version number of the rs_ticket. It should be either 1 or 2. The default value is 2, if not specified.

Examples
Example 1
This command injects one transaction in to the Replication Server inbound queue. 
sysadmin issue_ticket, <103>, 'start'
go

where:

<103> is the <q_number> of a logical connection to Replication Server.

Example2
This example injects a transaction in to the Replication Server outbound queue.
sysadmin issue_ticket,<103>,<0>,'<t6>'
go

where:

<103> is the q_number, <0> is the outbound queue type, and <t6> is the h1 header of a logical Replication Server.

Usage
When using the sysadmin issue_ticket command:

  • You must have at least one subscription from the replicated database in Replication Server. If there are no subscriptions, the Distributor (DIST) module will not send the rs_ticket marker to the corresponding Data Server Interface (DSI).

  • The timestamp for the primary database (PDB) and EXEC module is an arbitrary value in the injected rs_ticket marker.

  • You can specify a stable queue only by using <q_number>, <q_type> or <ds_name>, <db_name>, and <q_type>. In a warm standby environment, an inbound queue is related to the logical connection, and Replication Server does not have inbound queue for the standby database. When using sysadmin issue_ticket for warm standby:

    • If the user specifies the stable queue by an existing logical connection or the physical connection for the active database, the specific rs_ticket marker is written into Replication Server inbound queue. The corresponding rs_ticket record can be found in both the replicate database and the standby database at the primary site.

      Note In a two Replication Server(RS) DR setup, if the primary server is down, then bring down both primary Adaptive Server Enterprise (ASE) and RS. In thiss case, ensure that the outbound queue is cleared before client can failover to DR ASE. To do that, you need to inject a ticket to the outbound queue. When the ticket is found in the rs_ticket_history table, clients can failover.

    • If the user specifies the stable queue by an existing physical connection for the standby database, an error message appears indicating that no such inbound queue exists.