April 16, 2009 at 9:19 pm
Comments posted to this topic are about the item @@CPU_BUSY
April 17, 2009 at 9:41 am
I disagree with the answer, that the return value exceeds the limit of an integer, a variable of type integer is not able to save millions
April 17, 2009 at 10:34 am
Really? AFAIK an integer hold a few billion:
http://msdn.microsoft.com/en-us/library/aa933198(SQL.80).aspx
April 17, 2009 at 10:54 am
ChacMoll (4/17/2009)
I disagree with the answer, that the return value exceeds the limit of an integer, a variable of type integer is not able to save millions
The answer is correct.
Per books online: If the time returned in @@CPU_BUSY or @@IO_BUSY exceeds approximately 49 days of cumulative CPU time, you receive an arithmetic overflow warning. In that case, the value of @@CPU_BUSY, @@IO_BUSY and @@IDLE variables are not accurate.
The Redneck DBA
April 17, 2009 at 11:02 am
Jason Shadonix (4/17/2009)
ChacMoll (4/17/2009)
I disagree with the answer, that the return value exceeds the limit of an integer, a variable of type integer is not able to save millionsThe answer is correct.
Per books online: If the time returned in @@CPU_BUSY or @@IO_BUSY exceeds approximately 49 days of cumulative CPU time, you receive an arithmetic overflow warning. In that case, the value of @@CPU_BUSY, @@IO_BUSY and @@IDLE variables are not accurate.
Have that happen to me all the time. I wrote some monitoring scripts that aggregate and graph CPU usage on a regular basis and it dies after the server has been up for a long time. Guess I should be happy it doesn't require a reboot that often!
April 17, 2009 at 11:59 am
Sorry, my comment was too hasty, because I answer the question the wrong way.
I totally agree my mistake.
April 17, 2009 at 2:14 pm
No worries. The questions aren't here to mark you with a score. They're here to get you to think about things, and perhaps learn something.
And they teach me how to better ask questions. Believe me, I'm sure I make more mistakes asking them than you do answering!
April 19, 2009 at 5:20 am
Returns the time that SQL Server has spent working since it was last started. Result is in CPU time increments, or "ticks," and is cumulative for all CPUs, so it may exceed the actual elapsed time. Multiply by @@TIMETICKS to convert to microseconds.
select @@CPU_BUSY,@@TIMETICKS ,@@CPU_BUSY*@@TIMETICKS
April 20, 2009 at 9:11 am
Jason Shadonix (4/17/2009)
ChacMoll (4/17/2009)
I disagree with the answer, that the return value exceeds the limit of an integer, a variable of type integer is not able to save millionsThe answer is correct.
Per books online: If the time returned in @@CPU_BUSY or @@IO_BUSY exceeds approximately 49 days of cumulative CPU time, you receive an arithmetic overflow warning. In that case, the value of @@CPU_BUSY, @@IO_BUSY and @@IDLE variables are not accurate.
I think for @@CPU_BUSY it should be for 24 and 3/4 days, if counted in Milliseconds.
Int can take value upto 2,147,483,647
and 24*60*60*1000 = 86400000
SQL DBA.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply