You administer a Microsoft SQL Server 2012 server.
One of the databases on the server supports a highly active OLTP application.
Users report abnormally long wait times when they submit data into the application.
You need to identify which queries are taking longer than 1 second to run over an extended period of time.
What should you do?
A.
Use SQL Profiler to trace all queries that are processing on the server. Filter queries that have a Duration
value of more than 1,000.
B.
Use sp_configure to set a value for blocked process threshold. Create an extended event session.
C.
Run the sp_who command from a query window.
D.
Run the DBCC TRACEON 1222 command from a query window and review the SQL Server event log.
E.
Use the Job Activity monitor to review all processes that are actively running. Review the Job History to find
out the duration of each step.
Explanation:
Verified the SQL Profiler and DBCC answers as correct. However, while Profiler will show this information, the
best practice with Profiler is to use it short-term. The question specifically states “over an extended period of
time”. That means Profiler wouldn’t be the best tool for this scenario. Therefore, DBCC would be the best
answer.
Reference: http://www.mssqltips.com/sqlservertip/2130/finding-sql-server-deadlocks-using-trace-flag-1222/
Reference: http://msdn.microsoft.com/en-us/library/ms188396.aspx
I believe A is the correct option, we are not investigating deadlocks (plus syntax for DBCC is incorrect).
Agree with Mustafa. A is correct.
It seems more correct the answer A…but there is something conflicting with the requisite “over and extended period of time”. The D on the other part is not correct because there is nothing correlated to deadlocks in the question.
Agree A seems correct. We are not looking into deadlocks and syntax of dbcc trace flag is wrong.
The question specifically states “over an extended period of time”. That means Profiler wouldn’t be the best tool for this scenario. Therefore, DBCC would be the best answer.
so what is the correct answer?
what is the correct answer then?
The correct answer is option A. To examine the culprit query “over a lenghty time period”, you only need to capture/replay the SQL Profiler Trace as many time as is necessary.
Well guys, you are all not right! Check out the blocked process threshold:
https://msdn.microsoft.com/en-us/library/ms181150.aspx
“Use the blocked process threshold option to specify the threshold, in seconds, at which blocked process reports are generated. The threshold can be set from 0 to 86,400. By default, no blocked process reports are produced. This event is not generated for system tasks or for tasks that are waiting on resources that do not generate detectable deadlocks.”
and the info about extended events:
https://msdn.microsoft.com/en-us/library/hh213147.aspx
“You can create Extended Events sessions to diagnose SQL Server tracing, which enables you to resolve issues such as the following:
Find your most expensive queries
Find root causes of latch contention
Find a query that is blocking other queries
Troubleshoot excessive CPU usage caused by query recompilation
Troubleshoot deadlocks”
So this is B fo shoe!
…and you are right Josef..