And most importantly, if you get a room full of TSM gurus, IBM types and folks like us, nobody will really agree on a hard number.
What I have seen during 10 years and hundreds of TSM environments is that the number has gradually increased. When I first got into this business, 50GB was huge. Now that's nothing. The more normal is 100-150GB and things seem to be working just fine. I recall a period of time, soon after Dave Cannon arrived, that IBM's engineering focus was on quality. They did a ton of great work fixing what ailed the product. We could see the results afterwards. This work set the base for what we're seeing today (up to 5.5.x anyway). Couple that with huge improvements in hardware performance and our favorite product has grown up nicely. Our problems are so much different than everybody else's. They're still worried about getting the weekly full backup done they can't think about anything else. That or adding the next freaking band-aid to their already half assed (and declining) solution. You can sure tell when I'm working on a customer presentation can't you? Kelly Lipp Chief Technical Officer www.storserver.com 719-266-8777 x7105 STORServer solves your data backup challenges. Once and for all. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Shawn Drew Sent: Tuesday, November 10, 2009 10:10 AM To: [email protected] Subject: Re: [ADSM-L] TSM DB Size 100-120GB was the IBM recommended limit based on their tests on a baseline AIX system (Specs are lost to history). I talked to the Watson Research guys at a Symposium quite a while ago on this. (The guy was from one of their east coast research places, and I'm assuming it was Watson. He was with IBM Global Services and described his job as basically playing with all the hardware that came out and wrote reports and guidelines for them.) The idea was that if you have a faster system than their baseline, you can go higher. It was a general rule-of-thumb type of thing. You can decide for yourself on your own hardware with your own data based on how long your expirations/db backups take and if that's acceptable to you. Regards, Shawn ________________________________________________ Shawn Drew Internet [email protected] Sent by: [email protected] 11/10/2009 11:51 AM Please respond to [email protected] To ADSM-L cc Subject Re: [ADSM-L] TSM DB Size We had a health check done by IBM when we were at TSM 5.3 and were told they don't recommend a DB size higher than 120Gb for performance and restore purposes. Rich -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Kelly Lipp Sent: Tuesday, November 10, 2009 11:48 AM To: [email protected] Subject: Re: [ADSM-L] TSM DB Size The architectural limit is 500GB. Practically, one should be a good bit smaller. It really boils down to how long do you want a restore of the backed up DB to take? Figure about 150% of the backup time for a restore. Can you live with that? Kelly Lipp Chief Technical Officer www.storserver.com 719-266-8777 x7105 STORServer solves your data backup challenges. Once and for all. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Huebschman, George J. Sent: Tuesday, November 10, 2009 9:42 AM To: [email protected] Subject: Re: [ADSM-L] TSM DB Size We have DB's over 190 Gb in 5.5, on AIX servers: TSM_Server CAP_GB MAX_EXT_GB PCT_UTIL MAX_UTIL ----------- ------- ---------- -------- -------- AIXPRODXYZ 191.95 0.00 89.4 89.4 AIXPRODDMZ 219.76 4.17 90.3 91.1 -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of Richard Mochnaczewski Sent: Tuesday, November 10, 2009 11:35 AM To: [email protected] Subject: [ADSM-L] TSM DB Size Hi *, Does anyone know what the maximum size database is for TSM 5.4 and TSM 5.5 ? We were told by IBM when we were at TSM 5.3 that 120Gb was the limit and was wondering what the limit is for 5.4 and 5.5. Currently running TSM 5.4.3.0 on AIX 5.3 TL 9. Rich IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you. This message and any attachments (the "message") is intended solely for the addressees and is confidential. If you receive this message in error, please delete it and immediately notify the sender. Any use not in accord with its purpose, any dissemination or disclosure, either whole or partial, is prohibited except formal approval. The internet can not guarantee the integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) not therefore be liable for the message if modified. Please note that certain functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
