Re: No future for DB2

DA Morgan said: > > Larry wrote: >> I don't think you could convince the Oracle marketing people of that for >> the temporary periods when they have been in the lead ... > > I agree. But then I can't imagine why any serious technologist would > feel otherwise. I don't know that I am a serious technologist, but here are some pro-TPC-C comments (given that it's C that seems to be the contentious one -- H and DS don't seem to enjoy the same level of abuse): 1. A TPC-C benchmark will never prove anything about my specific application, but presence in the TPC-C benchmarks shows that my vendor(s) take the business of transaction processing performance seriously. 2. Running TPC-C benchmarks and artificially stressing the database is another form of QA, and can identify bottlenecks that only occur in extremis. This can lead to significant improvements in in product quality and performance overall. 3. Most businesses (and I really mean most businesses, even the largest corporations in my [admittedly limited] experience) do not have the budget and, more importantly, the resourcing for proper benchmarking of anything but the most performance-critical applications. This means that where application benchmarking _is_ done, it's generally less than rigorous and the results are usually read in conjunction with the TPC results or some other canned benchmark. But in reality, very few customers do anything like that, because they have taken a "strategic decision" on a golf course somewhere to go Oracle or DB2 or SQL Server or whatever. The "technologists" just have to make it work. -- Bye now, Obnoxio "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche A smile is a gift that is free to the giver and precious to the recipient. But giving someone the finger is free too, and I find it more personal and sincere. sending to informix-list

Obnoxio The Clown wrote: > DA Morgan said: > >>Larry wrote: >> >>>I don't think you could convince the Oracle marketing people of that for >>>the temporary periods when they have been in the lead ... >> >>I agree. But then I can't imagine why any serious technologist would >>feel otherwise. > > > I don't know that I am a serious technologist, but here are some pro-TPC-C > comments (given that it's C that seems to be the contentious one -- H and > DS don't seem to enjoy the same level of abuse): > > 1. A TPC-C benchmark will never prove anything about my specific > application, but presence in the TPC-C benchmarks shows that my vendor(s) > take the business of transaction processing performance seriously. > > 2. Running TPC-C benchmarks and artificially stressing the database is > another form of QA, and can identify bottlenecks that only occur in > extremis. This can lead to significant improvements in in product quality > and performance overall. > > 3. Most businesses (and I really mean most businesses, even the largest > corporations in my [admittedly limited] experience) do not have the budget > and, more importantly, the resourcing for proper benchmarking of anything > but the most performance-critical applications. This means that where > application benchmarking _is_ done, it's generally less than rigorous and > the results are usually read in conjunction with the TPC results or some > other canned benchmark. > > But in reality, very few customers do anything like that, because they > have taken a "strategic decision" on a golf course somewhere to go Oracle > or DB2 or SQL Server or whatever. The "technologists" just have to make it > work. > Oh, Oh OTC. Are you not OK? What didn't happen to you? You don't sound wrong... -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Comments in-line. Obnoxio The Clown wrote: > DA Morgan said: > >>Larry wrote: >> >>>I don't think you could convince the Oracle marketing people of that for >>>the temporary periods when they have been in the lead ... >> >>I agree. But then I can't imagine why any serious technologist would >>feel otherwise. > > > I don't know that I am a serious technologist, but here are some pro-TPC-C > comments (given that it's C that seems to be the contentious one -- H and > DS don't seem to enjoy the same level of abuse): > > 1. A TPC-C benchmark will never prove anything about my specific > application, but presence in the TPC-C benchmarks shows that my vendor(s) > take the business of transaction processing performance seriously. I disagree. My vendor's TPC benchmark demonstrates their willingness to spend money in the hope of getting something they can use in a magazine advertisement to impress CTOs that are lacking in analysis skills. > 2. Running TPC-C benchmarks and artificially stressing the database is > another form of QA, and can identify bottlenecks that only occur in > extremis. This can lead to significant improvements in in product quality > and performance overall. Here I agree. But that benefit happens in the QA lab of the vendor. They have those bugs worked out before sumitting their product for testing. Thus the results of the test, the metrics, are still without value. > 3. Most businesses (and I really mean most businesses, even the largest > corporations in my [admittedly limited] experience) do not have the budget > and, more importantly, the resourcing for proper benchmarking of anything > but the most performance-critical applications. I think it is more a lack of skill and lazyiness than a lack of budget but I again agree. But your argument reads like this: "We need to do something. Jumping off a cliff is something. Therefore we need to jump off a cliff." or The fact that an organization can't/won't benchmark their own application hardly equates to using some irrelevant but published metric as a substitute. > But in reality, very few customers do anything like that, because they > have taken a "strategic decision" on a golf course somewhere to go Oracle > or DB2 or SQL Server or whatever. The "technologists" just have to make it > work. How true how true. Since so far I have been wholly negative toward TPC and their swill I will take a different point-of-view and propose benchmarks that would have value. 1. Load the databases on identical hardware and operating systems 2. Install SAP, PeopleSoft, Oracle Apps, or Siebel 3. Load up the system with transactions until the DB chokes 4. Load up the system with users until the DB chokes 5. Get a room full of 22 year old crackers to attack the system Award a gold star to the RDBMS vendor whose system survives the longest. No one on the planet uses TPC code in production. The products I list in #2, above, are real-world and the results would have value to many. -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)