A sequence is the right ask, because the DMVs answer different questions and the questions have an order: is it now or always, waiting on what, caused by which queries.

Now: sys.dm_exec_requests joined to sys.dm_exec_sessions with a cross apply of sys.dm_exec_sql_text shows every running request, its wait type, elapsed time and statement. Two columns solve half of all loud user incidents by themselves: blocking_session_id nonzero means a blocking chain, follow it to the head and the check active transactions thread linked alongside takes over. A wait_type on the slow requests names what they wait for.

Always: sys.dm_os_wait_stats aggregates every wait since restart, the instance's autobiography. Filter the benign background waits out and the top few tell the story, PAGEIOLATCH means storage reads, WRITELOG means log disk, CXPACKET with high counts means parallelism thrash, LCK waits mean blocking is chronic rather than tonight's news. This reframes the incident from this query is slow to this instance always waits on storage, different problems, different fixes.

Which queries: sys.dm_exec_query_stats cross applied to the sql text and ordered three ways, total_worker_time for CPU eaters, total_logical_reads for IO eaters, execution_count for the death by a million cuts query running constantly. The top offenders under the wait story from step two are your suspects, and their plans via sys.dm_exec_query_plan show why. Supporting cast once suspects exist: sys.dm_db_index_usage_stats for indexes never read but expensively maintained, and the missing index DMVs as suggestions to evaluate rather than obey, they propose overlapping indexes with cheerful abandon.

All of it resets at service restart, so note the uptime before trusting the aggregates. When this sequence becomes routine, capture it on a schedule or enable Query Store so the history survives restarts and the next incident starts with evidence instead of adrenaline.