| Mode |
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.
|
| Quiesce |
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.
|
| Status |
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: - DETECTING
–
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
qid=0000000000018ddb0000142f00290000142f00140000a10000f362ed0000000000000005
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
qid=000000000000baf100000b58008800000b5800860000a10000f39b2f0000000000000003
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.
- SUSPECT
–
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
- IGNORING
–
I. 2012/11/05 21:54:46. Ignoring loss for NY_RS.ERSSD2 from BEJ_RS.ERSSD1
|
