Scheduled Update Failures
- Last UpdatedFeb 07, 2022
- 3 minute read
Generally a scheduled update will always succeed with a number of database failures
Failure messages will contain detailed reasons:
In this case, the databases could not be propagated, since the secondary database had a higher compaction number than the primary database. This may happen when a remote merge is executed without stopping scheduled updates. Normally it will be necessary to recover the database to resolve this error.
Prevention of Reverse propagation may also be reported in the following situation ‑ a satellite has executed a direct update (UPDATE DIRECT from the command-line) with a non-neighbor satellite. The next scheduled update with the intermediate location will report ‘Prevented reverse propagation’. In this case, scheduled updates will eventually resolve the situation.
The following table summarizes Failure messages that can be generated for Scheduled updates. This does not include all possible failures that may be generated from failed file copies.
|
Error No |
Symptom |
Reason |
|---|---|---|
|
- |
Scheduled update was suppressed |
Attribute LNOUPD set TRUE on LCOMD to disable scheduled update |
|
- |
Remote location CAM is unavailable |
Daemon for CAM is not available; |
|
- |
Update will not report results to CAM |
this failure cannot be reported at CAM ‑ usually due to location unavailable |
|
612 |
Prevented reverse copying |
Secondary location has a higher compaction number than the primary location. Database may need recovering |
|
611 |
Prevented reverse update |
Secondary location has a higher session number than the primary location. Database may need recovering |
|
613 |
Unable to check update direction ‑ update skipped |
The Global database is in use. This is normally temporary, due to another command. |
|
610 |
Update skipped ‑ cannot get local details for <database> |
The specified database is in use at the current location. This is normally temporary, due to another command using the database. |
|
610 |
Update skipped ‑ cannot get remote details for <database> |
The specified database is in use at the remote location. This is normally temporary. |
|
610 |
Update skipped ‑ cannot get local/remote details for CAM system DB |
In the case of system databases, if one system db is in use, then the update will fail for any system db (they all have the same DB number) |
|
- |
Failed database copy ‑ file may be in use at HUB |
Unspecified COPY failure ‑ compaction numbers are still out of step. If the copy destination was the update location, then additional failures will give further detail. |
|
619 |
Cannot verify success - may be failed COPY |
Unspecified COPY failure ‑ compaction numbers are still out of step. No further detail is available. |
|
- |
Missing remote/local file. Prevented reverse propagation. |
System databases only. A system database file is missing at the specified location. This may need to be recovered. |
|
615 |
Update failure ‑ possibly database error |
A database error was encountered during the update. Full detail will be in the daemon log |
|
614 |
Update failure ‑ database pages are not contiguous |
The database file is corrupt at the destination. This database must be recovered from its primary location. |
|
628 |
Failed database copy. File in use. Cannot remove |
Database file is locked and overwriting is disabled. File copy has failed to commit the .admnew file. The .admnew file will be retained for later use. |
|
630 |
Failed database copy - update for previous extract failed |
Prevention of an inconsistent extract hierarchy. A file copy for an extract db has not been attempted because of an update failure on another extract of the same database. (Not fully working at Global 2.4) |