疑難雜症--SQL SERVER 2012下數據庫內存異常回收

--===================================================================

--背景：

在一台SQL SERVER 2012 SP1(11.0.3000)服務器上，由於批處理請求較高，CPU使用率超過40%，於是開始各種調研。。

服務器情況：

服務器物理內存為128GB, 分配給SQL SERVER 115GB,Windows 可用物理內存為6GB左右

壓力情況：

批處理請求超過30000+，有大量UPDATE和INSERT操作，CPU使用率超過40%，IO隊列在20以上。

--===================================================================

首先查看當前運行的SQL，查看是否有可優化的SQL

--==================================================
--查看正在執行的SQL
SELECT 
s.[session_id],
r.[start_time],
DATEDIFF(SECOND,r.start_time,GETDATE()) AS elapsed_seconds,
r.[status] AS RequestStatus,
DB_NAME(r.database_id) AS DatabaseName,
r.[wait_type],
r.[wait_resource],
r.[wait_time],
r.[reads],
r.[writes],
r.[logical_reads],
s.[status] AS SessionStatus,
s.[host_name],
s.[original_login_name],
s.[nt_user_name],
s.[program_name],
s.[client_interface_name],
c.[client_net_address],
SUBSTRING (qt.text,
             r.statement_start_offset/2,
(CASE WHEN r.statement_end_offset = -1
       THEN LEN(CONVERT(NVARCHAR(MAX), qt.text)) * 2
ELSE r.statement_end_offset END -
r.statement_start_offset)/2) AS ExecutingSQL,
qp.query_plan
FROM sys.dm_exec_requests r
INNER JOIN sys.dm_exec_sessions s
ON r.session_id=s.session_id
LEFT JOIN sys.dm_exec_connections c
ON c.session_id=s.session_id
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) as qt
CROSS APPLY sys.dm_exec_query_plan(r.plan_handle) as qp

 經過分析，未發現執行時間較長或耗CPU較多的執行計划，但發現有大量的寫日志等待情況和一些等待IO的操作，於是分析IO

--=====================================================
--查看當前掛起的IO請求
SELECT 
DB_NAME(S.database_id) AS DBName,
S.file_id,
S.io_stall,
R.io_pending_ms_ticks
FROM sys.dm_io_pending_io_requests R
INNER JOIN sys.dm_io_virtual_file_stats(NULL,NULL) S
ON R.io_handle=S.file_handle

查詢發現除日志文件(FILE_ID=2)外，還有其他文件也有IO操作，多次執行發現對非日志文件的IO操作頻率較高，於是懷疑存在內存壓力，導致數據被頻繁換入換出，從而導致IO操作。

--=====================================
--查看內存狀態
SELECT m.total_physical_memory_kb,
m.available_physical_memory_kb,
m.total_page_file_kb,
m.available_page_file_kb,
m.system_memory_state_desc
FROM sys.dm_os_sys_memory m

由於system_memory_state_desc顯示為“Available physical memory is high”，表明內存沒有壓力。

 

查看BUFFER POOL 的使用情況

--=========================================================
--查看各內存對象使用內存情況
--在SQL SERVER 2012及以上版本運行
SELECT M.type, 
sum(M.virtual_memory_reserved_kb) AS VirtualMemoryReservedKB, 
SUM(M.virtual_memory_committed_kb) AS VirtualMemortCommitedKB, 
SUM(M.shared_memory_committed_kb) AS SharedMemroyCommittedKB, 
SUM(M.shared_memory_reserved_kb) AS SharedMemroyReservedKB, 
SUM(M.pages_kb) AS PagesKB 
FROM sys.dm_os_memory_clerks M 
GROUP BY M.type 
ORDER BY PagesKB DESC
--=========================================================
--查看各內存對象使用內存情況
--在SQL SERVER 2012以下版本運行
SELECT M.type,
SUM(M.virtual_memory_reserved_kb) AS VirtualMemoryReservedKB,
SUM(M.virtual_memory_committed_kb) AS VirtualMemortCommitedKB,
SUM(M.shared_memory_committed_kb) AS SharedMemroyCommittedKB,
SUM(M.shared_memory_reserved_kb) AS SharedMemroyReservedKB,
SUM(M.multi_pages_kb) AS MultiPagesKB,
SUM(M.single_pages_kb) AS SinglePagesKB,
SUM(M.multi_pages_kb)+SUM(M.single_pages_kb) AS TotalPagesKB
FROM sys.dm_os_memory_clerks M
GROUP BY M.type
ORDER BY TotalPagesKB DESC

其中MEMORYCLERK_SQLBUFFERPOOL使用40多GB，而max server memory (MB)被設置為115GB, 參考數據庫的大小（800GB）和訪問情況(頻繁更新)，我們預估活躍數據應該比較多，BUFFER POOL應該占用更多的內存，於是我們進一步分析各數據庫的內存使用

--=========================================================
--查看各數據庫的內存使用情況
SET TRAN ISOLATION LEVEL READ UNCOMMITTED 
SELECT ISNULL(DB_NAME(database_id), 'ResourceDb') AS DatabaseName 
, CAST(COUNT(row_count) * 8.0 / (1024.0) AS DECIMAL(28,2)) AS [Size (MB)] 
FROM sys.dm_os_buffer_descriptors 
GROUP BY database_id 
ORDER BY DatabaseName

發現數據庫使用的內存的確不高，查看相關性能計數器

--===============================================
--查看數據庫內存相關性能計數器
SELECT * ,
CAST(P.cntr_value*8.0/1024.0 AS INT) AS MemoryMB
FROM sys.sysperfinfo p
WHERE p.object_name LIKE '%SQLServer:Buffer Manager%'

SELECT * ,
CAST(P.cntr_value*8.0/1024.0 AS INT) AS MemoryMB
FROM sys.sysperfinfo p
WHERE p.object_name LIKE '%SQLServer:Memory Manager%'

發現Page life expectancy 的值很低，表明有內存壓力。

 

經過一段時間的觀察發現，各數據庫使用的內存會突然被釋放，從四五十GB突然釋放到十幾個GB,為此百思不得其解，於是請何雷何大師出馬，何大師先使用語句進行簡單的驗證后，着手使用windows的性能計數器來分析問題，由於我們關注點放在內存上，因此性能計數器只選擇SQLServer:Buffer Manager和SQLServer:Memory Manager，通過一段時間的數據抓取，發現SQLServer:Memory Manager下的Database Cache Memory(kb)數據周期性出現直線下降，而對應的SQLServer:Buffer Manager下的Lazy Write/Sec也有明顯變化，因此猜測該時間點有Lazy Write，導致釋放大量數據頁，並使得Page life expectancy變得很低，而由於數據頻繁修改，從而又導致數據庫占用內存緩慢增長，直到下一次突然下降。

 

由於性能計數器的頻率設置為1秒（何大師設定的，換我設置的話，我估計會設置為10秒，估計Lazy Write就會被忽略掉），因此我們很容易找出問題發生的時間點和周期頻率，通過查詢作業，發現日志傳送的備份時間和周期與這完全吻合，初步斷定有日志傳送引起，修改日志傳送的備份執行頻率，我們發現該問題的出現頻率也隨之變化，因此可以確定日志傳送導致。

 

調查進行到這一步，相信很多人會考慮移除日志傳送(換我我也會這么干)，而何大師第一時間點選擇了查詢SQL SERVER 相關的BUG，並成功找到解決辦法（與大師差距就在這里體現），原來在系統壓力較大的情況下，SQL SERVER的內存回收機制可能出現問題，引發內存回收並回收超過需求的大量內存。

該BUG相關描述和解決辦法

--=========================================

PS1：正常情況下，當數據庫存在內存壓力，SQL SERVER 會釋放一部分BUFFER POOL中的數據頁，從而保證SQL SERVER 有一定的空閑頁,如果空閑頁的數量太多會導致內存利用率低，而如果空閑頁的數量過低會導致頻繁地內存申請等待。本案例中的情況就屬於釋放過多數據頁導致。

PS2：由於該問題是日志傳送中的備份作業誘發，而備份使用的不是SQL SERVER 外部內存，因此我們曾懷疑是外部內存壓力所導致，嘗試降低max server memory (MB)來使Windows有更多的可用內存（從原來的5GB左右增大到20GB左右），后發現該操作並不能解決此問題。

PS3：一部分DBA同仁（包括我和我以前的一些同事）在遇到問題時總是從自身操作查找原因，卻忽略了查找SQL SERVER BUG，做了很多無用功還解決不了問題。

PS4：除了在安裝SQL SERVER時會考慮打補丁外，我此前就從不關注補丁及其最新動態，在以往和一些高手們討論問題時，他們經常會提及某某補丁修復了某某bug，讓我很驚奇，現在知道差距所在！

--========================================

亂七八糟地寫了一堆，主要是想記錄下處理問題的過程，學習別人處理的思路，找到自己不足的地方，如有不對，望諸君及時拍磚指點！

--========================================

慣例依舊是妹子