3

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

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

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

任何有关如何做到这一点的见解，或朝着正确方向的推动，将不胜感激。

4

3 回答 3

2

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

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

于 2012-08-22T16:44:05.897 回答
1

Maintaining two different DBMS with a single transaction requires a transaction monitor such as the XA system to coordinate the transactions. There are such systems. The XA specification is typically the underlying standard. Both Microsoft's SQL Server and IBM's Informix work with such systems, and it is possible to have SQL Server and Informix controlled by the same transaction monitor. I have fewer qualms about the technical competency of such systems than the others who've answered; I share their concerns about whether it is appropriate for you.

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

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

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

  • 不要自己滚动。

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

于 2012-08-23T14:30:41.780 回答
0

这取决于您对“可能”的定义。从技术上讲，您可以使用一种称为“两阶段提交”的技术。

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

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

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

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

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

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

于 2012-08-22T15:37:53.833 回答