In a two machine setup ,One way replication is happing by bringing down the repagents on the secondary machine ..
Sometimes the primary machine is up and when the secondary machine comes alive it starting syncing .
if we do admin quiesce_check ,i get the following output
Msg 6145, Level 12, State 0:
Can't Quiesce. Queue 104:0 has not been read out. Write=14.48 Read=13.46
Reader=104:0 DSI 104 WS2SYB.ncdb
the above quiesing takes a lot of time ..
can i do purging of queues on both the machine ? will it have any repercussions ?
I assume you are using one Repserver in this configuration, and based on the names of your connection you have a Warm Standby setup.
You should note that Replication Server was designed for an always-on replication environment, which is different to a synchronized environment. It expects the servers to be always available for the replicate data changes.
If the same record is updated 6 times while the secondary machine is down, it will still replicate and apply all 6 of the data changes in the same sequence to the secondary when it becomes available. This differs from synchronized environments where only the latest version for the record will be read from the primary and applied to the secondary.
The reason that it takes this long, is the fact that is doing all of the data changes against the replicate database server that was done on the primary server over the period of time when the Repagent was inactive, or the Secondary database was unavailable.
Also bear in mind, that should you purge the queues, you will end up with the 2 databases being out of sync with one another. You could also end up with later updates to data that fails, as some of the records that depends on referential integrity could be missing the parent records, which is part of the data that you purged from the queues.
The admin_quiesce_check will only indicate a quiesced server if all inbound transactions have been processed, all outbound messages have been sent, and the are no open transactions active. There should also be no materialization or dematerialization queues for subscriptions.
This usually only applies and is actually only useful when you have more than one Replication Server set up in the same domain, and they send data over routes. This will verify that all data was sent downstream to the next repserver on a route.