Another reason to keep database size down is the dreaded audit. A small database can be audited in a few hours. A really large database can take days. Architecting a multiple instance TSM that shares resources is a bit more challenging, but the fast DB backups and DR restores have me managing to a 60 GB database target. Maybe when I get a look of TSM under DB2, the target can rise. Orville L. Lantto
________________________________ From: ADSM: Dist Stor Manager on behalf of Curtis Preston Sent: Mon 1/21/2008 14:51 To: [email protected] Subject: Re: [ADSM-L] 2ND TSM Instance Question A second instance increases complexity and therefore increases management effort. So the preferred state would be to stay with one instance if you can do so without problems. If you can fit all of your daily activities (e.g. backup, migration, TSM db backup, expiration, reclamation) in a single 24-hour period, then there's really no need to add a second instance. If the length of one or more of these activities causes you to not finish your daily activities within a 24-hour period, then you should do what you can to make that activity faster first, before splitting your instance. Is backing up to disk taking too long? Perhaps you need faster disk or more CPU/RAM for TSM. Is backing up the disk pool to tape take too long? Again, maybe you need faster disk; maybe you need more/faster tape drives (or more/faster CPU/RAM). Is expiration taking too long? Perhaps you need more CPU/RAM. Reclamation taking too long? Maybe you need more/faster tape drives; maybe you need more/faster CPU/RAM. If reclamation is being slowed down because you don't have enough tape drives, adding a second instance won't help if it's sharing the same tape drives. Another thing to consider is whether or not you're giving TSM too much to do at one time. There was a good discussion last week called "Spanking my data" that discussed the benefits and drawbacks to doing multiple TSM tasks simultaneously. (Read it at http://tinyurl.com/yrpde3 .) TSM will perform better if you have it do daily activities serially rather than simultaneously. (But, as you will see in that discussion, that's not always possible.) SO, if you've done your best to serialize your activities, bought more/faster CPU/RAM and more/faster tape drives, and you still can't fit anything within 24 hours, then it's time to split the instance. The short answer is that most people find that happens when your database gets well beyond 100 GB -- although not always. I've talked to people with larger databases that still fit their activities into a 24-hour day. Don't split your instance just because you're at 150 GB. Split it because you can't get your work done in a 24-hour period and you've already tried everything else. --- W. Curtis Preston Backup Blog @ www.backupcentral.com VP Data Protection, GlassHouse Technologies -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Lamb, Charles P. Sent: Monday, January 21, 2008 11:04 AM To: [email protected] Subject: [ADSM-L] 2ND TSM Instance Question Hi.......... What is the criteria that tells a person that a 2nd TSM instance is needed?? Our TSM consultant is saying we are close to needing a 2nd TSM instance since our DB has 23+ million pages. The DB backup runs about 35 minutes. Our TSM System is as follows: AIX 5.3 ML7 SP1 TSM 5.3.4.2 IBM 9133-55A 4-WAY w/16GB of memory IBM 3584-L32/D32 w/14-LTO2 tape drives directly FC connected IBM FAStT700 with 1GB SAN using 3TB for DB, log and disk cache IT Management has authorized having a 8-way RISC w/64GB of memory, 2GB SAN system and replacing the LTO2 with LTO3 tape drives/LTO3 tapes. Doesn't a 2nd instance cause 2 operational schemes (on-site and off-site tapes) of two TSM systems??
