When the admin logical_status command indicates that there is no operation in progress, or when the wait for switch command returns an isql prompt, you can restart client applications in the new active database.
Client applications must wait until Replication Server switch to the new active database is complete before they begin executing transactions in the new active database. You should provide an orderly method for moving clients from the old active database to the new active database. See “Setting up clients to work with the active data server” for more information.
If the old active database failed, determine if any transactions were not transmitted to the new active database. Such transactions are called paper-trail transactions if there is an external record of their execution.
When you switch from an active to a standby database, all committed transactions in the inbound queue are applied to the new active database before the switch is complete. However, it is possible that some transactions that committed at the active database before the failure were not received by Replication Server and, therefore, were not applied to the standby database.
When you switch the active and standby databases, you can re-execute the paper-trail transactions in the new active database. If there are dependencies, you may need to re-execute the paper-trail transactions before you allow new transactions to execute. Be sure to execute the paper-trail transactions using the original client’s login name, not the maintenance user login name.
If you bring the old active database online as the new standby database, you must first reverse the paper-trail transactions so they will not be duplicated in the standby database.
