It sounds like you may be encountering the following scenario:
Several of your tapes are near end-of-volume. The backup trys to
store data on these tapes, hits end-of-volume, marks the tapes
as full, but then aborts its transaction because it runs out of storage
space. Because the transaction aborts, the database update indicating that
your tapes are full is is rolled-back. The real question would then be
why you are running of of storage space. Before calling service, you might
consider the following...
>Before I call this in for support..
>Every morning at 9AM I fire up the following admin schedule:
>backup stg dltpool offsitepool
>My offsitepool has plenty of tapes in the filling and empty status, and are
>all 'available'.
I'm not sure what you mean by available. Make sure that all the volumes
have access mode readwrite. If the empty volumes are readonly, for example,
this could lead to the the insufficient space situation.
>The process asks to mount a filling volume, and then gets a message:
>ANR8341I End-of-volume reached for DLT volume OFF009.
>This is within 2 minutes of mounting the tape.
The tape was apparently near end-of-volume before you started the backup.
>It then asks for another tape in the 'filling' status, and again within two
>minutes gets the same error as above.
ANR8341I is not an error message. It simply indicates that the tape hit
end-of-volume. Keep in mind that a tape can hit end-of-volume even
if its utilization is very low, because there may be a lot of reclaimable
space on the volume.
>The process terminates with the following messages:
>ANR1221E BACKUP STGPOOL: Process 1 terminated -
> insufficient space in target copy storage pool.
The process should use the empty tapes if they are readwrite, not in use, etc.
>ANR1214I Backup of primary storage pool DLTPOOL to copy
> storage pool OFFSITEPOOL has ended. Files Backed Up: 0,
> Bytes Backed Up: 0, Unreadable Files: 0, Unreadable
> Bytes: 0.
>There are 4 tapes that have empty status, and there are at least 20 tapes that
>are in 'filling'. The process fails in less than 5 minutes.
That's quite a few tapes to be in filling state, but there may be a good
reason for this. If your tape pool is collocated, make sure your server is
at a recent level. We fixed a problem early this year that allowed an
excessive number of filling volumes to accumulate in collocated storage pools.
>The real funny thing is, that if I run the command by hand, it seems to run
>normally, asking for tapes that are 'empty' and going on.
>I also think that if the process gets ANR8341I that it should mark the
>volume 'FULL' and go on.
The volume is marked full when ANR8341I is issued. However, if the transaction
aborts (as it would if the process runs out of storage in the target
pool), the database update for this volume rolls backs.
Make sure your empty tapes are readwrite. It shouldn't be necessary, but
you could also mark the tapes that are near end-of-volume as readonly so they
don't get selected. Or reclaim these tapes.
Dave Cannon
ADSM Development
|
