Performance Tuning with SQL Server Dynamic Management Views

Chapter 2: Connections, Sessions and Requests
Listing 2.1: Running the query against sysprocesses.
Now, also in Tab #1, run the equivalent query against sys.dm_exec_requests.
SELECT session_id ,
command ,
sql_handle
FROM sys.dm_exec_requests
WHERE DB_NAME(database_id) = 'SimpleTalk'
Listing 2.2: Running the query against sys.dm_exec_requests.
In sysprocesses, the sql_handle is available at session-scope and so we see an entry
for the "empty session" (Tab #2) as well as for the query being executed in the current
session. With sys.dm_exec_requests, a request is only observable while the query
engine is processing each transaction associated with it. Once the final commit for the
last transaction associated with the request is made, the request is no more. Thus, the
second idle session is invisible to sys.dm_exec_requests, since no requests are
currently being processed.
Furthermore, sql_handle is not available from sys.dm_exec_sessions, so we could
not run the equivalent query against that view. Both sysprocesses and sys.dm_exec_
requests will, of course, detect currently executing queries, but, interestingly, if the
second session (56) contained, for example, a modification that had completed, but not
committed (or rolled back), then it would not be detected by a simple query against
sys.dm_exec_requests.
36