sysadmin issue

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.