Profiler [SQL Timeout using perfmon.msc]

After reading the information on the Poor man's monitor
http://www.sqlmag.com/Articles/ArticleID/37468/pg/2/2.html I began to believe
I could write an application that would immediately tell me when a timeout
was happening. Being that the server is a production server, I don't dare
test on it and the testing I did indicated that only the Server 2003 was able
to pull the data I was looking for (as the article indicated).
The problem is that when I set up the profmon.msc on the 2003 server to look
at the SQL timeouts on the 2000 server, it brings back nulls to the three
monitoring tables Counterdata, CounterDataDetails, and DisplayToID.
Is there a way to coax the actual SQL Lock Timeout data back from the 2000
server to the 2003 server through PerfMon.msc?
Should I post this to a different user group?
--
Regards,
JamieAnswered my own question. The counterid will increment each time the table
is created. I believe my smallest counterid in the counterdetails was 191.
When I reset the query to point to the right counterid, it immediately
produced results.
--
Regards,
Jamie
"thejamie" wrote:
> After reading the information on the Poor man's monitor
> http://www.sqlmag.com/Articles/ArticleID/37468/pg/2/2.html I began to believe
> I could write an application that would immediately tell me when a timeout
> was happening. Being that the server is a production server, I don't dare
> test on it and the testing I did indicated that only the Server 2003 was able
> to pull the data I was looking for (as the article indicated).
> The problem is that when I set up the profmon.msc on the 2003 server to look
> at the SQL timeouts on the 2000 server, it brings back nulls to the three
> monitoring tables Counterdata, CounterDataDetails, and DisplayToID.
> Is there a way to coax the actual SQL Lock Timeout data back from the 2000
> server to the 2003 server through PerfMon.msc?
> Should I post this to a different user group?
> --
> Regards,
> Jamie

Processor Queue - Weird

Howdy,

This is a follow on from a previous post

http://www.dbforums.com/t984271.html

And now I have found something interesting :

(1) When I was monitoring the System\Processor Queue locally ( Via a term server login onto the box ) I would see a queue of 3-4. If I monitor the same parameter from a remote PC, I see a Processor Queue of 1 - why?
The box had 1 GB RAM ( SQL used 500 MB and had 250 MB free according to Task manager ).

(2)
I have another almost identical box that has same CPU but twice ammount of RAM ( 2 GB ) but has System\Processor Queue of almost
0 - why?

All other parameters for Disk, IO etc are fine.

Cheers,

SGHow about PROCESS counter during these values?|||sqlguy:

I think this guy (http://groups.google.com/groups?q=%22processor+queue+length%22&hl=en&lr=&ie=UTF-8&selm=YhwfOM4ZTgdHxYwWN9bu3Av1M6%2BQ%404ax.com&rnum=1) knows what he is talking about.sql

Processor License

I read the FAQ at
http://www.microsoft.com/sql/howtobuy/partitioning.asp, but it is still
not clear to me how to buy processor licenses basing on the number of
processors
The FAQ states
"If any processor in the server is made inaccessible to all of the
operating system copies set up to run SQL Server, then that processor
does not require a Processor license for SQL Server. In other words, a
SQL Server Processor license is required for each processor that is
accessible to any operating system copy on which SQL Server is set up
to run. "
Does this mean that the only way to avoid buying multiple processor
licenses is disabling the processor from the server's BIOS?
I guess that the "processor control" tab in the SQL server properties
has nothing to do with this, even if I'd find it very wise if MS
provided us with such a tool...
I also guess that they mean physical processor AND NOT virtual
processor deriving from Hyperthreading...
Thanks
DaveHi,
Of course per processor licence is for physical processor and not for
Hyperthreading.
As regards disabling is as far as I know exactly as you wrote. You have to
disable processor in BIOS otherwise you should buy a licence.
Danijel
<dbwmn2001@.yahoo.com> wrote in message
news:1106241266.515795.105740@.c13g2000cwb.googlegroups.com...
>I read the FAQ at
> http://www.microsoft.com/sql/howtobuy/partitioning.asp, but it is still
> not clear to me how to buy processor licenses basing on the number of
> processors
> The FAQ states
> "If any processor in the server is made inaccessible to all of the
> operating system copies set up to run SQL Server, then that processor
> does not require a Processor license for SQL Server. In other words, a
> SQL Server Processor license is required for each processor that is
> accessible to any operating system copy on which SQL Server is set up
> to run. "
> Does this mean that the only way to avoid buying multiple processor
> licenses is disabling the processor from the server's BIOS?
> I guess that the "processor control" tab in the SQL server properties
> has nothing to do with this, even if I'd find it very wise if MS
> provided us with such a tool...
> I also guess that they mean physical processor AND NOT virtual
> processor deriving from Hyperthreading...
> Thanks
> Dave
>|||> Does this mean that the only way to avoid buying multiple processor
> licenses is disabling the processor from the server's BIOS?
That is how I understand it.
> I also guess that they mean physical processor AND NOT virtual
> processor deriving from Hyperthreading...
Yep
--
Keith
<dbwmn2001@.yahoo.com> wrote in message
news:1106241266.515795.105740@.c13g2000cwb.googlegroups.com...
> I read the FAQ at
> http://www.microsoft.com/sql/howtobuy/partitioning.asp, but it is still
> not clear to me how to buy processor licenses basing on the number of
> processors
> The FAQ states
> "If any processor in the server is made inaccessible to all of the
> operating system copies set up to run SQL Server, then that processor
> does not require a Processor license for SQL Server. In other words, a
> SQL Server Processor license is required for each processor that is
> accessible to any operating system copy on which SQL Server is set up
> to run. "
> Does this mean that the only way to avoid buying multiple processor
> licenses is disabling the processor from the server's BIOS?
> I guess that the "processor control" tab in the SQL server properties
> has nothing to do with this, even if I'd find it very wise if MS
> provided us with such a tool...
> I also guess that they mean physical processor AND NOT virtual
> processor deriving from Hyperthreading...
> Thanks
> Dave
>|||Disabling in BIOS or physically removing a processor is the only way to keep
from counting a processor towards licensing requirements. If the OS sees
it, you must license it.
"Processors" means physical processors, not logical processors. Turning
HyperThreading on or off has no effect on licensing requirements.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
<dbwmn2001@.yahoo.com> wrote in message
news:1106241266.515795.105740@.c13g2000cwb.googlegroups.com...
> I read the FAQ at
> http://www.microsoft.com/sql/howtobuy/partitioning.asp, but it is still
> not clear to me how to buy processor licenses basing on the number of
> processors
> The FAQ states
> "If any processor in the server is made inaccessible to all of the
> operating system copies set up to run SQL Server, then that processor
> does not require a Processor license for SQL Server. In other words, a
> SQL Server Processor license is required for each processor that is
> accessible to any operating system copy on which SQL Server is set up
> to run. "
> Does this mean that the only way to avoid buying multiple processor
> licenses is disabling the processor from the server's BIOS?
> I guess that the "processor control" tab in the SQL server properties
> has nothing to do with this, even if I'd find it very wise if MS
> provided us with such a tool...
> I also guess that they mean physical processor AND NOT virtual
> processor deriving from Hyperthreading...
> Thanks
> Dave
>