Paul - I have run *SM on a mainframe since 1992 - my company
participated in both the alpha and beta test. DB2 was never used
for the database. What I have heard is that the database engine
in tsm is an early model of DB2, so we are all using DB2 in a sense.
No doubt you are right that things are optimized, but the question is
if the internal database is a sow's ear, how much can it be optimized;
it will never be a silk purse.
I don't know if tsm would perform better with today's version of db2
or oracle. People with large tsm db's aren't looking for better performance,
we are looking for better manageability. With commercial dbms's you
don't have the logging problem, you can do multithreaded db backups,
you can reorg it without an extended outage.
In any case I think this is just an academic debate; I am 99% certain that
it will never happen if only for the reason that vendors like blackboxes
to protect their software assets.
Bill
At 07:13 PM 5/2/2002 -0400, you wrote:
>ADSM on the mainframe use to use DB2 and they killed it because of the cost
>to the customer, both maintaining another product and the actual license
>cost. The TSM relational engine is optimized for TSM processing. A general
>relational database cannot hold a candle to the performance differences on
>equal hardware. The other issue is Tivoli does not want you mucking around
>in the tables updating them with update commands. The referential integrity
>is paramount to TSM stability. The real missing piece in TSM's DB engine is
>the ability to partition the database and parallel backup/restore. More
>important is the 4K block size that kills IO performance on sequential
>operations such as a backup/restore. I think Tivoli will see the need and
>do something about it. These have been discussed at Share.
>
>You will find that "black box" is what most customers require to protect
>themselves. I realize if they used a general RDBMS that we could extend the
>code of TSM significantly further than with the current command
>capabilities. But, that is exactly what they want to prevent. You end up
>with large customers developing extensions that are impacted by Tivoli
>architectural changes that carry a loud voice about making changes that
>affect them and thus prevent progress. I am one of them, trust me it
>happens.
>
>This all said. If you can define the requirements that a RDBMS would solve
>for you that I have not mentioned, we will carry those requirements forward.
>
>Paul D. Seay, Jr.
>Technical Specialist
>Naptheon, INC
>757-688-8180
>
>
>-----Original Message-----
>From: Prather, Wanda [mailto:Wanda.Prather AT JHUAPL DOT EDU]
>Sent: Thursday, May 02, 2002 2:05 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Recovery Log almost 100%
>
>
>.... and that is JUST the problem.
>
>I used to (try to) run an IBM lan management product that used DB/2 as its
>database underneath. IT WAS IMPOSSIBLE.
>
>Every problem we ran into, we got finger pointing - the product people said
>they were waiting for DB/2 to to fix the problem, the DB/2 people said they
>couldn't fix it because it was a product problem.
>
>YOU DON"T WANT TO GO THERE!
>
>CRINGE AND BE AFRAID....
>
>My opinions and nobody else's...
>Wanda Prather
>
>
>-----Original Message-----
>From: William F. Colwell [mailto:bcolwell AT DRAPER DOT COM]
>Sent: Thursday, May 02, 2002 12:28 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Recovery Log almost 100%
>
>
>Tom, I like the taste of this food for thought!
>
>I have raised this issue with TSM developers at SHARE and the short summary
>of their response is "Cringe". So I don't think it will happen anytime soon
>if and most likely it will never happen. I agree with you completely that
>it would be a great option for site with large databases. Plus TSM would
>have 2 development teams working on the product - the current one plus the
>database developers who are always trying to make Oracle, DB2 etc. faster.
>
>- Bill
>
>
>At 06:20 AM 5/2/2002 -0700, you wrote:
>>I wonder, also, if there is still any discussion about supporting the
>>use of an alternate RDBMS underneat TSM. It is quite clear that there
>>are many more sites with database sizes in the
>>25-50GB+ range. Five years ago I felt very lonely with a database
>>of this size, but given the discussions on the listserv over the past
>>year I feel more comfortable that we are no longer one of the only
>>sites supporting TSM instances that large. It has always seemed to me
>>that the database functions of TSM have been the most problematic
>>(deadlock issues, log full issues, SQL query performance problems,
>>complicated and unclear recommendations for physical database layout,
>>etc.). All of these problems have been solved by Oracle, DB2, and
>>Sybase. Granted there is the issue that plugging in an external
>>database adds greatly to the complexity of TSM, and reduces it's "black
>>box-ness", but I think the resources are available to administer such a
>>beast at the large sites that require very large databases.
>>
>>More food for thought *early* on a Thursday morning.
>>
>> -- Tom
>>
>>Thomas A. La Porte
>>DreamWorks SKG
>>tlaporte AT dreamworks DOT com
>
>
>
>
>----------
>Bill Colwell
>C. S. Draper Lab
>Cambridge Ma.
----------
Bill Colwell
Bill Colwell
C. S. Draper Lab
Cambridge Ma.
|
