Re: MS SQL Serveror ORACLE?

From: Buck Webb <bwebb_at_lightind.com>
Date: 1998/03/16
Message-ID: <350d5eea.15376226_at_news.clark.net>#1/1


On Mon, 9 Mar 1998 15:44:06 -0500 , Mike Adams <103701.1437_at_compuserve.com> wrote:

>What are you trying to do that causes it to crash?
>
>Basta wrote:
>
>> My SQL Sever 6.5 SP3 have CRASHED 3-RD TIME while working with Access
>> 97
>> database!
>> I am going to change SQL Server to ORACLE.
>> Have anybody Something to say?
>>
>> --
>> Russian Automotive Publishing House "Za Rulom"
>> Computer Division
>> Ruslan Sulakov
>> mailto:ruslan_at_zr.ru

In its current incarnation (SQL 6.5, any SP you care to name), NT SQL server doesn't support large databases with lots of inserts & updates, in my opinion.

I've just spent one horrific 13 days after getting called in to evaluate the problems with a large DB install. Large in this case defined as a moderate DB (6 gigs), but mostly concentrated in one table (> 7 million rows).

That single table experiences hundreds of thousands of inserts and updates a day. The server regularly experiences table/index corruption (page allocation faults, mostly), in the big table.

 I've gone through many, many MS Engineers on this, and the only thing they can say is DBCC regularly. Great, but DBCC doesn't correct these particular problems, it only reports them. Too late by then.

Not to mention the fact that a dbcc checkdb takes 7 hours to run on this quad 200mhz system with 512 meg o' ram. By the time you throw in the newallocs, dumps, etc, you're down to having only 12-14 hours of the day available to work. The rest of the time, you're checking for errors.

MS' solution is to buy another machine, copy dumps/logs across to it, and let it dbcc while production work continues. Yech.

DBCC turns out to be (in my opinion) just a fancy mechanism to find the errors brought about by poor product maturity.

I've got Oracle sites running this software, and NEVER hear about this kind of problem.

That's the bad news...

The good news is that, within it's limits, it's the best one to use if you don't have strong, dedicated IS staff. It can install and go and go, and we have several of them out there doing that. It just seems to me to choke for us when the inserts/updates are large and the table in question is large.

Just my opinion. Received on Mon Mar 16 1998 - 00:00:00 CET

Original text of this message