Anyone have a fix for a corrupt recovery log? Whenever I want to start DSMSERV (and with AUDITDB) I get this; ANR7800I DSMSERV generated at 16:11:39 on Apr 25 2000. ANR7801I Subsystem process ID is 895. ANR0900I Processing options file dsmserv.opt. ANR0990I Server restart-recovery in progress. ANR0200I Recovery log assigned capacity is 3616 megabytes. ANR0201I Database assigned capacity is 48084 megabytes. ANR0306I Recovery log volume mount in progress. ANR0353I Recovery log analysis pass in progress. ANR0354I Recovery log redo pass in progress. ANR9999D dbrec.c(701): Error applying update to database page 1132780; Page Lsn = 930689.68.4000, Log Record Update Lsn = 930682.38.2617. ANR7824S Server operation terminated. ANR7823S Internal error DBREC106 detected. ANR9999D Trace-back of called functions: ANR9999D 0x00074880 pkAbort ANR9999D 0x0031F994 RestartRedo ANR9999D 0x0031DAA4 DbRestartRecovery ANR9999D 0x00315394 dbInit ANR9999D 0x0011ECDC admStartServer ANR9999D 0x00121A58 admAuditServer ANR9999D 0x00065164 AuditServer ANR9999D 0x0006234C main ANR9999D 0x000614B8 _start ANR7820S Server thread 1 terminated in response to program abort. ANR7820S Server thread 2 terminated in response to program abort. ANR7820S Server thread 3 terminated in response to program abort. ...and so on Which makes things more sticky is I am working in roll-forward mode (learnt my lesson on that one). Could there be a way of firing it up without using the logs? Would I have to format the logvolumes? I don't think recovering the database is going to work as the database does not look to be the fault. Cheers, Suad -- BTW. Solaris 2.6, TSM 3.7.3
