Gerald, the main obstacles for unlimited growth of the TSM DB are DB backup/restore times, inventory expiration, usage of select statements over some huge tables. I would try to analyse with real world equipment 1. Daily operations & select statements - If you have DB volumes on IBM ESS (or EMC Symmetrix) spread across loops/8-packs/spindles you can achieve very good performance. To have good DB cache hit ratio you will need much more memory which would lead us to a system like pSeries 670, 680, 690. The limit is put higher so your expected 300-500 GB might be achievable on single instance. I say might - we are pushing the limits at the end and you are the explorer of the unknown. I have not played in a $20 million sandbox (hope I will someday) so am just estimating. If I have to prove all those my statements in a real project I would be happy to participate and present detailed calculations, presentations, ... (sorry, I just dreamed loud for a while) 2. Inventory expiration - besides DB volumes performance you will need plenty of processor power. Answer again leads to p670, p680 or p690-sized system. Of course we can think about Sun box or mainframe but you are having AIX experience so why not to stay there. 3. DB backup/restore - depends on the speed of DB volumes and the speed of backup device (device not tape). If LTO tape is used DB backup would take 5-10 hours and for sure is not acceptable. But if FILE class is used to a DR site's ESS through SAN we can expect higher speed and we can expect no more than 3-4 hours based on 500 GB DB. 4. Disk/tape, LAN/SAN connectivity - to avoid bottlenecks you will need many adapters and slots. And the answer again lies in the highend servers. 99. Still beyond the limit - if things become very huge you can split it on two instances (IMO no need for more than two). This may happen on the deployment and might become an issue later. My answer is partitioning capability of p670 and p690 - you can start two TSM instances within the OS image or have two HW partitions with AIX&TSM in them. So the conclusion (as Kelly wrote) - when new technology comes, limits are pushed higher. "Impossible" sizes of the past now can be real examples.
Zlatko Krastev IT Consultant Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: TSM DB Max Size (how scalable is TSM?) Good to know thanks. It seems like most of the postings I've read correlate the problem with TSM's DB growing to how long it takes to backup and restore the DB. Seems like this is directly proportional to the technology currently available at the time. I.e. for some people, restoring 100GB DB might take 5-6 hours while in your case clearly it's acceptable. Probably highly dependent on the performance of the tape drive you're doing your DB backup to. I wonder if that wasn't a factor (say my tape drive has unlimited performance and can always restore in 10 minutes), what the next consideration or "wall" would be in the DB growing so large? Performance degradation for standard TSM commands that involve use of the DB? I.e. an auditdb would be an extreme example but how about simply restoring a directory structure for a given client. At what point would a large DB affect that or other day to day processes such as inventory expiration? Ah well just thinking out loud.. Gerald Wichmann Sr. Systems Development Engineer Zantaz, Inc. 925.598.3099 w 408.836.9062 c -----Original Message----- From: Kelly J. Lipp [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 3:35 PM To: [EMAIL PROTECTED] Subject: Re: TSM DB Max Size (how scalable is TSM?) I have two real-life examples: 110 GB on a Windows platform, 180 GB on a Mainframe platform. Backup times on the Windows system a little over two hours, 2.5 hours to restore the db. I don't know about the Mainframe site. Much larger than we've seen in the past seems to be just fine. Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs, CO 80949 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Gerald Wichmann Sent: Friday, April 26, 2002 1:31 PM To: [EMAIL PROTECTED] Subject: Re: TSM DB Max Size (how scalable is TSM?) Hmm at 66.5% you're using more like 7,820MB of DB space. With 22,760,941 files that's more like (7,820,000,000 / 22,760,941) 343 bytes per file. The TSM admin guide says for each backup version you calculate 400-600 bytes (they use 600) and for each copy pool 100-200 bytes. So with their numbers it's more like 500-800 bytes per file vs your "real world" 343 bytes. If I calculate with 343 bytes per file I get: 625,000,000 * 343 = 214,375,000,000 bytes = 214GB DB Much smaller then 500GB but still very large. All in all my question remains. How much can a single TSM server handle? Is there a limit to DB size? Does performance degrade once the DB reaches a certain size? Gerald Wichmann Sr. Systems Development Engineer Zantaz, Inc. 925.598.3099 w 408.836.9062 c -----Original Message----- From: Lawrence Clark [mailto:[EMAIL PROTECTED]] Sent: Friday, April 26, 2002 12:58 PM To: [EMAIL PROTECTED] Subject: Re: TSM DB Max Size Hi: We have an assigned capacity on our DB of 11,760 MB, of which 66.5 % is currently in use. We have 22760941 files, which represent 4953359.67 MB in physical storage, and includes copypool data. This are actual numbers that do not jive with your calculations. >>> [EMAIL PROTECTED] 04/26/02 03:08PM >>> My environment could be up to 25TB and 625,000,000 files. According to the TSM 4.2 Admin Guide to calculate the size of my DB I multiply that by 600 bytes.. 625,000,000 * 600 = 375,000,000,000 bytes = 375,000,000 KB = 375,000 MB = 375 GB There also needs to be an offsite copypool of this data.. According to the TSM 4.2 Admin Guide: 625,000,000 * 200 = 125,000,000,000 bytes = 125GB So my DB needs to be 500GB, yikes.. How big can one scale a single TSM server installation up to before you need to start thinking about additional TSM servers? I.e. in this instance can my TSM server even handle this amount of data? How much could it handle? Gerald Wichmann Sr. Systems Development Engineer Zantaz, Inc. 925.598.3099 w 408.836.9062 c
