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
Friday, March 30, 2012
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment