How to bring the subscriber online as a test or reporting box (and how to restart the Plan from the original Publisher)
WORKAROUND:
1. Manually disable all LiteSpeed jobs associated with the log shipping plan.
Jobs may include: SQL LiteSpeed Log Shipping Backup, SQL LiteSpeed Log Shipping File Cleanup, SQL LiteSpeed Log Shipping Init Plan, SQL LiteSpeed Log Shipping Latency Notification Backup,SQL LiteSpeed Log Shipping Latency Notification Restore and SQL LiteSpeed Log Shipping Restore
2. Run SLS_LogShipping_Restore_Secondary with @Recover=1 (from the subscriber). In Query Analyzer run the following:
SLS_LogShipping_Restore_Secondary
@PlanName = 'Test Plan'
,@DataBaseName = 'SubscriberDB'
,@Recover = 1
When ready to bring the publisher back online:
1. Reinitialize the Log Shipping Plan via the LiteSpeed Gui Wizard. If there have been transactions added to the Subscriber (even by changing the status of the database from NORECOVERY to RECOVERY), the publisher & Subscriber are 'out of sync'
Additonal Information:
The resaon that the Log Shipping jobs cannot just be restarted:
If the recovery path of the restored database is now different than before (recovery paths or forks)
see: http://msdn.microsoft.com/en-us/library/ms175078.aspx
In general, a recovery point starts a new recovery path if the recovery point causes transactions to be rolled back. Preexisting backups may now have log sequence numbers (LSNs) greater than the LSN of this recovery point. The LSNs in these backups exist on a different recovery branch from the new branch that is created by the current recovery operation.
Best practice To avoid creating a recovery path that has multiple recovery forks, perform a complete set of data backups as soon as possible after you recover the database. This approach guarantees that all backups are taken on a single recovery branch. To verify this, you can look at the last_recovery_fork_guid column in thebackupset table or RESTORE HEADERONLY results set after backing up the data.
Example of a Recovery Path:
A recovery branch is a range of LSNs that share the same GUID. A recovery path describes a range of LSNs from a start point (LSN,GUID) to an end point (LSN,GUID). The range of LSNs in a recovery path may traverse one or more recovery branches from start to end. A new recovery branch originates when a database is created and when RESTORE WITH RECOVERY generates a recovery fork.
A recovery fork. is the point (LSN,GUID) at which a new recovery branch is started, every time a RESTORE WITH RECOVERY is performed. Each recovery fork determines a parent-child relationship between the recovery branches.
Recovering the database sets the whole database state, including the next LSN, to the recovery point. LSNs are then reused, starting with the fork_point_lsn. When constructing a restore sequence, therefore, backups must be linked by recovery fork and also by LSN, because the same LSN might exist on more than one fork. The following illustration shows LSN reuse. It shows how LSNs are reused in different recovery forks. The green boxes in the illustration indicate two backups that use the same LSN.
