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:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 2:05 PM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Thursday, May 02, 2002 12:28 PM To: [EMAIL PROTECTED] 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 >[EMAIL PROTECTED] ---------- Bill Colwell C. S. Draper Lab Cambridge Ma.
