Running Global Projects
Recovery from Reverse Propagation Errors : Identifying the Problem
Identifying the Problem
When the Transaction database reports that an Update has failed due to Reverse Propagation, the following should be done for the Database element:
•
Query the primary location of the database (Q PRMLOC at the DB element for the database; or Q DB <name> contains this information)
•
Query the Filename ‑ this is useful in identifying the database in the daemon trace.
•
Query the NACCNT, Latest session number, HCCNT and CLCCNT for the database
•
Do the same at the remote location.
•
Decide from this in which direction to RECOVER the database; and recover the database.
•
Note that the new command Q REMOTE <locname> <dbname> FILEDETAILS may be used to gather this information for both locations.
Note:
Note that the RECOVER command is the only command which is allowed to copy the file without a check on the propagation direction.
In general, if the ‘Prevented Reverse Propagation’ message contains ‘Copy’, it is the NACCNT attribute that is the problem. This counter is incremented by a database MERGE, BACKTRACK (but not REVERT ‑ the Appware uses REVERT) or Reconfiguration. In this case, the propagation needs to copy the entire database file. However the copy has failed, because the NACCNT is higher at the secondary location than the primary location.
The other properties are used to control normal database propagation, where only the required sessions and the database header are sent. If the Latest session number is higher at the secondary location than at the primary location, then database recovery is required. If the session numbers are equal, but the HCCNT and CLCCNT attributes are higher at the secondary location than at the primary location, then a database recovery is also required.
Usually, recovery should be made from the Primary location, unless there are good reasons why a secondary location has the correct version of the database.
RECOVER AT <secondary location>
It may be necessary to recover the database at more than one satellite location.
If the secondary database is correct for some reason, then recovery should be from the required secondary location:
RECOVER AT <Primary> FROM <Secondary>. 
This is deliberately replacing the database at the primary location by the version at a secondary location.
1974 to current year. AVEVA Solutions Limited and its subsidiaries. All rights reserved.
AVEVA Logo