标签: sp-blitz

我遇到了一个奇怪的问题，SQL Server 2016 标准版 64 位似乎将自己限制在分配给它的总内存的一半（128GB 中的 64GB）。

的输出@@VERSION是：

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 2017 年 12 月 22 日 11:25:00 版权所有 (c) Windows Server 2012 R2 Datacenter 6.3 上的 Microsoft Corporation 标准版（64 位）（内部版本 9600：）（管理程序）

的输出sys.dm_os_process_memory是：

当我查询时sys.dm_os_performance_counters，我看到Target Server Memory (KB)是在131072000和Total Server Memory (KB)是 at 的一半以下65308016。在大多数情况下，我认为这是正常行为，因为 SQL Server 尚未确定它需要为自己分配更多内存。

然而，它已经“卡住”在 64GB 左右超过 2 个月了。在此期间，我们对一些数据库执行了大量内存密集型操作，并向实例添加了近 40 个数据库。我们总共有 292 个数据库，每个数据库都有 4GB 的预分配数据文件和 256MB 的自动增长速率和 2GB …

我登录到一个新的客户端系统并运行 sp_blitz 以查看发生了什么变化。它报告说“ CPU Schedulers Offline ”对我来说是一个新的。

由于关联屏蔽或许可问题，SQL Server 无法访问某些 CPU 内核。

很公平，我运行基本查询

SELECT
    DOS.is_online
,   DOS.status
,   DOS.*
FROM
    sys.dm_os_schedulers AS DOS
ORDER BY
    1;

那报告说我有 8 个设置为离线可见，43 个设置为在线。据我所知，该客户端上的任何人都不会故意设置任何 CPU 关联性。

我决定看看我是否可以解开它。当我查看属性窗口时，我看到 40 个可用的处理器，但没有一个设置为具有关联性。

为什么在 is_online 为 true 的 dm_os_schedulers 中有 40 个显示 43 个条目似乎也很好奇。8离线的cpu_id是32到39。

sys.configurations 似乎同意没有明确开启关联

name                 value  value_in_use  description
affinity I/O mask    0      0             affinity I/O mask
affinity mask        0      0             affinity mask
affinity64 I/O mask  0      0             affinity64 I/O mask
affinity64 mask      0      0             affinity64 mask …

我正在运行带有 SQL Server 实例的云 VPS。因为它是供个人使用的，所以我使用的是 express 版（我不能使用开发者版，因为我在技术上运行了生产应用程序，而且我买不起 Standard+）。

我正在尝试使用Brent Ozar 的教程使用sp_BlitzFirst. 我遇到的问题是，无论当时的实际 CPU 使用情况如何，ProcessUtilizationinsys.dm_os_ring_buffers总是100以 形式出现。

虚拟机信息

@@version： Microsoft SQL Server 2017 (RTM-CU15) (KB4498951) - 14.0.3162.1 (X64) May 15 2019 19:14:30 版权所有 (C) 2017 Microsoft Corporation Express Edition（64 位）Linux (Ubuntu 18.04) .2 LTS)

主机： 1 & 1 Ionos VPS

lscpu 输出

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              2
On-line CPU(s) list: 0,1
Thread(s) per …

Run Code Online (Sandbox Code Playgroud)

我在我的一台生产服务器上运行了 Brent Ozar 的 sp_blitz。IT 将 MSDB 数据库中的一些表标记为是用户创建的。它们都遵循 dbo.DTA_* 模式。这些表是随 MSDB 一起提供的，还是由某事/某人添加的？

大约每周一次，查询 sp_Blitz @IgnorePrioritiesAbove = 50, @CheckUserDatabaseObjects = 0 显示非常旧的数据库备份的“错误”。

显示这一点是正确的，但是如果可用性组 DB 位于辅助节点上且未备份（我使用 Ola 的脚本来备份 DB），是否可以过滤此错误？

我需要运行sp_BlitzGlenn Berry 的 Dr DMV 并为 SQL 2016 设置一堆 DMV 查询sp_Blitz。BrentOzar.com 上的文档指出“系统管理员权限。sp_Blitz® 检查大量系统级诊断数据。”

sysadmin 真的是所需的最低权限级别还是有人能够以更严格的权限级别运行它？

不确定我是否会在客户端的生产服务器上请求 sysadmin 权限。

我正在使用 Brent Ozar 的 sp_BlitzCache 存储过程，并试图确定它报告的原因：

“您计划中的某些内容正在强制进行串行查询。如果这不是故意的，则需要进一步调查。”

经过调查，我发现服务器配置已设置：

'Max Degree of Parallelism = 1' 

（这是我要正确配置的清单。这是无知的日子。）

这是否是 Brent 报告强制序列化的原因？

我已经在我们的测试数据库服务器上运行了 sp_blitz（版本 45）。它抱怨

数据库 [MDS] 具有用于页面验证的 TORN_PAGE_DETECTION。SQL Server 可能更难识别存储损坏并从中恢复。考虑使用 CHECKSUM 代替。

但这是来自微软的数据库。
将页面验证更改为 CheckSum 是否明智？

还是应该等微软发布新版本的MDS？

为什么一个查询的多个计划不好

所以我跑去sp_Blitz处理一些系统。有一些代码可以像往常一样清理。一些应该是聚集索引的堆。等等。

这个特定的查询使用了文字，似乎产生了很多计划。在此查询中的表上整理了索引和内容，甚至为最新的代码/数据库将查询参数化以投入生产。

但是查询仍然显示为参数化问题。（DBA 帮助将计划缓存查询转换为 SSRS 报告，因此我可以从浏览器在 PROD 环境中快速运行它们）。

然后去哪儿？忽略它？（似乎很多计划都很重要）

使用强制参数化？（但显式参数化的那个出现了）。

呃 - 我看到开发人员没有接受我的建议，认为它LEFT JOIN正在变成INNER JOIN......我必须把它修好......

如果没有强制参数化，所有这些文字样式的查询将永远不会共享相同的计划吗？这个查询对于简单的参数化是否太复杂了？

我运行了sp_Blitz，它指出了一个内存问题，说：

Memory Dangerously Low 服务器有 32755 MB 的物理内存，但只有 235 MB 可用。由于服务器内存不足，因此存在交换到磁盘的危险，这会降低性能。

服务器有32 GB RAM总，0-2 MB FreeRAM， 200 - 2376 Mb Available。

@@版本：Microsoft SQL Server 2008 R2 (SP2) - 10.50.4000.0 (X64) 2012 年 6 月 28 日 08:36:30 版权所有 (c) Microsoft Corporation Enterprise Edition（64 位），Windows NT 6.1（内部版本 7601：Service Pack） 1)

我看了一会儿性能计数器，看到了以下值：

Page Faults/s _Total ~ 1.200 Average, Max 18.000, regular Peeks up to 1500.
Page Faults/s sqlserver ~ 380 Average, Max 1600, regular Peeks …