Re: Oracle versus MS Sqlserver 2000: Technical Comparison of the Features in the two databases

Can I ask what the point of this bit of anti-MS bashing is? The audience in this group presumably has already bought into the Oracle model, so it seems to be rather a waste of time.

As it happens, if you are a Windows shop, I think you would seriously want to question any proposal to install anything other than SQL Server. The Windows architecture plays merry havoc with Oracle performance, but suits SQl Server rather nicely.

And issues such as a lack of multi-versioning (read consistency is the term I prefer) can be designed around. And is, frequently.

> 4. PERFORMANCE and TUNING
>
> a. No control of sorting (memory allocation) in Sql Server.
> Oracle can fully control the sort area size and allows it
> to be set by the Dba.

Have I introduced you to PGA_AGGREGATE_TARGET yet?? It's the way of the future, so this particular point is moot.

> b. No control over SQL Caching (memory allocation) in Sql Serv.
> This is controllable in Oracle.

This is like saying apples don't taste like Oranges! SQL Server grabs whatever it can from the server, and dynamically aquires it and releases it as needed. Pretty neat, actually.

Come on: sell Oracle on its merits (of which it has an abundance), not on a pretty naff comparison with A. N. Other product, which doesn't compare legitimately in any case. And an absence of obvious propaganda would also make more sense.

> c. No control over storage/space management to prevent fragmentation in
> Sql Serv. 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. In Oracle, this is
> fully configurable.

Hang on: get your facts right. Fragmentation is *caused* by DBAs and developers having way too *much* control over the size of extents. Welcome to the wonderful world of Locally Managed Tablespace, where such control is largely taken away from you. And nothing is contiguous anyway, so the contiguity argument is a load of rubbish, frankly.  

> d. No range partioning of large tables and indexes in Sql Server,
> whereas in Oracle a large table (eg. 100 GB or more) 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.

Can be, can be. Provided you pay extra for the partitioning option. In SQL Server's target market, it has to be said that the *need* to partition 100GB tables is pretty small. They are relatively speaking unlikely to meet such tables.

> e. No Log miner facility in Sql Server. Oracle 8i and 9i supply a
> Log Miner which enables inspection of archived redo logs.

Actually of ANY redo log, archived or not. If you must peddle this sort of stuff, get your facts straight.

>This comes
> free with the database. But in the case of Sql Server, external products
> from other companies have to be purchased to do this important Dba
>task.

If it's that important, you'll have no difficulty explaining WHY it's so important, will you?

>
> f. A Sql-Server dba claimed that fully qualifying the name of an object
> in Sql Server code would lead to performance gains of 7% to 10%.
> There are no dictionary performance problems like that in Oracle.

Clearly, you've never had a plethora of public synonyms. There *can be* performance problems related to such dictionary issues.

> 5. MISSING OBJECT TYPES IN SQL SERVER
>
> a. No public or private synonyms
>
> b. no independent sequences

This really annoys me, frankly. Its apples and oranges time again. Why don't you save yourself some time and just post a message saying 'SQL Server is crap'? I actually like the SQL Server 'identity' auto-incrementing data type. I wish Oracle had something similar. The lack of sequences in SQL Server is not a 'missing object type' if you consider that they have something else which does the job very nicely, and rather more simply than the Oracle equivalent.

> 6. PROGRAMMING
>
> a. Significant extensions to the ANSI SQL-92 standard in Sql Server,
> which means converting applications to a different database later
> will be a challenge (code re-write).

And Oracle's move to SQL-99 compliant syntax in 9i doesn't have exactly the same drawback? Should we just stick to SQL-77 (or whatever it was back in the stone age) to maximise compatibility?

>
> b. Sql Server has no inbuilt JAVA database engine as in Oracle.

And some might say that's a bloody good thing! Come to think of it, so might Oracle Corporation themselves, who are now pushing the deployment of Java onto the middle tier (ie, the application server) and not the back-end.

> In Oracle, Java classes can be loaded and executed in the database
> itself, thus adding the database's security and scalability to
> Java applications.

And thus contributing to a host of performance issues.

>
> c. In Sql Server, stored Procedures are not compiled until
> executed (overhead). In Oracle, packages and procs/functions
> are compiled before execution.

Uh huh. So this new feature of 9i whereby you can choose to have them compiled into C instead of into byte-code which has to be interpreted at run time is just a figment of my imagination is it? Guess what the default is!

> e. Sql Server uses cryptic commands for database adminstration like:
>
> exec sp_addrolemember N'db_datareader', N'davidb'
> GO

Come off it. One piece of syntax is as cryptic as another if you are new to the product. Who gives a damn? We have the Big Boys' Book of SQL Syntax to get us through such issues.

And if we're going to compare like with like, how about

'exec dbms_resource_manager.blah blah blah'. A nastier piece of syntax than setting up Resource Manager I can't think of.

I've snipped the rest. It's boring. Oracle is a fabulous product. And I like SQL Server too. But this sort of bogus comparison doesn't deserve the bandwith.

Define your business problem. Define your business environment. Select the right tool for the job. Sometimes it will be SQL Server, sometimes Oracle. You shouldn't get slated for making the appropriate choice in the appropriate circumstances.

You should get slated for bringing "religion" into what should be a cool, calculated evaluation.

HJR Received on Mon Mar 10 2003 - 02:59:37 CST