4

I've seen a couple of blog posts where fairly knowledgeable sounding MVPs are still using sys.sysprocesses rather than the recommended DMVs: sys.dm_exec_connections, sys.dm_exec_sessions and sys.dm_exec_requests.

Given that sysprocesses is deprecated, I'm curious why anyone would continue to use it, particularly MVPs. Is it just that using sysprocesses is less hassle than joining three DMVs or is there a better reason for using it?

The two blog posts I mentioned were:

Adam Machanic: Smashing a DMV Myth

Tim Chapman: Find blocking processes using recursion in SQL Server 2005

Aaron Bertrand
  • 181,950
  • 28
  • 405
  • 624
Simon Elms
  • 295
  • 2
  • 7

1 Answers1

4

At the time this question was asked in 2012, sys.sysprocesses still contained information that was either very cumbersome or impossible to get from the DMVs, since they weren't complete. Two standout examples:

  • database_id for a non-active request (e.g. there is a row in sys.dm_exec_sessions but not in sys.dm_exec_requests)
  • open transaction count

I suspect this backward compatibility view will remain around forever, and long-timers may continue using it out of habit, muscle memory, etc. I'd tell you to ask the authors of those two blog posts why they used a deprecated object, but the blog posts are so old they don't even exist anymore. I don't see people referencing sys.sysprocesses anymore, but hopefully this explains why they might (or might have, once).

Aaron Bertrand
  • 181,950
  • 28
  • 405
  • 624