问题[metrics](dba)

我需要按应用程序/数据库报告 SQL Server 正常运行时间的每月指标。这将在集群级别。IE，如果辅助副本离线，但主副本仍可用于处理事务，则正常运行时间仍将被视为 100%。

我已经查看了可能用于此目的的各种工具，其中一些工具接近了。但是，除了 SQL Server 服务处于联机状态并接受连接之外，它们似乎都没有捕获任何东西。他们也无法在集群/AG 级别聚合这些指标。这意味着如果辅助副本离线，这些正常运行时间报告将受到影响。

例如，假设数据库脱机或日志文件已满，并且无法针对单个数据库处理事务。这些工具会说 SQL Server 已启动，但我仍然会有人说这是数据库问题。因此，这些指标需要反映当时 SQL 尚未完全启动。

在这一点上我想出的最好的想法是创建一个 SQL 代理作业，该作业将记录插入每个数据库的 Canary 表中，每分钟一次。然后在月底，查询该表并将上个月的行数除以预期的行数。我认为没有比尝试插入一行更好的方法来证明数据库实际上是可用的。

我已经开发、测试和工作了上述解决方案。但我很好奇是否有人知道更好的方法来做到这一点。包括我可能忽略的任何商品工具或 DMV，我可以用来推断 SQL 实例上所有数据库的最终用户可用性指标？

我们目前有 2 个 DBA，我和另一个人，我们都觉得需要额外的资源（或两个）。我已经和我的直属经理就这个话题进行过几次不同的谈话，但我很难把这个想法卖掉。最近，我们的经理与我们分享说，列出我们想要或觉得需要做的事情的“软价值观”清单真的很好，但真正有帮助的是提出“硬价值观”，显示美元储蓄。

您能否首先帮助我了解我们的感知需求是否合理，如果是这样，我们如何着手提出这个“硬价值观”清单。我觉得我们可以想出一些我们需要做的事情来为公司省钱，但这可能只是放在我们优先事项列表的前面，并且在这个过程中给我们带来更多压力。

为了让您对我们的环境有一个更高层次的了解，以下是我所关注的关于我们提供支持的内容。

生产服务器 – 30 多个
生产数据库 – 200 多个
SQL 版本 – 2008/2008R2/2012，现在展望 2014 年，今年晚些时候展望 2016 年
应用程序（第 3 方和本土开发） –
支持 20 多个应用程序团队 – 6
虚拟化 – 75%虚拟化 25% 的物理
集群 – 3 个以上计划
复制 – 1 个分发服务器、2 个订阅服务器、24 个订阅、6 个发布服务器、12 个发布
日志传送 – 8 个主要 + 更多计划，4 个辅助 + 更多计划，49 个日志传送数据库 + 更多计划
的可用性组 – 目前没有，但正在探索
推动版本更改或 DBA 资源的每年平均应用程序升级/安装的可能性 – 2-3
修补（SP、CU）——目前不存在，除非出现问题累积数据库大小——14TB+
报告服务器——一个由 2 台服务器组成的横向扩展部署，我们都不精通 SSRS
分析服务器——两台服务器，我们都不精通 SSAS

我们应该使用什么指标来证明或反驳对额外 DBA 的需求？

我的初衷是展示我们当前的能力与我们计划的项目和重复任务的对比，但我们需要展示雇用额外资源的投资回报率。