廣告：

前言

由于昨晚線上服務(wù)器數(shù)據(jù)庫(kù)突然訪問數(shù)據(jù)緩慢，任務(wù)管理里面SQL server進(jìn)程爆滿等等，重大事故的排查擬寫解決方案。

整體思路

查詢數(shù)據(jù)庫(kù)請(qǐng)求連接：排查連接池是否占滿

查詢數(shù)據(jù)庫(kù)請(qǐng)求量：排查數(shù)據(jù)是否存在反復(fù)查詢

查詢數(shù)據(jù)庫(kù)阻塞語(yǔ)句以及執(zhí)行語(yǔ)句：排查數(shù)據(jù)庫(kù)是否存在歷史SQL語(yǔ)句阻塞以及當(dāng)前執(zhí)行的SQL語(yǔ)句是否存在問題

查詢數(shù)據(jù)庫(kù)語(yǔ)句執(zhí)行時(shí)間：排查數(shù)據(jù)庫(kù)是否因?yàn)閿?shù)據(jù)量過大導(dǎo)致的

定位到問題指定位置

查詢數(shù)據(jù)庫(kù)請(qǐng)求連接

SELECT DB_NAME(dbid) AS DatabaseName, COUNT(*) AS ConnectionCount 
FROM sys.sysprocesses
WHERE dbid > 0
GROUP BY dbid;

查看連接池比較正常，除了master主數(shù)據(jù)庫(kù)存在大量連接，其他業(yè)務(wù)數(shù)據(jù)庫(kù)正常，猜測(cè)應(yīng)該是排查人員的連接池，不太確定具體原因，但是排除連接池超量的問題。

查詢數(shù)據(jù)庫(kù)請(qǐng)求量

SELECT client_net_address AS '客戶端IP', COUNT(*) AS '請(qǐng)求次數(shù)'
FROM sys.dm_exec_connections
GROUP BY client_net_address
ORDER BY COUNT(*) DESC;

通過SQL語(yǔ)句排查是否存在大量重復(fù)數(shù)據(jù)請(qǐng)求量，顯然并不是請(qǐng)求次數(shù)的問題，也就是說沒有頻繁的請(qǐng)求量，因此排除數(shù)據(jù)請(qǐng)求頻繁的問題。

查詢數(shù)據(jù)庫(kù)阻塞語(yǔ)句以及執(zhí)行語(yǔ)句

SELECT TOP 100 dest.[text] AS 'sql語(yǔ)句',session_id,status,start_time FROM sys.[dm_exec_requests] AS der CROSS APPLY sys.[dm_exec_sql_text](der.[sql_handle]) AS dest ORDER BY [cpu_time] DESC

查詢到數(shù)據(jù)庫(kù)正在執(zhí)行的SQL語(yǔ)句并不存在阻塞的SQL語(yǔ)句，發(fā)現(xiàn)當(dāng)前在執(zhí)行的SQL語(yǔ)句比較正常，單獨(dú)執(zhí)行這些SQL語(yǔ)句并不存在大量數(shù)據(jù)訪問，最多六千條數(shù)據(jù)量，這個(gè)量很小，因此無法確定，但是可以確定數(shù)據(jù)庫(kù)不存在問題，SQL語(yǔ)句也比較正常。

查詢數(shù)據(jù)庫(kù)語(yǔ)句執(zhí)行時(shí)間

SELECT --TOP 20 
total_worker_time / 1000 AS [自編譯以來執(zhí)行所用的CPU時(shí)間總量(ms)],
 total_elapsed_time/1000 as [完成執(zhí)行此計(jì)劃所用的總時(shí)間],
 total_elapsed_time / execution_count/1000 as [平均完成執(zhí)行此計(jì)劃所用時(shí)間],
 execution_count as [上次編譯以來所執(zhí)行的次數(shù)], 
 creation_time as [編譯計(jì)劃的時(shí)間],
 deqs.total_worker_time / deqs.execution_count / 1000 AS [平均使用CPU時(shí)間(ms)],
 last_execution_time AS [上次開始執(zhí)行計(jì)劃的時(shí)間],
 total_physical_reads [編譯后在執(zhí)行期間所執(zhí)行的物理讀取總次數(shù)],
 total_logical_reads/execution_count [平均邏輯讀次數(shù)],
 min_worker_time /1000 AS [單次執(zhí)行期間所用的最小CPU時(shí)間(ms)],
 max_worker_time / 1000 AS [單次執(zhí)行期間所用的最大 CPU 時(shí)間(ms)],
 SUBSTRING(dest.text, deqs.statement_start_offset / 2 + 1,  
 (CASE
  WHEN deqs.statement_end_offset = -1 THEN
  DATALENGTH(dest.text)  
  ELSE deqs.statement_end_offset
 END - deqs.statement_start_offset
 ) / 2 + 1) AS [執(zhí)行SQL],
 dest.text as [完整SQL],
 db_name(dest.dbid) as [數(shù)據(jù)庫(kù)名稱],
 object_name(dest.objectid, dest.dbid) as [對(duì)象名稱]
 ,deqs.plan_handle [查詢所屬的已編譯計(jì)劃]
 FROM sys.dm_exec_query_stats deqs WITH(NOLOCK)
 CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest
WHERE (max_worker_time / 1000)>100
 --完成執(zhí)行此計(jì)劃所用的總時(shí)間降序
 ORDER BY total_elapsed_time/1000 DESC

從SQL語(yǔ)句執(zhí)行時(shí)間分析出（后補(bǔ)的圖忽略第一個(gè)刪除的操作），整體分析下來是 tb_SN 和 tb_SNs 兩張表耗時(shí)嚴(yán)重，接下來只需使用查詢語(yǔ)句查詢兩張表數(shù)量即可。

問題分析與定位

查詢序列號(hào)表 tb_SN

SELECT COUNT(*) FROM tb_SN

243779 條

排查不是序列號(hào)表的問題，那么就只有序列號(hào)流水表的問題啦

查詢序列號(hào)流水表 tb_SNs

 SELECT COUNT(*) FROM tb_SNs

使用該命令果然執(zhí)行時(shí)間緩慢，因此可以判斷是數(shù)據(jù)量太大導(dǎo)致的。

使用壓縮存儲(chǔ)快速查看數(shù)據(jù)量

點(diǎn)擊 tb_SNs 流水表 【右鍵】【存儲(chǔ)】【管理壓縮】【下一步】

流水表五千萬(wàn)條數(shù)據(jù)，因此可以確定序列號(hào)流水表存在數(shù)據(jù)量過多導(dǎo)致的，整個(gè)和序列號(hào)流水相關(guān)的程序出現(xiàn)訪問緩慢的問題。

竟然知道問題了，和相關(guān)領(lǐng)導(dǎo)咨詢是否可以刪除數(shù)據(jù)，并確定刪除的時(shí)限范圍，確定刪除 2023 年以前的所有數(shù)據(jù)，釋放數(shù)據(jù)量。

首先我們備份整個(gè)數(shù)據(jù)庫(kù)防止誤操作，然后復(fù)制并創(chuàng)建與 tb_SNs 的數(shù)據(jù)結(jié)構(gòu)相同的表，接下來將 2023 年以前的所有數(shù)據(jù)拷貝到該表上，最后在刪除 tb_SNs 的 2023 年以前的所有數(shù)據(jù)。

如此操作下，我們發(fā)現(xiàn)刪除的數(shù)據(jù)量只有十萬(wàn)條，顯然這是不對(duì)的，總共三年不到，不可能只有怎么點(diǎn)數(shù)據(jù)，因此判斷是不是某個(gè)時(shí)間點(diǎn)插入大量數(shù)據(jù)，然后我們根據(jù)去年年份查詢?nèi)ツ甑臄?shù)據(jù)量：

SELECT TOP 10 COUNT(*) FROM tb_SNs WHERE CreationDate < '2024-01-01'
571638

五十萬(wàn)條顯然是今年數(shù)據(jù)量突然增加的，因此開始查詢?cè)聲r(shí)間節(jié)點(diǎn)產(chǎn)生的數(shù)據(jù)，發(fā)現(xiàn)三月以前都正常，數(shù)據(jù)出現(xiàn)在三月份，接下來開始查詢每日的數(shù)據(jù)量，三月五號(hào)正常，三月六號(hào)出現(xiàn)五千萬(wàn)數(shù)據(jù)，因此問題出現(xiàn)在昨天的時(shí)候。

解析問題

接下來問題就好解決啦，首先根據(jù)主要數(shù)據(jù)查詢事故發(fā)生節(jié)點(diǎn)，再通過事故發(fā)生節(jié)點(diǎn)咨詢是否出現(xiàn)錯(cuò)誤操作。

查詢負(fù)責(zé)人該節(jié)點(diǎn)人員工作安排

根據(jù)業(yè)務(wù)確定程序是否存在邏輯判斷插入問題

判斷數(shù)據(jù)是否可以刪除

廣告：