August 31, 2009 at 12:57 pm
Hi,
I have made a observation in our sql server 2008 log. I see "dbcc traceon 3604" which is immediately followed by "dbcc traceoff 3604". The time interval between the two commands is few milliseconds. These commands are fired alternately many times in span of few minutes which can wary from 10 to 30 mins. When I checked the full log I found this has been happening for the past 20 days and it happens at different times and on different days( doesnt happen everyday)
I am sure no user is firing this trace. What could be the reason for this trace? I tried to google and found some people complaining it for 2000 sql server , but no one had a solution or concrete answer for it.
This problem has started both on our test and production 2008 sql server around the same time. Both our servers have been running for more than 6 months. I checked our other 2005 sql servers, they dont have this problem.
I have started my own trace to figure out the problem. At the same time I would appreciate suggestions.
Thanks,
Apurva
August 31, 2009 at 1:27 pm
is it causing any specific errors/performance problems on your servers or you are concerned just by looking at the log file ??
3604 is used to send output back to the client instead of writing to error log. Cant say why SQL 2008 is doing it ....
is the front end app .net ??
-------------------------------------------------
-Amit
Give a man a fish and he'll ask for a lemon. Teach a man to fish and he wont get paged on weekends !! :w00t: - desparately trying to fish [/size]
August 31, 2009 at 1:37 pm
Yes the front end applications are .net. You mean to say that someone from application is running it and sending the trace back to the client? If that is the case should I ask the developers?
August 31, 2009 at 1:38 pm
Right now I dont have any performance issues. but I still need to knwo the reason this is happening.
August 31, 2009 at 1:45 pm
Are you using any 3rd part monitoring tools?
DBCC TRACEON is usually used in conjunction with something like DBCC PAge, to return output to the client.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 31, 2009 at 1:49 pm
yeah looks more like a monitoring tool ... but the question still remains ... is it causing any problems ???
-------------------------------------------------
-Amit
Give a man a fish and he'll ask for a lemon. Teach a man to fish and he wont get paged on weekends !! :w00t: - desparately trying to fish [/size]
August 31, 2009 at 1:51 pm
is the front end app .net ??
I asked this as i was wondering if there is some setting in driver used in connection string or something i .net thats requesting any errors back instead of writing to the error log.
-------------------------------------------------
-Amit
Give a man a fish and he'll ask for a lemon. Teach a man to fish and he wont get paged on weekends !! :w00t: - desparately trying to fish [/size]
August 31, 2009 at 2:06 pm
Hi,
Around 20 days back one of the dba's in our team installed a monitoring software trial version to test. this is the same time when the commands started appearing in the sql log. I think this software may be causing it. Although it was installed on the local user PC, the software was used to connect both the test and production version of 2008. We have got the software uninstalled and hopefully the issue gets resolved.
Thanks Amit and GilaMonster
August 31, 2009 at 2:11 pm
Amit Singh (8/31/2009)
yeah looks more like a monitoring tool ... but the question still remains ... is it causing any problems ???
Highly unlikely. All it's doing is on one single connection getting the engine to send data to the client that would otherwise have been discarded. I've often used it on a production server
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
August 31, 2009 at 2:25 pm
Yes. It dint cause any performance problem otherwise it would have been detected long time back. My only concern was that the server was not compromised.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply