Greetings, all.
I'm musing about strategies to deal with backups of "files" which are larger than some of my volumes. The DB2 API client stores full backups as single files; so I've got 150, 180, 210GB files rattling around in my stgpools. Now, I'm moving towards virtual volumes as my copy stgpools, and have so far set the virtual volume size at 20G. Rationale there is that I want the files which represent the volumes to be sanely sized for remote management: reclaiming a 2TB tape when your file size is 400G sounds irritating. So this means that, when one of my 20G volumes that contains a snippet of a DB Full comes up for reclamation, I have to move around all 180 G. Eugh. I understand why they reconstruct the fragmented file on reclamation as a general case; but in this case: + I'm going to start with 7 or 8 full volumes, and a head and tail segment; + I'm going to finish with 7 or 8 full volumes and a head and tail segment; So I see three major divisions of response, and I'm wondering which of them have been popular, and what other responses I've missed. 1) Deal with it, whiny-boy. 2) Put your huge files elsewhere (separate copy pool) so they are sanely managed independantly 3) Use bigger volumes so the mismatch between the big-file workload and the normal workload is less severe (if I have 400-500G volumes then moving 210G to reclaim one is less odd) I'd prefer to avoid option 1. ;) Notions? - Allen S. Rout
