Senior DBA Class - Transaction Log Shipping Tips and Tricks

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.

[@jimmynashville3494]

Thanks, buddy. This was very helpful!

[@BrentOzarUnlimited]

Glad to hear it!

[@sxygeekdn]

Microsoft gave us some more entitlement in the SQL Server 2019 Licensing guide.
(Up to three secondary replicas)
Failover Basics
For each on-prem server OSE licensed with SQL Server 2019 and covered by active SA, customers can use the
following passive replicas in anticipation of a failover event:
• One passive fail-over replica for High Availability in a separate OSE
• One passive fail-over replica for Disaster Recovery in a separate OSE
• One passive fail-over replica for Disaster Recovery in a single VM on Azure
And they allow for using the secondaries for maintenance like
• Database consistency checks
• Log Back-ups
• Full Back-ups
So now we can cover Availability with Always-On while also covering disaster with Log Shipping and toss a copy to Azure if we really want for kicks.
no Extra SQL licensing ;)

[@sachinkhari5058]

Thank you for upload

[@Paramonos01]

Standby mode does not support log shipping with different SQL versions, only NORECOVERY mode does.

[@ced4298]

@brent can you share the link to the white paper that demonstrates the google cloud process that you referenced?

[@shankarkulkarni9615]

thanks you

[@kiuandziu9550]

Why is log shipping recommended then over Full back up and restore approach?

[@TheBrentOzar]

Because full backups & restores take a long time.

[@Patmorgan235Us]

If you use log shipping you're constantly restoring to the secondary. So your only ever a few minutes behind. all you have to do is wait for the last transaction log back up to apply and your done.
if you do full backs/restore you have to wait for the entire back up to transfer and be pulled into SQL Server