Or better yet, I could just reformat everything, since this is a test
system.

I just want to know why..........

Yeah, yeah, I realize V6.1 with DB2 will "fix all DB
issues".............;----))))




"Schneider, Jim" <jschneider AT USSCO DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
12/02/2008 12:58 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?






I'm waiting for the firestorm of comments following this suggestions.
(Sitting back, waiting for fireworks.)

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Gee, Norman
Sent: Tuesday, December 02, 2008 11:52 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Where is the missing 38GB?

The dreaded DSMSERV DUMPDB and DSMSERV LOADDB  (not recommended)

DSMSERV LOADDB (Reload the database)

Use this command to reload a Tivoli Storage Manager database in optimal
order.

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Tuesday, December 02, 2008 9:44 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Where is the missing 38GB?

12/2/2008 12:41:46 PM ANR0984I Process 1 for ESTIMATE DBREORG started in
the BACKGROUND at 12:41:46 PM.
12/2/2008 12:41:46 PM ANR1782W ESTIMATE DBREORG process 1 started -
server
performance may be degraded while this process is running.
12/2/2008 12:41:46 PM ANR0405I Session 78 ended for administrator
ZFORRAY
(WinNT).
12/2/2008 12:41:53 PM ANR1784I A database reorganization would reduce
the
database utilization by an estimated 0 MB.
12/2/2008 12:41:53 PM ANR0987I Process 1 for ESTIMATE DBREORG running in
the BACKGROUND processed 1344 items with a completion state of SUCCESS
at
12:41:54 PM.
12/2/2008 12:41:53 PM ANR0381I Buffer pool statistics were successfully
reset.

On 02/12, 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:
>
...
> 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".

The DB is probably fragmented. Try:

 ESTIMATE DBREORGSTATS
 Q DBVOL F=D