February 13, 2006 at 10:20 pm
Here's one for you. One might assume that if you had your SQL Server set up for 200 "per seat" connections you would only be able to have up to 200 concurrent connections. Any connections above that point would effectively be unable to access the SQL Server? Does anybody know if "per seat" licensing cuts off connections once the "per seat" number is hit? And since it's based on "device", it would have to be 200 different "devices" connecting to the server before the limit was hit. Right?
And to go one step further. If I had a SQL Server that was only being used by an IIS server pulling data from it (separate IIS server). Effectively, SQL Server only sees the one "device" connecting to it. So, in theory, The top end "per seat" limit of 200 should never be hit? Even though I believe technically that all end users that pull information from a SQL Server in this scenario do need a license.
Thoughts? Does anyone have experience running into a hard "per seat" licensing limit?
February 14, 2006 at 12:14 am
February 14, 2006 at 9:14 am
I knew that SQL Server per-processor license was required for the web applications in SQL Server 2000. I looked up the updated licensing page for 2005
http://www.microsoft.com/sql/howtobuy/processor.mspx
and it says it is "appropriate" but does not say it was required. I also checked with the Licensing White Paper
which says per-processor license "can be used", but does not say it is required.
Does someone have more information?
Also, I did not find any licensing utility in 2005. There is SERVERPROPERTY ('LicenseType') , but it read-only as I understand. I did not encounter any license type questions during the installation for both Standard Edition promotional copy given us at the Launch Event and Standard Edition purchased under our company's Select volume agreement that covers clients. I did not find anything relevant in BOL
Regards,Yelena Varsha
February 14, 2006 at 10:16 am
Wishful thinking. This is called "multiplexing" and Microsoft isn't giving anyone a break for using it. From http://www.microsoft.com/sql/howtobuy/multiplexing.mspx , "Use of such multiplexing or pooling hardware and/or software does not reduce the number of client access licenses (CALs) required to access or use SQL Server software." In other words, if you choose server + CAL licensing, you have to have a license fore each user. That's why processor licensing is more cost effective for web based access to SQL Server. Also, Microsoft's
version of "per seat" are called Device CALs and User CALs.
I don't have any experience with hitting a "hard" licensing limit. My place of employment has used per processor licensing so far, but we're probably going to license our internal servers i.e. those that aren't accessed from the web, with server + CAL when we buy SQL 2005 licenses.
Greg
Greg
February 15, 2006 at 6:30 am
Been a while since I have use a CAL scenario but I believe it does throw a message about license limit being reached but that would mean 200 connections at least have to be open at a given moment in the stated scenario.
February 15, 2006 at 7:10 am
In 7 and prior versions it would log the event when you exceeded connections, but I don't think it stopped anyone from connecting. Not sure about 2000/2005
February 15, 2006 at 8:55 am
As steve says theres nothing to stop you going above the limit physically.
Youre right in what you say about devices and users although I dont believe there is such a thing as 'concurent' anymore. If a user/device has the ability to connect to a sql server they need a license, concurrent or not.
Additionally if you are going through middleware to extract data ie IIS or even excel, you still need a license. Where you have a large amount of users connecting then consider per processor licensing.
HTH....
February 15, 2006 at 4:39 pm
CALs - either per-seat or per-user - do not count connections. If a user has a per-user CAL, that user may simultaneously open multiple connections to several per-server-licensed SQL Server services (of the same edition in the same local network), using multiple computers.
A per-user CAL licenses the right of a single user to access data on licensed servers. It is not a 'users at one time' license.
When using per-user CALs, if you have 100 users who occasionally hit a website that only ever holds at most 3 connections to the SQL Server, you still need 100 per-user CAL licenses. If you have a website hit by anonymous surfers once each, you need separate CAL for each of them, which is why the per-processor model makes sense for many application servers.
-Eddie
Eddie Wuerch
MCM: SQL
June 9, 2006 at 5:36 am
Does anyone know how to tell how many licences have being used. Say I have 155 cals. How do I know I am reaching that number. Where does SQL Server keep count
Regards,
TOny
June 9, 2006 at 5:59 am
I'm pretty sure it doesn't. If it does someone please tell!!
We try and track ours by using 3rd party software, in our case Altiris. This can scan all machines on a network and report those which have SQL client installed or use certain dll's used by ODBC drivers etc.
June 9, 2006 at 9:38 am
In a Server + CAL environment, SQL Server does not keep count of CALs used. Remember: a User CAL licenses a user for an unlimited number of connections, a Device CAL licenses a single (non-multiplexed) machine for an unlimited number of connections.
If you have a server license and one User CAL, then one person could fire up 10,000 simultaneous connections to that server from 25 (non-multiplexed) machines and still comply with the license.
If you have a server license and one Device ('per seat') CAL, then several people could take turns opening thousands of connections - and leave all of them open at once - from one non-multiplexed machine and still comply. You'd want to kill them, but they'd be legal.
Because a user or device can connect multiple times with a single CAL, then unless each user and device connected with "I'm user X and I'm using a User CAL" or "I'm device Y and I'm using a Device CAL", it would basically be impossible for the server to know how many CALs were being used.
-Eddie
Eddie Wuerch
MCM: SQL
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply