|
Hi Henk,
I have observed reclamation of our copypool volumes and once ADSM has
reclaimed the data of these volumes they return to the scratch pool.
Can you check volume U00020 with q volume f=d and compare
it with this example?
Volume Name:
WPDV00
¦
¦
Storage Pool Name:
TAPEPOOL
¦
¦
Device Class Name:
TAPE
¦
¦ Estimated
Capacity (MB):
5.8
¦
¦
Pct Util:
0.1
¦
¦
Volume Status:
On-line
¦
¦
Access:
Read/Write
¦
¦ Pct.
Reclaimable Space:
3.2
¦
¦
Scratch Volume?:
Yes
¦
¦
In Error State?:
No
¦
¦ Number of Writable
Sides:
1
¦
¦ Number of Times
Mounted:
11
¦
¦
Write Pass Number:
1
¦
¦ Approx. Date Last Written:
04/14/1995
16:17:26
¦
¦ Approx.
Date Last Read: 04/01/1995
13:26:18
¦
¦
Date Became
Pending:
¦
¦ Number of
Write Errors:
0
¦
¦
Number of Read Errors:
0
¦
¦
Volume
Location:
¦
¦ Last Update by (administrator):
COLLIN
¦
¦ Last
Update Date/Time: 05/01/1995
14:07:27
¦
¦
all our volumes
have scratch volume?:yes and they do exactly what you
described.
I don't
think that there is anything to worry about.
Cheers
>I think a have a serious
problem. Well, actually I don't think so, but
>I'am sure.
>
>A
volume (U00020) is defined to a storagepool (UNITEPOOL) and is
>used for
backup's. After a while, Space reclamation started for
this
>volume:
>
>03/29/99 09:33:53 ANR1040I
Space reclamation started for volume
U00020,
>
storage pool UNITEPOOL (process number 597).
>03/29/99
09:33:53 ANR1044I Removable volume U00020 is required for
space
>
reclamation.
>03/29/99 09:33:53 ANR8324I 3590 volume
U00020 is expected to be
mounted
>
(R/O).
>03/29/99 09:33:53 ANR1142I Moving data for
collocation cluster 1 of 1
on
>
volume U00020.
>03/29/99 12:28:20 ANR1175W Volume U00020
contains files which could not
be
>
reclaimed.
>03/29/99 12:28:20 ANR1410W Access mode for
volume U00020 now set
to
>
"unavailable".
>03/29/99 12:28:20 ANR1041I
Space reclamation ended for volume U00020.
>
>Well, after the space
reclamation ended and the volume is set to "unavailable",
>it is
disappeared from the storagepool:
>
>adsm> q vol
U*
>....
>U00018
UNITEPOOL
3494-3590 0.0
0.0
Pending
>U00019
UNITEPOOL
3494-3590 0.0
0.0
Pending
>U00021
UNITEPOOL 3494-3590 14,920.0
68.1
Full
>U00022
UNITEPOOL
3494-3590 0.0
0.0 Pending
>....
>
>Every morning at 09:00, a backup db
started, which should use only
>scratch volumes. Well, at least, this is
the way it works for a long
>time
:-(
>
>SURPRISE:
>Private volume U00020 is
used:
>
>03/30/99 09:00:24 ANR2750I Starting
scheduled command BACKUP_DB ( backup
db
>
devclass=3494-3590 type=full ).
>03/30/99 09:00:24
ANR2017I Administrator ADMIN issued command: BACKUP
DB
>
devclass=3494-3590 type=full
>03/30/99 09:00:24 ANR0984I
Process 628 for DATABASE BACKUP started in
the
>
BACKGROUND at 09:00:24.
>03/30/99 09:00:24 ANR2280I Full
database backup started as process 628.
>03/30/99
09:00:24 ANR2280I Full database backup started as process
628.
>03/30/99 09:00:24 ANR2753I (BACKUP_DB):ANR2280I
Full database backup
started
>
as
>03/30/99 09:00:24 ANR2753I (BACKUP_DB):process
628.
>03/30/99 09:00:24 ANR2756I Scheduled command
BACKUP_DB started successfully.
>03/30/99 09:01:05
ANR8337I 3590 volume U00020 mounted in drive
3590-2
>
(/dev/rmt2).
>03/30/99 09:01:07 ANR1360I Output volume
U00020 opened (sequence number
1).
>.....
>.....
>03/30/99 09:52:40
ANR4554I Backed up 2292528 of 2326863 database
pages.
>03/30/99 09:53:10 ANR4554I Backed up 2316736 of
2326863 database pages.
>03/30/99 09:53:31 ANR1361I
Output volume U00020 closed.
>03/30/99 09:53:33 ANR8336I
Verifying label of 3590 volume U00020 in
drive
>
3590-2 (/dev/rmt2).
>03/30/99 09:53:36 ANR4550I Full
database backup (process 628)
complete,
>
2326863 pages copied.
>03/30/99 09:53:36 ANR0985I
Process 628 for DATABASE BACKUP running in
the
>
BACKGROUND completed with completion state SUCCESS
at
>
09:53:36.
>03/30/99 09:54:02 ANR8468I 3590 volume U00020
dismounted from drive
3590-2
>
(/dev/rmt2) in library 3494LIB.
>
>And volume U00020 suddenly appear
in the libvol as Private/DbBackup:
>
>adsm> q libvol *
U*
>3494LIB
U00018
Private
Data
>3494LIB
U00019
Private
Data
>3494LIB
U00020
Private
DbBackup
>3494LIB
U00021
Private
Data
>3494LIB
U00022
Private
Data
>
>So, the backup-data from volume U00020 is gone for
ever.
>
>And this is not the only volume which is destroyed this
way.
>
>Questions:
>
>1. Why are the volumes disappear
from the storagepool?
>2. Why is backup db using private
volumes?
>
>Anyone any clues?
>
>Cheers,
>Henk ten
Have ( ADSM Server 3.1.2.15 on AIX 4.2.1.0)
------=_NextPart_000_000D_01BE7BB7.08026980--
=======================================================================
|
