Re: Oracle versus Sqlserver

You'd think I would know by now - don't post to a newsgroup after a long night in the pub!

But I think really your list can be condensed to:

the mechanism used to prevent dirty reads ie multiversioning vs locking the mechansim used to record locks ie in memory vs in data

Daniel A. Morgan <damorgan_at_exesolutions.com> wrote in message news:3C460F48.1C9E8D6D_at_exesolutions.com...
> Well I presume the initial posting was intended to start a flame war so it
would
> be almost rude not to jump in ... right?
>
> I've seen this list before. In fact I use it in my class at the University
of
> Washington to demonstrate how most of the comparisons made between
products are
> totally pointless and are just done to inspire angst and release
testosterone.
>
> Want to deal with real differences? Deal with:
>
> 1. Multiversioning
> 2. Read consistent queries
> 3. Blocking reads
> 4. Blocking writes
> 5. Atomicity of SQL statements
> 6. Lock escalation
>
> Daniel Morgan
>
>
>
> Keith Boulton wrote:
>
> > I am an Oracle developer but:
> >
> > >
> > > 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
> > No it isn't
> >
> > > 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
> > But sql server is considerably faster and in most cases you can design
> > around this issue just like you can design around "snapshot too old"
> >
> > > 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.
> > Not generally an issue, given it doesn't occur until > 10,000 rows. cf
> > performance impact of oracle data block update
> >
> > >
> > > 3. PERFORMANCE and TUNING
> > >
> > > a. No control of sorting (memory allocation)
> > But Oracles sorting algorithm is crap - ignore available memory when
> > sorting.
> >
> > >
> > > b. No control over SQL Caching (memory allocation)
> > Not sure if this is true
> >
> > > c. 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.
> > Funny how oracle have moved to locally managed tablespaces. -> proof of
> > performance impact
> >
> > >
> > > d. 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.
> > Useful for <1% of applications
> >
> > > e. No Log miner facility. Oracle 8i and 9i supply a Log Miner which
> > > enables inspection of archived redo logs. This comes free with the
> > If only it didn't crash when you tried to use it!
> >
> > >
> > > f. A Sql-Server dba claimed that fully qualifying the name in code
> > > would lead to performance gains of 7% to 10%. There are no dictionary
> > But from what base?
> > Irrelevant to stored procedures which is the recommended approach for
> > sqlserver
> >
> > > 4. MISSING OBJECT TYPES
> > > a. No public or private synonyms
> > Largely irrelevant given dbo
> >
> > > b. no independent sequences
> > A pointless waste of resources
> >
> > > c. no packages ie. collection of procedures and functions.
> > so?
> >
> > > 5. PROGRAMMING
> > >
> > > a. Significant extensions to the ANSI SQL-92 standard which means
> > > converting
> > > applications to a different database later will be a challenge
(code
> > > re-write).
> > Oracle is SO standard.
> >
> > >
> > > b. No inbuilt JAVA database engine as in Oracle. In Oracle, Java
classes
> > Welcome to the slowest common denominator.
> > Please try to understand the point of n-tier architectures.
> >
> > > c. Stored Procedures are not compiled until executed (overhead).
> > Are we talking about oracle or sqlserver here - given that neither are
> > compiled?
> >
> > >
> > > d. No ability to read/write from external files from a stored
procedure.
> > Not true
> >
> > > e. Oracle Sql and Pl/Sql are more powerful and can do things better
than
> > > Microsoft Transact-Sql.
> > see n-tier architecture
> >
> > > f. In Sql Server, you cannot issue a "create or replace" for either
> > big deal
> >
> > > 6. CLUSTER TECHNOLOGY
> > > In clustering technology, Oracle is light years ahead, since
> > > Sql server has nothing like Oracle Parallel server - 2 instances
> > I'd like to spend more on the licence for a database feature than the
> > combined cost of database and hardware please!
> >
> > > the new version of Parallel Server in Oracle 9i, renamed as the
> > > Oracle real application cluster, there is diskless contention
> > > handling of read-read, read-write, write-read, and write-write
> > 10 fucking years after any semi-compentent ape would have implemented
it.
> >
> > Please fuck off you retarded troll.
>
Received on Thu Jan 17 2002 - 02:45:36 CST