On Dec 4, 2008, at 23:41 , Roger Deschner wrote:
.
The missing 38GB is just simply gone. Wave it goodbye. Disks are
cheap -
find something more expensive to worry about.
ok, I'll have to disagree here. an empty db (and this one is) should
not have 100% fragmentation. And like my test server, with only 2*18GB
internally, I'd hate to loose 38 ;-)
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.
in normal operations, agreed, unless you agree that 100% fragmentation
should at least clean up pretty nicely with an unload/load.
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.
Now, you should be worried. 377 GB is huge :) I agree, in a production
db of that size, about 10-20% external fragmentation (free block
amongst the used ones) is nothing to worry about, neither is 50% or
more internal fragmentation (half used blocks). Zoltan's db is
something completely different and a good example of a db that does
apply for an unload/load cycle.
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.
delete dbvol only solves external fragmentation, non-empty block will
be moved as they are. In Zoltan's case, these make up about 100% of
his database.
I happen to like thinking and discussing about intresting TSM
oddities, I even do it when I'm not at work.
Zoltan, did you ever do the unload/load?
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
======== "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
r.post AT plcs DOT nl
+31 6 248 21 622
--
Met vriendelijke groeten,
Remco Post
r.post AT plcs DOT nl
+31 6 248 21 622
|