At times one may want to reorg the table on the secondary node in a peer to peer replication. Since there is an active config on secondary side due to peer to peer replication, and since the reorg results in change in object_id of the table in question (which automatically takes the table out of replication), and moreover there is a Post process active on the secondary, the steps involved in reorg process are a bit involved.
General information.
The following steps will be needed when reorganizing the table on secondary side in a peer to peer environment (all steps are to be carried out on secondary side):
1. Stop post on secondary.
2. Stop user activity on the table. Then do the necessary reorg on secondary table. This step will render the table out of replication.
3. Make a copy of the currently active config file and activate the copy so that the table is brought back in replication. The reason one should refrain from activating the currently active config file is that if anything causes it to fail, then there will be no active config left and a downtime will be required to activate another config. When activating a copy, if there are any issues, at least the previously active config file will prevail (remain active).
4. Resume user activity on the table and start Post on secondary.
The same steps need to be carried out if the reorg is being done on other secondary nodes in this peer to peer environment.
