asnoqacmd: Working with a running Q Apply program for native Oracle targets

Use asnoqacmd on Linux®, UNIX, and Windows to send commands to a running Q Apply program that is replicating natively to Oracle. Run this command at an operating system prompt or in a shell script.

Syntax

Read syntax diagramSkip visual syntax diagram asnoqacmd apply_server= db_nameapply_schema= schemachgparmsparametersloaddonesub= receive_queue: sub_namepruneqryparmsqstatus= receive_queuestatusshow detailsstopstopq= receive_queuestartq= receive_queuestartq=" receive_queue;skiptrans= skiptrans-clause"reinitq= receive_queueresumesub= receive_queue: sub_namespillsub= receive_queue: sub_name

Parameters

Table 1 defines the invocation parameters for the asnoqacmd command.

Table 1. Definitions for the asnoqacmd invocation parameters
Parameter Definition
apply_server=db_name Specifies the name of the Oracle database that contains the Q Apply control tables.
apply_schema=schema Specifies a name that identifies the running Q Apply program that you want to work with.
chgparms Specify to change one or more of the following operational parameters of the Q Apply program while it is running:
  • autostop
  • deadlock_retries
  • dropris
  • logreuse
  • logstdout
  • monitor_interval
  • monitor_limit
  • prune_interval
  • term
  • trace_limit
  • warntxlatency
  • warntxevts
  • warntxreset
Important: The parameters that you are changing must immediately follow the chgparms parameter.

You can specify multiple parameters when you specify chgparms, and you can change these parameter values as often as you wish. The changes temporarily override the values in the IBMQREP_APPLYPARMS table, but they are not written to the table. When you stop and restart the Q Apply program, it uses the values in IBMQREP_APPLYPARMS. Descriptions of asnoqapp parameters includes details about the parameters that you can override with this command.

loaddonesub = receive_queue:sub_name Specify to inform the Q Apply program that a manual load of the target table for the Q subscription is done. Use this parameter only if a manual load is specified for the Q subscription (HAS_LOADPHASE column in the IBMQREP_SUBS table has a value of E). When Q Apply receives the command, it starts processing messages in the spill queue for the Q subscription. When all spilled messages are processed, Q Apply changes the Q subscription state to A (active).
prune Specify to instruct the Q Apply program to prune the IBMQREP_APPLYMON and IBMQREP_APPLYTRACE tables once. This pruning is in addition to any regularly scheduled pruning as specified by the prune_interval parameter.
qryparms Specify if you want the current operational parameter values for the Q Apply program to be written to the standard output (stdout).
qstatus=receive_queue Specify to see an informational message with the status of the queue (active or inactive) and the queue depth (number of messages on the queue).
status Specify to see a message about the state of each Q Apply thread (main, housekeeping, monitor, browsers, and agents).
show details Specify after the status parameter to view a more detailed report about the status of the Q Apply program, with the following information about the Q Apply instance:
  • Whether the Q Apply program is running
  • Time since the program started
  • Location of the Q Apply diagnostic log
  • Number of active Q subscriptions
  • Time period used to calculate averages

The following information is also displayed for each active receive queue:

  • Queue name
  • Number of active Q subscriptions
  • All transactions applied as of (time) (OLDEST_TRANS)
  • Restart point for Q Capture (MAXCMTSEQ)
  • All transactions applied as of (LSN)
  • Oldest in-progress transaction (OLDEST_INFLT_TRANS)
  • Average end-to-end latency
  • Average Q Capture latency
  • Average queue latency
  • Average Q Apply latency
  • Amount of memory in bytes that the browser thread used for reading transactions from the queue
  • Number of messages on the queue (queue depth)
  • Percent fullness of queue
  • Which agent threads are processing transactions
  • Which agent threads are waiting for transactions
  • Which agents are processing internal messages
  • Which agents are initializing
stop Specify to stop the Q Apply program in an orderly way and commit the messages that it has processed up to that point.
stopq=receive_queue
Specify to instruct the Q Apply program to stop processing messages for a receive queue. All in-memory transactions are processed.
startq=receive_queue
Specify to instruct the Q Apply program to start processing messages on a receive queue.
startq=
receive_queue;
skiptrans=
transaction_ID
Specify to instruct the Q Apply program to not apply one or a range of transactions from a receive queue when you start message processing on the receive queue. For details on how to specify the transaction identifier or range of identifiers, see Prompting a Q Apply program to ignore transactions.
reinitq=receive_queue Specify to have the Q Apply program update the attributes for NUM_APPLY_AGENTS and MEMORY_LIMIT from the IBMQREP_RECVQUEUES table for all Q subscriptions that use a particular receive queue. This command works only if the Q Apply program is reading from the receive queue that is named in the IBMQREP_RECVQUEUES table when you issue the command.
resumesub=
recv_queue:sub_name

Specify to resume applying spilled rows to the target table. Specify the name of the receive queue and Q subscription that identify the target table. The spillsub parameter is used to put the Q subscription in a spilling state (S) and the resumesub parameter is used to resume normal operations.

Spill agents apply the rows from the temporary spill queue until the queue is emptied. While the spill agents are processing rows, incoming rows are added to the spill queue. When the spill queue is emptied, the state of the Q subscription is set to active (A) and normal operation resumes.

spillsub=
recv_queue:sub_name

Specify to have all row changes for a Q subscription redirected to a temporary spill queue. You can perform maintenance on the target table such as reorganizing the table. Specify the name of the receive queue and Q subscription that identify the target table.

The temporary spill queue is created based on the definition of your model queue. Ensure that the maximum depth of the queue is large enough to hold the spilled rows until the rows can be applied after resuming operations.