DBMS, September 1997
Thanks for the double-barreled discussion of overall system performance problems you presented in the July issue of DBMS.
The article "Uniting Object-Oriented and Distributed Systems," by Marcia and Philip Gulesian (page 84), went into the subject in fairly quantitative terms, and "Performance Anxiety" by David Linthicum (page 26) was complementary with pithy insights and a summary of a Windows NT-based simulation tool.
Together these articles help move the process of improving overall system performance from a mostly a posteriori task to an a priori one. I'd be interested in seeing more on this subject in future issues.
Hans Hellstrom
wwhh@agate.net
Can you think of any examples in the history of the database industry where a hybrid solution has succeeded? I can't and I've been in this business for more than 25 years.
When I was president of Cullinet, the largest database vendor in the world in the early 1980s, we built a hybrid database solution of a relational front end to a network database. It was called IDMS-R. Larry Ellison, Michael Stonebraker, and the other relational pundits laughed at us and said it couldn't be done. And guess what? They were right. It is interesting to see that they are now doing what they said was impossible and impractical.
The promise of a next-generation database that delivers all the benefits of object technology while retaining all the strengths of relational is a great marketing message. However, as we are seeing with Informix's Universal Server and Oracle's Oracle8, object-relational is not meeting the claims made by its vendors.
Robert Goldman
rgoldman@odi.com
I was perplexed by the benchmarks listed in Robin Schumacher's article, "Oracle Performance Strategies" (DBMS, May 1997, page 89), especially by the two-table join between a 6K row table and a 1.2Mb row table. The speed of 1 minute, 5 seconds shown using the parallel query option in Oracle is unacceptably slow, let alone the pathetic time of 2 minutes, 50 seconds, without the parallel query option -- and this on an SMP server (probably with no other active connections during the tests, either)?!
I just conducted two tests against our production database, one at 6:45 a.m. when 20 customer service reps were connected to the database and again at 7:45 a.m. when 43 customer service reps were connected to the database. The test was performed with a table containing 7.8K rows and one with 1.175MB rows, joined on columns with indexes in both tables. At 6:45 a.m. the time to execute the query was 36 to 37 seconds. At 7:45 a.m. the time was 44 to 45 seconds. (Query results are available in the September Letters section on the DBMS Web site, www.dbmsmag.com.)
The query reads as follows:
SELECT COUNT (*) FROM agents,plan_transaction WHERE agents.agentid = plan_transaction.agentid.
Each agentid entry in agents has a set of corrsponding agentid entries in plan_transaction, so the result of the query is 1.175 Mb.
The query optimizer returned the following implementation scheme:
R> prompt
06/30/97 7:45:48
SelectCost=32.13846 (OptimizationTime=0ms) agents (IndexName=I61,Type=I) IndexOnly Dup=1 Adj=0.9928934
plan_transaction (ColumnName=agentid,Type=I) IndexOnly Dup=882.9256
Adj=0.7701336
We use Microrim Inc.'s R:BASE, which provides the ability to use the default automated query optimization and manually implement "rules"-based query optimization. Rules-based query optimization can be performed via settings and modifications to the conditional clause, similar to Oracle's technique. The aforementioned query utilized automated query optimization. There was no speed gain by manually implementing rules-based query optimization.
Ken Hamermesh
President, UMMG Software