Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: SQL Server vs. Oracle

Re: SQL Server vs. Oracle

From: Niall Litchfield <>
Date: Thu, 3 Jun 2004 10:50:57 +0100
Message-ID: <> outlines quite well the tool that is appropriate for use with sqlserver and that is what they call serverside tracing. The trace file that is generated is not anywhere near as useful as a 10046 level 8 trace (and if you thought that the event syntax in Oracle is cryptic you should see the sp interface for tracing in mssql). Never the less usable information is there.

There are 2 basic problems that I see prevalent in the MSSQL community though

  1. I agree with John that whilst excessive elapsed time is used to determine a poorly performing process, the focus of tuning efforts isn't on the makeup of that elapsed time. I think this is partly due to still being in what I call the sysadmin mode of what % of x resource is being used so we look at BCHR, %processor time and all sorts of other tangential metrics. It is also partly a problem of the underlying product - so you find that you spend all your time waiting for a hot page. How are you going to fix this within sqlservers limitations?
  2. The basic admin interface is really really straightforward - though I hate the fact that the mmc shows you out of date information and doesn't refresh reliably. Then you move from click here, set this checkmark here, run this wizard to code like this
    • Declarations
declare @rc int
declare @TraceID int
declare @maxfilesize bigint

set @maxfilesize = 50000
declare @on bit
set @on = 1
declare @intfilter int
declare @bigintfilter bigint

clear as mud really.

oh and 3 which has only just occurred to me but happens with Oracle systems as well - the question John paraphrases is exactly the sort of question that gets asked - how can I fix my "system" not "this order process has problems".

Niall Litchfield
Oracle DBA On Wed, 2 Jun 2004 15:15:54 -0700 , John Kanagaraj <> wrote:
> Fernando,
> >SQLServer suffers from the same "syndrome" as Visual Basic: it makes
> >the easiest parts of programming (in VB) or of administration
> >(SQLServer) easier. But the hard parts actually get much harder. So,
> >the experience of administering a large, production SQLServer2k db is
> >probably as nasty as maintaining/upgrading a large VB app.
> I was just looking up one of the SS forums - the (paraphrased) question was
> "What can I do to make my 1000 user Website backed by SS2K go faster?" And
> the answer (again paraphrased) was 'Use DML with the 'with nolock'"
> parameter!! SS2k suffers from basic concurrency, transaction management and
> scalability issues. [And they only recenly moved from the Block-level lock
> to the Row-Level lock mode in SS2k (or was in in 6.x?)] Not sure what the
> new 'Yukon' version does though...
> >One thing is that SQLServer doesn't give as much control as you can
> >expect, so when things like "why is this so slow" happens,
> >life is much
> >harder. Of course, things really go bad when you have a very large
> >legacy VB code using SQLServer2k and everything is very slow and they
> >just call you to "optimize this" (where "this" can be legacy vb code,
> >db schema, sql, etc, etc).
> I think this sort of thing is available - just that the SS2K community
> hasn't quite figured out how to really use trace, bind vars, Cost
> optimization, Wait event based tuning and ultimately good SQL tuning. [MS
> has also not released much information as well] It seems that the
> master.dbo.sysperfinfo does contain Stats (including the 'Buffer Caceh Hit
> Ratio'!!!) and master.dbo.sysprocesses does contain basic Wait event info,
> including 'PAGEIOLATCH_SH', 'PAGEIOLATCH_EX', 'NETWORKIO' etc. However,
> there is either no or mimimal information on this very basic event out
> there...
> John Kanagaraj <><
> DB Soft Inc
> Phone: 408-970-7002 (W)
> Listen to great, commercial-free christian music 24x7x365 at
> ** The opinions and facts contained in this message are entirely mine and do
> not reflect those of my employer or customers **
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ:
> ----------------------------------------------------------------
> To unsubscribe send email to:
> put 'unsubscribe' in the subject line.
> --
> Archives are at
> FAQ is at
> -----------------------------------------------------------------

Please see the official ORACLE-L FAQ:

To unsubscribe send email to: put 'unsubscribe' in the subject line.
Archives are at
FAQ is at
Received on Thu Jun 03 2004 - 04:47:45 CDT

Original text of this message