在查询时删除 PLE

Question

在公司中，我们正在从事非常大的数据库项目。它使用 100GB 内存。有什么奇怪的，第一次运行查询 PLE 之前是 11k~，运行后下降到大约 70，无论如何，15 分钟后我再次检查 PLE 大约 1k~，当我再次运行查询时它下降到 60。为什么会发生？如果在运行查询之间的时间 PLE 增加是否意味着所有需要的数据都在缓存中？如果是这样，为什么在 15 分钟后运行相同的查询会导致 PLE 再次下降？

这是查询：

select
    ResultType = case r.TypeID
        when 'dlp' then 'DLP'
        when 'bill' then 'BILL'
        when 'evtlog' then 'EVTLOG'
    end,
    SerialNumber, 
    ESerialNumber, 
    ResultDateTime, 
    DateTimeStamp as SavedInSystem
from 
    Results r
where
    TypeID in ('typeid1','typeid2')
    and DateTimeStamp > '2016-05-19 23:00:00'
    and SerialNumber in ('serialnumber')

我有一个聚集索引的datetimestamp和非在群集typeid, datetimestamp并resultdatetime, resultid, typeid和其他几个... @Update

    select
(physical_memory_in_use_kb/1024)Memory_usedby_Sqlserver_MB,
(locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB,
(total_virtual_address_space_kb/1024 )Total_VAS_in_MB,
process_physical_memory_low,
process_virtual_memory_low
from sys. dm_os_process_memory

返回

Memory_usedby_Sqlserver_MB  Locked_pages_used_Sqlserver_MB  Total_VAS_in_MB process_physical_memory_low process_virtual_memory_low
102569  0   134217727   0   0

这里是计数器，因为 freepages 在 2012 版本中被删除，我添加了一些其他计数器

object_name counter_name instance_name cntr_value cntr_type
MSSQL$ServerNameC3SCW:Buffer Manager Database pages 11356975 65792
MSSQL$ServerNameC3SCW:Buffer Manager Checkpoint pages/sec 1053996662 272696576
MSSQL$ServerNameC3SCW:Buffer Manager Page life expectancy 4233 65792
MSSQL$ServerNameC3SCW:Buffer Node Database pages 003 2975519 65792
MSSQL$ServerNameC3SCW:Buffer Node Page life expectancy 003 4892 65792
MSSQL$ServerNameC3SCW:Buffer Node Database pages 002 2938151 65792
MSSQL$ServerNameC3SCW:Buffer Node Page life expectancy 002 4051 65792
MSSQL$ServerNameC3SCW:Buffer Node Database pages 001 3002872 65792
MSSQL$ServerNameC3SCW:Buffer Node Page life expectancy 001 4052 65792
MSSQL$ServerNameC3SCW:Buffer Node Database pages 000 2440433 65792
MSSQL$ServerNameC3SCW:Buffer Node Page life expectancy 000 4052 65792
MSSQL$ServerNameC3SCW:Memory Manager Database Cache Memory (KB) 90855800 65792
MSSQL$ServerNameC3SCW:Memory Manager Free Memory (KB) 286672 65792
MSSQL$ServerNameC3SCW:Memory Manager Memory Grants Pending 0 65792
MSSQL$ServerNameC3SCW:Memory Manager Total Server Memory (KB) 104857608 65792
MSSQL$ServerNameC3SCW:Memory Node Database Node Memory (KB) 003 23804152 65792
MSSQL$ServerNameC3SCW:Memory Node Free Node Memory (KB) 003 73256 65792
MSSQL$ServerNameC3SCW:Memory Node Database Node Memory (KB) 002 23505208 65792
MSSQL$ServerNameC3SCW:Memory Node Free Node Memory (KB) 002 76392 65792
MSSQL$ServerNameC3SCW:Memory Node Database Node Memory (KB) 001 24022976 65792
MSSQL$ServerNameC3SCW:Memory Node Free Node Memory (KB) 001 77504 65792
MSSQL$ServerNameC3SCW:Memory Node Database Node Memory (KB) 000 19523464 65792
MSSQL$ServerNameC3SCW:Memory Node Free Node Memory (KB) 000 59520 65792

和查询后的计数器

object_name counter_name instance_name cntr_value cntr_type
MSSQL$ ServerNameC3SCW:Buffer Manager Database pages 11355652 65792
MSSQL$ ServerNameC3SCW:Buffer Manager Checkpoint pages/sec 1054000434 272696576
MSSQL$ ServerNameC3SCW:Buffer Manager Page life expectancy 310 65792
MSSQL$ ServerNameC3SCW:Buffer Node Database pages 003 2980418 65792
MSSQL$ ServerNameC3SCW:Buffer Node Page life expectancy 003 5417 65792
MSSQL$ ServerNameC3SCW:Buffer Node Database pages 002 2946298 65792
MSSQL$ ServerNameC3SCW:Buffer Node Page life expectancy 002 4591 65792
MSSQL$ ServerNameC3SCW:Buffer Node Database pages 001 2995850 65792
MSSQL$ ServerNameC3SCW:Buffer Node Page life expectancy 001 155 65792
MSSQL$ ServerNameC3SCW:Buffer Node Database pages 000 2433086 65792
MSSQL$ ServerNameC3SCW:Buffer Node Page life expectancy 000 165 65792
MSSQL$ ServerNameC3SCW:Memory Manager Database Cache Memory (KB) 90845216 65792
MSSQL$ ServerNameC3SCW:Memory Manager Free Memory (KB) 219240 65792
MSSQL$ ServerNameC3SCW:Memory Manager Memory Grants Pending 0 65792
MSSQL$ ServerNameC3SCW:Memory Manager Total Server Memory (KB) 104857608 65792
MSSQL$ ServerNameC3SCW:Memory Node Database Node Memory (KB) 003 23843344 65792
MSSQL$ ServerNameC3SCW:Memory Node Free Node Memory (KB) 003 51864 65792
MSSQL$ ServerNameC3SCW:Memory Node Database Node Memory (KB) 002 23570384 65792
MSSQL$ ServerNameC3SCW:Memory Node Free Node Memory (KB) 002 59680 65792
MSSQL$ ServerNameC3SCW:Memory Node Database Node Memory (KB) 001 23966800 65792
MSSQL$ ServerNameC3SCW:Memory Node Free Node Memory (KB) 001 58144 65792
MSSQL$ ServerNameC3SCW:Memory Node Database Node Memory (KB) 000 19464688 65792
MSSQL$ ServerNameC3SCW:Memory Node Free Node Memory (KB) 000 49552 65792
Target Server Memory (KB) MSSQL$GKKTSQLC3SCW:Memory Manager 104857608 65792

SELECT @@version 返回：

Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 
    2014 年 5 月 14 日 18:34:29 
    版权所有 (c) 微软公司
    企业版：Windows NT 6.3 (Build 9600:) 上的基于内核的许可（64 位）

在执行计划中，我可以看到聚集索引查找的成本为 100%，排序、哈希匹配的成本为 0%。有一个关于缺少索引的提示，但对于具有 2900 万行的表来说，这将是一个超过 5 列的附加索引。

Answer 1

查询删除 PLE 的情况并不少见。查询可以消耗任意数量的内存。这通常有两个原因：

1. 用于排序和散列的工作内存。
2. 用读取的数据填充缓冲池。

您可以通过在查询运行时观察来自相应 DMV 的未完成内存授予来证明 (1) 正在发生。如果查询消耗大量内存，您应该尝试实现不需要那么多内存的执行计划。您还可以尝试使用资源调控器限制消耗的内存。

问题 (2) 可以通过尝试使查询读取更少的数据来改善。在这里，您将创建一个索引，其中键列设置为支持where子句，包含列以覆盖所选列。您可以启用DATA_COMPRESSION.

通常，由于“页面不受欢迎”，大量扫描不会对缓冲池造成破坏。新读取的大扫描页面被处理为当必须释放内存时，它们是第一个而不是最后一个被驱逐的页面。我不记得确切的规则，但通常 SQL Server 可以扫描大量数据集而不会杀死缓冲池。

因此，作为实验，创建该索引（如果可能）和/或观察查询内存授权。