Re: ANR0209E Page address mismatch detected on recovery log

I want to add a comment.

The point to me is that an audit db FAILS to detect and correct the error.
Period. And thats is not good since we reley on our db to read our tapes.

An unload may discover a corruption and we have the possibilities to audit
or dump our db.
And when thoose option
fails..................................................................
somebody wont get happy and you loose data.

In Antons case I dont know what the solution is besides a restore from a
previus db backup.
"ANR0209E Page address mismatch detected on recovery log volume
ADSMRE.RCVLOG2B,
ANR0209E logical page 0 (physical page 18688); actual: 129024."

In an other case like this below, is something you DONT want to see.
The TSM server starts and you can do backup, restores, migration and
reclamation etc. Some backup are sucessfull and some fails with:
15-02-2005 21:15:36      ANR0406I Session 1941 started for node ST-WZ07
(WinNT)
                          (Tcp/Ip 143.97.143.52(1449)). (SESSION: 1941)
15-02-2005 21:15:37      ANR0102E imbkins.c(4103): Error 1 inserting row in
table
                          "Backup.Objects". (SESSION: 1941)
15-02-2005 21:15:37      ANR0530W Transaction failed for session 1941 for
node
                          ST-WZ07 (WinNT) - internal server error detected.
                          (SESSION: 1941)
(Cleanup backup groups)
Unload DB failed
Dump DB ok
Load DB failed
Audit DB....... = restore db later on....
ANR4177I AUDITDB: Primary backup entry for an object (0.57126454) cannot be
found - entry will be deleted.
ANR4177I AUDITDB: Primary backup entry for an object (0.57128288) cannot be
found - entry will be deleted.
ANR4306I AUDITDB: Processed 72911226 database entries (cumulative).
ANR4306I AUDITDB: Processed 73139460 database entries (cumulative).
ANR4306I AUDITDB: Processed 73325165 database entries (cumulative).
ANR4306I AUDITDB: Processed 73441006 database entries (cumulative).
ANR9999D imaudit.c(776): ThreadId<0> Audit of one or more secondary tables
failed, objRc=0, expRc=0, grpRc=4
Callchain of previous message: 7C59BBF3  RaiseException()+56 <-
1000F969  tsmInitializeServer()+8139 <- 104E6399  outTextf()+1469 <-
10222EBB tsmInitializeServer()+21B68B <-
ANR4142I AUDITDB: Database audit process terminated in error.

Wort a note: Anton used TSM 5.2.1.0 on an Z/OS. In the other was a w2k
server with 5.2.2.5 involved.

//Henrik






                    asr AT UFL DOT EDU
                    Sent by:             To:     ADSM-L AT VM.MARIST DOT EDU
                    "ADSM: Dist          cc:     (bcc: Henrik Wahlstedt)
                    Stor Manager"        Subject:     Re: ANR0209E Page address 
mismatch detected on recovery log
                    <ADSM-L AT VM DOT MA
                    RIST.EDU>


                    2005-03-30
                    18:04
                    Please
                    respond to
                    "ADSM: Dist
                    Stor Manager"






==> On Wed, 30 Mar 2005 07:25:17 -0500, Richard Sims <rbs AT BU DOT EDU> said:


> I rue the day that IBM started encouraging customers to take their TSM
> system out of service and run salvage utilities to reorganize the db, as
> situations like this inevitably result, particularly as these utilities
are
> not subject to the same development intensity and scrutiny as mainline
TSM
> code. This has been a very poor decision on someone's part in IBM, to
foster
> this kind of risky undertaking in enterprise sites as though it were a
> casual, risk-free activity. Some vendor thinking is just unfathomable.


I don't share Richard's tropism away from the offline utilities.  However,
embarking on any such process without a DB incremental immediately previous
is, well, foolhardy.

I think of the motorcyclists I sometimes see, on the highway with shorts, a
tank-top, flip-flops and sunglasses in leiu of helmet.

If you run regular DB fulls, and cut incrementals before you do anything
scary, you limit your downside to inconvenience and a setback schedule.  I
highly recommend the practice.


BTW, I've promoted my DB reload procedure to our main site.  Thanks greatly
to those of you who commented.  I continue to solicit experiences of before
and after sizes, and comments about behavior before and after.


http://open-systems.ufl.edu/services/NSAM/maint_docs/db_un_reload.html




- Allen S. Rout




-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.