Page Life Expectancy 對實例有何評價？
我已經在環境中的幾個 SQL Server 實例上安裝了監控軟體。我試圖找到瓶頸並解決一些性能問題。我想知道某些伺服器是否需要更多記憶體。
我對一個計數器感興趣：頁面預期壽命。它在每台機器上看起來都不一樣。為什麼它在某些情況下經常改變，這是什麼意思？
請查看上週在幾台不同機器上收集的數據。你能對每個實例說些什麼？
大量使用的生產實例（一）：
適度使用的生產距離 (2)
很少使用的測試實例（3）
大量使用的生產實例（4）
中度使用的測試實例（5）
大量使用的數據倉庫 (6)
編輯：我為所有這些伺服器添加了 SELECT @@VERSION 的輸出：
Instance 1: Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) Jun 17 2011 00:54:03 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor) Instance 2: Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) Oct 19 2012 13:38:57 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor) Instance 3: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) May 14 2014 18:34:29 Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor) Instance 4: Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) Jun 28 2012 08:36:30 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor) Instance 5: Microsoft SQL Server 2012 - 11.0.5058.0 (X64) May 14 2014 18:34:29 Copyright (c) Microsoft Corporation Developer Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor) Instance 6: Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) Apr 2 2010 15:48:46 Copyright (c) Microsoft Corporation Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)我還在機器上執行了以下查詢：
SELECT DISTINCT memory_node_id FROM sys.dm_os_memory_clerks它為每個伺服器返回 2 或 3 行：
Instance 1: 0; 64; 1 Instance 2: 0; 64 Instance 3: 0; 64 Instance 4: 0; 64 Instance 5: 0; 64 Instance 6: 0; 64; 1這是什麼意思？這些伺服器是否執行 NUMA？
取自 MSDN：- https://msdn.microsoft.com/en-us/library/ms189628.aspx
頁面預期壽命 - 表示頁面將在沒有引用的情況下停留在緩衝池中的秒數。
SQL 總是在記憶體中查找數據頁。如果數據頁不在記憶體中，SQL 將不得不進入磁碟（執行物理 IO 操作）以檢索完成請求所需的數據。如果您的 PLE 計數器較低，則表明記憶體中的數據頁面經常被來自物理 IO 操作的新頁面覆蓋。物理 IO 操作代價高昂，這意味著您的 SQL 實例的性能會受到不利影響。所以你會希望你的 PLE 計數器盡可能高。
忽略您在網上看到的任何建議，其中提到 300 作為此計數器的良好門檻值
這個門檻值來自記憶體有限的日子（想想 32 位系統）。現在我們有 64 位系統，可以有 TB 的 RAM，所以這個建議已經過時了。
首先，您是否限制了 SQL 的記憶體？如果是這樣，還剩下多少可用記憶體？可以提高限額嗎？
我要在您的伺服器上尋找的第二件事是，是否有任何維護工作正在執行？檢查執行索引重建、更新統計資訊或 DBCC CHECKDB 操作的作業。這些執行大量讀取，可能是您的 PLE 扁平化的原因，
接下來，當您使用 SQL Server 2008 + 時，您可以設置擴展事件會話來擷取傳入執行大量讀取的查詢。這是執行此操作的程式碼：-
CREATE EVENT SESSION [QueriesWithHighLogicalReads] ON SERVER ADD EVENT sqlserver.sql_batch_completed( ACTION(sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_id,sqlserver.sql_text,sqlserver.tsql_stack,sqlserver.username) WHERE ([logical_reads]>200000)) ADD TARGET package0.event_file(SET filename=N'C:\SQLServer\XEvents\QueriesWithHighLogicalReads.xel') GO這將擷取伺服器上執行超過 200000 次邏輯讀取的所有查詢。我不知道您在每台伺服器上有多少記憶體，因此您可能需要調整該數字。創建完成後，您可以通過執行以下命令開始會話：-
ALTER EVENT SESSION [QueriesWithHighLogicalReads] ON SERVER STATE = START; GO然後通過執行查詢會話：-
WITH CTE_ExecutedSQLStatements AS (SELECT [XML Data], [XML Data].value('(/event[@name=''sql_statement_completed'']/@timestamp)[1]','DATETIME') AS [Time], [XML Data].value('(/event/data[@name=''duration'']/value)[1]','int') AS [Duration], [XML Data].value('(/event/data[@name=''cpu_time'']/value)[1]','int') AS [CPU], [XML Data].value('(/event/data[@name=''logical_reads'']/value)[1]','int') AS [logical_reads], [XML Data].value('(/event/data[@name=''physical_reads'']/value)[1]','int') AS [physical_reads], [XML Data].value('(/event/action[@name=''sql_text'']/value)[1]','varchar(max)') AS [SQL Statement] FROM (SELECT OBJECT_NAME AS [Event], CONVERT(XML, event_data) AS [XML Data] FROM sys.fn_xe_file_target_read_file ('C:\SQLServer\XEvents\QueriesWithHighLogicalReads*.xel',NULL,NULL,NULL)) as v) SELECT [SQL Statement] AS [SQL Statement], SUM(Duration) AS [Total Duration], SUM(CPU) AS [Total CPU], SUM(Logical_Reads) AS [Total Logical Reads], SUM(Physical_Reads) AS [Total Physical Reads] FROM CTE_ExecutedSQLStatements GROUP BY [SQL Statement] ORDER BY [Total Logical Reads] DESC GO執行時要小心！該文件的大小可能會變得非常大，因此請先在開發實例上對其進行測試。您可以設置最大值。文件的大小，但我沒有在這裡包含它。這是擴展事件的 MSDN 連結：- https://msdn.microsoft.com/en-us/library/hh213147.aspx
定期監控此會話，並希望它能夠接收到任何與您的 PLE 一致的查詢。
延伸閱讀——
PLE 上的 MSDN 部落格 - http://blogs.msdn.com/b/mcsukbi/archive/2013/04/12/sql-server-page-life-expectancy.aspx
關於設置擴展事件的影片 - https://dbafromthecold.wordpress.com/2014/12/05/video-identifying-large-queries-using-extended-events/ （來自我自己的部落格，非常抱歉無恥的自我宣傳)
頁面預期壽命是衡量您可以預期剛剛從磁碟讀取的頁面在被其他東西推出或被破壞之前在記憶體中停留多長時間（即該頁面在磁碟上被釋放到不需要將副本記憶體在 RAM 中）。
作為一般措施，它越高，載入模式的處理速度就越快，因為事情被保存在記憶體中。如果它非常低，這可能表示記憶體不足導致的性能問題。
但是，讀數偏低並不總是意味著存在問題：例如，在使用大量頁面的大量一次性過剩程序之後，讀數可能會偏低，因此將它們引入並丟棄以騰出更多空間。例如，您的圖表在每天結束時似乎下降，這可能是由夜間管理工作（備份、數據歸檔、其他夜間處理）引起的。