如何使用事务复制避免table锁和复制大文章

Question

我们计划将我们的 SQL 本地数据库迁移到 Azure，这个数据库有很多 table，其中很少有非常高的事务 table（包含数百万记录），我们希望最大限度地减少应用程序的停机时间，并决定使用使用快照的事务复制来复制数据，然后花一些停机时间并从我们的应用程序切换到 Azure 数据库

以下是我们目前在预生产中看到的问题

1. Table 初始时间锁定，来自应用程序的大量请求由于此锁定而失败。我们怎样才能避免这种情况？
2. 2 篇文章（数百万行）复制失败，一篇几乎完成 (90%) 和其他由于一些数据问题，我们创建了 3 个单独的出版物，一个用于其余的小 tables 和其他每个大 tables 2。 我知道我们可以重新初始化发布并从头开始，但这会再次延迟切割时间和 table 锁。
   那么我们如何处理这种情况 1，因为我们复制了大部分数据并且我们不想从头开始

我希望你们中的许多人都遇到过这个问题并且有一些最佳实践可以分享。

Answer 1

这篇文章说

[ @sync_method=] 'sync_method'

Produces native-mode bulk copy program output of all tables but does not lock tables during the snapshot. Only supported for transactional publications. Not supported for Oracle Publishers.

你可能想试试..

参考文献：
https://dba.stackexchange.com/questions/73629/how-to-generate-replication-snapshot-without-locking-tables
https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-addpublication-transact-sql

Answer 2

我建议对您的程序使用时间参考。我可以想出两种方法来实现：

1. 在实时数据库和目标数据库之间建立一个桥梁table。加载桥并检查数据是否有效后，将它们传递给目标数据库。但是由于bridge上的数据验证，这种方式可能很难实现。
2. 在您 table 的时间戳列中。当复制过程开始时，获取那些在初始时间之前具有时间戳的行。因此，您将在过程开始后忽略所有行。这将保证您不会有任何复杂的键绑定 (fk)。