Database numbers don't add up

2003-07-22 Thread Zoltan Forray/AC/VCU
TSM server V5.1.6.2 on z/OS.

Can someone explain why these numbers from a Q DB F=D don't add up (at
least they don't make sense to me ?):

  Available Space (MB): 35,160
Assigned Capacity (MB): 35,160
Maximum Extension (MB): 0
Maximum Reduction (MB): 5,372
 Page Size (bytes): 4,096
Total Usable Pages: 9,000,960
Used Pages: 4,968,239
  Pct Util: 55.2
 Max. Pct Util: 55.2
  Physical Volumes: 15

In summary, it says that of the roughly 35GB DB, only 55% is used.  In
round numbers, 20GB is in use. This means that 15GB is not.

However, the Maximum Reduction value is 5GB.

Where is the other 10GB ?

Even if TSM kept the reduction values based on the volume sizes (roughly
2.3GB per 3390-3 volume is what it is reporting), I should still be able
to reduce the size by 6-volumes, or roughly 13GB !


Re: Database numbers don't add up

2003-07-22 Thread Remco Post
On Tue, 22 Jul 2003 10:27:04 -0400
Zoltan Forray/AC/VCU [EMAIL PROTECTED] wrote:

 TSM server V5.1.6.2 on z/OS.

 Can someone explain why these numbers from a Q DB F=D don't add up (at
 least they don't make sense to me ?):

   Available Space (MB): 35,160
 Assigned Capacity (MB): 35,160
 Maximum Extension (MB): 0
 Maximum Reduction (MB): 5,372
  Page Size (bytes): 4,096
 Total Usable Pages: 9,000,960
 Used Pages: 4,968,239
   Pct Util: 55.2
  Max. Pct Util: 55.2
   Physical Volumes: 15

 In summary, it says that of the roughly 35GB DB, only 55% is used.  In
 round numbers, 20GB is in use. This means that 15GB is not.

 However, the Maximum Reduction value is 5GB.

 Where is the other 10GB ?



'In between', some people refer tot this as database fragmentation. There
are appereantly in your case, a lot op pages unused, but that cannot be
freed for database reduction. This probably has something to do with how TSM
allocates a fresh db page when it needs one, I'm guessing that it tries to
allocate pages in a way that leaves you with a as good as possible
performance. As long as you don't really need the diskspace, I wouldn't
worry. If you really do need the disks, I guess unloading than loading the
db will temporarely resolve this problem (and in the end will leavy you with
a db that performs far less than currently).

 Even if TSM kept the reduction values based on the volume sizes (roughly
 2.3GB per 3390-3 volume is what it is reporting), I should still be able
 to reduce the size by 6-volumes, or roughly 13GB !


--
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdamhttp://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008Fax. +31 20 668 3167

I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer industry
didn't even foresee that the century was going to end. -- Douglas Adams


Re: Database numbers don't add up

2003-07-22 Thread Loon, E.J. van - SPLXM
Hi Zoltan!
There is a formula to check your 'fragmentation' level to verify Remco's
explanation:

SELECT CAST((100 - (CAST(MAX_REDUCTION_MB AS FLOAT) * 256 ) /
(CAST(USABLE_PAGES AS FLOAT) - CAST(USED_PAGES AS FLOAT) ) * 100) AS
DECIMAL(4,2)) AS PERCENT_FRAG FROM DB

Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines

-Original Message-
From: Remco Post [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 22, 2003 16:42
To: [EMAIL PROTECTED]
Subject: Re: Database numbers don't add up


On Tue, 22 Jul 2003 10:27:04 -0400
Zoltan Forray/AC/VCU [EMAIL PROTECTED] wrote:

 TSM server V5.1.6.2 on z/OS.

 Can someone explain why these numbers from a Q DB F=D don't add up (at
 least they don't make sense to me ?):

   Available Space (MB): 35,160
 Assigned Capacity (MB): 35,160
 Maximum Extension (MB): 0
 Maximum Reduction (MB): 5,372
  Page Size (bytes): 4,096
 Total Usable Pages: 9,000,960
 Used Pages: 4,968,239
   Pct Util: 55.2
  Max. Pct Util: 55.2
   Physical Volumes: 15

 In summary, it says that of the roughly 35GB DB, only 55% is used.  In
 round numbers, 20GB is in use. This means that 15GB is not.

 However, the Maximum Reduction value is 5GB.

 Where is the other 10GB ?



'In between', some people refer tot this as database fragmentation. There
are appereantly in your case, a lot op pages unused, but that cannot be
freed for database reduction. This probably has something to do with how TSM
allocates a fresh db page when it needs one, I'm guessing that it tries to
allocate pages in a way that leaves you with a as good as possible
performance. As long as you don't really need the diskspace, I wouldn't
worry. If you really do need the disks, I guess unloading than loading the
db will temporarely resolve this problem (and in the end will leavy you with
a db that performs far less than currently).

 Even if TSM kept the reduction values based on the volume sizes (roughly
 2.3GB per 3390-3 volume is what it is reporting), I should still be able
 to reduce the size by 6-volumes, or roughly 13GB !


--
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdamhttp://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008Fax. +31 20 668 3167

I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer industry
didn't even foresee that the century was going to end. -- Douglas Adams


**
For information, services and offers, please visit our web site: http://www.klm.com. 
This e-mail and any attachment may contain confidential and privileged material 
intended for the addressee only. If you are not the addressee, you are notified that 
no part of the e-mail or any attachment may be disclosed, copied or distributed, and 
that any other action related to this e-mail or attachment is strictly prohibited, and 
may be unlawful. If you have received this e-mail by error, please notify the sender 
immediately by return e-mail, and delete this message. Koninklijke Luchtvaart 
Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for 
the incorrect or incomplete transmission of this e-mail or any attachments, nor 
responsible for any delay in receipt.
**