March 12, 2010 at 12:04 pm
How good is the idea of running SQL Profiler remotely from a user machine in a different domain from the domain of the production servers? My fellow DBA ran the trace for 5 minutes from his user machine. He said he stopped the trace after 5 minutes, but when I checked the log the trace was still running and I stopped it manually. Is the profiler GUI the culprit? The trace seems to have got hung, and the 10 minutes the trace ran, it kicked out users from the app. Please help! He was saving the trace data directly to a table on the same instance. Is the saving to table a lot heavier than saving to file?
March 12, 2010 at 1:29 pm
also, will running profiler remotely pull trace data to the remote machine and then push back to the server to write on the server? Any help is appreciated!
March 12, 2010 at 4:17 pm
Rajan John-243593 (3/12/2010)
How good is the idea of running SQL Profiler remotely from a user machine in a different domain from the domain of the production servers? My fellow DBA ran the trace for 5 minutes from his user machine. He said he stopped the trace after 5 minutes, but when I checked the log the trace was still running and I stopped it manually. Is the profiler GUI the culprit? The trace seems to have got hung, and the 10 minutes the trace ran, it kicked out users from the app. Please help! He was saving the trace data directly to a table on the same instance. Is the saving to table a lot heavier than saving to file?
I don't think it is an good idea, unless there is specific reason. It depends on the network speed if you are running profiler on different domain. It may be hung, he may have paused and closed the profiler without stopping. Yes saving to table is heavier than saving to file.
From BOL
Capturing trace data to a table is a slower operation than capturing trace data to a file. An alternative is to capture trace data to a file, open the trace file, and then save the trace as a trace table.
March 15, 2010 at 8:50 am
Thanks! It makes sense. But, I am trying to understand why there should be big blockage due to this. Id the app getting the data to the remote machine which can block the network? Or is the data writing that caused the problem? Appreciated if the experts can give me some hint/help. Thanks!
March 15, 2010 at 9:55 am
Bad idea. Using the profiler GUI at all on a production server is a bad idea.
http://scarydba.wordpress.com/2008/12/18/profiler-research/
http://scarydba.wordpress.com/2009/10/28/snags-with-profiler-gui/
Rather use the server-side trace and save the trace to a fast local drive.
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
March 15, 2010 at 9:58 am
Rajan John-243593 (3/12/2010)
also, will running profiler remotely pull trace data to the remote machine and then push back to the server to write on the server?
Yes.
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
March 15, 2010 at 10:23 am
Thanks Gail!!
March 15, 2010 at 10:34 am
GilaMonster (3/15/2010)
Bad idea. Using the profiler GUI at all on a production server is a bad idea.http://scarydba.wordpress.com/2008/12/18/profiler-research/
http://scarydba.wordpress.com/2009/10/28/snags-with-profiler-gui/
Rather use the server-side trace and save the trace to a fast local drive.
Agreed.
March 15, 2010 at 12:57 pm
To learn how to perform a server-side trace, and for other Profiler advice, check out my free eBook, "How to Become a Profiler Master" at http://www.sqlservercentral.com/books.
Brad M. McGehee
DBA
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply