November 4, 2009 at 12:05 pm
Hi All,
I ran SQL Server Profiler on SQL Server Management Studio while a client was running another program that accessed the same database server through t-SQL, and when I ran SQL Server Profiler he was unable to run the program. When I stopped profiler the program was able to run. I didn't think Profiler locked any resources and am a bit puzzled by this. Can anybody shed any light on such behavior.
Thanks in advance,
Umayal
November 4, 2009 at 12:12 pm
SQL Profiler does not place locks on tables. It does use system resources but from my experience, not enough to have a noticable impact on the end-user.
Is this reproducable or did you attempt this more than once and get the same result? What is the program trying to do?
November 4, 2009 at 12:15 pm
Depending on a bunch of factors such as how big the box is and what events you are tracing you could cause the box to be slower, however, I agree with Mr. Rowan, it doesn't lock resources.
Did the app timeout? In what ways didn't it work, because that is a really open statement that could be interpreted many different ways.
CEWII
November 4, 2009 at 12:18 pm
John Rowan (11/4/2009)
SQL Profiler does not place locks on tables. It does use system resources but from my experience, not enough to have a noticable impact on the end-user.Is this reproducable or did you attempt this more than once and get the same result? What is the program trying to do?
Thanks for the speedy reply John. I did not attempt to reproduce. As after the instance the client believed his instance of the program became corrupt and wasn't very happy. He was able to run the program prior to me running profiler however wasn't able to run the program from this local computer even after I stopped running profiler. He tried running the program from another computer where it worked.
The program essentially runs a relational query with lots of joins across many different tables to manipulate data for a financial report with currency conversions.
TIA.
November 4, 2009 at 12:21 pm
Elliott W (11/4/2009)
Depending on a bunch of factors such as how big the box is and what events you are tracing you could cause the box to be slower, however, I agree with Mr. Rowan, it doesn't lock resources.Did the app timeout? In what ways didn't it work, because that is a really open statement that could be interpreted many different ways.
CEWII
Yes definitely, sorry for the vagueness.
The program wasn't able to run the relational query that it usually runs successfully and produced an error message saying it couldn't INSERT, UPDATE or DELETE.
November 4, 2009 at 12:21 pm
Sounds coincidental to me. Profiler doesn't lock tables. When Profiler was running, did it capture the query that was sent by the client's program?
November 4, 2009 at 12:27 pm
I didn't attempt to save the trace and did not look over the trace. We were trying to capture the results when the program ran successfully (related to currency conversion.)
November 4, 2009 at 1:10 pm
I agree likely coincidental..
CEWII
November 4, 2009 at 1:14 pm
umayal5 (11/4/2009)
I didn't attempt to save the trace and did not look over the trace. We were trying to capture the results when the program ran successfully (related to currency conversion.)
If you are trying to capture information pertaining to that query, I'd suggest setting up another trace and trying again. You'll likely need to talk w/ your client and advise them that it would be very unlikely for the SQL trace to cause the failures that they saw.
If you run into the same problem again, let us know and we'll help you dig in further.
November 4, 2009 at 2:06 pm
John Rowan (11/4/2009)
umayal5 (11/4/2009)
I didn't attempt to save the trace and did not look over the trace. We were trying to capture the results when the program ran successfully (related to currency conversion.)If you are trying to capture information pertaining to that query, I'd suggest setting up another trace and trying again. You'll likely need to talk w/ your client and advise them that it would be very unlikely for the SQL trace to cause the failures that they saw.
If you run into the same problem again, let us know and we'll help you dig in further.
Thanks so much all. You've been so helpful:-D
Viewing 10 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply