Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle vs SQl Server

Re: Oracle vs SQl Server

From: Sybrand Bakker <postbus_at_sybrandb.demon.nl>
Date: Thu, 21 Dec 2000 21:19:24 +0100
Message-ID: <91togv$5clgf$1@ID-62141.news.dfncis.de>

Evidently this discussion has been conducted numerous times before. One common attribute of sqlserver addicts is they never read any manual and they never search deja.com forcing the group to answer the same questions over and over again.
If you would know anything about Oracle you would know Oracle is scalable, it is not platform dependent as sqlserver is

I will quote a previous post in full as that adequately summarizes reasons.

Start quote

  1. Single platform dependancy.

SQL Server is only operable on the Windows platform, and this is a major limitation
for it to be an enterprise solution. Oracle is available on multiple platforms such as
Windows, all flavours of Unix from vendors such as Ibm, Sun, Digital, HP, Sequent,
etc. and VAX-VMS as well as MVS. The multi-platform nature of Oracle makes it
a true enterprise solution.

2. Locking / concurrency

SQL Server has no multi-version consistency model which means that "writers block readers
and readers block writers" to ensure data integrity. In contrast, with Oracle the rule is
"readers dont block writers and writers dont block readers". This is possible without
compromising data integrity because Oracle will dynamically re-create a read-consistent
image for a reader of any requested data that has been changed but not yet committed.
In other words, the reader will see the data as it was before the writer began changing
it (until the writer commits). SQL Server's locking scheme is much simpler (less mature)
and will result in a lot of delays/waits in a heavy OLTP environment.

Also, SQL Server will escalate row locks to page level locks when too many rows on
a page are locked. This locks rows which are uninvolved in any updates for no good reason.

3. PERFORMANCE and TUNING

  1. No control of sorting (memory allocation)
  2. No control over SQL Caching (memory allocation)
  3. No control over storage/space management to prevent fragmentation. All pages (blocks) are always 8k and all extents are always 8 pages (64k). This means you have no way to specify larger extents to ensure contiguous space for large objects.
  4. No range partioning of large tables and indexes eg. in Oracle a large 100 GB table can be seamlessly partitioned at the database level into range partitions, for eg. an invoice table can be partitioned into monthly partitions. Such partitioned tables and partitioned indexes give performance and maintenance benefits and are transparent to the application.
  5. MISSING OBJECT TYPES
  6. No public or private synonyms
  7. no independent sequences
  8. no packages ie. collection of procedures and functions.
  9. PROGRAMMING
  10. Significant extensions to the ANSI SQL-92 standard which means converting applications to a different database later will be a challenge (code re-write).
  11. No JAVA database engine as in Oracle
  12. Stored Procedures are not compiled until executed (overhead).
  13. No ability to read/write from external files from a stored procedure.

SUMMARY.
SQL Server is clearly positioned between MS-ACCESS and ORACLE in terms of functionality,
performance, and scalability. It makes a work group level solution (small number of users with
small amount of data). Oracle is much more advanced and has more to offer for larger applications
with both OLTP and Data Warehouse applications, and its open-source nature makes it the
most convincing argument for an enterprise.

end-quote

In short, after numerous years as development sqlserver still is a *toy* like Access is, and Oracle is a mature, robust and scalable product, which you couldn't say of most Microsoft products.

Regards,

Sybrand Bakker, Oracle DBA

<dlander1525_at_my-deja.com> wrote in message news:91tj16$ink$1_at_nnrp1.deja.com...
> I work in a SQL 7.0 development shop where a rebel element is working
> overtime to convert us to Oracle presenting it as the Holy Grail of
> database engines. I confess I know very little about Oracle but most of
> the reasons they are presenting to justify the switch seem to be things
> already offered by SQL 2000.
>
> Maybe I am just being difficult but I can't find any motivation to
> switch unless we are going to gain access to a whole new level of power
> and capability.
>
> Can anyone provide me some insight into the relative merits of Oracle
> vs SQL 2000?
>
>
>
>
> Sent via Deja.com
> http://www.deja.com/
Received on Thu Dec 21 2000 - 14:19:24 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US