我继承了 SQL 服务器 { 2012 (SP3)，但是这个问题是通用的} 我们使用 SCOM 来监视它。以前，我每个月收到一两次 PLE < 300 的警报。现在我有时一天会收到 2 或 3 条警报。
有很多关于 PLE 的博客文章，一些你可以用来监控它的工具，以及关于什么是好的、坏的或无所谓的许多不同的意见。最后有很多变数。没有任何解决方案是一刀切的。低 PLE 与其说是一种症状，不如说是一个问题，它有很多潜在的原因，以及需要考虑的相关措施。
{这一段可能不会增加问题的价值，我愿意删除它} 我想每个人都同意在隔夜报告创建期间 PLE 每月一次下降到 299，是一种不需要解决的症状（假设报告在营业时间之前完成）。大多数人也同意 PLE 一直保持在 350 是不好的。在进行硬件更改之前，有几个原因需要考虑，查询和索引接近顶部。
在阅读了大约 12 篇关于 PLE 的博客文章后。我试图缩小关键症状的范围，以便对正在发生的事情有一个很好的了解。下面的查询是我想出的。它给出了与 PLE 互连的 4 个缓冲区管理器项的值
...
SELECT [object_name],
[counter_name],
[cntr_value] FROM sys.dm_os_performance_counters -- https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-os-performance-counters-transact-sql
WHERE [counter_name] = 'Page life expectancy' --if multiple NUMA on a server should return multiple Nodes,
OR [counter_name] = 'Free list stalls/sec' …我正在阅读 Grant Friitchey 的 SQL Server 执行计划，他提到：
SQL Server 不会永远将执行计划保存在内存中。使用“年龄”公式将计划的估计成本乘以计划的使用次数，它们会慢慢地从系统中老化出来。lazywriter 进程是一个内部进程，用于释放所有类型的缓存（包括计划缓存），它会定期扫描缓存中的对象并每次将该值减一。
如果满足以下条件，将从内存中删除该计划：
- 系统需要更多内存
- 计划的“年龄”已经到了零
- 该计划当前未被现有连接引用。
他还在书的前面提到了以下内容：
一旦优化器到达一个执行计划，估计的计划就会被创建并存储在一个称为计划缓存的内存空间中——尽管如果一个计划已经存在于缓存中，这一切都是不同的。
如果实际计划和估计计划不同，我会假设该计划理论上可以达到零。即使它存储在缓存中，这也会使估计的计划执行计数为零。
我的问题是计划年龄可以达到零的不同情况是什么？我的假设是否正确？
弗里奇，G.（2012 年）。SQL Server 执行计划。美国斯普林菲尔德：Simple Talk 出版。
今天早上，收到了以下电子邮件警报：
日期/时间：2/28/2018 9:26:42 AM
描述：尝试在数据库 9 中获取逻辑页 (1:3948712) 失败。它属于分配单元 72057594045857792 不属于 72059184917512192。
评论：（无）
作业运行：SQL Sentry 2.0 警报陷阱
查看辅助副本的事件日志，同一消息出现了 3 次：
源 spid138
消息 尝试获取数据库 9 中的逻辑页 (1:3948712) 失败。它属于分配单元 72057594045857792 不属于 72059184917512192。
在辅助副本（2 节点同步可用性组）上运行以下内容：
DBCC TRACEON(3604)
dbcc page (9, 1,3948712,3)
go
DBCC TRACEOff(3604)
任一副本的结果片段：
Page @0x00000070DAB8C000
m_pageId = (1:3948712) m_headerVersion = 1
m_type = 3 m_typeFlagBits = 0x0 m_level = 0
m_flagBits = 0x8200 m_objId (AllocUnitId.idObj) = 129 m_indexId
(AllocUnitId.idInd) = 256 Metadata: AllocUnitId = 72057594046382080
Metadata: PartitionId = 72057594040811520
Metadata: …我在 SQL 2017 实例上运行了查询存储 (QS)。目前在 RTM 中，RTM CU13 目前正在测试中，将在下个月的补丁窗口中应用于 prod。
虽然大多数查询和报告快速返回结果，几乎没有影响，但我尝试查看等待的任何事情都是有问题的。CPU 使用率从 20% 上升到 80%，并在那里停留几分钟，直到我杀死它。这是 24/7 生产系统，所以如果我真的想查看 QS 等待，我将需要在其他地方进行。
数据库为 150GB，其中 1000MB 空间用于 QS。我有一个有 10GB 空间的沙箱，所以如果我能把 QS 数据拿出来，我就可以在那里玩。
我环顾四周，我没有找到如何做到这一点。我发现的最好的是这篇sql.sasquatch 2016 post with an 2016 answer by Erin Stellato
目前没有导出和/或导入查询存储数据的选项，但有一个 Connect 项目可以投票：https : //connect.microsoft.com/SQLServer/feedback/details/2620017/export-query-store -tables-separately-from-the-database-tables
注意：链接转到重定向“Microsoft Connect 已停用”看起来实际链接应该是https://feedback.azure.com/forums/908035-sql-server/suggestions/32901670-export-query-store -表与数据分开
看看 Microsoft，我发现您可能用来访问数据的大多数东西都是视图、存储过程或报告。我没有看到从数据库中提取所有 QS 内容的方法。
直接查询的示例，使用视图示例 Kendra Little我曾想过从Select *视图中执行一个并将结果导出到我的沙箱的想法。但由于我没有找到任何人谈论它，我不确定这是个好主意。
有关的
此外， 我希望能够保留 CU13 之前的查询存储结果，以用作比较 CU13 之后的基线。
在第一个回答后编辑并编辑相同的 最近编辑 jadarnel27 对答案的编辑 …