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" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
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
|
