Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««123»»

Better Licensing Expand / Collapse
Author
Message
Posted Monday, December 17, 2007 10:18 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 6:44 PM
Points: 7,084, Visits: 14,684
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?
Post #434140
Posted Tuesday, December 18, 2007 3:19 AM
Mr or Mrs. 500

Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500Mr or Mrs. 500

Group: General Forum Members
Last Login: Yesterday @ 8:20 AM
Points: 547, Visits: 1,126
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 :-(
Post #434186
Posted Wednesday, December 19, 2007 12:49 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, February 18, 2013 2:52 PM
Points: 87, 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.
Post #434923
Posted Thursday, December 20, 2007 1:46 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, January 13, 2014 4:35 AM
Points: 1,046, Visits: 2,997
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
Post #435099
Posted Thursday, December 20, 2007 9:44 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, February 18, 2013 2:52 PM
Points: 87, 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
Post #435280
Posted Wednesday, January 02, 2008 11:46 AM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, April 27, 2009 6:05 AM
Points: 98, 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!

Post #438106
Posted Wednesday, January 02, 2008 12:25 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Today @ 4:31 PM
Points: 32,780, Visits: 14,941
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
Post #438113
Posted Wednesday, January 02, 2008 1:06 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, April 27, 2009 6:05 AM
Points: 98, 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.
Post #438135
Posted Wednesday, January 02, 2008 1:33 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 6:52 PM
Points: 22,492, Visits: 30,197
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).




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)
Post #438141
Posted Wednesday, January 02, 2008 2:43 PM
SSC Journeyman

SSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC JourneymanSSC Journeyman

Group: General Forum Members
Last Login: Monday, February 18, 2013 2:52 PM
Points: 87, 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.
Post #438162
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse