我们目前有 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 的需求？
我最初的意图是展示我们当前的能力与我们计划的项目和重复任务的对比，但我们需要展示雇用额外资源的投资回报率。
我工作的公司目前使用 SQL Server 数据库（通常是最新的企业版）用于我们开发的产品。
我会将它描述为一个 OLTP 数据库，它具有大量时间关键应用程序的读写密集程度。除此之外，根据同一 OLTP 数据库（单独问题）中的信息显示了大量报告和图形数据，这些数据以频繁的速率读取和写入许多相同的表。
我们通常会遇到发生阻塞的问题，并且通常最终会减慢时间关键应用程序的速度，甚至由于这些应用程序中的死锁而导致问题。这个问题的常见解决方案似乎通常是对nolock有问题的查询提出提示。老实说，我讨厌这个解决方案，很长一段时间以来，我一直认为这是尝试解决这个问题的错误方法，从我阅读的所有内容中，我得出了相同的结论。
一段时间以来，我一直试图说服我的团队 RCSI 是我们绝对可以从中受益的东西，特别是考虑到我们的数据库类型。他们似乎认为这是一个很大的风险，并且经常因为风险因素而推迟它，但我们继续遇到性能问题，我们只是nolock在暗示它。
我正在寻找一种向我们的团队展示具体指标的好方法，以最终说服他们我们应该转向这种方法。
在数据库上启用AUTO_CREATE_STATISTICS&后AUTO_UPDATE_STATISTICS_ASYNC，什么性能指标最能显示更改？
我们刚刚意识到遗留系统的数据库从来没有打开过AUTO_CREATE_STATISTICS& AUTO_UPDATE_STATISTICS_ASYNC（AUTO_UPDATE_STATISTICS被打开）。
正如您所期望的那样，在打开这些功能后，我们的应用程序的性能要好得多。响应时间明显缩短，用户无需等待屏幕刷新或页面加载。
数据库索引良好，我们已经在我们认为需要的地方手动创建了统计信息。启用后立即检查sys.stats（加入sys.stats_columns& sys.objects），它只需要在三个对象上创建统计信息。（我将这些记录下来，以防量化这些变化取决于它们。）
我在此服务器上捕获了大量性能数据，并且查看了更改之前和之后的数据，但我还没有确定实际收益在哪里。
我还有其他类似的系统，其中该数据库的自动统计功能仍处于关闭状态。这些系统也将从启用它们中受益，但我正在等待，以防有一些我还没有的指标，我可以在进行更改之前添加它。
除了用户体验之外，我如何量化通过更改系统上的 Auto-Stats 设置所带来的增加？
Windows Server 2008 上的 SQL Server 2008R2。
在尝试确定最合适的高可用性选项时，我们专注于减少停机时间（计划内或计划外）。我已经能够收集有关故障转移群集实例 (FCI) 的统计信息（通过阅读大量 MSDN 文档和博客）。
我还没有找到有关可用性组的故障转移统计信息/次数的文档。
作为比较 (FCI)：
故障转移 2008R2 集群的时间范围从 30 秒到 5 分钟不等（取决于流量以及硬件/网络设置）：
进行手动故障转移时，它会完成对 LUN 的写入，将 LUN 切换到新的主动节点，并在新的主动节点上启动 SQL Server 实例。
在进行自动故障转移时，启动节点后，它将对数据库进行一致性检查并回滚任何进行中的事务。
可用性组
我知道，当您比较相同的硬件和流量时，可用性组应该能够更快地进行故障转移。
我无法找到比较两者的任何真实世界的实际指标。
具体来说，是否有人对正在积极使用的可用性组中的主写入节点进行故障转移所需的时间有任何指标？
（故障转移到同步辅助）理想情况下，这将包括对任何 Microsoft 或可信赖来源的引用。请不要基于意见，只有指标。