【问题标题】:SQL server Transactional replication and SSRSSQL 服务器事务复制和 SSRS
【发布时间】:2016-08-06 23:28:58
【问题描述】:

我正在考虑在具有中高级 CRUD 活动的 70GB 主数据库(即将迁移到 SQL Server 2014)上实现事务复制。我们使用 SQL Reporting Services (2005-> 2014) 在工作时间内生成大量的夜间报告和中等的临时报告。

我的想法是使用事务复制,其中 1 个新 VM 用于主(发布者)数据库,1 个新 VM 用于分发者 + 1 个新 VM 用于订阅者,它自己的只读数据库用于 SSRS + 1 个新 VMN 用于报告目录 + 1 个 VM报告服务器(5 个新虚拟机)。

我打算使用 SSRS 从订阅者(只读,包含来自发布者的表子集)而不是发布者中检索数据。

如果我想保存一些虚拟机(不损失太多性能),我的问题: - 我可以将报告目录与订阅者放在同一台服务器上吗?或者 - 将分发者和订阅者数据库合并在同一个虚拟机上,但将报告目录留在单独的虚拟机上?

还有其他推荐吗?提前致谢。 WM

【问题讨论】:

    标签: reporting-services sql-server-2014 transactional-replication


    【解决方案1】:

    我们目前为两个客户的设置如下

    Publisher (VM) - 托管主应用程序数据库的服务器。 订阅者 (VM) - 服务器托管订阅者数据库、分发器(我们使用拉取订阅)和报告服务器。

    数据库大小约为 10gb,也是中高 CRUD

    该过程有效,其中一个缺点是当客户端使用事务处理试图更新的表对订阅者运行密集查询时。事务复制过程不会向订阅者提交事务。接下来,错误消息在最好的情况下没有帮助。如果您能找到其他解决方案,例如具有只读副本的可用性组可能是更好的解决方案。

    【讨论】:

    • 谢谢...但是带有只读副本的 AG 不会有同样的延迟问题吗?或者如果 AG 配置为异步提交模式,AG 的问题将是最小的?原谅我的无知。
    • 在我的情况下,DR 要求不高
    • 你对延迟提出了一个很好的观点,我会检查,因为我不确定。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-10-15
    相关资源
    最近更新 更多