Page Life Expectancy对实例有何看法？

我已经在环境中的一些SQL Server实例上安装了监视软件。我正在尝试查找瓶颈并解决一些性能问题。我想找出某些服务器是否需要更多内存。

我对一个计数器感兴趣：页面预期寿命。在每台机器上看起来都不同。为什么在某些情况下经常更改，这意味着什么？

请查看上周在不同计算机上收集的数据。您能对每个实例说些什么？

大量使用的生产实例（1）：

适度使用的生产方式（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位系统）。现在，我们拥有可以拥有TB RAM的64位系统，因此该建议已过时。

第一件事，您是否限制了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/zh-cn/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中）。

通常，由于将内容保存在内存中，因此越高，处理负载模式的速度就越快。如果它很低，则可能表示由于内存不足而导致的性能问题。

读数低并不总是意味着存在问题：例如，在大量的一次性大量使用大量页面的过程之后，读数可能会很低，因此请引入它们并放下它们以腾出更多空间。例如，您的图表似乎在每天结束时下降，可能是由每晚的管理工作（备份，数据归档，其他夜间处理）引起的。