SQL reverse log shipping techniques.

I have been testing the Reverse Log Shipping technique as in http://sqlmag.com/database-high-availability/3-log-shipping-techniques. I was able to do reverse log shipping if I leave out the 2 optional steps7 and 8 below. If I include step 7 & 8, I found the new secondary database will always have a status of"restoring" rather than "standby & Readonly". i did this a few times over and over to make sure it is right. But I am not sure what went wrong and causing the new secondary DBs in restoring mode rather than Standby & RO mode even the LSbackup, LSCOPY & LSRESTORE run after step 9.

Can someone shed some light on this?

Thanks & regards,

Irene

Reversing Log Shipping

Reversing log shipping is an often overlooked practice. When DBAs need to fail over to a secondary log shipping server, they tend to worry about getting log shipping back up later. This is especially true in the case of very large databases. If you're using log shipping as your primary disaster recovery solution and you need to fail over to the secondary log shipping server, you should get log shipping running as quickly as possible. With no disaster recovery failover in place, you might be running exposed.

Reversing log shipping is simple. It doesn’t require reinitializing the database with a full backup if performed carefully. However, it’s crucial that you remember the following:

• You need to preserve the log sequence number (LSN) chain.

• You need to perform the final log backup using the NORECOVERY option. Backing up the log with this option puts the database in a state that allows log backups to be restored and ensures that the database’s LSN chain doesn’t deviate.

• The primary log shipping server must still be accessible to use this technique.

To fail over to a secondary log shipping server, follow this 10-step process:

1. Disable all backup jobs that might back up the database on both log shipping partners.

2. Disable the log shipping jobs.

3. Run each log shipping job in order (i.e., backup, copy, and restore).

4. Drop log shipping.

5. Manually back up the log of the primary database using the NORECOVERY option. Use the command
   BACKUP LOG [DatabaseName]
     TO DISK = 'BackupFilePathname'
     WITH NORECOVERY;
   where DatabaseName is the name of the database whose log you want to back up and BackupFilePathname is the backup file’s pathname (e.g., Z:\SQLServerBackups\TLog.bck).

6. Restore the log backup on the secondary database using the RECOVERY option, and bring the secondary database online. The primary and secondary databases have now switched positions.

7. Back up the log of the new primary database (optional).

8. Restore the log on the new secondary database using the NORECOVERY option (optional).

9. Reconfigure log shipping.

10. Re-enable any backup jobs that were disabled.

Note that step 7 and step 8 are listed as optional because they’re not required for establishing log shipping. However, I recommend performing these steps to ensure that the log shipping configuration will proceed without any problems.

With a few minor adjustments, this 10-step process works with multiple secondary log shipping databases. You perform the same basic steps, keeping in mind that the other secondary databases will still be secondary databases after the failover. After you back up the log on the new primary database, you should use the NORECOVERY option to restore that backup on all the planned secondary databases. You can then add them as secondary databases to the new primary database.