For the TraceBlockedProcessReport stored procedure presented in this post see my Traces project at GitHub. This is from the Microsoft’s official documentation “The Blocked Process Report event class indicates that a task has been blocked for more than a specified amount of time. This event class does not include system tasks or tasks that are […]
Capture SQL Server’s Blocked Process Report event Read More »
This is a link to previous related posts that you may find interesting https://sqlserverutilities.com/maximize-sql-trace/ https://sqlserverutilities.com/use-sql-trace-to-capture-database-exceptions/ If we want to capture all the commands being sent to the database engine we should capture just these 2 events: SQL:BatchCompleted and RPC:Completed. By doing so we guarantee to be capturing all executions sent to the database engine which
For the previous post discussing SQL Trace see this post For the TraceExceptions stored procedure presented in this post see my Traces project at Github. Capturing all the exceptions that occur in the database engine has been proved to be very useful in my experience. Actually, when thinking about it, I realize most DBAs do
SQL Server allows marking any stored procedure as a “startup” procedure which means it will get executed upon a service restart. A “startup” procedure has to reside in the master database and cannot accept input parameters – cool, this is something we can live with. I find this option to be very simple and practical
As far as I recall the trigger to code sp_helpindex2 was that with the introduction of INCLUDE columns to indexes that was added in SQL Server 2005 the old way of viewing indexes using sp_helpindex was useless since Microsoft has not modified their procedure to support the recently added INCLUDE columns. I had therefore found myself, when tuning queries,
