If the percent_complete column continues to increase over time, you can know that the process is making progress. Keep in mind that you can’t necessarily extrapolate the time it will finish from the start_time and percent_complete columns, or expect that estimated_completion_time is accurate. For example, during a DBCC CHECKDB operation, if corruption is found at any level, a deeper check might be required and that would extend the time it takes to run the CHECKDB. If you do make the lovely mistake of, say, killing a query that had been running forever, you can also get an idea of just how much has to rollback now. Yay.
To be clear, the percent_complete command isn’t populated for everything. Here’s the list from the MSDN article on sys.dm_exec_requests:
Operations that populate the percent_complete column | |
---|---|
|
|
You’ll notice that SELECT/INSERT/UPDATE/DELETE statements are not included in this list. So you can’t use it to figure out how long a query is going to run.
I’ve focused on percent_complete, because that’s what saves me from the crazy house, but there is a lot of great information to be found in this DMV. You can capture both the SQL and Plan handles. You can see what the last wait type was and how long it spent on that wait type.
Keeping an eye on that DMV lets me know that the process is progressing and has kept me from overreacting and canceling processes that seem to be stuck, but aren’t. I’ve since used that on long-running processes like backups and restores. It also provides a way to tell users that, yes, this is running, and it’s roughly x% done.