![为 SQL Server 报告设置单独的数据库](https://linux22.com/image/605627/%E4%B8%BA%20SQL%20Server%20%E6%8A%A5%E5%91%8A%E8%AE%BE%E7%BD%AE%E5%8D%95%E7%8B%AC%E7%9A%84%E6%95%B0%E6%8D%AE%E5%BA%93.png)
我在这里(和其他网站)对此进行过大量研究。我觉得我遗漏了一些简单的东西。所以请引导我查看另一篇帖子或帮助回答我的问题。
基本上,我们已经超出了当前数据库服务器的承载能力。主要问题是 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:感谢您对可用性组和异步数据库镜像的修正。但是,据我所知,快照和日志传送恢复存在同样的问题。创建快照时用户将断开连接。我们使用的是企业版,所以这是一个选项。由于它不会干扰我们当前的备份系统,因此最终这可能是一个更好的选择。感谢您的意见,我会认真考虑。