0

Is there anyway to identify by how much time we can get a deadlock when we enable Snapshot replication for our subscriber, we have a subscriber considered as Azure SQL Database, and we have 8 databases one of them consists of 200GB in size. Is there any way to identify the downtime for genereating snapshots?

user0001 ttt
  • 11
  • 7
  • You can [use a backup instead of an initial snapsho](https://learn.microsoft.com/en-us/sql/relational-databases/replication/initialize-a-transactional-subscription-without-a-snapshot?view=sql-server-2017). That's the recommended way to handle large datasets. Backing up a database is an online operation – Panagiotis Kanavos Apr 23 '19 at 09:13
  • But sometimes azure sql database dont handle import/export very well specially when we talk about huge databases. If we even do this, how can we replicate extra changes that will be happening when we will doing restore into the azure sql database. Do we need to restore differential backups again and then setup replication? – user0001 ttt Apr 23 '19 at 11:21
  • You asked about *transactional replication*, not import/export. Publishing changes as soon as they happen is what transactional replication does. There should be no huge databases to move, unless replication stops from some reason. – Panagiotis Kanavos Apr 23 '19 at 11:24
  • but we need to restore the backup on the subscriber right and as per my understanding we cannot directly restore databases to azure sql databases neither by GUI nor by commands, the only way to do this is using import export operation that is provided in the Azure SQL Database? – user0001 ttt Apr 23 '19 at 11:32

0 Answers0