我在这里（和其他网站）对此进行过大量研究。我觉得我遗漏了一些简单的东西。所以请引导我查看另一篇帖子或帮助回答我的问题。
基本上，我们已经超出了当前数据库服务器的承载能力。主要问题是 CPU 使用率过高，这是因为报告编写不当，而关系数据库设计不当。另一个问题是由于运行的两个工作负载的 IO 使用率。在使用率高时以及报告指向同一台服务器时，用户在尝试保存到系统中时会遇到锁定和问题。索引和维护工作经常进行。索引中几乎没有会导致 IO 或 CPU 增加的碎片。锁定（由报告）已被最小化，但其他查询仍需要获取锁定以保持合规性。
我被迫从中分割出两个主要工作负载...顺便说一句，无论如何都应该这样做，因为一个是 OLTP 工作负载，另一个是使用 SSRS 的报告工作负载。
以下是我尝试创建单独报告数据库的三个主要选项，以及每个选项不起作用的原因。
已经尝试过的事情：
完整数据库复制 – 这是我们一直在做的事情，但速度很慢，而且我们的报告会保留 12 小时前的旧数据。这不符合我们的业务需求或最终用户的期望。
日志传送 – 我尝试实施此操作，但我们失去了备份的 15 分钟恢复选项（数据保护管理器）。能够以 15 分钟为增量恢复数据库似乎比拥有单独的报告数据库更重要。这是我的主管提出的一个有效观点，尽管由于用户在系统的 OLTP 方面遇到的问题，它正成为一个日益严重的问题。日志传送的另一个问题是，在报告数据库上进行恢复时，报告服务器可能会关闭。
3.复制 – 事务复制是 Microsoft 推荐的解决方案。它可以保留我们的 15 分钟备份，并为我们提供几乎实时的报告数据。由于他们在我们的医疗记录系统中使用的一些代码，它与复制不兼容。大量使用截断（复制不支持）以及允许最终用户通过 Web 界面创建新数据库列（对架构进行更改）的（可疑）能力。
有没有什么帮助？谢谢。
答案1
由于我似乎没有能力回复已发布的答案，所以我将以这种方式回复。抱歉造成混淆。
Mark Henderson：是的，我做了大量优化这些查询的工作。不幸的是，我能做的只有这么多，无法让它们表现更好。其中一些与第三方医疗记录系统的代码有关……其中一些与我为服务器提供的资源不足有关，无法充分处理这两种工作负载。索引值得重新检查，尽管我已经做了相当多的工作，但我会继续调查。
CMcKeown：我最近读了更多关于镜像的文章。其中的注意事项似乎与日志传送类似。在快照发生时，报告数据库将处于脱机状态，用户将断开连接。据我所知，镜像还需要一个可用性组，这可能需要对医疗记录应用程序进行更改，而我可能没有能力实施。
darin strait：是的，我编写了脚本，只对碎片率只有一定百分比的索引进行碎片整理或重建。这是由于数据库的增长量而必须的。频繁更新的表上的索引比其他索引碎片化得更快……因此，必须单独处理它们。我们就报告数据的滞后时间进行了一些讨论。起初长达 24 小时是可以的，然后我们收到了一些用户的反对，现在许多报告显然需要几乎实时的数据。我现在正试图推动每小时或半小时的窗口。问题的一部分是让每个人都满意，如果我做不到，那么就让合适的人尽可能高兴。我不知道为什么我没有考虑使用发送到 DPM 的日志备份来填充报告数据库。如果不真正研究它，问题似乎与日志传送相同，因为数据库在恢复时必须处于脱机状态。我也不知道 DPM 是否有一种很好的自动化方法来处理这样的任务。这是值得研究的，所以我感谢你的想法。
darin strait：感谢您对可用性组和异步数据库镜像的修正。但是，据我所知，快照和日志传送恢复存在同样的问题。创建快照时用户将断开连接。我们使用的是企业版，所以这是一个选项。由于它不会干扰我们当前的备份系统，因此最终这可能是一个更好的选择。感谢您的意见，我会认真考虑。