|
Re: [ADSM-L] Where is the missing 38GB?
2008-12-05 18:21:41
On Dec 5, 2008, at 16:55 , Phillip Burgess wrote:
From my experience, TSM is not capable of re-using the space once it
becomes fragmented.
TSM will reuse empty pages, it will not reuse empty space in a
partially used page, just like tapes, the cycle is empty->filling-
>full->empty except that there is no page-reclaim process.
I have worked on servers with 150GB databases reduced down to 50%
utilization after several large filespace deletions. We could not
recover any space on the database and it continued to fill until it
eventually failed to run a select statement, stating that there was
not enough temporary space in the DB to process the statement. The
DB utilization was still at 52%.
A reload of the database reduced the size down to 75GB, we have been
using it for nearly a year without any consequences from the reload.
I have seen databases with fragmentation as high as 95%, no option
left other than to export or reload the database
Phil
________________________________
From: Roger Deschner [mailto:rogerd AT UIC DOT EDU]
Sent: Thu 04/12/2008 22:41
To: ADSM-L AT VM.MARIST DOT EDU
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 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
|
|
|
