Tag Archives: sys.dm_exec_requests

Identify the cause of SQL Server blocking

In my previous article (Different techniques to identify blocking in SQL Server) on MSSQLTips.com, I discussed about locks and blocks, and presented you with an overview on how to troubleshoot and resolve blocks using dynamic management views and Activity Monitor. After I wrote this article, I received several emails from readers asking how they can use the information returned by these dynamic management views (DMVs) to identify SPIDs and other useful information about the processes that are actually causing blocking on a SQL Server instance.

Check out my latest article (Identify the cause of SQL Server blocking) on MSSQLTips.com, in which I shared the query that will help you to quickly identify SPIDs and other useful information about the processes that are causing blocking on SQL Server instance.

Advertisement

SQL Server DMV: sys.dm_exec_requests

Today, I’ve received an email from friend asking that that is there any way to find out the progress of following operation using T- SQL query. As we know, with the release of SQL Server 2005, Microsoft provides set of dynamic management views (DMVs) which helps ease the administration SQL Server Database Engine. These sets of new DMVs include one particular DMV that is sys.dm_exec_requests, which we can use to return information about the requests that are currently executing on SQL Server instance. I used this DMV to write the following query, which helps to find the progress of following operations programmatically:

  • ALTER INDEX REORGANIZE
  • AUTO_SHRINK
  • BACKUP DATABASE
  • DBCC CHECKDB
  • DBCC CHECKFILEGROUP
  • DBCC CHECKTABLE
  • DBCC INDEXDEFRAG
  • DBCC SHRINKDATABASE
  • DBCC SHRINKFILE
  • RECOVERY
  • RESTORE DATABASE
  • ROLLBACK
  • TDE ENCRYPTION
  • RESTORE LOG
  • BACKUP LOG
SELECT dmv1.[session_id] AS [UserSessionID]
	,dmv2.[login_name] AS [SessionLoginName]
	,dmv2.[original_login_name] AS [ConnectionLoginName]
	,dmv1.[command] AS [TSQLCommandType]
	,est.[text] AS [TSQLCommandText]
	,dmv2.[status] AS [Status]
	,dmv2.[cpu_time] AS [CPUTime]
	,dmv2.[memory_usage] AS [MemoryUsage]
	,dmv1.[start_time] AS [StartTime]
	,dmv1.[percent_complete] AS [PercentComplete]
	,dmv2.[program_name] AS [ProgramName]
	,CAST(((DATEDIFF(s, dmv1.[start_time], CURRENT_TIMESTAMP)) / 3600) AS [varchar](32)) + ' hour(s), ' + CAST((DATEDIFF(s, dmv1.[start_time], CURRENT_TIMESTAMP) % 3600) / 60 AS [varchar](32)) + 'min, ' + CAST((DATEDIFF(s, dmv1.[start_time], CURRENT_TIMESTAMP) % 60) AS [varchar](32)) + ' sec' AS [RunningTime]
	,CAST((dmv1.[estimated_completion_time] / 3600000) AS [varchar](32)) + ' hour(s), ' + CAST((dmv1.[estimated_completion_time] % 3600000) / 60000 AS [varchar](32)) + 'min, ' + CAST((dmv1.[estimated_completion_time] % 60000) / 1000 AS [varchar](32)) + ' sec' AS [TimeRequiredToCompleteOperation]
	,dateadd(second, dmv1.[estimated_completion_time] / 1000, CURRENT_TIMESTAMP) AS [EstimatedCompletionTime]
FROM [sys].[dm_exec_requests] dmv1
CROSS APPLY [sys].[dm_exec_sql_text](dmv1.[sql_handle]) est
INNER JOIN [sys].[dm_exec_sessions] dmv2
	ON dmv1.[session_id] = dmv2.[session_id]
WHERE dmv1.[command] IN ('ALTER INDEX REORGANIZE', 'AUTO_SHRINK', 'BACKUP DATABASE', 'DBCC CHECKDB', 'DBCC CHECKFILEGROUP', 'DBCC CHECKTABLE', 'DBCC INDEXDEFRAG', 'DBCC SHRINKDATABASE', 'DBCC SHRINKFILE', 'RECOVERY', 'RESTORE DATABASE', 'ROLLBACK', 'TDE ENCRYPTION', 'RESTORE LOG', 'BACKUP LOG')

Then following is the resultset this query returned, when I executed against server where I’m performing backup of the database (Note: To fit the resultset on the page, I splitted into two images):

progress_1

progress_2

For more information about this DMV, see sys.dm_exec_requests (Transact-SQL).

Different techniques to identify blocking in SQL Server

SQL Server is able to service requests from a large number of concurrent users. When SQL Server is servicing requests from many customers, there is a strong possibility that conflicts arise because different processes access the same resources at the same time. A conflict in which a process waits a release the resource is a block. Although in SQL Server a blocked process usually resolves itself when the first process releases the resource but there are times when a process holds a transaction lock and doesn’t release it.

Checkout my tip (i.e. Different techniques to identify blocking in SQL Server) in which I discussed various techniques for troubleshooting and resolving blocks in SQL Server. This tip is published on MSSQLTips.com.