What is "optimal" for DB size depends on your hardware, your platform, your
load. and your response requirements. When you see comments about an
"optimal" size, what you are really seeing is comments about people's
experience with a certain combination of hardware, platform, and load.
If your DB is 100GB and you get acceptable throughput for DB-intensive
operations like EXPIRATION processing, and acceptable response time for
restores, then it's not too big. If your DB is 20 GB and your hardware
config won't give you acceptable throughput or restore times, then even 20
GB is too big.
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu
"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************
-----Original Message-----
From: bizzorg [mailto:i.hunley AT ATTBI DOT COM]
Sent: Sunday, November 10, 2002 9:18 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: TSM Client server and data migration
I'm hearing that 20GB is the optimal size for a TSM database. I've also
heard that 40GB is the optimal size. Is either number correct? What is
the correct optimal TSM database size? The TSM servers, with the
exception of one, are running at fix test 4.2.2.12 on z/OS 1.2.
We are moving client servers from a TSM with a 100+ GB database to TSM
servers with 20GB databases. There is data on the older TSM server that
was backed up by TSM 4.1.x. When we worked with IBM on a previous
problem, it was suggested by IBM that we run a CLEANUP process against
the 4.1.x data.
CLEANUP is a long running process and all sessions must be disabled
while running cleanup. Because of this, CLEANUP cannot run on
production TSM servers. We've run reports against the older TSM and
discovered 4.88TB of file spaces we think we can delete. The list of
file spaces has been distributed for written approval.
Here's my plan of action...
1.) Complete the client server migration.
2.) Obtain written approval to delete the old backup file spaces(CYA).
3.) Delete the file spaces.
4.) Run the CLEANUP process on the decommissioned TSM.
5.) EXPORT the data from the decommissioned TSM.
6.) IMPORT the data to the new TSM servers.
It just doesn't make sense to me to run the CLEANUP process against file
spaces that could be deleted. It also seems unwise to me to
EXPORT/IMPORT data that could be deleted, but believe it or not, someone
here wants to do just that. I'm looking for Pros and Cons. After all,
it's possible that my plan is the one that doesn't make sense and I just
can't see it.
|
