>Kent,
> Did you just upgrade from an ADSM V1 server ?? If so, this looks real
>familiar. The good news is you don't have to do an AUDIT DB but there are
>steps that need to be taken to correct the problem and they do take a while -
>this happened when our DB was about 6 GB in size and it took 6-8 hours to
>complete the procedure...
>
>
> APAR Identifier ...... II08975 Last Changed ........ 96/10/24
> ANR0104E ASTXN.C (898) ERROR 2 DELETING ROW FROM TABLE
> "AS.VOLUME.ASSIGNMENT" OR "DF.MIGRCANDIDATES"
>
> Symptom ...... IN INFO Status ........... INTRAN
> Severity ................... 4 Date Closed .........
> Component .......... INFOPCLIB Duplicate of ........
> Reported Release ......... 001 Fixed Release ............
> Component Name PC LIB INFO ITE Special Notice
> Current Target Date .. Flags
> SCP ...................
> Platform ............
>
> Status Detail: Not Available
>
> PE PTF List:
>
> PTF List:
>
>
> Parent APAR:
> Child APAR list:
>
>
> ERROR DESCRIPTION:
> ADSM V1 to V2 migration consideration.
>
> 576556401 R210 ADSM AIX V2 server
> 565511901 R210 ADSM MVS V2 server
> 5639a0801 R210 ADSM OS/2 V2 server
> 565511891 R210 ADSM VM V2 server
> .
> (5763SV200 R320 ADSM OS400 V2 Server ***SEE II09359***)
> (5716SV200 R370 ADSM OS400 V2 Server ***SEE II09359***)
>
>
>IBM ADSM development discovered and corrected a minor server
>database problem in the ADSM Version 2 Server Level 0.0/0.0. The
>correction is included in the HSM refresh for the Version 2
>product, which displays a server level of "Level 0.2/0.2"
>or for the OS/2 and VM server at level "0.9/0.9".
>If you are running the "Level 0.0/0.0 or 0.9/0.9" server,
>you may encounter occasional error messages involving the
>AS.Volume.Assignment database object or the DF.MigrCandidates
>object during backup, migration, or reclamation
>The messages usually indicate an "Error 2" deleting updating,
>or inserting new information in the database for the
>AS.Volume.Assignment or DF.MigrCandidates object: msganr0104e
>ANR0104E astxn.c (898) Error 2 deleting row from table
>"AS.Volume.Assignment" or "DF.MigrCandidates"
>
>This problem not only affects users of ADSM V2 at levels below
>0.2/0.2 it can also affect users migrating from and ADSM V1
>server to an ADSM V2 server. Here is a suggestion for checking
>on the V1 server to see if you might have the problem. This
>problem can then be corrected on the V1 server before migrating
>
> For the DF.MigrCandidates table:
>
> 1 - Run Q OCC STG=xxxx to get an occupancy report for the disk
> storage pools.
> 2 - For each disk storage pool determine if a client has between
> 2G and 4G for a single backup filespace or between 2G and 4G
> of archive data in that disk storage pool.
> 3 - For these storage pools change the high migration and low
> migration thresholds to force that data to be migrated to
> the next storage pool in the storage pool hierarchy.
>
> For the AS.Volume.Assignment table:
>
> 1 - Run a Q VOL to get a list of the volumes, their estimated
> capacity and percent utilized.
> 2 - For each of the tape volumes multiply the estimated capacity
> by the percent utilized to determine if the volume currently
> contains between 2G and 4G of data. Since rounding errors
> can occur in the calculation allow for a little under 2G
>
> and a little over 4G as volumes that are suspected as
> having the problem.
>
> 3 - For the tapes that contain between 2g and 4g of data do a
> move data on these volumes.
>
> Make sure that there are no clients backing up data, and no
> expiration or migration activity is occurring since these can
> change the utilization on the tape volumes. This is an
> iterative process since the move data can cause new tapes to
> have between 2G and 4G of utilization.
>
> To permanently correct this problem if it was discovered after
> migrating to V2 do the following:
>
> 1) Obtain and install the latest Version 2 server (Level
> 0.2/0.2 or higher) from your service representative.
>
> 2) Specify a device configuration file in the server options
> file using the DEVCONFIG parameter. Device configuration
> will be written to this file by the server when device
> classes are changed or when the BACKUP DEVCONFIG command is
> specified at the server console or from an administrative
> client.
> example:
>
> On AIX, OS/2, and VM:
> DEVCONFIG /usr/lpp/adsmserv/device.configuration
>
> On MVS:
> DEVCONFIG 'ADSM.DEVICE.DEFS'
>
> Device class information in the device configuration file is
> used by the server when running in stand-alone mode to
> access all device class information required to mount
> volumes.
>
> 3) Start the server and issue the BACKUP DEVCONFIG command to
> copy server device class information to the device
> configuration file.
>
>4) When the server is not active with client, migration,
> reclamation, or backup stgpool operations HALT the server
> using the QUIESCE option:
>
> HALT QUIESCE
>
> This command should be entered at the server console or from
> an administrative client.
>
>5) Use the stand-alone DUMPDB command to copy the server
> database to sequential media:
>
> On AIX, OS/2, and VM:
> dsmserv -t AS.Volume.Assignment dumpdb dev=myclass vol=myvol
>
> On MVS:
>//SERVER EXEC PGM=ANRSERV,
>
> // PARM='/-t AS.Volume.Assignment DUMPDB DEV=MYCLASS VOL=MYVOL'
>
> The table name AS.Volume.Assignment is CASE-SENSITIVE and
> must be entered exactly as specified above. If the problem
> was with the DF.MigrCandidates substitute that table name
> in place of AS.Volume.Assignment in the example. This table
> name is also case sensitive.
>
> 6) Use the stand-alone database load utility to re-load the
> AS.Volume.Assignment object. The following command
> illustrates the syntax to perform this operation:
>
> On AIX, OS/2, and VM:
> dsmserv -t AS.Volume.Assignment loaddb dev=myclass vol=myvol
>
> On MVS:
> //SERVER EXEC PGM=ANRSERV,
> // PARM='/-t AS.Volume.Assignment LOADDB DEV=MYCLASS VOL=MYVOL'
>
> The table name AS.Volume.Assignment is CASE-SENSITIVE and
> must be entered exactly as specified above. If the problem
> was with the DF.MigrCandidates substitute that table name
> in place of AS.Volume.Assignment in the example. This table
> name is also case sensitive.
>
> 7) If the server was halted with quiesce then you can
> safely ignore the message that states an AUDIT is
> required. The AUDIT DB does NOT need to be performed.
>
> 8) Restart the ADSM server and resume normal operation.
>
> The Level 0.2/0.2 (or higher) ADSM server will prevent this
> situation from re-occurring.
>
> We apologize for this error and will assist in an way possible
> with these corrective actions.
>
> LOCAL FIX:
>
>
>
>Good luck !!
>Tim Pittson
>tpittson AT himail.hcc DOT com
>
>
>----------
>From: Kent L. Johnson[SMTP:johnsk6 AT RPI DOT EDU]
>Sent: Thursday, January 09, 1997 12:09 PM
>To: Multiple recipients of list ADSM-L
>Subject: DB Problems?
>
>This morning, I upgraded our ADSM server to v2.1.0.11. I also upgraded Atape
>to 2.5.2.1 and atldd to 2.5.1.0.
>
>We are running ADSM on AIX 3.2.5 with 3 3590s and a 3494.
>
>All went well, with the software installs.
>
>However, I got the following error messages during a space reclaim process.
>
>01/09/1997 11:45:03 ANR0104E astxn.c(1168): Error 2 deleting row from table
> "AS.Volume.Assignment".
>01/09/1997 11:45:03 ANR1181E astxn.c301: Data storage transaction 0:6790909
> was aborted.
>01/09/1997 11:45:04 ANR2183W afmove.c3047: Transaction 0:6790909 was
>aborted.
>01/09/1997 11:45:04 ANR9999D afmigr.c(2523): Space reclamation terminated
>for
> volume 000139 - unexpected result code (88).
>01/09/1997 11:45:04 ANR1092W Space reclamation terminated for volume 000139
>-
> internal server error detected.
>
>I have a bad feeling in my gut about this. Am I about to feel the pain of
>the dreaded "audit db"?
>
>I think I'm going to call this one in to support, but does anybody out there
>have any words of wisdom, encouragement, or insight?
>
>- Kent
>
>--
>Kent Johnson Internet: johnsk6 AT rpi DOT edu
>Unix Systems Programmer (VCC 323) Phone: (518) 276-8175
>Rensselaer Polytechnic Institute Fax: (518) 276-2809
>
>
|
