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

Question

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

以下是我们目前在 pre prod 中看到的问题

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

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

Answer 1

这篇文章说

[@sync_method=]'sync_method'

生成所有表的本机模式大容量复制程序输出但在快照期间不锁定表。仅支持事务发布。不支持 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. 在活动数据库和目标数据库之间建立一个桥接表。加载网桥并检查数据是否有效后，将它们传递给目标数据库。但由于桥接数据验证，这种方式可能难以实现。
2. 在您的表的时间戳列中。当复制过程开始时，获取那些在初始时间之前具有时间戳的行。因此，您将在程序开始后忽略所有行。这将保证您不会有任何不合适的键绑定 (fk)。