在SQLServer中如何快速的排除內存故障

這篇文章主要介紹“在SQLServer中如何快速的排除內存故障”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“在SQLServer中如何快速的排除內存故障”文章能幫助大家解決問題。

關于 SQL 在物理服務器上使用內存 (RAM) 存在許多誤解。我聽到的最常見的情況是用戶擔心服務器 RAM 即將用完。SQL Server 旨在使用盡可能多的內存。唯一的限制是實例設置為上限（最大內存）的內存量以及服務器上實際使用的 RAM 量。

例如，假設您的 SQL 服務器僅使用 8GB 內存以最佳方式運行，并且服務器顯示大約 95% 的總 RAM 正在使用中。您可以將機器上的 RAM 加倍，將 SQL 實例的 Max Memory 設置加倍，然后看著服務器慢慢回升到 95%。這不一定是問題。SQL 只是根據給定的內容緩存盡可能多的臨時數據。

下面是我的快速調查要點，以確定是否確實存在內存問題，或者 SQL Server 是否只是在做它應該做的事情：

從實例屬性驗證最大內存設置并將其與服務器總內存進行比較。盡量給出SQL，但是每個環境不一樣。還有許多因素需要考慮（實例數量、應用程序、工作負載、集群狀態等）。至少，請確保為操作系統留出一些 GB。此外，確保這臺機器上還有其他任何需要它的東西。

如果您的最大內存設置為 2147483647，請立即更改。這是 SQL 安裝時使用的默認值，告訴它根據需要使用多少。這可能會導致服務器上的操作系統和其他應用程序出現性能問題，并在遇到瓶頸時減慢一切。

從實例屬性運行內置的內存消耗報告。要立即查找的健康細節是高 PLE 值和低內存授予待定值。頁面預期壽命是頁面在釋放以“重用”服務器上的內存之前將在緩沖池中停留的秒數。一般建議是 300 秒或更長，但當服務器上的 RAM 量較大時，此建議會呈指數增加。Memory Grants Pending 是等待工作區內存授予的進程數。零是最好的值，因為它意味著所有運行的東西都能夠以它需要的足夠內存量來運行。  

運行以下查詢以檢查當前內存計數器。第三個結果集將顯示內存更改發生時的時間戳。留意任何“低”內存警報，然后確定如果 SQL 使用了適當的數量，是否應該進一步調查內存壓力。

SQL:

SELECT @@SERVERNAME AS [Server Name]
,total_physical_memory_kb / 1024 AS [Total Physical Memory (MB)]
,available_physical_memory_kb / 1024 AS [Available Physical Memory (MB)]
,total_page_file_kb / 1024 AS [Total Page File Memory (MB)]
,available_page_file_kb / 1024 AS [Available Page File Memory (MB)]
,system_memory_state_desc AS [Available Physical Memory]
,CURRENT_TIMESTAMP AS [Current Date Time]
FROM sys.dm_os_sys_memory
OPTION (RECOMPILE);
GO
SELECT physical_memory_in_use_kb / 1024 AS [Physical Memory In Use (MB)]
,locked_page_allocations_kb / 1024 AS [Locked Page In Memory Allocations (MB)]
,memory_utilization_percentage AS [Memory Utilization Percentage]
,available_commit_limit_kb / 1024 AS [Available Commit Limit (MB)]
,CASE WHEN process_physical_memory_low = 0 THEN ‘No Memory Pressure Detected’ ELSE ‘Memory Low’ END AS ‘Process Physical Memory’
,CASE WHEN process_virtual_memory_low = 0 THEN ‘No Memory Pressure Detected’ ELSE ‘Memory Low’ END AS ‘Process Virtual Memory’
,CURRENT_TIMESTAMP AS [Current Date Time]
FROM sys.dm_os_process_memory
OPTION (RECOMPILE);
GO
WITH RingBuffer
AS (
SELECT CAST(dorb.record AS XML) AS xRecord
,dorb.TIMESTAMP
FROM sys.dm_os_ring_buffers AS dorb
WHERE dorb.ring_buffer_type = ‘RING_BUFFER_RESOURCE_MONITOR’
)
SELECT xr.value(‘(ResourceMonitor/Notification)[1]’, ‘varchar(75)’) AS Notification
,CASE
WHEN xr.value(‘(ResourceMonitor/IndicatorsProcess)[1]’, ‘tinyint’) = 1
THEN ‘High Physical Memory Available’
WHEN xr.value(‘(ResourceMonitor/IndicatorsProcess)[1]’, ‘tinyint’) = 2
THEN ‘Low Physical Memory Available’
WHEN xr.value(‘(ResourceMonitor/IndicatorsProcess)[1]’, ‘tinyint’) = 4
THEN ‘Low Virtual Memory Available’
ELSE ‘Physical Memory Available’
END AS ‘Process Memory Status’
,CASE
WHEN xr.value(‘(ResourceMonitor/IndicatorsSystem)[1]’, ‘tinyint’) = 1
THEN ‘High Physical Memory Available’
WHEN xr.value(‘(ResourceMonitor/IndicatorsSystem)[1]’, ‘tinyint’) = 2
THEN ‘Low Physical Memory Available’
WHEN xr.value(‘(ResourceMonitor/IndicatorsSystem)[1]’, ‘tinyint’) = 4
THEN ‘Low Virtual Memory Available’
ELSE ‘Physical Memory Available’
END AS ‘System-Wide Memory Status’
,DATEADD(ms, – 1 * dosi.ms_ticks – rb.TIMESTAMP, GETDATE()) AS NotificationDateTime
FROM RingBuffer AS rb
CROSS APPLY rb.xRecord.nodes(‘Record’) record(xr)
CROSS JOIN sys.dm_os_sys_info AS dosi
ORDER BY NotificationDateTime DESC;

關于“在SQLServer中如何快速的排除內存故障”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。