是否可以同时更新 SQL Server 数据库和 Informix 数据库？

Posted 2023-04-19

【中文标题】是否可以同时更新 SQL Server 数据库和 Informix 数据库？

【英文标题】：Is it possible to Update an SQL Server Database and an Informix Database at the same time?

【发布时间】：2012-08-22 15:24:00

【问题描述】：

我想知道是否可以同时添加/更新/删除一个 SQL Server 数据库表以及一个 Informix 数据库表。

两个数据库将具有相同的表（数据和所有），因此查询只会根据要访问的数据库而改变。出于某种原因，我们需要两个数据库中的数据并实时保持。

是否可以使用 SQL 触发器或 SProc 来执行此操作？

非常感谢您对如何做到这一点的任何见解，或朝着正确的方向前进。

【参考方案1】：

进行同步更新，即。通过使用链接服务器的分布式事务，可能用于触发器，虽然在技术上是可行的，但我绝对不建议这样做。 Aaron 提出了 XA 的可靠性问题，但我的观点不同：可用性。如果在 Informix 中无法连接和更新，您在 SQL Server 中的更新将失败。 Informix 站点的停机时间（修补、维护，更不用说灾难）将意味着 SQL Server 站点的停机时间，从而使您的 5 个 9 更快地向 9 个 5 移动……这就是为什么我强烈主张将更新应用程序解耦的原因。 Transactional Replication 就是这样一个解耦示例，它支持异构环境（即 Informix 客户端下游接受更改）。

您将延迟更新可见性（SQL Server 中的状态将在延迟后反映在 Informix 中，延迟可能是毫秒、秒、分钟，甚至在糟糕的一天中的几个小时）。更新是一种方式，没有任何东西从 Informix 流回 SQL Server。但是在异构环境中进行主-主复制是连 Chuck Norris 都不会尝试的，只是说。

【讨论】：

只有oracle和db2两种非sqlserver db可用的类型，没有informix，请你帮我添加informix

【参考方案2】：

使用单个事务维护两个不同的 DBMS 需要事务监视器（例如 XA 系统）来协调事务。有这样的系统。 XA 规范通常是基础标准。 Microsoft 的 SQL Server 和 IBM 的 Informix 都与此类系统一起工作，并且可以让 SQL Server 和 Informix 由同一个事务监视器控制。与其他回答过的人相比，我对此类系统的技术能力的疑虑更少；我同意他们对这是否适合您的担忧。

这样的系统非常重量级。如果您想要一致性，那么修改问题中描述的单个表的所有事务都需要使用相同的 XA 服务（复数；可能一个用于插入，一个用于更新，一个用于删除）来执行此操作。此外，如果相同的事务也需要管理任何其他表，那么您还需要为这些表添加和使用服务。正是这一方面使此类系统难以管理。

使用在站点一致之前可能会延迟的复制系统可能比尝试绝对同步要好，除非对这种同步有令人信服的要求。

如果确实需要绝对同步，则使用事务监视器。

不要自己动手。

他们很难做到正确。处理所有特殊情况很棘手。而且（在您需要绝对同步的假设下）做错代价高昂，但很容易。

【参考方案3】：

这取决于您对“可能”的定义。从技术上讲，您可以使用一种称为“two-phase commit”的技术。

这个想法是您将数据发送到两个数据库，然后执行“准备提交”命令，该命令执行提交数据所需的所有操作，但提交数据除外。如果准备失败，提交也会失败。如果prepare成功，那么commit一定成功。

好主意，在实践中行不通。一种常见的情况是，您将提交发送到两个数据库，其中一个在途中丢失（网络中断）。很少发生，但当它发生时，您的状态会不一致，并且由于此步骤不能失败，因此没有好的清理方法。

所以我的解决方案是这样的：

您将数据加载到一个新表中，该表有两个额外的列，您可以在其中说“服务器 X 已看到此记录”

您添加了一个作业，它将服务器 X 的所有作业复制到服务器 X 并更新相应的列。以可以随时中止和重新启动的方式编写作业（即，它必须能够处理目标端已经存在数据的情况）。

这样，您可以以一致的容错方式将数据分发到任意数量的服务器。

【讨论】：

有趣的 cmets ...“绝妙的想法，在实践中行不通”和 ...“以可以随时中止和重新启动的方式编写作业”。我猜 OP 必须拨打电话以信任符合 XA 的框架/产品并使用两阶段提交，或者他/她自己掌握自己的编码技能

实际上资源管理器的所有商业实现（SQL Server 和 Informix 就是这样）和常用的事务协调器（如 MSDTC）都知道如何处理这样的中断。见in-doubt xact resolution Server Configuration Option。并不是说我提倡 DTC，但您对丢失“提交”场景的解释是不准确的。

@RemusRusanu：XA 社区几十年来一直未能交付——我还没有看到一种产品可以在没有人工干预的情况下从所有条件下优雅地恢复。而且太过分了。使用中间表的解决方案可以在其中记录已传输的行，该解决方案易于实现且牢不可破。当出现问题时，普通人可以解决它。

@RemusRusanu：另外请注意，这个网站并不意味着复杂的解释。部分提交场景是最容易用几句话解释的场景。

我明白了。由于双方都必须确认准备（否则不会有提交），因此双方都必须保证他们能够提交即使存在进程关闭。此外，协调者必须保证它可以稍后在被询问时将结果（“已提交”）提供给参与者，即使它遭受重新启动。因此，丢失提交消息的资源管理器可以在中断结束后向 DTC 询问结果，并获得正确的答案和适当的操作（即提交）。因此，至少在理论上，这种情况已经涵盖。