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

时间:2018-01-05 00:31:05

标签: sql sql-server azure-sql-database database-migration transactional-replication

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

以下是我们迄今为止在预产品中看到的问题

  1. 表初始化时锁定,应用程序的大量请求因此锁定而失败。我们怎能避免这种情况?
  2. 2篇文章(数百万行)复制失败,其中几乎完成了(90%),而另一篇由于某些数据问题,我们创建了3个单独的出版物,一个用于其余的小表,另外两个用于每个大表。 我知道我们可以重新初始化出版物,并从一开始就这样做,但这将再次延迟时间和表锁定。
    那么我们如何处理这个案例1,因为我们大部分数据都被复制了,我们不想从头开始
  3. 我希望你们中的许多人都能遇到这个问题,并且有一些最佳实践可供分享。

2 个答案:

答案 0 :(得分: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

答案 1 :(得分:0)

我建议您使用时间参考程序。我可以想出两种方法来实现这一目标:

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