Re: Microsoft destroys TPC-C records!

> Shakespeare didn't work with many databases, but I'm sure he'd
> agree that speed is superior to tunability. Still, I've talked with

Since when has speed and tunability become mutually exclusive? You can't have speed with tunability? Again, another crock of b.s.

> a lot of people recently who position Oracle as better because it's
> "more tunable" than SQL Server. True, Oracle 8i has more than 400
> tunable parameters while SQL Server 7.0 has fewer than 50--and that
> number drops in SQL Server 2000. The argument is that, because Oracle
> offers many more tuning parameters than SQL Server, you can make
> Oracle run more efficiently than SQL Server. However, this argument
> has a fatal foundational flaw: that "manually tunable" equals
> "optimal performance."

I'm sorry, but I'd rather have 400 tunable params than 50 anyday. The more control I have over my database the better. And the last thing I want is the database performing tuning for me. The database can not, nor will it ever, be able to fully understand my applications, how they relate and work together.  

> Database administrators and developers easily fall for this
> assumption. The engineer deep down inside us desperately wants to
> believe that we're smarter than the machine. We love to feel needed

We are smarter than the machine. A computer is only capable of doing only what we tell it to do. Nothing more, and unfortunately in some cases, nothing less.

> astonishing performance improvement. But it's time we got over
> ourselves. We're not that smart. And most of our tuning successes
> have come as a result of working with a database that couldn't do
> the job for us.

Most of our tuning successes have come as a result of working with technologies that are not up to par with our business needs. These technologies are a combination of hardware and software. Part of our job is to eke every drop of performance from our techologies when we have reached it's limits.  

> Remember when we optimized queries by listing tables and conditions
> in a certain order in the FROM and WHERE clauses? Wasn't that "tuning"
> the query? Today, no one seems to mind that cost-based optimizers find
> the best execution path for our queries. In fact, we'd laugh at a

I seem to mind. While cost based optimization is great and works in most cases, it does not always find the best execution path for our queries. Thankfully I can go back to rule based queries whenever I want.

> database product that didn't have a sophisticated cost-based optimizer.
> Why don't we expect the database engine to have the same level of
> intelligence?

Because it's very hard for a db to fully understand the applications that are running against and the users who use the db. After all, how is the db to know that I plan on performing a major load this weekend? Or that for the next week, I'll be experiencing a 50% increase in the number of users?  

> database code the job of tuning the database for shifting workloads.
> Microsoft says the result is a database that has few manual tuning
> parameters but that features rich automatic-tuning functionality,

I've always been weary of automatic, or self tuning databases. Too many times I've seen systems make adjustments based on data that is inaccurate.

> Don't lose sight of the real goal. We don't want tunable databases;
> we want fast databases. I've seen plenty of DBAs "tune" their system to
> run incredibly slow. By the same token, a simple set of tuning

Hey Microsoft! If you are listening.... We want TUNABLE database that are also FAST databases. If SQL Server is the panacea you claim it to be, why can't it do both? The real world out here is screaming for fast, tunable databases. Are you listening?

Just my 3.14159 cents worth,
Brian

-- 
========================================
Brian Peasland
Raytheons Systems at
  USGS EROS Data Center
These opinions are my own and do not
necessarily reflect the opinions of my 
company!
========================================