ADSM-L

ANR0102E - how to fix?

2000-04-13 18:47:11
Subject: ANR0102E - how to fix?
From: Eric Winters <ewinters AT AU1.IBM DOT COM>
Date: Fri, 14 Apr 2000 08:47:11 +1000
I have a critical problem which is preventing the backup of a production
database.

Software Versions
ADSM 3.1.2.40
AIX 4.3.2

My server is started showing ANR0102E messages yesterday during 3 types of
scenarios.
Either
a) while node Z was backing up (using EBU/Backint) to storage pool A.
b) while storage pool A was migrating.
or
c) while storage pool B was migrating. Storage pool B accepts database
archives from node Z.

Storage pools A and B accept data only from node Z.

All sessions from this node were ended as follows;

04/14/00   07:17:01      ANR0102E asalloc.c(4138): Error 1 inserting row in
 table
                                   "AS.Segments".

04/14/00   07:17:01      ANR0530W Transaction failed for session 3262 for
node
               Z (AIX LF) - internal server error detected.

04/14/00   07:17:01      ANR0403I Session 3262 ended for node Z (AIX LF).

The storage pool B migration problem looks like this

04/13/00   19:02:40      ANR0102E asalloc.c(4138): Error 1 inserting row in
 table
                                   "AS.Segments".

04/13/00   19:02:40      ANR1032W Migration process 230 terminated for
storage pool
                         REDOLOG1_DISK - internal server error detected.

The migrations fail and retry over a period of hours until finally
succeeding.

I've looked back in the ADSM forum archives and found a number of pleas for
help with this problem. The few answers I've seen suggest an audit db is
the way to fix it. As an interim attempt to resolve the problem I deleted
and recreated the disk volumes associated with the two storage pools. This
morning I've come in to find the same ANR0102E messages as yesterday - the
same client sessions being ended, the same storage pools failing to
migrate.

So my questions are;

a) What can I do to fix the problem?
b) If the answer is an audit db, how long might this take for a 3GB
database? And can I audit just part of the database and if so which part is
appropriate? I'll start an online audit db just to see how long it takes
but I'm alarmed at some of the reports at how long this can take.
c) If I can afford to lose the last 2 days backups, might a db restore from
a database backup from before the problem started to show itself be a
sensible solution?

Any ideas people? Your ideas/suggestions are much appreciated.



Regards and thanks,

Eric Winters

Sydney
Australia
<Prev in Thread] Current Thread [Next in Thread>