Exploring SQL Server 2000 Configuration Properties

  • Comments posted to this topic are about the content posted at http://www.sqlservercentral.co

  • Hi.

    Just to point something:

    "Key points (Figure 6):

    SQL Server Standard Edition supports up to 4 processors.  Advanced Server supports 8 processors. Data Center Server supports 32 processors."

    I think you're really meaning MS Windows

  • Mithrandir,

    From the mouth of Microsoft:

    "On Windows 2000, standard editions of SQL Server support up to four processors. Enterprise Editions support up to 32 processors (8 with Advanced Server and 32 on Data Center Server)." 

    I suppose I should have clarified the part about SQL Standard Edition which supports up to 4 processors on Windows 2000 vs. SQL Server 2000 Enterprise Edition (which supports 8 processors on Advanced Server and 32 processors on Data Center Server).  Sorry about that.  The wording was unclear.  Please see the reference link at the bottom of the article to go to Microsoft's Pocket Consultant for SQL Server 2000 for further details.

  • A really nice reference resource, good work, man !

  • An excellent reference resource

  •  This article is more like a reference material or white paper. I feel it is bit dry..

  • There are some serious errors and misconceptions and this is only going to add to more users messing with options they don't understand!.

    Procs, the number are doubled under w2k3 and procs are also depenedant upon the underlying o/s. You should never check the reserve physical memory unless you are using a fixed memory ( with min and max the same ) Note that once you use awe or instances you MUST fix memory sizes otherwise you will have problems.

    Boost priority should ONLY ONLY ONLY ever be used if ms support tell you, this setting causes major problems. ( it was I understand added for SBS where multiple apps run on a server - the guys I've spoken to at microsoft wish this option was removed as it causes so many support calls )

    fibre mode is relevent only on large multiproc boxes where cpu is almost maxed out and you have very high levels of context switches.

    I could go on -- I fail to see how you can quote the admin guide - did you really read it properly? and how on earth did you come to some of your calculations?

    My advice ( and that of microsoft ) is that unless you really know what you're doing and then really only if microsoft support tell you all config settings should remain "out of the box" Changing settings on a production server could easily bring the system down.


    [font="Comic Sans MS"]The GrumpyOldDBA[/font]

  • This is an excellent article for the GUI DBA ... There is also enough information to get the inexperienced DBA in real trouble as well. However the one piece of information that is missing (as in many SQL things these days) is the command line equivalents for everything there. After all most DBAs rarely do things just once, it's usually many times. The only way tio be truly efficient is to 'automate' it - i.e. script it and become a COMMANDLINE DBA !

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

  • woman!

    David Russell
    Any Cloud, Any Database, Oracle since 1982

  • Rudy - I totally agree! I normally work within controlled production environments where the use of the GUI is an absolute no-no. You'll never get SOX using the GUI !!! I still worry about some of the content, still it's these changes which keep me employed when i go in and fix the mess < grin >

    [font="Comic Sans MS"]The GrumpyOldDBA[/font]

  • Colin,

    "Cheers to 'the mess'"

    ... excuse the citation ...

    I mean our livelyhood !

    RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply