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 [EMAIL PROTECTED] "Intelligence has much less practical application than you'd think" - Scott Adams/Dilbert ************************************************************************ -----Original Message----- From: bizzorg [mailto:i.hunley@;ATTBI.COM] Sent: Sunday, November 10, 2002 9:18 AM To: [EMAIL PROTECTED] 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.
