Four instances of SQL Server

  • I am planning a new SQL Server for our shared hosting business and reducing licensing cost is a major consideration.

    I am planning a 3GHz Xeon with hyperthreading and 8GB of RAM on a Windows 2000 Advanced Server.

    I intend to run four instances of SQL Server 2000 standard edition each taking 2GB of RAM. This will isolate instances from others in case some high usage user brings down the whole instance.

    I wanted to ask if anyone else has tried this configuration? If yes are there any problems or tips for such thing.

    Since there will be too many small databases on this server, we intend to take per processor license. As far as I can see, I will only need one processor license for SQL Server. Correct? If anyone has any insight into such a licensing scheme, please let me know.

  • This was removed by the editor as SPAM

  • Incorrect. Each Std instance needs a separate license. If you buy Enterprise edition, you can install unlimited instances.

    http://www.sqlservercentral.com/columnists/sjones/sqlserverlicensingresources.asp

    Steve Jones

    sjones@sqlservercentral.com

    http://www.sqlservercentral.com/columnists/sjones

    http://www.dkranch.net

  • This is what I read in the licensing doc.

    Processor License – A Processor license is required for each processor installed on each server running SQL Server or any of its components (for example, Analysis Services). It includes access for an unlimited number of users/devices to connect from either inside or outside the firewall. Customers do not need to purchase additional Server Licenses or Client Access Licenses (CALs).

    Processor licenses are available in both Enterprise and Standard Editions and offer tremendous simplicity.

    I would assume that it will allow me to run any number of SQL Server instances/users/devices etc. as long as the processor is licensed.

    Can anyone clarify that if I am running four instances of SQL Server on a single processor, I need to pay the same price as if I was running four instances on a four processor box?

  • This is what it says in one of the documents from the link that Steve put here.

    MULTIPLE INSTANCES

    SQL Server 2000 includes a multi-instancing feature which allows customers to install SQL Server more than once on a server. This is used in hosting and multi-application environments, for example. Customers using SQL Server Standard Edition must fully license each instance server (whether in per-seat or per-processor mode). Customers using SQL Server Enterprise Edition can install an unlimited number of instances on each machine without requiring any additional licensing.

    So i think that yes, you would need to licence each instance.


    Growing old is mandatory, growing up is optional

  • Hi

    Customers using SQL Server Standard Edition must fully license each instance server (whether in per-seat or per-processor mode).

    is this also apply to sql2005 std version?

    Thanks,

    Jack

  • ...from the SQL 2005 "how to license" document.

    http://download.microsoft.com/download/e/c/a/ecafe5d1-b514-48ab-93eb-61377df9c5c2/SQLServer2005Licensingv1.1.doc

    <quote>

    Virtualization is defined broadly as the running of software on a “virtual environment.” A virtual environment takes place when an operating system (OS) is somehow emulated, or does not run directly on the physical hardware.

    When software is virtualized, one or several applications and their associated operating systems can run on one physical server inside their respective virtual environments. One of the benefits of a virtualized scenario is that multiple applications can run concurrently on a server with isolation at the OS level.

    An option to virtualizing software is multi-instancing. In this case, multiple copies of an application run concurrently on a single copy of an OS. Multi-instancing for SQL Server 2005 can take place both in a virtual environment or in a physical environment. While multi-instancing offers a relatively high degree of isolation between copies of SQL2005, this isolation takes place at the application level (instead of at the OS level).

    When SQL Server 2005 runs inside a virtual operating environment, it requires at least one license per virtual operating environment, except for SQL Server Enterprise Edition. Several copies or instances of SQL Server 2005 can run inside a virtual operating environment. These must be licensed as follows:

    When licensed Server / CAL

    Workgroup, Standard, and Enterprise Editions now allow for unlimited instances within each virtual or physical operating environment. Previously, only the Enterprise Edition of the Server license allowed multi-instancing. This is a great incentive for customers to adopt the Server/CAL model.

    For Workgroup and Standard each virtual or physical operating environment containing a running instance of SQL Server requires a Server license. For enterprise edition, each physical operating environment containing a running instance of SQL server requires a Server license and no separate licenses are needed for SQL server instances running in virtual operating environments on the same machine.

    When licensed Per Processor

    Workgroup, Standard, and Enterprise Editions allow for unlimited instances in each virtual or physical operating environment.

    For Workgroup, Standard and enterprise edition, each virtual operating environment running SQL Server 2005 must have a processor license for each processor that the virtual machine accesses. If a copy of SQL is running on a physical operating environment, then processor licenses are required for all of the processors on that physical server. For enterprise edition there is an added option : if all processors in a machine have been licensed, then the customer may run unlimited instances of SQL server 2005 on an unlimited number of virtual operating environments on that same machine.

    </quote>

    So - they require you to license each virtual (meaning a VMWARE-like situation) instance separately (in std and workgroup edition), but no such mention when "multi-instancing" (multiple instances in a single OS). Also - enterprise edition only gets a "free ride" if all procs on the machine are licensed for it, so you can't "dedicate" one CPU to OS activities and continue to get away with not licensing it by proc for each instance.

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • To address the original post, if you have each of 4 sql instances take 2GB of RAM on an 8GB box, what is the OS going to use?? I would limit each instance to a maximum of 1.5GB+- or so to leave sufficient resources for non-sql services.

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

  • The licensing has changed since the OP, and so that's not an problem. Honestly it seems that people have issues they post about managing the multiple instances. You definitely need to leave some RAM for the OS, so the 1.5GB above makes some sense.

    If you could get a touch more RAM, I wonder how 4 virtual instances would run? There's overhead, but it would be an interesting experiment, especially as it should make splitting off one instance to new hardware a trivial matter.

  • I missed a VERY important statement in the OP: "...I am planning a 3GHz Xeon with hyperthreading and..."

    If only 1 cpu, this baby will be a TOTAL DOG.

    Regardless of number of CPUs, you should test with hyperthreading TURNED OFF. This is a BIOS setting. I am 90% certain (without further information even) that performance will INCREASE for this configuration with HT disabled.

    I strongly recommend at least 4 true cores. 5+ would be even better, since even with all 4 sql instances hitting the cpus heavily you should have some cpu 'left' for OS activities. This would also allow you to test restricting instances to specific cpus to prevent any one instance from eating the whole box, which can be important for hosting situations to ensure you can meet SLAs. Also consider setting MAXDOP=1 for the instances too to approximate the same limitation although that isn't as good a processor affinity.

    Oh, and yet another thing - I hope you have a VERY good I/O subsystem. If not, you will have a 3-legged dog on your hands. 🙂

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

  • I think that TheSQLGuru was being a bit overly optimistic about the 3-legged dog ... more likely than not the aforementioned dog would have to learn how to walk upright on 2 legs or even possibly learn how to hop on one leg in order to ambulate

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

  • ROFL-ROFL-ROFL!!

    In my defense I note that the OPer is both a newbie and also seemed quite happy with his proffered solution, so I didn't want to TOTALLY deflate him with such a blatantly negative affront!!

    Best,
    Kevin G. Boles
    SQL Server Consultant
    SQL MVP 2007-2012
    TheSQLGuru on googles mail service

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

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