The options to replicate a secondary read-only copy of a big database with limited network connection?

Question

There is a big database on remote server. A read-only replicate is required on a local server. The data can only be transferred via FTP, etc. It's ok to replicate it once a day.
Logshipping is an option. However, it need to kill all the connections when doing restoring. What's the other options (pros/cons)? How about merge repl or .Net sync framework?

Answer 1

Hi
ydbn,
Do you need to update data on the local server and propagate those changes to remote server? If no, you can use log shipping or transaction replication achieve your requirement.  It doesn’t need to kill all the connections if you
clear the Disconnect users in the database when restoring backups check box when configuring log shipping,
With transaction replication, the benefits are as follows.
Synchronization. This method can be used to keep multiple subscribers synchronized in real time.
Scale out. Transactional replication is excellent for scenarios in which read-only data can be scaled
out for reporting purposes or to enable e-commerce scalability (such as providing multiple copies of product catalogs).
There are a few disadvantages of utilizing transaction replication, including:
    • Schema changes/failover. Transactional subscribers require several schema changes that impact foreign keys and impose other constraints.
    • Performance. Large-scale operations or changes at the publisher might require a long time to reach subscribers.
However, if you need to update data on the local server and propagate those changes to remote server, merge replication
 is more appropriate, and it comes with the following advantages:
    • Multi-master architecture. Merge replication does allow multiple master databases. These databases can manage their own copies of data and marshal those changes as needed between other members of
a replication topology.
    • Disconnected architecture. Merge replication is natively built to endure periods of no connectivity, meaning that it can send and receive changes after communication is restored.
    • Availability. With effort on the part of the developers, merge-replicated databases can be used to achieve excellent scale-out and redundancy options.
Merge replication comes with some disadvantages, including:
    • Schema changes. Merge replication requires the existence of a specialized GUID column per replicated table.
    • Complexity. Merge replication needs to address the possibility for conflicts and manage operations between multiple subscribers, which makes it harder to manage. For more details, please review this
article.
For the option of sync framework, I would like to recommend you post the question in the Sync Framework forums at
https://social.msdn.microsoft.com/Forums/en-US/home?category=sync . It is appropriate and more experts will assist you. Also you can check this
article about introduction to Sync Framework database synchronization.
Thanks,
Lydia Zhang
If you have any feedback on our support, please click
here.
Lydia Zhang
TechNet Community Support