经常需要将一个数据库中的主表数据同步到其他数据库的克隆表，通常是在其他服务器上。例如，考虑这样一种情况，后端系统管理库存数据，而这些库存数据最终必须被推送到一个或多个属于网站应用程序的数据库中。
后端系统中的源数据经过了大量规范化处理，有着数十个表和外键约束。它是一个设计良好的 OLTP 关系型数据库系统。其中许多表包含数百万行数据。需要定期将这些数据推送到其他数据库中。尽可能频繁；可以容忍延迟。最重要的是，后端和远程数据库的最大正常运行时间是至关重要的。
我正在使用 SQL Server，并熟悉更改跟踪、rowversion、触发器等技术。我知道 Microsoft 强烈推荐使用复制、SyncFx 和 SSIS 来解决这些问题。然而，供应商的白皮书和概述推荐技术与实际实现、部署和维护方案之间存在相当大的差异。在 SQL Server 的世界中，复制通常被视为成套的解决方案，但我试图探索替代方案。（有些人担心，复制难以管理，使得更改架构变得困难，在需要重新初始化时，关键系统将会有大量的停机时间。）
有许多需要注意的地方。由于大量表之间存在复杂的外键关系，确定执行捕获或应用更新的顺序并不是简单的。由于唯一索引，两行数据可能会以这样的方式相互锁定，以至于逐行更新甚至都不起作用（需要在最终更新之前对每行进行中间更新）。虽然这些问题不一定是无法解决的，因为唯一索引通常可以更改为普通索引，外键可以被禁用（尽管禁用外键是极不可取的）。通常你会听到，“只需要”使用 SQL 2008 更改跟踪和 SSIS 或 SyncFx。这种回答真的没有充分考虑实际困难。（当然，客户们真的很难理解复制数据为什么会如此困难，这使得本来就困难的情况更加糟糕！）
这个问题最终非常通用：对许多密切相关的数据库表进行单向同步，这些表具有大量的行。几乎所有涉及数据库的人都需要处理这种问题。白皮书很常见，实际专业知识很难找到。我们知道这可能是一个困难的问题，但工作必须完成。让我们听听您的经验（以及要避免的问题）。告诉我们您使用 Microsoft 产品或其他供应商产品的经验。但是如果你个人没有在大量密切相关的表和行上进行过实战测试，请不要回答。让我们保持实际 - 不要理论化。
后端系统中的源数据经过了大量规范化处理，有着数十个表和外键约束。它是一个设计良好的 OLTP 关系型数据库系统。其中许多表包含数百万行数据。需要定期将这些数据推送到其他数据库中。尽可能频繁；可以容忍延迟。最重要的是，后端和远程数据库的最大正常运行时间是至关重要的。
我正在使用 SQL Server，并熟悉更改跟踪、rowversion、触发器等技术。我知道 Microsoft 强烈推荐使用复制、SyncFx 和 SSIS 来解决这些问题。然而，供应商的白皮书和概述推荐技术与实际实现、部署和维护方案之间存在相当大的差异。在 SQL Server 的世界中，复制通常被视为成套的解决方案，但我试图探索替代方案。（有些人担心，复制难以管理，使得更改架构变得困难，在需要重新初始化时，关键系统将会有大量的停机时间。）
有许多需要注意的地方。由于大量表之间存在复杂的外键关系，确定执行捕获或应用更新的顺序并不是简单的。由于唯一索引，两行数据可能会以这样的方式相互锁定，以至于逐行更新甚至都不起作用（需要在最终更新之前对每行进行中间更新）。虽然这些问题不一定是无法解决的，因为唯一索引通常可以更改为普通索引，外键可以被禁用（尽管禁用外键是极不可取的）。通常你会听到，“只需要”使用 SQL 2008 更改跟踪和 SSIS 或 SyncFx。这种回答真的没有充分考虑实际困难。（当然，客户们真的很难理解复制数据为什么会如此困难，这使得本来就困难的情况更加糟糕！）
这个问题最终非常通用：对许多密切相关的数据库表进行单向同步，这些表具有大量的行。几乎所有涉及数据库的人都需要处理这种问题。白皮书很常见，实际专业知识很难找到。我们知道这可能是一个困难的问题，但工作必须完成。让我们听听您的经验（以及要避免的问题）。告诉我们您使用 Microsoft 产品或其他供应商产品的经验。但是如果你个人没有在大量密切相关的表和行上进行过实战测试，请不要回答。让我们保持实际 - 不要理论化。