Showing posts with label Log Shipping. Show all posts
Showing posts with label Log Shipping. Show all posts

Sunday, 24 April 2022

 If I create the NDF file in a disk in the primary server that the secondary server does not have: does the log shipping process will fail?

If paths are same on the primary and secondary servers then adding an ndf will be seamless.

If the paths are different, then Manually restore the log file  using the "RESTORE log with MOVE , NORECOVERY" 

Sunday, 28 February 2016

Differences between TUF File and WRK Files in Log Shipping ?

·    Differences between TUF File and WRK Files in Log Shipping 
·          
·    TUF File: TUF file is known as "Transaction Undo File"This file is created when LogShipping is configured in SQL Server. This file consists of list of uncommitted transactions while backup is going on the primary server in Log Shipping.                                                                                                                If this file is deleted you have to reconfigure the LogShipping as the secondary server.  
        This file is located in the path where transaction log files are saved.

    WRK File :  This Extension Is Given To A File Which is  Being Copied From Primary Backup Location to Secondary and Once Copy Process has been completed these file are renamed with .trn file. 

How to Reverse Log Shipping Roles

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., E:\SQLBackups\TLog.trn).
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.