经常需要同步一个数据库中主表中的数据以克隆其他数据库中的表(通常在其他服务器上)。例如,考虑后端系统管理库存数据并且库存数据最终必须推送到作为网站应用程序一部分的一个或多个数据库的情况。单向数据库同步
后台系统中的源数据严重规范化,有数十个表和外键约束。这是一个设计良好的OLTP RDBMS系统。许多表格都包含数百万行。需要将这些数据定期推送到其他数据库。尽可能频繁;延迟是可以容忍的。最重要的是,后端和远程数据库的最大正常运行时间是必不可少的。
我正在使用SQL Server,并且熟悉更改跟踪,rowversion,触发器等等。我知道Microsoft为这些场景大量推送复制,SyncFx和SSIS。但是,供应商的白皮书和推荐技术的概述与解决方案的实际实施,部署和维护之间存在很大差异。在SQL Server领域,复制通常被视为一揽子解决方案,但我正在尝试探索备用解决方案。 (有些人担心复制难以管理,难以更改模式,并且在需要重新初始化的情况下,关键系统的停机时间会很长。)
有很多问题。由于大量表格之间存在复杂的外键关系,因此确定要执行的操作顺序是捕获还是应用更新并非微不足道。由于唯一索引,两行可能会互锁,以致一次一行更新甚至无法工作(需要在最终更新之前对每行执行中间更新)。这些不一定是show-stoppers,因为唯一索引通常可以更改为常规索引,并且可以禁用外键(尽管禁用外键是非常不可取的)。通常,您会听到“只是”使用SQL 2008更改跟踪和SSIS或SyncFx。这些答案实际上并不符合实际的困难。 (当然,客户真的很难考虑如何复制数据如此困难,从而使情况变得更糟!)
此问题最终非常通用:执行许多单向同步大量相关的数据库表。几乎所有参与数据库的人都必须处理这类问题。白皮书是常见的,实用的专业知识很难找到。我们知道这可能是一个棘手的问题,但工作必须完成。让我们听听什么对你有用(以及要避免什么)。告诉您使用Microsoft产品或其他供应商的产品的经验。但是,如果你个人没有经过大量严重相关的表格和行的战斗测试,请不要回答。让我们保持这种实际 - 而不是理论。
谢谢,但我从数据库开发人员的角度来看待这个问题,而不是服务器管理员。从前期的软件设计角度来看,这非常重要,而不仅仅是操作问题。 – 2009-06-26 15:23:51