Re: Sybase v/s Oracle

From: Ken Clement <ken_at_letigre.com>
Date: 1996/08/01
Message-ID: <4tos8v$isi_at_uuneo.neosoft.com>


Jason Salem <jasonds_at_computerland.net> wrote:
>Srikanth Goli wrote:
>
>> Use SQL server from Microsoft. It is cheap. Does the job for the
>> kind of concurrent users you are talking about. Their 6.5 has
>> lot of new features too including web support, distribution
>> transaction controller.
>>
>> sri.

I think it would be worthwhile to look into Sybase SQL Server for NT as well. I haven't done any direct price comparisions lately, but I've heard from colleagues who have that the prices are compariable (as long as one stays in the NT world). Sybase SQL Server 11 has a number of features not found in Microsoft SQL Server for larger databases including configurable named memory caches, private log caches, data slices, & other stuff to support VLDB and lots of users.

>
>I would tend to agree here. MS-SQL Server is a good
>workgroup/transactional RDBMS. If you go over 100-150 users, have a lot
>of batch/reporting and can't have a separate server for reporting alone,
>or have a VLDB, then I'd recommend Oracle for it's better handling of
>the following: locks - in MS-SQL readers block writers (as in sybase)
>which brings about the recomendation for a separate report box.

I have also run into contention issues when trying to do "heavy duty" reporting out of an active database in the SQL Server world (either Microsoft or Sybase). Typically I've dealt with this by creating a seperate reporting database, not a seperate reporting server running on its own box. With SQL Server multiple, seperate databases can exist under a single server. If this approach yeilds unsatisfactory results and a seperate reporting box is called for - then it will probably be needed no matter whose database engine is used.

>Transaction/redo logs - MS-SQL has one monolithic logfile that, if it
>fills, halts the DB until such a time as it is dumped to null. Oracle
>goes round-robin between as many logs as you please, moving old ones to
>an archival location (if you are in archivelog mode). Granted, you can
>get around the way MS_SQL handles this, but it's extra overhead that in
>a large system would tend to enhance the chances of a blowup, IMO.

With Sybase SQL Server 11 (starting with v10 I believe) you can specify a threshold on the transaction log and actions to be carried out when it is reached - such as dumping the transaction log to backup media, or paging the administrator, etc.

>Lastly, corruption - I have not directly seen MS-SQL corrupt, but have
>seen several posts, and our main corporate ofice experienced a MS-SQL
>corruption fairly recently. I have only seen Oracle corrupt once as an
>internal problem, and one drive badspot that was truly a unix problem.
>Going on this, it seems to me in a rough qualitative sense that Oracle
>is more resistant to corruption.

I don't know about data corruption and MS-SQL 6.5 (their latest and greatest) I know that Microsoft has put a lot of work into their SQL Server product so that its entirely possible that there are some data corruption bugs, though I haven't seen any. Sybase SQL Server 10 (the previous major release) had a number of serious bugs for which Sybase got (deservedly) bad press. But their current release, SQL Server 11, appears to be their best kept secret. I've spoken to a number of their big clients and all were extremely pleased with the product's performance (and lack of bugs).

>Perhaps this is due to the fact that
>the server will down if it hits any sort of moderately serious error,
>whereas MS-SQL seems to just sort of log it and go on. I'd rather
>explain downtime than clean corruption, but that's just me.
>HTH and wasn't _too_ much ranting <g>
>--
>Jason Salem
>Database Administrator
>DATASTORM Technologies, Inc./Quarterdeck Communications Division

I agree with Jason that if very large numbers of users and VLDB are issues, then Microsoft SQL Server may not yet be the platform of choice. But I don't think that this problem will manifest itself at only 150 users especially since MS-SQL can run on RISC boxes (such as DEC Alpha) with up to 4 SMP CPUs (beware you're getting 32bit instead of 64bit, but still powerful). Depending on your server platform of choice the number could easily be in the upper hundreds or lower thousands. So if this is in your range, capacity would not be an elimination.

Most of the comparitive analysis above was MS-SQL / ORACLE. However, I would not overlook Sybase SQL Server. In addition to the points above, its price/performance ratio is almost always better than its competition, and the scability of the System 11 product is by all accounts very impressive.

Ken Clement
ken_at_letigre.com
LeTigre Consulting, Inc. Received on Thu Aug 01 1996 - 00:00:00 CEST

Original text of this message