SQL Sentry需手动配置Windows性能计数器Processor(_Total)\% Processor Time告警，推荐15秒采样、动态基线2.5标准差，并注意实例名与通知扩展。

SQL Sentry 里怎么设置 CPU 使用率超阈值实时告警

SQL Sentry 默认不自动触发 CPU 异常告警，必须手动绑定性能计数器 + 配置告警策略。它监控的是 Windows 性能计数器 Processor(_Total)\% Processor Time，不是 SQL Server 内部的 sys.dm_os_ring_buffers 数据。

• 在 Alerts → New Alert → Performance Counter Alert 中选择该计数器，采样间隔建议设为 15 秒（太短易误报，太长漏告）
• 阈值别直接填 80——基线波动大时，固定值会频繁抖动；改用「动态基线」：勾选 Use baseline deviation，设为 2.5 标准差（比默认 2.0 更稳）
• 注意计数器实例名：虚拟机或 NUMA 节点多时，_Total 可能掩盖局部过载，必要时要单独配 Processor(0)、Processor(1) 等实例
• 告警触发后，SQL Sentry 默认只发邮件；若需企业微信/钉钉，得走 Alert Action → Execute Program 调外部脚本，别指望内置集成

SolarWinds DPA 的 SQL Server 基线是怎么算出来的

DPA 的「基线」不是简单取 7 天平均值，而是基于历史负载模式自动聚类：按小时、工作日/周末、是否节假日分段建模，再对每段拟合趋势+周期项。这意味着周一早 9 点的基线，和周五晚 9 点的基线，完全独立。

• 基线更新频率默认是 24 小时一次，但只有当新数据与当前模型残差持续超 3σ 达 3 次，才会触发重训练——所以突发流量不会立刻拉高基线，这是优点也是坑点
• Baseline Deviation 告警里的 2.0 并非标准差倍数，而是 DPA 自定义的「偏离强度」，实际对应约 1.8–2.2σ，不同版本有浮动，不能直接套统计学理解
• 如果数据库刚上线不到 14 天，DPA 会用「冷启动基线」：取前 3 天最高值 × 0.7 作为初始参考，此时告警极容易误触发

两个工具都报「内存压力」但指标对不上怎么办

SQL Sentry 看的是 Windows 层 Memory\Available MBytes，DPA 看的是 SQL Server 层 SQLServer:Memory Manager\Total Server Memory (KB) 和 Page Life Expectancy 的加权组合。两者根本不在同一抽象层级，硬对比等于拿油表读数比发动机转速。

• 当 Available MBytes 1024 且 Total Server Memory 接近 max server memory 配置时，才是真内存争用；单看一个指标就开火，90% 是虚警
• DPA 的 Memory Pressure 评分含内部权重，你无法调整。但 SQL Sentry 的 Memory\Pages/sec > 20 持续 5 分钟，比 DPA 的评分更早暴露换页风暴
• 若两者结论冲突，优先信 sys.dm_os_memory_clerks 里 single_pages_kb + multi_pages_kb 的实时增长趋势，工具只是代理，不是真相

告警太多刷屏，怎么快速过滤掉维护窗口的噪音

SQL Sentry 支持按「Maintenance Window」静音，DPA 需靠「Scheduled Maintenance」，但二者逻辑不同：前者是时间范围屏蔽，后者是对象+时间双重匹配，漏配一个数据库就照常告警。

• SQL Sentry 的维护窗口必须提前在 Configuration → Maintenance Windows 里创建，且告警规则要显式勾选 Suppress during maintenance windows——不勾没用
• DPA 的维护计划必须关联到具体实例（不是实例组），且起止时间得精确到分钟；它不识别 SQL Agent 维护作业的运行时间，别想自动同步
• 最稳妥的做法：在维护开始前，用 SQL Sentry 的 Alert Suppression API 或 DPA 的 /api/v1/maintenance 接口发一次性静音，比界面点更可靠

基线不是贴在墙上的参考线，它是活的模型，会随你删库、加索引、切版本悄悄偏移。最常被忽略的，是告警响应时没顺手查下基线本身的稳定性——比如 DPA 的基线健康度低于 60%，那所有偏离告警都该打个问号。