RE: Limitations of MSSQL Server Vs. Oracle OR simply otherwise limitations in general - OT

From: Marc Perkowitz <mperkowitz_at_comcast.net>
Date: Tue, 23 Nov 2004 10:26:16 -0600
Message-ID: <002201c4d179$2ccff250$34099943@MTPSYS>

We recently ported a Java application that was written initially for = Oracle
but using standard JDBC calls, to SQL Server. I was surprised at the = number
of code changes I still had to make. If anyone is interested, I can = give
details.

One aspect in particular is referred to below. To enforce = read-consistency,
SQL Server uses read-locking. However, in most cases, read-locking = turns
out to be unusable. You end up with a very slow or unworkable system = because
of lock waits and deadlocks, especially with a system originally = designed
for Oracle. So far, every SQL Server developer that I have talked with advises me to disable the read locking and asserts that this is the = normal
and accepted practice. This means that you permit reading uncommitted updates, which was quite shocking to someone coming from an Oracle background.

Marc.

-----Original Message-----
From: oracle-l-bounce_at_freelists.org =
[mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of Niall Litchfield
Sent: Tuesday, November 23, 2004 6:33 AM To: vivek_sharma_at_infosys.com
Cc: ORACLE-L
Subject: Re: Limitations of MSSQL Server Vs. Oracle OR simply otherwise limitations in general - OT

On Tue, 23 Nov 2004 16:36:17 +0530, VIVEK_SHARMA <vivek_sharma_at_infosys.com> wrote:
> Folks

>=20

> Limitations of MSSQL Server Vs. Oracle OR simply otherwise General
> limitations of MSSQL Server.

>=20

> Need to give a presentation to Management on the same=3D20

>=20

> Any Good Links, docs etc?

>=20
> Thanks in advance

I've said before that I think SQL Server is really a rather good product now, unless your target is an application with one or both of very high concurrency or very high transaction rates. Usually of course your management will envisage that any applications they run are world leading in size,scale and importance and so suggesting that MSSQL is limited in terms of scalability or throughput compared with Oracle is a big minus against MSSQL.

There are however a number of important differences.=20

Read-consistency doesn't exist yet in MSSQL, except by virtue of locking things. It is scheduled for SQL2005 though (and I think it will be there - it is in the Beta). This means that readers block writers and vice versa. This in turn means a well written Oracle app will behave abysmally if just ported to MSSQL, it should be rewritten. You all have well written Oracle apps right? That use Oracle specific features a sensible transaction model, bind variables and all the rest?

If you are looking at Datawarehousing - Oracle's featureset is considerably in advance of Microsofts. The microsoft one rather benefits from ease of understanding and use though :(.

Lex makes an important point in his paper about the split of UNDO and REDO - its probably this 'feature' that single handledly limits the available throughput for MSSQL.

Rebuilding indexes is a highly recommended activity in this environment though so plenty of 'tuning' opportunities there.

--=20
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l

Received on Tue Nov 23 2004 - 12:25:35 CST