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
Leo Humar
LCS Pty Ltd
lhumar AT vic.bigpond.net DOT au
>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)
|