Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Better Licensing


Better Licensing

Author
Message
Matt Miller (#4)
Matt Miller (#4)
SSCertifiable
SSCertifiable (7.6K reputation)SSCertifiable (7.6K reputation)SSCertifiable (7.6K reputation)SSCertifiable (7.6K reputation)SSCertifiable (7.6K reputation)SSCertifiable (7.6K reputation)SSCertifiable (7.6K reputation)SSCertifiable (7.6K reputation)

Group: General Forum Members
Points: 7639 Visits: 18062
Wayne West (12/17/2007)
It depends on the version of SQL Server. Technically (I studied this earlier this year) if you're running SS 2000 Standard Edition, if I recall correctly you have to have a license for each named instance. If you're running Enterprise 2000, you can have an unlimited number of instances on the same server with no change in licensing.

I also looked at the licensing requirements for 2K5 but I don't recall them off-hand.

I believe that you also get licenses for development through certain MS subscriptions, but I have no specifics on that.


The multi instance thing isn't true any more for SQL2005. Meaning - you can run multiple instances for no extra licensing under workgroup, standard and enterprise editions as long as you're dealing with a single OS instance. Different rules apply under VM's - but suffice it to say that if you license for all physical procs under Enterprise, you only need ONE copy of enterprise edition for all instance over all VM's (standard/WG needs to be licensed for each logical processor that VM sees.)

Developer Edition is licensed per tester seat - somewhere around 40-50$/per. That license covers any server components you want installed (again - not in a production setting).

----------------------------------------------------------------------------------
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?
P Jones
P Jones
Say Hey Kid
Say Hey Kid (682 reputation)Say Hey Kid (682 reputation)Say Hey Kid (682 reputation)Say Hey Kid (682 reputation)Say Hey Kid (682 reputation)Say Hey Kid (682 reputation)Say Hey Kid (682 reputation)Say Hey Kid (682 reputation)

Group: General Forum Members
Points: 682 Visits: 1505
Our main business and finance system is making the Oracle to SQL Server 2005 jump in order to get off unix as the costs of replacing and maintaining the unix-oracle boxes are higher than getting windows servers and converting. We're already a Microsoft shop for everything else so the learning curve is low - apart from the three Oracle dba's and report writer being re-trained.

On the minus side it looks like they'll take my DBA role on as they'll have less to do once the sql version is running. I'll then have to do just the .NET development side and SSIS and small databases :-(
Meredith Ryan
Meredith Ryan
SSC Journeyman
SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)

Group: General Forum Members
Points: 95 Visits: 231
majorbloodnock (12/17/2007)
I'm a little rusty on licensing options now, since it's a while since I had that particular responsibility in my current company. However, last time I made a comparison, the water was muddied quite a bit based on the whole area of development environments.

At that point, Oracle charged quite a bit per processor for any production installation, whilst SQL Server was far cheaper, but required licenses for every installation. Given any of our mainstream applications have a production, test, development and (usually) at least one sandpit environment, that means SQL Server had to be less than a quarter of the per processor price of Oracle to be fiscally competitive. And that, of course, was before we took into account the high-volume capabilities of different platforms (the gap's closing, but at that point Solaris provided a clear advantage, effectively ruling out SQL Server at the first hurdle).

Now, if MS moved to a Production Instances Only licensing model, that'd really be something to think about.



Not quite. With each MSDN dev seat you get accesss to OS's and Server licenses for dev/test. The cavat here is that those installs are only used for dev/test. So, you buy your testers and dev folk MSDN seats and your licensing issues are mute. Also, they get the added advantage of the MSDN resources.
majorbloodnock
majorbloodnock
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1113 Visits: 3062
Meredith Ryan (12/19/2007)
majorbloodnock (12/17/2007)
I'm a little rusty on licensing options now, since it's a while since I had that particular responsibility in my current company. However, last time I made a comparison, the water was muddied quite a bit based on the whole area of development environments.

At that point, Oracle charged quite a bit per processor for any production installation, whilst SQL Server was far cheaper, but required licenses for every installation. Given any of our mainstream applications have a production, test, development and (usually) at least one sandpit environment, that means SQL Server had to be less than a quarter of the per processor price of Oracle to be fiscally competitive. And that, of course, was before we took into account the high-volume capabilities of different platforms (the gap's closing, but at that point Solaris provided a clear advantage, effectively ruling out SQL Server at the first hurdle).

Now, if MS moved to a Production Instances Only licensing model, that'd really be something to think about.



Not quite. With each MSDN dev seat you get accesss to OS's and Server licenses for dev/test. The cavat here is that those installs are only used for dev/test. So, you buy your testers and dev folk MSDN seats and your licensing issues are mute. Also, they get the added advantage of the MSDN resources.


Thanks, Meredith. That makes a lot of sense, and clarifies well.

However, and it's a big however, it's got me thinking - dangerous at the best of times. What about test environments that are used for UAT? If your user testing base is a random selection of perhaps 50 or 100 from a potential audience of thousands, does that not still mean you have to buy a full SQL Server license for that box? Obviously this still doesn't make the situation as bad as it seemed in my first posting, but it feels like a cost that is, if not hidden, at least obfuscated. Or am I just being obtuse?

Semper in excretia, sumus solum profundum variat
Meredith Ryan
Meredith Ryan
SSC Journeyman
SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)

Group: General Forum Members
Points: 95 Visits: 231
You do need to license that box that is involved in UAT. All other dev/test could be handled by MSDN seats, provided everyone that touches that box has a msdn seat and it is only used for dev/test
Cat-253986
Cat-253986
SSC-Enthusiastic
SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)

Group: General Forum Members
Points: 104 Visits: 215
I just wished that there was only one license type. When you work for a large company and everyone is buying licenses, its hard to match up what type of licesenses were purchased for what! Some people buy CALs and some buy per processor - I wish they would all buy per processor. I'm always getting myself confused over how everything is licensed!
Steve Jones
Steve Jones
SSC-Dedicated
SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)SSC-Dedicated (36K reputation)

Group: Administrators
Points: 36050 Visits: 18736
It's actually easy. Inside a company, you buy CALs. If the people are authenticated users, Windows Auth, or just AD accounts, they should use CALs. Per processor is for unauthenticated users, primarily Internet ones.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
Cat-253986
Cat-253986
SSC-Enthusiastic
SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)SSC-Enthusiastic (104 reputation)

Group: General Forum Members
Points: 104 Visits: 215
Steve Jones - Editor (1/2/2008)
It's actually easy. Inside a company, you buy CALs. If the people are authenticated users, Windows Auth, or just AD accounts, they should use CALs. Per processor is for unauthenticated users, primarily Internet ones.


I agree with your point.

I think CALs may be more difficult to manage when you have A LOT of SQL Servers and different users in your environment. Also, you need per processor licenses in a Farm situation.
Lynn Pettis
Lynn Pettis
SSC-Insane
SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)SSC-Insane (24K reputation)

Group: General Forum Members
Points: 24171 Visits: 37936
Per processor licensing is also valid if you have a large internal user community that is accessing your database. If you purchased SQL Server 2000 or SQL Server 2005 using User CALs, you could spend more than by licensing either per processor. You have to look at how many users may access the system, assuming that it is possible that all may hit the system at the same time (no connurent user licensing with SQL Server).

Cool
Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Meredith Ryan
Meredith Ryan
SSC Journeyman
SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)SSC Journeyman (95 reputation)

Group: General Forum Members
Points: 95 Visits: 231
Cat (1/2/2008)
I just wished that there was only one license type. When you work for a large company and everyone is buying licenses, its hard to match up what type of licesenses were purchased for what! Some people buy CALs and some buy per processor - I wish they would all buy per processor. I'm always getting myself confused over how everything is licensed!



The only way to ensure that you in compliance all the time is to have one person (or a team of a few people) that purchase all licensing for the company. We were completely out of whack licensing wise until we changed our process. At this point, we're small enough (between 400-500 associates) that if an invoice for software goes to our payables team and I haven't signed off on it, AP doesn't pay it until I have all the details, and say okay. Its the only way to ensure that your licensing is compliant and that you can prove compliancy. That proof is almost as important as the compliancy itself.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search