5. SQL Server數(shù)據(jù)庫性能監(jiān)控 - 當(dāng)前請(qǐng)求 原文:5. SQL Server數(shù)據(jù)庫性能監(jiān)控 - 當(dāng)前請(qǐng)求

對(duì)于在線運(yùn)行的系統(tǒng)，當(dāng)前數(shù)據(jù)庫性能監(jiān)控，通常監(jiān)視以下幾點(diǎn)：

(1) 是否有阻塞 (Blocking);

(2) 是否有等待 (Waiting)，阻塞就是鎖 (Lock) 等待;

(3) 是否運(yùn)行時(shí)間過長(zhǎng)(Long running)；

(4) 是否有死鎖 (Deadlock)；

sys.dm_exec_query_stats之類，等一些統(tǒng)計(jì)性的信息，通常不作為實(shí)時(shí)告警內(nèi)容，而是在性能優(yōu)化時(shí)，作為參考。

?

一. 阻塞/等待/長(zhǎng)時(shí)間運(yùn)行

1. SQL Server 2005 及以后版本檢查

SELECT r.session_id,r.blocking_session_id,DB_Name(r.database_id) as database_name,r.start_time,r.total_elapsed_time,r.[status],CASE WHEN r.blocking_session_id <> 0 THEN 'Blocking'WHEN r.blocking_session_id = 0 AND r.wait_type is not null THEN 'Waiting'ELSE 'Long-running'END as slowness_type,r.percent_complete,r.command,r.wait_type,r.wait_time,r.wait_resource,r.last_wait_type,r.cpu_time,r.reads,r.writes,r.logical_reads,t.[text] as executing_batch,SUBSTRING(t.[text],r.statement_start_offset/2,(CASE WHEN r.statement_end_offset = -1 THEN DATALENGTH (t.[text]) --LEN(CONVERT(NVARCHAR(MAX), t.text)) * 2ELSE r.statement_end_offset END - r.statement_start_offset )/2 + 1) as executing_sql,bt.[text] as blocking_batch,SUBSTRING(bt.[text],br.statement_start_offset/2,(CASE WHEN br.statement_end_offset = -1 THEN DATALENGTH (bt.[text]) --LEN(CONVERT(NVARCHAR(MAX), bt.text)) * 2ELSE br.statement_end_offset END - br.statement_start_offset )/2 + 1) as blocking_sql--,p.query_planFROM sys.dm_exec_requests rCROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as tCROSS APPLY sys.dm_exec_query_plan(r.plan_handle) as pLEFT JOIN sys.dm_exec_requests brON r.blocking_session_id = br.session_idOUTER APPLY sys.dm_exec_sql_text(br.session_id) as btWHERE r.session_id > 50 and r.session_id <> @@SPIDAND r.total_elapsed_time > 30 * 60 * 1000ORDER BY r.total_elapsed_time DESC;

以上腳本返回運(yùn)行超過30分鐘的語句，需要注意的是：

(1) 如果返回執(zhí)行計(jì)劃，會(huì)讓以上腳本變慢很多，可以不返回，在收到告警后檢查語句時(shí)，再去查看執(zhí)行計(jì)劃；

(2) 顯示TEXT，比如: xp_cmdshell這樣的語句，start_offset, end_offset都為0，截取的 text是空白，只有看TEXT才知道是什么語句；還有就是有時(shí)需要知道這個(gè)請(qǐng)求來自哪個(gè)batch或者存儲(chǔ)過程；

(3) 有時(shí)顯示TEXT還不夠，還以xp_cmdshell為例，需要dbcc inputbuffer才能看到完整的sql語句；另外已運(yùn)行結(jié)束但還沒有commit/rollback的事務(wù)，在requests中已經(jīng)沒有了，也需要借用dbcc inputbuffer來查看sql 語句；

dbcc inputbuffer(@@SPID)

(4) SQL Agent作業(yè)，在這里會(huì)被一并檢查，也可以通過msdb..sysjobactivity另行檢查；

select b.name, * from msdb..sysjobactivity ainner join msdb.dbo.sysjobs bon a.job_id = b.job_idwhere b.name like '%backup%'

?

2. SQL Server 2000沿用過來的方法

select p.dbid, p.spid, p.blocked, p.waittime/1000.0/60.0 as wait_minutes, ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) elapsed_minutes, p.last_batch, p.status, p.program_name, (select [text] FROM ::fn_get_sql(p.sql_handle)) sql_text from master..sysprocesses pwhere spid > 50 and spid <> @@SPIDAND (status <> 'sleeping' AND ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) > 30)

以上腳本返回運(yùn)行超過30分鐘的語句，需要注意的是：

sysprocesses中把connection/session/request信息三者合一，其中沒有請(qǐng)求開始的具體時(shí)間，通過last_batch監(jiān)視運(yùn)行時(shí)長(zhǎng)并不準(zhǔn)確。測(cè)試如下：

(1) 通過ISQL連接到SQL Server，如果當(dāng)前連接沒發(fā)起過任何請(qǐng)求，last_batch的時(shí)間為 1900-01-01 00:00:00，在此連接上發(fā)起請(qǐng)求時(shí)，通過last_batch計(jì)算當(dāng)前請(qǐng)求運(yùn)行時(shí)長(zhǎng)不準(zhǔn)確；

(2) 在SQL Analyzer/SSMS中新建查詢窗口，未發(fā)起任何查詢時(shí)，last_batch與login_time一樣，而非1900-01-01 00:00:00，通過last_batch計(jì)算當(dāng)前請(qǐng)求運(yùn)行時(shí)長(zhǎng)不準(zhǔn)確；或者當(dāng)前窗口發(fā)起的請(qǐng)求已結(jié)束，但窗口/連接未關(guān)閉，則在此連接上再次發(fā)起請(qǐng)求，last_batch為上次請(qǐng)求結(jié)束的時(shí)間，通過last_batch計(jì)算當(dāng)前請(qǐng)求運(yùn)行時(shí)長(zhǎng)也不準(zhǔn)確；

(3) SQL Agent作業(yè)運(yùn)行結(jié)束后，會(huì)把在sysprocesses的連接關(guān)閉，下次運(yùn)行時(shí)重新建立連接，新建連接中l(wèi)ast_batch等于login_time，通過last_batch計(jì)算作業(yè)運(yùn)行時(shí)長(zhǎng)準(zhǔn)確；

?

作為一個(gè)老的方法，估且不再去深究，不過用sysprocesses來監(jiān)視阻塞/等待還是沒有問題的，另外作業(yè)的運(yùn)行時(shí)長(zhǎng)也是可以監(jiān)視的，腳本改動(dòng)后如下：

select p.dbid, p.spid, p.blocked, p.waittime/1000.0/60.0 as wait_minutes, ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) elapsed_minutes, p.last_batch, p.status, p.program_name, (select [text] FROM ::fn_get_sql(p.sql_handle)) sql_text from master..sysprocesses pwhere spid > 50 and spid <> @@SPIDand ((p.program_name like 'SQLAgent - TSQL JobStep (Job %' AND ISNULL(DATEDIFF(MI, p.last_batch, GETDATE()), 0) > 30)or (p.blocked <> 0 and p.waittime/1000.0/60.0 > 30))

這樣一來，只剩下未被阻塞但長(zhǎng)時(shí)間運(yùn)行的sql請(qǐng)求未被監(jiān)視到。如果一定要全面監(jiān)視的話，可以選擇開啟跟蹤，進(jìn)而分析跟蹤文件。

?

二. 死鎖

死鎖的監(jiān)控可以通過監(jiān)視SQL Server的ERRORLOG來實(shí)現(xiàn)，不過需要事先打開死鎖的跟蹤標(biāo)記。腳本如下：

--sql server 2000 dbcc traceon(1204,-1)--sql server 2005 + dbcc traceon(1222,-1)

這樣發(fā)生死鎖時(shí)，死鎖詳細(xì)信息就會(huì)被寫入ERRORLOG，檢查deadlock或者victim關(guān)鍵字即可進(jìn)行監(jiān)控。

?

小結(jié)

各個(gè)語句的運(yùn)行時(shí)長(zhǎng)/基線并不一樣，通常不好設(shè)置統(tǒng)一的閥值，有時(shí)會(huì)借用第三方工具針對(duì)不同的請(qǐng)求設(shè)置不同的時(shí)長(zhǎng)閥值并告警，所以在數(shù)據(jù)庫這層大多告警阻塞即可，大致步驟如下 ：

(1) 部署數(shù)據(jù)庫郵件；

(2) 部署作業(yè)：定時(shí)檢查阻塞，發(fā)郵件告警。

?

posted on 2014-09-21 19:26 NET未來之路 閱讀(...) 評(píng)論(...) 編輯 收藏

轉(zhuǎn)載于:https://www.cnblogs.com/lonelyxmas/p/3984880.html

總結(jié)

以上是生活随笔為你收集整理的5. SQL Server数据库性能监控 - 当前请求的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。