ADSM-L

Re: [ADSM-L] Where is the missing 38GB?

2008-12-05 09:46:41
Subject: Re: [ADSM-L] Where is the missing 38GB?
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 5 Dec 2008 09:44:36 -0500
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 <rogerd AT UIC DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
12/04/2008 05:45 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
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     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
>

<Prev in Thread] Current Thread [Next in Thread>