Content area
Microsoft Corp., Sybase Inc, and IBM were asked to recommend a database server solution. Microsoft recommended its SQL Server 6.5 on Compaq's ProLiant 5000, with four 200-MHz Pentium Pro processors and 256MB of RAM; IBM recommended the DB2/400 relational database of OS/400, Version 3, Release 6 on its AS/400 9406 Model 50S, with one processor and 320MB of RAM. The solution Sybase recommended was Sybase SQL Server 11.02 on Hewlett-Packard's Mohawk. When all was said and done, the Microsoft/Compaq solution won the comparison because it was the best solution to the problem. Its overall speed was impressive, and it earned high scores in every category.
Full text
The relational database is an integral part of the enterprise. We ran two popular SQL databases through a battery of tests and found that you can have it all speed and ease of use for a reasonable price.
Being a database administrator is sort of like being a politician -- you've got to keep everybody happy. Your users, like constituents, make constant demands on the database you administer. Your customers, like lobbyists, can't conduct business with you if your database server is down. The corporate controller, who controls the purse strings, has ordered you to keep costs down. And finally, the collective lot of them expect the database to maintain the fastest possible speed regardless of the number of users accessing the system. This is no small task. Fortunately, the latest generation of SQL database servers are up to the challenge. All of which, hopefully, help you stay in office for at least another four years.
SOLUTIONS OR BUST. It's easy to get seduced by the vendor-speak of the latest TCP benchmark. Like 5-year-olds fighting over whose new bicycle is shinier and faster, database vendors are constantly touting a new benchmark using the snazziest, most expensive technology in a never-ending race to outdo each other. We know that even though you'd like to run your database on a system with 28 processors and hundreds of megabytes of memory, your budget probably won't allow it. Which is why we approached this comparison from the perspective of an administrator at a growing organization that has outgrown its current desktop database and is looking to upgrade to a relational database. And, most importantly, the administrator doesn't have a budget as bottomless as the federal government's.
Our fictitious company, Info World Distribution Inc. (IWDI), invited all of the SQL heavyweights -- Microsoft, Sybase, Oracle, Informix, and IBM - to recommend a database server solution to our problem (including server hardware, software, and a person to do the configuration and performance tuning). Of the five, and after much ado, Oracle and Informix declined to participate because of a lack of resources.
Microsoft recommended we test its SQL Server 6.5 on Compaq's ProLiant 5000, with four 200-MHz Pentium Pro processors and 256MB of RAM; IBM gave us the DB2/400 relational database of OS/400, Version 3, Release 6, on its AS/400 9406 Model 50S, with one processor and 320MB of RAM. The solution Sybase recommended was Sybase SQL Server 11.02 on Hewlett-Packard's Mohawk; unfortunately, the demand for that server is high and availability is low, so HP was unable to get us one in time for our tests. Sybase decided to go with Sun's Ultra Enterprise 3000, but we ran into a number of roadblocks, and, at the last minute, we had to pull the solution out of contention. (For more information on our experience with Sybase SQL Server, see article, page 75.)
When all was said and done, the Microsoft/Compaq solution won this comparison because it was the best solution to our problem. Its overall speed was impressive, and it earned high scores in every category (with the exception of support policies). IBM's solution, however, was a worthy opponent. It's a capable, robust system: The only caveat is that to get the most out of it, you must have a lot of AS/400 programming experience. Indeed, its overall performance was disappointing, and it's likely that it would have been markedly faster and more scalable if the system we tested had more processors. We did our best to get additional processors from IBM, but it seemed that wild horses couldn't get any out of them. So we ended up testing the system the way IBM originally gave it to us.
WAlK A MILE IN MY SHOES. To help the vendors decide what solution to recommend, we gave them a Request for Proposal (RFP) for our company and a few ground rules. The RFP described our business in detail, including our immediate needs as well as projected growth during the next few years. And the ground rules were to prevent the participants from doing anything sneaky. (Because no matter how much we try to act like a company in search of a solution, we know that the vendors are still aware of the bottom line: The results will be scored and published.)
A summary of the RFP follows: IWDI is a retail company that has grown dramatically in the past five years. It currently employs more than 2,200 people; it sells its products direct -- through a team of telesales representatives. The phones are staffed by at least 100 operators, 24 hours per day, seven days per week, although during peak hours (9 a.m. to 2 p.m.) as many as 450 people can be taking phone calls and, therefore, be logged in to the database server. IWDI expects to employ as many as 600 operators within two years.
The application used most heavily by IWDI is an order-entry online transaction processing (OLTP) application written in Visual Basic; it uses an ODBC driver to connect the clients to the database. Several of the most common queries used by the operators were created for them by the database administrator, but IS also supports a number of query tools that let users create custom queries.
The company has budgeted $400,000 for the project, which must include the following: database server software and hardware; any software or hardware necessary to connect the server to the clients (such as ODBC drivers or emulation software); and three years of server hardware and software support.
IWDI's goal is to obtain the fastest possible fault-tolerant database server that scales as the number of users increases.
The ground rules were few but steadfast: We let the vendors review our OLTP application code as well as the database structure. They could make recommendations to us on both counts to optimize the performance of their server. We then made the appropriate changes on-site in our Test Center lab; the vendor was not allowed under any circumstances to touch the actual code or database structure. Finally, the vendor could suggest the design of stored procedures to improve performance.
WHY WE DID WHAT WE DID. When we evaluated SQL databases in November 1994, performance was the most important factor when choosing a database. Backup and restore procedures came in a close second, and cost of administration and price rounded out the top three. Today, speedy response times and backup and recovery still top the list. System administration also remains important. But the proliferation of the Internet and the now more common implementation of a data warehouse has made a database server's capability to communicate to the outside world critical. We updated our test plan with these marketplace changes in mind.
There are two distinct types of administration. The first, database definition and maintenance, is static; the other, system administration, is dynamic. We evaluated both. In the database definition and maintenance category, we examined the process of creating and maintaining database structures as well as how easily we could create stored procedures and triggers and enforce business rules. In the latter, we evaluated the tools that help the administrator manage and troubleshoot the database server on an ongoing, long-term basis.
We did modify our benchmark tests. We ran six OLTP tests. For the first, we ran our OLTP application on 10 workstations without think times and 15, 30, and 60 workstations with think times. For the second, we ran 20 workstations without think times and 15, 30, and 60 workstations with think times. We also tested query response times, but we placed more weight on the OLTP benchmark.
Copyright Infoworld Media Group Dec 2, 1996