Unfortunately, it does seem to be some kind of "design issue". I tried the "create new DBVOL - delete OLD" and basically shuffled all 5-DBvolumes, to no avail. The numbers remain the same after ending up with the same amount of DB space/volumes.
In this case, disk is not cheap since it is an old test machine with a finite fixed internal disk that will not be expanded. I am stuck with what I have. Since the DB stats keep telling me I have data in 40GB of DB volumes that I can not release/reclaim, I am stuck with what I have. I wonder if I send enough data to it to really fill up the DB, would that resolve the bad DB pointer or would it just quit when it fills up to it's imaginary highwater mark? Yeah, I could do the reload....I could also just delete and start all over again since it is a TEST system. Nothing of any value in the DB. This is just nawing at me as to why there isn't a way to resolve it without extreme measures (how long would it take for you to unload/reload your 377GB DB?). Where is the internal tool that does a full/real AUDITDB that repairs such problems? Roger Deschner <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[email protected]> 12/04/2008 05:45 PM Please respond to "ADSM: Dist Stor Manager" <[email protected]> To [email protected] cc Subject Re: [ADSM-L] Where is the missing 38GB? . The missing 38GB is just simply gone. Wave it goodbye. Disks are cheap - find something more expensive to worry about. You will get it back, though, if you ever refill this database with data. But wait, you say, won't the new data be fragmented too? Sure, just like it would be if you started fresh with an empty database and let it run a year or so. Our 377gb database is from 1999 and has never been audited fully or reloaded, and is running smoothly on v5.5.1 now. We have done some large DELETE FILESPACE operations as we move some nodes to a second server, and some space has disappeared just like you report, but I'm not really worried about it. It will get reused by natural growth. OTOH, judging by the amount of data left in your database, an unload/load cycle should be cheap and fast, so why not? At least try it as a test, reloading to a test server, and let us know what happened. We're all waiting anxiously to hear - because we on this list can argue about TSM database fragmentation forever, as you have just seen. A third idea was suggested already - DELETE DBVOL. I've watched this remarkable command work, and it's like reclamation, except on the database. It's going to run for a very long time, and it's goal is not defragmentation so it won't do very well at that, but it will accomplish a basic reclamation operation on this database. The nice thing about DELETE DBVOL is that it can run with the system up and running. The not-so-nice thing about it is that it's unmirrored. You've got to delete all the mirror copies before DELETE DBVOL can work its real magic, and while it does you're very badly exposed to a single-disk failure, especially because it's slow. Therefore, before using DELETE DBVOL for this kind of thing, I always move that database extent to something that does hardware mirroring such as a commonplace hardware RAID box, or SSA RAID, etc. Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] ======== "Whether you think you can or can not, you are right." ======== On Tue, 2 Dec 2008, Remco Post wrote: > >I'd say, from what I read in the thread, that an unload/load at this >point will remove a lot of fragmentation, even though the estimate >says nill. > >The other option is to run an export server, reformat everything, and >then import server. You'll probably want to save your devconf.txt so >you can easily recreate the stgpools, devclasses and server2server >comms you might have. > >On Dec 2, 2008, at 18:20 , Zoltan Forray/AC/VCU wrote: > >> I have a test TSM server (5.5.1) which is producing some strange DB >> statistics. >> >> ************************************************** >> *** ---> Q DB F=D >> ************************************************** >> >> >> Available Space (MB): 56,336 >> Assigned Capacity (MB): 53,264 >> Maximum Extension (MB): 3,072 >> Maximum Reduction (MB): 14,360 >> Page Size (bytes): 4,096 >> Total Usable Pages: 13,635,584 >> Used Pages: 15,676 >> Pct Util: 0.1 >> Max. Pct Util: 0.1 >> Physical Volumes: 6 >> Buffer Pool Pages: 131,072 >> Total Buffer Requests: 249 >> Cache Hit Pct.: 100.00 >> Cache Wait Pct.: 0.00 >> Backup in Progress?: No >> Type of Backup In Progress: >> Incrementals Since Last Full: 4 >> Changed Since Last Backup (MB): 211.15 >> Percentage Changed: 344.82 >> Last Complete Backup Date/Time: 08/20/2008 09:49:38 >> Estimate of Recoverable Space (MB): >> Last Estimate of Recoverable Space (MB): >> >> >> With an assigned capacity of 52GB yet only 0.1% utilized (52MB?), it >> says >> I can only reduce the DB by 13GB ???? >> >> So, where is the remaining 38GB of DB usage ? >> >> There are 5-Disk STG volumes (empty/0% utilized), 2-Nodes with NO >> filespaces, defined. "Q STG" shows: >> >> 12:15:11 PM TSMTEST : q stg >> >> Storage Device Estimated Pct Pct High Low Next >> Stora- >> Pool Name Class Name Capacity Util Migr Mig Mig ge Pool >> Pct Pct >> ----------- ---------- ---------- ----- ----- ---- --- >> ----------- >> ARCHIVEPOOL DISK 0.0 M 0.0 0.0 90 30 >> BACKUPPOOL DISK 123 G 0.0 0.0 90 30 >> COPYPOOL-I- IBM3583-1 0.0 M 0.0 >> BM3583-1 >> COPYPOOL-I- IBM3583-2 0.0 M 0.0 >> BM3583-2 >> IBM3494-35- 3592E05 0.0 M 0.0 0.0 90 70 >> 92 >> >> I did a "DSMSERV AUDITDB FIX=YES" and the only thing it complained >> (and >> fixed) about was old schedules for non-existing nodes. Also did an >> "EXPIRE INVENTORY". > >-- >Met vriendelijke groeten, > >Remco Post >[EMAIL PROTECTED] >+31 6 248 21 622 >
