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

Question

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

两个数据库都将具有相同的表（数据和所有），因此查询只会根据它将要进入的数据库进行更改。出于某种原因，我们需要两个数据库中的数据并实时保存。

是否可以使用SQL触发器或SProc？

执行此操作

非常感谢任何关于如何做到这一点或者正确方向的见解。

Answer 1

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

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

Answer 2

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

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

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

如果确实需要绝对同步，请使用交易监控器。

• 不滚动自己。

他们很难做对。处理所有特殊情况都很棘手。并且（在你需要绝对同步性的假设下）做错是昂贵但容易的。

Answer 3

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

我们的想法是将数据发送到两个数据库，然后发送“prepare commit”命令，该命令执行提交数据所需的一切，除了提交数据。如果准备失败，则提交也会失败。如果准备成功，则提交必须成功。

很棒的主意，在实践中不起作用。一种常见的情况是您将提交发送到两个数据库，其中一个在途中丢失（网络中断）。很少发生，但当它发生时，你的状态不一致，因为这一步不能失败，没有好的方法可以清理。

所以我的解决方案就像这样：

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

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

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