Beginning Microsoft SQL Server 2008 ... - S3 Tech Training

Appendix A: System Functions
In addition, we have the OVER operator, which, while largely working as a ranking tool, can be applied
to other forms of T-SQL functions (most notably aggregates). While I only discuss it as part of the ranking
functions, you may see it referenced several other places in this appendix.
Legacy System Functions
(a.k.a. Global Variables)
@@CONNECTIONS
Returns the number of connections attempted since the last time your SQL Server was started.
This one is the total of all connection attempts made since the last time your SQL Server was started. The
key thing to remember here is that we are talking about attempts, not actual connections, and that we
are talking about connections as opposed to users.
Every attempt made to create a connection increments this counter regardless of whether that connection
was successful or not. The only catch with this is that the connection attempt has to have made it as far
as the server. If the connection failed because of NetLib differences or some other network issue, then
your SQL Server wouldn’t even know that it needed to increase the count — it only counts if the server
saw the connection attempt. Whether the attempt succeeded or failed does not matter.
It’s also important to understand that we’re talking about connections instead of login attempts. Depending
on your application, you may create several connections to your server, but you’ll probably only ask
the user for information once. Indeed, even Query Analyzer does this. When you click for a new window,
it automatically creates another connection based on the same login information.
This, like a number of other system functions, is often better served by a system stored procedure,
sp_monitor. This procedure, in one command, produces the information from the number of connections,
CPU busy, through to the total number of writes by SQL Server. So, if basic information is what
you’re after, then sp_monitor may be better — if you need discrete data that you can manipulate,
then @@CONNECTIONS provides a nice, neat, scalar piece of data.
@@CPU_BUSY
588
Returns the time in milliseconds that the CPU has been actively doing work since SQL Server was last
started. This number is based on the resolution of the system timer — which can vary — and can therefore
vary in accuracy.
This is another of the “since the server started” kind of functions. This means that you can’t always count
on the number going up as your application runs. It’s possible, based on this number, to figure out a CPU
percentage that your SQL Server is taking up. Realistically though, I’d rather tap right into the Performance
Monitor for that if I had some dire need for it. The bottom line is that this is one of those really cool
things from a “gee, isn’t it swell to know that” point of view, but doesn’t have all that many practical
uses in most applications.