【问题标题】:SQL Server replacement for trigger with data transformationSQL Server 用数据转换替换触发器
【发布时间】:2015-04-23 08:50:53
【问题描述】:

我们有以下设置:

  • 服务器 SRV_1 有两个数据库:OLTP 数据库 DB_APP 和报告数据库 DB_REP。
    DB_APP 有许多触发器,它们执行一些数据转换(非规范化,使用连接到其他表来匹配非规范化数据)并将数据插入/更新到 DB_REP
  • SRV_1 具有从 DB_REP 发布数据的事务复制
  • SRV_1 上很少有作业会根据 DB_APP 中的数据定期修改 DB_REP 中的数据
  • DB_REP 不被任何应用程序使用,它只是一个复制源
  • 服务器 SRV_2 是一个报告服务器,它订阅 DB_REP 并将其提供给客户。

问题在于 DB_APP 很少有经常更新的表,并且触发器会造成非常沉重的 CPU 负载。最常更新的表之一每秒大约有 100 次更新。

优化此设置的最佳方法是什么?到目前为止,我正在考虑这样的事情:

  • 尽量优化触发器(现在他们使用是否存在检查来执行插入/更新,我可以用 MERGE 替换它)
  • 创建索引视图而不是触发器并将视图从 DB_APP 复制到 DB_REP
  • 删除触发器、删除 DB_REP 并使用复制存储过程 sp_msins_xxx 直接从 DB_APP 发布复制,并实现数据转换。我不确定是否可以在这些过程中查询其他表。以及如何处理工作?

【问题讨论】:

    标签: sql-server database triggers replication


    【解决方案1】:

    我认为使用单独的数据库进行复制并不是一个糟糕的设计,尤其是当数据正在从您的事务数据库中转换时。

    但是,我确实认为使用触发器填充复制的数据库很糟糕。我们曾经有类似的设置,但您发现随着交易量的增长,性能会受到影响。

    我认为直接从事务数据库复制也不是最好的主意 - 复制(无论如何都是事务和合并)使用触发器本身,并且转换选项几乎仅限于行和列过滤。您要做的最后一件事是开始修改复制过程或触发器!

    我强烈建议您将所有更新/转换逻辑从触发器中移出并放入可以从定期运行的批量更新作业中调用的存储过程中(例如过夜)。

    这就是我们对大多数触发器所做的事情,性能提升可能很大。我们的用户不得不忍受一些数据不再是最新的事实,但这在我们的案例中并不是什么大问题。

    【讨论】:

    • 问题是数据需要几乎在线可用,因为它不仅被报告使用,还被操作员(人)用来监控实时数据。
    • 在那种情况下,我认为您需要将您的需求和每个使用的数据分开: * 报告,需要对数据进行转换,但可能不需要实时可以使用 DB_REP 数据. * 直接从 DB_APP 实时监控实时数据,无需昂贵的触发器或转换。这就是我处理这两个要求的方式。
    猜你喜欢
    • 1970-01-01
    • 2020-07-15
    • 1970-01-01
    • 2011-09-11
    • 2019-04-08
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多