Re: My database is too fast

Teppicamon wrote:

> Comments inline... And please don't think I'm flaming, they're just
> answers from my personal experience with SQL Server, just as yours seems
> to be really good with Oracle ;-)

My posting was tongue-in-cheek seeing that there's so many postings around here regarding slow databases, SQLs and performance. BTW, the select count(*) stuff is all true. :-)

Got nothing against SQL-Server myself. Used it extensively in the 90's. Was working for a company that was one of the 1st local Microsoft solution providers (as oppose to a product provider). At one stage I ran into a weird db problem and phoned the local MS Support. In return they gave me my name and phone number with a "All SQL-Server support is now handled by our certified solution provider partners. Phone him as he will be able to help." Yeah right... as usual (in that company) I was the last to know what the hell was going on...

> Not at all, believe me... We wrote one application using SQLServer that
> made some quite complex queries on a materialized view resulting of
> joining five tables, one of them of about 50 million rows (guess the size
> of the view, then ;-) ).

Back in Oracle Parallel Server 7.3.2. Fact table was about 170 million rows (small in today's term, but sizeable back then). A complex query with a join to several other tables (3 to 5 tables as I recall) took less than 2 seconds. (the query did a medical procedure profile). Of course, it was tuned and put together especially for demo purposes... (no cheating though with pre-processed/calculated results) :-)

> and asp interpretation overhead) in less than two seconds... I must
> confess that I'm quite happy with Oracle also, but I really think that in
> general you're really misleaded about what SQL Server can and cannot do
> with similar hardware... or even with slightly worse hardware...

Interesting comment.. but then I have not yet seen SQL-Server running on anything bigger than a 4 CPU SMP box (we never went into the specialised HAL stuff for bigger SMP Intel boxes). Nor do we run Oracle on Windows SMP, so in that aspect it is not comparing apples with apples.

What I do remember though is that we had a lot of issues with indexes and page locking. Indexes required a rebuild often. DBCC had to be run often. In general, a lot of maintenance... But then that was also back with 6.5...

Even so - the db platform ran a mission critical database for several 1000 users on a nationwide WAN. The stories that SQL-Server and WinNT are not capable are just that - stories. The facts differ. I had a rant on exactly this topic yesterday.

> Nah, don't think so... He's quite happy with what he's got. If not, he
> would just buy Oracle and rename it as Oracle.NET ;-)

The Great .NET Equaliser. Introducing Octane. Running in the Sidewinder IDE.

Delphi rules. Microsoft drools. :-)

> Developers using SQL Server never needed DBA assistance other than
> restoring some backups or creating logins... They just write good SQL and
> voilą!! Good performance is there...

Beg you pardon for the blunt language, but that is bullshit IMO. Very few developers can write "good" SQL. They all know "very basic" SQL and have some vague notion of things like transactions and what a database does.

Maybe you're lucky in dealing with developers that do know Transact SQL very well and do know SQL-Server very well. This is however not the norm IMO from having experienced exactly the opposite in the SQL-Server, Informix and Oracle development environments.

My opinion - the single biggest factor causing problem issues around databases is ignorance.

The "architect" is clueless about what the database can provide (he treats it as a black box).

The developers are clueless about the basic behaviour of the database - and also treat it as a black box.

Then we wind up with partially normalised databases. OLTP tables where the ratio of table data to index data is 1:1 or even greater. With horrific SQLs that were left untouched as despite it all, the database is still able to do that crap SQL within "acceptable limits".

Thus the reason for my posting. A select count(*) on a VLT *can* be done in seconds.. unlike the perception of the _vast_ majority of "architects" and developers that it will take 20 to 30 minutes.

Know Thy Database. (pointing to myself too - I need to seriously brush up my Oracle skills in certain areas)

--
Billy