ADSM-L

[no subject]

2015-10-04 17:31:35
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>
  • [no subject], Unknown <=