...ANR0990I Server restart-recovery in progress. ANR0200I Recovery log assigned capacity is 13312 megabytes. ANR0201I Database assigned capacity is 24520 megabytes. ANR0306I Recovery log volume mount in progress. ANR0287W Contents of the page shadow file DBPGSHDW.BDT are not valid. ANR0285I Database page shadowing started using file DBPGSHDW.BDT. ANR0353I Recovery log analysis pass in progress. ANR0354I Recovery log redo pass in progress. ANR0355I Recovery log undo pass in progress. ANR9999D pkthread.c(791): ThreadId<0> Run-time assertion failed: "CmpLsn( *pageLsnP, hdrP->updtLsn ) != LESSTHAN", Thread 0, File dblog.c, Line 1061. ...
There has been no prior posting indicating what that ANR9999D message actually means, but I would guess that it reflects a Recovery Log problem, maybe even that the log (over)filled, as perhaps for lack of scratches when the Dbbackuptrigger level was reached. (Letting spaces fill to their maximum is dangerous in that such boundary conditions typically see little or not testing in most program development, and odd symptoms may result. This is an old TSM level, so may exhibit odd behavior when limits are reached.) Unfortunately, the administrator of that system disregarded best practices and maximized the size of the Recovery Log to 13 GB, which all but eliminates "wiggle room" in being able to add a small increment to get by restart. You might attempt to add a few megabytes to the Recovery Log to see if that allows you to get by the condition. I would set "NOMIGRRECL" and "DISABLESCheds Yes" in the server options file for the restart attempt, to try to eliminate extraneous ingredients. You could also try applying a higher level 4.2 patch level, but I'd be disinclined to. You may have to perform a DB restoral to get past this.
Richard Sims
