亚洲乱码中文字幕综合,中国熟女仑乱hd,亚洲精品乱拍国产一区二区三区,一本大道卡一卡二卡三乱码全集资源,又粗又黄又硬又爽的免费视频

SQL server內存問題排查方案

 更新時間：2024年03月08日 09:24:26   作者：hjhcos  
由于昨晚線上服務器數據庫突然訪問數據緩慢,任務管理里面SQL server進程爆滿等等,重大事故的排查擬寫解決方案,文中通過代碼示例和圖文講解的非常詳細,需要的朋友可以參考下

前言

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

在這里插入圖片描述

整體思路

  1. 查詢數據庫請求連接：排查連接池是否占滿
  2. 查詢數據庫請求量：排查數據是否存在反復查詢
  3. 查詢數據庫阻塞語句以及執(zhí)行語句：排查數據庫是否存在歷史SQL語句阻塞以及當前執(zhí)行的SQL語句是否存在問題
  4. 查詢數據庫語句執(zhí)行時間：排查數據庫是否因為數據量過大導致的
  5. 定位到問題指定位置

查詢數據庫請求連接

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

在這里插入圖片描述

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

查詢數據庫請求量

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

在這里插入圖片描述

通過SQL語句排查是否存在大量重復數據請求量，顯然并不是請求次數的問題，也就是說沒有頻繁的請求量，因此排除數據請求頻繁的問題。

查詢數據庫阻塞語句以及執(zhí)行語句

SELECT TOP 100 dest.[text] AS 'sql語句',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

在這里插入圖片描述

在這里插入圖片描述

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

查詢數據庫語句執(zhí)行時間

SELECT --TOP 20 
total_worker_time / 1000 AS [自編譯以來執(zhí)行所用的CPU時間總量(ms)],
       total_elapsed_time/1000 as [完成執(zhí)行此計劃所用的總時間],
       total_elapsed_time / execution_count/1000 as [平均完成執(zhí)行此計劃所用時間],
       execution_count  as [上次編譯以來所執(zhí)行的次數],   
       creation_time as [編譯計劃的時間],
       deqs.total_worker_time / deqs.execution_count / 1000 AS [平均使用CPU時間(ms)],
       last_execution_time AS [上次開始執(zhí)行計劃的時間],
       total_physical_reads [編譯后在執(zhí)行期間所執(zhí)行的物理讀取總次數],
       total_logical_reads/execution_count [平均邏輯讀次數],
       min_worker_time /1000 AS [單次執(zhí)行期間所用的最小CPU時間(ms)],
       max_worker_time / 1000 AS [單次執(zhí)行期間所用的最大 CPU 時間(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 [數據庫名稱],
       object_name(dest.objectid, dest.dbid) as [對象名稱]
       ,deqs.plan_handle [查詢所屬的已編譯計劃]
  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í)行此計劃所用的總時間降序
 ORDER BY total_elapsed_time/1000 DESC

在這里插入圖片描述

在這里插入圖片描述

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

問題分析與定位

查詢序列號表 tb_SN

SELECT COUNT(*) FROM tb_SN

243779 條

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

查詢序列號流水表 tb_SNs

SELECT COUNT(*) FROM tb_SNs

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

使用壓縮存儲快速查看數據量

點擊 tb_SNs 流水表 【右鍵】【存儲】【管理壓縮】【下一步】

在這里插入圖片描述

流水表五千萬條數據，因此可以確定序列號流水表存在數據量過多導致的，整個和序列號流水相關的程序出現訪問緩慢的問題。

竟然知道問題了，和相關領導咨詢是否可以刪除數據，并確定刪除的時限范圍，確定刪除 2023 年以前的所有數據，釋放數據量。

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

如此操作下，我們發(fā)現刪除的數據量只有十萬條，顯然這是不對的，總共三年不到，不可能只有怎么點數據，因此判斷是不是某個時間點插入大量數據，然后我們根據去年年份查詢去年的數據量：

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

五十萬條顯然是今年數據量突然增加的，因此開始查詢月時間節(jié)點產生的數據，發(fā)現三月以前都正常，數據出現在三月份，接下來開始查詢每日的數據量，三月五號正常，三月六號出現五千萬數據，因此問題出現在昨天的時候。

解析問題

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

  • 查詢負責人該節(jié)點人員工作安排
  • 根據業(yè)務確定程序是否存在邏輯判斷插入問題
  • 判斷數據是否可以刪除

在這里插入圖片描述

以上就是SQL server內存問題排查方案的詳細內容，更多關于SQL server內存問題的資料請關注腳本之家其它相關文章！

相關文章

最新評論