事务复制和触发器可以用于几乎实时的ETL吗？
我们希望有一个数据仓库与我们的生产OLTP数据库在几乎实时的同步。是否可以使用事务复制和触发器来完成此操作？
我们目前的ETL
我们使用托管在azure上的sql服务器。我们为我们的应用程序提供了一个OLTP数据库，并保留了第二个sql服务器数据库作为报告和建模的数据仓库。目前，我们安排了一个夜间ETL (ELT真的)进程与天青数据工厂。夜间处理与OLAP应用数据库同步数据仓库上的引用表，并调用大量存储过程来重建报告和建模所需的所有非规范化表。夜间的过程需要很长的时间。
我们认为它能在几乎实时的时间内更好地工作
建议选择我们希望从OLTP数据库同步到数据仓库的引用表，并与sql服务器内置的事务性复制进行单向同步。然后，在数据仓库中，我们会将更改触发器(IUD)放置到参考表中。这些触发器将将修改记录插入仓库中的表中，该表将充当队列跟踪对引用表数据的更改。然后，我们将构建一个进程来监视该队列。当新的修改记录出现时，流程将看到哪些表被更改，哪些主键被更改，然后更新所有依赖于引用表和主键组合的非规范化表。我们不确定是将这些去规范化过程编写为server上的存储过程，还是作为一个单独的.net应用程序编写。无论哪种方式似乎都是一种选择。
任何在这些领域有经验的人都认为这是可行的。我们疯了吗？
回答 2
Database Administration用户
发布于 2019-03-13 02:47:46
如果您使用的是支持更改数据捕获或更改跟踪的版本和版本，这些机制将更适合监视对引用表的更改，因为它们提供了一个轻量级解决方案，仅用于识别已更改的行。
您可以在参考表上实现CT或CDC，并经常轮询更改。当遇到更改时，您可以只调入已更改的行，更新数据仓库，并启动修复数据仓库中去错数据的过程。
您还可能需要重新评估数据仓库的设计。从您的描述来看，这些参考表可能正在缓慢地更改维度，使用正确的DWH设计，您不应该需要在更改到维度之后更新仓库中的去错误数据，应该自动处理该更改。
对于您的问题并没有一个完整的答案，因为有许多未知因素会影响您的数据仓库和ETL流程的设计决策。您需要正确地定义您的需求，包括性能、数据延迟( DWH可能落后多远)、历史数据(如果事实表记录反映插入时的维度细节或维度的当前状态)、报告以及其他几个因素，这些因素随后会通知您的DWH和ETL设计。
在定义了需求之后，您可以开始研究满足这些需求的技术和体系结构。
Database Administration用户
发布于 2019-03-13 02:33:50
对于评论来说，时间太长了，所以我的看法是:只需加上我的两分钱，我就有经验使用事务性复制来保持两个数据库几乎实时(几秒方差最大值)的同步性。数据库每个大约100 GB，我们可能每天进行几百MB的事务更改。
从整体上讲，它运行得很好。当它失败的时候，它很糟糕。这种情况每年只发生几次(由于我们进行了特定的模式更改)，但是在调试问题和重新生成新快照以使复制重新工作时，数据库实际上已经关闭了半天。从所有的因素来看，我们做的很好，我们目前的设置。
尽管如此，我认为复制已经开始有点过时，因为更多地使用了其他方法(日志传送、数据库镜像、可用性组集群等等)。我从来没有亲自使用过这些，所以我不能就利弊提出太多的建议，但我肯定建议在决定什么对您的需求有意义之前，先阅读其中的每一个。
另外，我认为Kendra上面链接的帖子的关键是“这个问题没有简单的答案”。事务性复制是某些场景(比如我的)的答案，其他情况需要我上面列出的其他方法之一或另一种解决方案。祝好运!
https://dba.stackexchange.com/questions/231684
复制相似问题
腾讯云开发者
