Step 1. Check if SQL Server Process has problem or not?
DECLARE @ts_now bigint;
SELECT @ts_now = cpu_ticks / CONVERT(float, cpu_ticks_in_ms) FROM sys.dm_os_sys_info
SELECT TOP(10) SQLProcessUtilization AS [SQL Server Process CPU Utilization],
SystemIdle AS [System Idle Process],
100 - SystemIdle - SQLProcessUtilization AS [Other Process CPU Utilization],
DATEADD(ms, -1 * (@ts_now - [timestamp]), GETDATE()) AS [Event Time]
FROM (
SELECT record.value('(./Record/@id)[1]', 'int') AS record_id,
record.value('(./Record/SchedulerMonitorEvent/SystemHealth/SystemIdle)[1]', 'int')
AS [SystemIdle],
record.value('(./Record/SchedulerMonitorEvent/SystemHealth/ProcessUtilization)[1]', 'int')
AS [SQLProcessUtilization], [timestamp]
FROM (
SELECT [timestamp], CONVERT(xml, record) AS [record]
FROM sys.dm_os_ring_buffers
WHERE ring_buffer_type = N'RING_BUFFER_SCHEDULER_MONITOR'
AND record LIKE '%<SystemHealth>%') AS x
) AS y
ORDER BY record_id DESC;
Then you will get result like this:
The picture above shows 70% of CPU% is taking by SQL Server 2005 , not by other processes on DB server.
Step2. Drill down to particular Loginuser and SPID which is taking most of CPU%:
select loginame, *
from master.dbo.sysprocesses
where spid> 50
order by cpu desc
PS: Why "spid > 50" here? Notice that SPIDs 1 to 50 are reserved for internal SQL Server processes, while SPIDs 51 and above are external connections. So most of time we assume that the suspects for High CPU% are from external connections.
Step3: Query the most expensive CPU process by spid (taking spid = 102 for example):
dbcc inputbuffer(102)
Then you can start to take further actions for tuning expensive Query or SPs... or just kill the abnormal ones for free :)
Cool one! Exactly whut Im looking 4~
ReplyDeleteImpressed
ReplyDelete