RE: SQL Server vs. Oracle

From: Niall Litchfield <n-litchfield_at_audit-commission.gov.uk>
Date: Wed, 12 May 2004 15:45:29 +0100
Message-ID: <CFECD6EA683C524BB5FD22C0F1F34ACB01936CAA@bristol43.audit-commission.gov.uk>

>-----Original Message-----
>From: oracle-l-bounce_at_freelists.org
>[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Leslie Tierstein
>Sent: 12 May 2004 01:23
>To: oracle-l
>Subject: SQL Server vs. Oracle
>
>
>See:
>http://www.progstrat.com/research/gems/040401rdbmscmcs.pdf
>
>The poster on the SQL Server list where I found this reference
>was astonished that the report would find that 10g was easier
>to configure and administer than SQL Server.

It does suffer from the usual problems of being somewhat unfair to generalize. For example in the installation category the sql server install required SP3 to be installed - this indicates that the install was being done specifically on a windows2003 server, and that you are comparing installing a new release with installing a new release and patching it. I wonder how many steps installing oracle 9.2 and patching to 9205 on RedHat linux would have taken!

It also seems somewhat unrealistic:

proactive performance management consists of

Set OEM alert for BCHR < 80%

Er - that's it.

In day to day management they measure reorganising because of fragmentation (don't get me started) and compare

Manually running an 'advisor' once and accepting all advice given with setting up an automated job to 'fix' things on a scheduled basis.

They set the backup and recovery strategy in a similar manner, On MSSQL set a scheduled task to do this for you according to some requirements, on 10g accept the out of the box backup and recovery settings.

My favourite part SQL Tuning

Oracle - run ADDM (isn't that extra cost), run the SQL Tuning Wizard against the highest resource consuming SQL (not identified problem processes) and accept the recommendations. MSSQL - Manually trace problem processes - identify problem SQL and manually tune.

That is because

<quote>
For Microsoft SQL Server 2000, the process of tuning a poorly performing complex SQL Statement is mostly manual (index tuning being the only exception); therefore, given the fact that this task will almost always take a significant and variable period of time, we feel that 10+ minutes is a fair, conservative estimate of how long it would take an expert performance engineer to perform this task on Microsoft SQL Server 2000 against a wide range of tunable queries encountered in a real world environment. On the other hand, Oracle Database 10g's SQL Tuning Advisor tunes SQL statements more comprehensively by looking at all aspects of SQL tuning as they apply to the Oracle database, e.g., index creation, query restructuring, statistics analysis, and SQL profiling. Hence, no manual tuning was required in Oracle's case. The only interaction with the user is in launching the advisor and accepting its recommendations, once they are generated. </quote>

So no need for manual tuning ever again - there's lucky.

So in Summary I think that this paper proves that (with some extra cost options) it is very easy to create and maintain an Oracle database without ever having to think too much.

Niall Litchfield
Oracle DBA
Audit Commission
+44 117 975 7805

This email contains information intended for the addressee only. It may be confidential and may be the subject of legal and/or
professional privilege. Any dissemination, distribution, copyright or use of this
communication without prior permission of the sender is strictly prohibited.

Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line.

--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Received on Wed May 12 2004 - 09:48:02 CDT