Show TOC

admin healthLocate this document in the navigation structure

Displays the status of the Replication Server.

admin health
Example 1

Displays the status of the Replication Server.

admin health
Mode        Quiesce    Status     Loss Status
-------     -------    -------    -----------
Table 1: Column descriptions for admin health output
Column Description
The state of the Replication Server with regard to recovery. It is one of these values:
  • NORMAL – Replication Server is operating normally.

  • REBUILDING – This is a transient state while Replication Server executes the rebuild queues command.

  • RECOVERY – The Replication Server is in stand-alone mode and the rebuild queues command has been executed.

  • STANDALONE – Replication Server is not accepting or starting any connections. You can only enter this state by starting Replication Server with the -M flag. Exit from stand-alone mode by shutting down the Replication Server and restarting it without the -M flag.

Indicates if the Replication Server is quiesced. It is one of:
  • TRUE – Replication Server is quiesced, that is, all messages have been flushed.

  • FALSE – Replication Server is not quiesced.

Overall status of the Replication Server. It is either:
  • HEALTHY – All threads are executing as expected.

  • SUSPECT – A thread is down and the Replication Server expected it to be running. Or, a thread is in a “Connecting” state. The “Connecting” state means that either the server to which Replication Server is connecting is unavailable and a problem exists, or the Replication Server will connect successfully in a moment and the suspect status is transitory.

You can see threads that are not running by executing admin who_is_down.

Loss Status Data loss status:
  • SUSPECT – Replication Server suspects possible data loss in the queues.
  • DETECTING – Replication Server is checking for data loss in the queues.
  • IGNORING – Replication Server is ignoring any data loss in the queues because you executed the ignore loss command .
  • NO LOSS – Replication Server does not detect any data loss in the queues.
There are corresponding entries in the Replication Server log for the states. For example:
    I. 2012/11/05 21:46:08. Checking loss for NY_RS.ERSSD2 from BEJ_RS.ERSSD1
    Date: Nov  5 2012  2:46:08:576PM
    I. 2012/11/05 21:46:08. Checking loss for SYDNEY_DS.rdb1 from LONDON_DS.pdb1
    Date: Nov  5 2012  2:46:56:583PM
    where NY_RS and BEJ_RS are the primary and replicate Replication Servers respectively, SYDNEY_DS.rdb1 is the replicate data server and database, and LONDON_DS.pdb1 is the primary data server and database.
    Replication Server has identified the possibility of data loss for NY_RS.ERSSD2 from BEJ_RS.ERSSD1.
    Confirmation of data consistency is needed for validation.
    If you see the SUSPECT status, you should check for data consistency between the primary and replicate databases and verify if there is data loss. If there is data loss, you may need to manually fix the loss by resynchronizing the database for example. For:
    • Adaptive Server – see Replication Server Administration Guide Volume 2 > Replication System Recovery > Replicate Database Resynchronization for Adaptive Server.
    • Oracle – see Replication Server Heterogeneous Replication Guide > Oracle Replicate Databases Resynchronization.
    If there is no loss, you can instruct Replication Server to ignore the data loss:
    ignore loss from LONDON_DS.pdb1 to SYDNEY_DS.rdb1
    I. 2012/11/05 21:54:46. Ignoring loss for NY_RS.ERSSD2 from BEJ_RS.ERSSD1

Any user may execute this command.