The parameter SP_OCT_REPLICATE_POSTER is used in cascading replication environment so that the Capture process on the intermediate Shareplex instance does not ignore the changes applied by the Post process on that instance and sends it as intended to the target server. However, at times the enabling of the parameter can result in a loopback of changes back to the source. The solution delves on what can cause this by using a complex replication topology as an example.
General information.
For argument's sake let us say we want to configure a replication between A,B and C in such a way that A and B are set to replicate in a peer to peer manner whereas B is also sending all changes received by it to C. The following schematic describes the setup (where A, B and C are all using the same port numbers):
A< >B >C
To achieve this, we set the parameter SP_OCT_REPLICATE_POSTER to 1 on B. The parameter functions as intended, in that it sends to C all the messages that post from A to B. However, by virtue of this parameter setting and the fact that there is another Capture on B (due to reverse replication from B to A) , the Capture on B does not ignore the Post process on B and starts looping back the transactions to A. This is undesirable. Anytime you have a reverse config on a server that also has the parameter SP_OCT_REPLICATE_POSTER set to 1, there is bound to be a loopback.
The correct way to tackle this problem is to let A and B replicate in a peer to peer fashion on a certain port (say port 2100) and let B and C replicate in a reporting environment on another port (say port 2200). There is no need to configure the parameter SP_OCT_REPLICATE_POSTER on server B as the Capture process on port 2200 will not ignore the actions of Post process on port 2100, while the Capture process on port 2100 would ignore the Post.
An sp_cop cannot have a dual role in both cascading and peer to peer (or high availability).
© 2025 Quest Software Inc. ALL RIGHTS RESERVED. Terms of Use Privacy Cookie Preference Center