RE: SQL Server vs. Oracle
- From: "Niall Litchfield" <n-litchfield@xxxxxxxxxxxxxxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 12 May 2004 15:45:29 +0100
>-----Original Message-----
>From: oracle-l-bounce@xxxxxxxxxxxxx
>[mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts: