Unified ICM and Unified CCE Database Troubleshooting: Recovery Process Assert

From DocWiki

(Difference between revisions)
Jump to: navigation, search
m (Bot: Adding {{Template:Required Metadata}})
m (1 revision)
 
(One intermediate revision not shown)
Line 1: Line 1:
-
{{Template:Required Metadata}}
 
== Recovery Process Assert ==
== Recovery Process Assert ==
Line 10: Line 9:
</td></tr><tr><td> '''Recommended Action''' </td><td> Manually remove the out of sequence ToRecoveryKey in the Recovery table on the HDS database.  
</td></tr><tr><td> '''Recommended Action''' </td><td> Manually remove the out of sequence ToRecoveryKey in the Recovery table on the HDS database.  
-
</td></tr><tr><td> '''Release''' </td><td>Release 7.5(1)</td></tr><tr><td> '''Associated CDETS&nbsp;#''' </td><td> None. </td></tr></table>
+
</td></tr><tr><td> '''Release''' </td><td>Release 7.5(1) and 8.0</td></tr><tr><td> '''Associated CDETS&nbsp;#''' </td><td> None. </td></tr></table>
[[Category:Unified ICM/CCE & Hosted, Release 7.5]]
[[Category:Unified ICM/CCE & Hosted, Release 7.5]]
 +
[[Category:Unified CCE, Release 8.0]]

Latest revision as of 23:53, 12 March 2010

Recovery Process Assert

Problem Summary The Recovery process asserts with the following message
Error Message "Fail: Assertion failed: (keytop - keybase) >= 0.0."
Possible Cause The recovery process has written a bad ToRecoveryKey value for a historical table in the Recovery control table. It may happen if the system time has been set back on the Router node. It may also happen if the logger and router on one side of the system start when does not see another side is up and running. It therefore creates its own RecoveryKey instead of synchronize with another side.
Recommended Action Manually remove the out of sequence ToRecoveryKey in the Recovery table on the HDS database.
Release Release 7.5(1) and 8.0
Associated CDETS # None.

Rating: 0.0/5 (0 votes cast)

Personal tools