SQL Server Instances

  • Hi guys,

    My boss just recently asked me to present to him the pro's and con's of using SQL Server instances, and when should you consider that sort of configuration. Any ideas, comments, reccommendations to share?

    TIA,

    Aurora01


    Aurora

  • I've got an enterprise dev and prod box with 8 instances each.

    Pros: One server supports multiple instances.

    Cons: One server supports multiple instances.

    They are not really instances, they are really multiple installations of SS2k. They do not share the same base code, only a few limited items (see BOL). Every time you have to apply SP's that need a server restart (SS2K or OS) you have an outage of ALL instances.

    IMHO - I hope it gets better w/ Yukon

  • Another thing to consider is what types of servers you're consolidating. As gfarlander pointed out, one of the drawbacks is that you have multiple instances on one server. You certainly wouldn't want to incorporate a mission cricial application on a server that has another application prone to failure. You also don't want to mix OLTP and DSS type databases on the same physical box, unless you have separate disk arrays (OLTP tends to be sequential disk access, DSS tend to be random).

    As far as when to consider it? If you have high hardware costs or your hitting a limitation as to how much hardware you can add (limited rack space,power,network ports), multi-instancing could come in handy.

    If you do decide to multi-instance, be sure to have quantitative documentation of the performance and capacity requirements of each instance. You definitely don't want to consolidate only to have the server get bogged down or run out of disk space...

    My 2 cents.

  • Another item to consider is licensing. With standard edition you pay for each instance while with Enterprise edition you pay per active physical node so you can run multiple instances without an increase in licensing costs. There are some other benefits, such as security, but in general we run one instance per physical server.

  • Thanks guys, all of this makes perfect sense. Now let me organize it into a brief to the point Pro's and Con's.

    Thanks again for the feedback, it was very helpful.


    Aurora

  • important: use current db libs for client access, otherwise you won't be able to access other than default instance (seen on crystal reports). more general: check if your client side apps (so you're using such) still can connect to named instances.

    best regards,

    chris.

  • To follow on Chris's comments, my DB was thrown on a separate instance because I need SA permissions, something the DBAs don't like to hand out on a shared box. We did initially run into problems because our app couldn't connect to a named instance. The solution was to create an alias using cliconfg.exe (aka, SQL Server Client Network Utility). This lets you come up with an alias that points to the port of your named instance. Seems to work great.

    Jeff

Viewing 7 posts - 1 through 6 (of 6 total)

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