In theory, log shipping is easy: just restore your transaction log backups. In reality, you need to understand how to deal with unplanned failovers, reversing log shipping the other direction, and fixing a lagging secondary.

5 Comments. Leave new

  • vladislav.dorciak
    January 12, 2020 10:54 am

    Hello Brent,

    You mention the secondary database should be in NORECOVERY mode during backup restore, and can be in STANDBY mode if we want to allow users read only access. Is it because the restore would fail?

    I tried to leave the database in STANDBY mode while running log restore, and it seemed to complete OK, and the new data is visible in the read-only copy of the database (SQL 2017). I did try to switch between the two modes without any issues, and the database would still restore fine. Is that the normal behavior for SQL 2017, or am I missing something in the process?

    Thank you Walter (Vladislav).

  • The problem is that the restore will be blocked while users have open queries, and then the request to do a restore will subsequently block OTHER user queries, so you end up with a blocking disaster.

  • Kevon Houghton
    February 27, 2020 1:19 pm

    At about 8:50 you mention that you have a blog post about how to sync to Google cloud. Is that still relevant in 2020? Can you provide a link to that, or a relevant blog post related to the idea? Google, Azure, AWS, or something like that? I did Google “Google database sync” and found some good articles, but not the one you mentioned.


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.