Will do. I have already been discussing this with another IBM TSM
technician and he also suggested open a ticket.
Is the DB space used supposed to contract, as well as expand, as needed?
This may be the in-flight issue you refer to since the server crashed
during the import (log space exhausted - HANGMONITOR issue).
The "Q DB F=D" says it should be a lot smaller (if I am reading this
correctly):
10:52:30 AM WIND : q db f=d
Database Name: TSMDB1
Total Size of File System(MB): 399,747
Space Used by Database(MB): 48,256
Free Space Available (MB): 36,169
Page Size(Bytes):
Total Pages: 2,173,956
Usable Pages: 2,173,820
Used Pages: 2,168,648
Free Pages: 5,172
Buffer Pool Hit Ratio: 100.0
Total Buffer Requests: 592,714,473
Sort Overflows: 0
Lock Escalation: 0
Package Cache Hit Ratio: 99.3
Last Database Reorganization: 05/08/2009 09:00:30
Full Device Class Name: 3592-E05
Incrementals Since Last Full: 0
Last Complete Backup Date/Time: 05/06/2009 11:00:17
yet the filesystem containing the DB is 91% used of 400GB.
From:
Colin Dawson <colind AT US.IBM DOT COM>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
05/08/2009 10:31 AM
Subject:
Re: [ADSM-L] V6 exponential DB growth
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Zoltan,
Please open a pmr with IBM service. There are a couple things that
need to be investigated. These are:
1) TSM is exploiting table compression within DB2 which is a dictionary
based compression approach. We need to evaluate and see whether or not we
are seeing the benefits that would be expected by this. Alternatively, it
may be that the compression dictionary is appropriate and we need to have
the online table reorganizations executed for a set of tables in order to
see the benefits from the use of this compression dictionary...
2) EXPORT/IMPORT keeps track of some in-flight information in tables
relating to objects processed and other attributes of the EXPORT/IMPORT
data stream. One question about the size use is whether or not it is the
temporary tables being used by EXPORT/IMPORT that accounts for this
growth.
If that is the case there are a couple considerations for us to look into.
First is whether or not this space usage goes away once the IMPORT
completes. The second relates to #1 above and the compression dictionary.
Or as the data is being IMPORTED, is TSM needing to perform an online
reorg
for some of the tables in question in order to build an appropriate
compression dictionary that will then benefit the rest of the import
operation and mitigate or eliminate this space requirement..
Thanks,
Colin
-----------------------------------------------------
Colin Dawson
TSM Server Development
colind AT us.ibm DOT com
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: 05/08/2009 07:09 AM
Subject: [ADSM-L] V6 exponential DB growth
I have been experimenting with my 6.1.1 server (thank you for the patch -
I can now keep it running for more than 3-days) to see how it performs and
utilizes resources.
Some of the numbers I am seeing, when it comes to DB size/growth, is
startling and is going to be a major factor in whether I can implement 6.1
As an experiment, I exported one of my largest (objects-wise - 100M) nodes
to my 6.1 server.
The source 5.5.2 server DB is 70G with 70% utilized (50GB) and also
contains other nodes, for a total of 138M objects.
On the 6.1 server, the DB has now grown to 355GB and I didn't finish
exporting all 100M objects (only 1.4TB of occupancy) since I blew out the
log space and crashed the server.
That is 7x as big then V5 !!!
If I take this same factor, to move my other server with 273M objects
(105GB DB) to 6.1, I would need more than 1TB of disk space for the DB
alone.
Is this what is to be expected? I realize the docs talk about 4x the
resource requirements, but not 7x!
If so, there is no way I could move my biggest servers to 6.1 since they
only have 500GB internal drives used for the DB.
|
