According to this I have around 90GB of partially empty pages in this database.
Two years ago it was at 60% utilization. After several large filespace
deletions it has not recovered any pages in the DB for reuse.
If I reduce the DB by the 1,012 MB of free space it will fail, reporting
various SQL Table space errors.
tsm: TSMS01>q db f=d
Available Space (MB): 120,000
Assigned Capacity (MB): 97,136
Maximum Extension (MB): 22,864
Maximum Reduction (MB): 1,012
Page Size (bytes): 4,096
Total Usable Pages: 24,866,816
Used Pages: 515,955
Pct Util: 2.1
Max. Pct Util: 3.7
Physical Volumes: 24
Buffer Pool Pages: 175,000
Total Buffer Requests: 2,271,606,552
Cache Hit Pct.: 99.97
Cache Wait Pct.: 0.00
Backup in Progress?: No
Type of Backup In Progress:
Incrementals Since Last Full: 0
Changed Since Last Backup (MB): 666.78
Percentage Changed: 33.08
Last Complete Backup Date/Time: 12/08/2008 06:01:48
Estimate of Recoverable Space (MB):
Last Estimate of Recoverable Space (MB):
________________________________
From: Remco Post [mailto:r.post AT PLCS DOT NL]
Sent: Fri 05/12/2008 23:19
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Where is the missing 38GB?
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
|
