. 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 >
