og shipping Configuration &

Failover steps
February 21, 2013 Manikandan Rajagopalan High Availablity, Log Shipping, UncategorizedHigh
Availablity

2 Votes

Understanding Log shipping

Log shipping allows you to automatically send transaction log

backups from one database (known as the primary database) to a
secondary database on another server (known as the secondary
server). At the secondary server, these transaction log backups are
restored to the secondary database, keeping it closely synchronized
with the primary database. An optional third server, known as the
monitor server, records the history and status of backup and restore
operations and optionally raises alerts if these operations fail to
occur as scheduled.

Log shipping consists of three operations:

1. Back up the transaction log at the primary server instance.

2. Copy the transaction log file to the secondary server instance.
3. Restore the log backup on the secondary server instance.

Primary Server and Database

The primary server in a log shipping configuration is the instance of
the SQL Server database engine that is your production server. The
primary database is the database on the primary server that you
want to back up to another server. All administration of the log
shipping configuration through SQL Server Management Studio is
performed from the primary database. The primary database must
use the full or bulk-logged recovery model; switching the database
to simple recovery will cause log shipping to stop functioning.

Requirements

Log shipping has the following requirements:

SQL Server 2005 Standard Edition, SQL Server 2005 Workgroup

Edition, or SQL Server 2005 Enterprise Edition must be installed
on all server instances involved in log shipping.
The servers involved in log shipping should have the same case
sensitivity settings.
The databases in a log shipping configuration must use the full or
2bulk-logged recovery model.

Permissions

You must be a sysadmin on each server instance to configure log

shipping. The backup and restore directories in your log shipping
configuration must adhere to these requirements:

Backup directory with read & write permissions: For the backup job
to be successful, the SQL Server service account on the primary
server instance and the proxy account of the backup job (by default,
this is the SQL Server Agent account on the primary server
instance) must have read/write permissions to the backup
directory.
Copy directory with write permissions: For the copy job to be
successful, the proxy account of the copy job (by default, this is the
SQL Server Agent account on the secondary server instance) must
have read permissions to the backup directory and write access to
the copy directory.
For the restore job to be successful, the SQL Server service account
on the secondary server instance and the proxy account of the
restore job (by default, this is the SQL Server Agent account on the
secondary server instance) must have read/write access to the copy
directory.

Configuration of Log shipping

Let us assume that the log shipping is configured with the following
setup:

Primary Server

Server Name : Primary

Server Share folder : D:\Logshipping
Backup Frequency : every 30 minutes (various with db size)
Backup retention : 1 day (various on disc space availability)
Secondary Server

Server Name : Secondary

Server Share folder : D:\Logshipping
Copy files Frequency : every 30 minutes
Copied files retention : 1 day (various on disc space availability)
Restore Frequency : every 30 minutes (various with db size)
Database state : Standby (Read-only)

To enable log shipping

1. Right click the database you want to use as your primary database
in the log shipping configuration, and then click Properties.

2. Under Select a page, click Transaction Log Shipping.

3. Select the Enable this as a primary database in a log shipping
configuration check box.

4. Under Transaction log backups, click Backup Settings.

5. In the Network path to the backup folder box, type the network
path to the share you created for the transaction log backup folder.

Say : \\ Primary\Logshipping
6. If the backup folder is located on the primary server, type the
local path to the backup folder in the If the backup folder is located
on the primary server, type a local path to the folder box. (If the
backup folder is not on the primary server, you can leave this box
empty.)

Say : D:\Logshipping
Important:

If the SQL Server service account on your primary server runs

under the local system account, you must create your backup folder
on the primary server and specify a local path to that folder.

7. Configure the Delete files older than and Alert if no backup

occurs within parameters.

Say: Delete files older than = 1 day (default)

8. Note the backup schedule listed in the Schedule box under
Backup job. If you want to customize the schedule for your
installation, then click Schedule and adjust the SQL Server Agent
schedule as needed.

Say : every 30 minutes

9. Click OK.

10. Under Secondary server instances and databases, click Add.

11. Click Connect and connect to the instance of SQL Server that
you want to use as your secondary server.

Say: Secondary
12. In the Secondary Database box, choose a database from the list
or type the name of the database you want to create.

13. On the Initialize Secondary database tab, choose the option

that you want to use to initialize the secondary database.

Note:

If you choose to have Management Studio initialize the secondary

database from a database backup, the data files created on the
secondary server will have the same names as those on the primary
server, and will be created in an identical directory structure,
including the drive letter.

14. On the Copy Files tab, in the Destination folder for copied
files box, type the path of the folder into which the transaction logs
backups should be copied. This folder is often located on the
secondary server.

Say: Destination folder for copied = \\Secondary\Logshipping\

: dbname as the directory name.
15. Note the copy schedule listed in the Schedule box under Copy
job. If you want to customize the schedule for your installation,
click Schedule and then adjust the SQL Server Agent schedule as
needed. This schedule should approximate the backup schedule.

Copy files Frequency : every 30 minutes

Copied files retention : 1 day (various on disc space availability)
16. On the Restore tab, under Database state when restoring
backups, choose the No recovery mode or Standby mode
option.
Say: Database state : Standby mode
17. If you chose the Standby mode option, choose if you want to
disconnect users from the secondary database while the restore
operation is underway.

18. If you want to delay the restore process on the secondary server,
choose a delay time under Delay restoring backups at least.

19. Choose an alert threshold under Alert if no restore occurs

within.

20. Note the restore schedule listed in the Schedule box under
Restore job. If you want to customize the schedule for your
installation, click Schedule and then adjust the SQL Server Agent
schedule as needed. This schedule should approximate the backup
schedule.

Restore Frequency : every 30 minutes (various with db size)

21. Click OK.

Optional Steps (steps 22 to 25)

22. Under Monitor server instance, select the Use a monitor

server instance check box, and then click Settings.

23. Click Connect and connect to the instance of SQL Server that
you want to use as your monitor server.

24. Under Monitor connections, choose the connection method to

be used by the backup, copy, and restore jobs to connect to the
monitor server.

25. Under History retention, choose the length of time you want to
retain a record of your log shipping history.

26. Click OK.

27. On the Database Properties dialog box, click OK to begin the
configuration process.

Failover Steps

When you fail over from your primary database to a secondary

database, it is unlikely that the primary and secondary databases
are fully synchronized. Some transaction log backups created on the
primary server may not yet have been copied or applied to the
secondary server. Also, changes to the databases on the primary
server may have occurred since the last transaction log backup.
Therefore, before using the secondary databases, synchronize the
primary databases with the standby databases and bring the
standby server online by following these steps:

1. Copy any remaining transaction log backup files from the backup
share to the copy destination folder. You can do this manually, or
start the copy job on each secondary server instance to copy the
files.

2. Apply to the secondary server, in sequence, any unapplied

transaction log backups created on the primary server. You can do
this manually, or use the restore job on each secondary server
instance to apply the backups.

To apply a transaction log backup

2.1. Execute the RESTORE LOG statement to apply the transaction
log backup, specifying:
The name of the database to which the transaction log will be
applied.
The backup device where the transaction log backup will be restored
from.
The NORECOVERY clause if you have another transaction log
backup to apply after the current one. Otherwise, specify the
RECOVERY clause.
2.2. Repeat step 2.1. for each transaction log backup you have to
apply.
3. Create a backup of the active transaction log on the primary
server and apply the backup to the database on the secondary
server. Applying the backup of the active transaction log to the
secondary server allows users to work with an exact copy of the
primary database immediately prior to failure (although any
uncommitted transactions will have been permanently lost).

4. If the primary server is undamaged, as in the case of planned

maintenance or upgrades, you can back up the active transaction
log with NORECOVERY. Using NORECOVERY will leave the
database in the restoring state and allow you to update the primary
server with transaction log backups from the secondary server.
Then, you can switch back to the primary server without creating a
full backup of the secondary server.

The first time you want to fail over to the secondary database and
make it your new primary database, there is a series of steps you
must take. After you have followed these initial steps, you will be
able to swap roles between the primary database and the secondary
database easily.

4.1. Manually fail over from the primary database to a secondary

database. Be sure to back up the active transaction log on your
primary server with NORECOVERY.
4.2. Disable the log shipping backup job on the original primary
server, and the copy and restore jobs on the original secondary
server.
4.3. On your secondary database (the database you want to be the
new primary), configure log shipping using SQL Server
Management Studio.
Include the following steps:
Use the same share for creating backups that you created for the
original primary server.
When adding the secondary database, in the Secondary Database
Settings dialog box, enter the name of the original primary database
in the Secondary database box.
In the Secondary Database Settings dialog box, select No, the
secondary database is initialized.
5. Recover the databases on the secondary server. This makes the
database available for users to modify.

failover

I have a few questions regarding Log Shipping in SQL Server 2012.

1. If the primary database server dies, is it possible to allow users to connect to the
secondary database so as to continue working with Read/Write access?

2. Once the primary server comes back online, is it a difficult process to switch back to the
primary database server?

3. Will changing the Recovery model to Full (from simple) have any issues?

4. Will my existing backups (using Symantec Backup Exec) be affected by enabling log
shipping and switching to a full recovery model?

add a
comme
nt

2 Answers
activeoldestvotes
up
vote2 1) If the primary database server dies, is it possible to allow users to connect to the
down secondary database so as to continue working with Read/Write access?
vote accept ed

You have to manually failover to the secondary server as logshipping does not have a
built-in mechanism to support automatic failover.

Once you failover, your application/s (provided they are using ADO.NET or SQL
Native Client) can leverage the Failover Partner=Secondary_server
Brent has blogged about failover partner:

you dont need to use database mirroring to use Failover Partner. Whether youre using
database mirroring, replication, log shipping, or duct tape, much like the honey badger,
your applications dont care. Theyll just try to connect to the Failover Partner name
whenever the primary server is down.

2) Once the primary server comes back online, is it a difficult process to switch back to
the primary database server?

Traditionally, depending on the size and number of database that are invloved in
logshipping, it may or may not be difficult.

Database size and your network bandwidth matters a lot. Normally, you just have to
resetup log-shipping. Meaning - point all your apps to primary and in background, do a
full backup of primary, copy that to secondary server and restore it with no-recovery
with subsequent log backups.

To minimize the downtime, you can use "Reverse logshipping" will prove to be a
huge help.

3) Will changing the Recovery model to Full (from simple) have any issues?

Yes. Changing recovery model breaks the log chain. Paul Randall talks in his myths
section. Also, see below chart :

4) Will my existing backups (using Symantec Backup Exec) be affected by enabling

log shipping and switching to a full recovery model?
 Once you setup logshipping, there is no need to take any additional log backups. In
fact, any adhoc log backups will break the log chain. Use COPY_ONLY backups.

As I mentioned above, any change to the recover model should be followed by a FULL
backup. That will be your base backup. Any adhoc backups (even full) should be taken
with a COPY_ONLY option as if you are relying on differential backups then it will be
an issue if someone takes an adhoc full backup.

As a side note, always fully document, test, test and test + automate (as much possible)
your disaster recovery strategy. See Paul's DR Poster for more details.

shareimprove this answer edited Oct 14 '14 at 2:06 answered Oct 14 '14 at 1:42

Kin

35.3k348112

One point is missed about users connecting to Secondary database: You must mention that
users cannot immediately connect because of orphaned users scenario and unless they have
build in script to take care of this even after when database comes online users would not be
able to connect. You should also include how to resolve orphaned users that would complete
your answer Shanky Oct 14 '14 at 17:38

add a comment

up
vote1down Kin provided some good details but just to address the questions directly:
vote
3) Well, you can only log ship a database in full recovery model, so not sure how
to answer that one.

1) If the primary database server dies, is it possible to allow users to connect to

the secondary database so as to continue working with Read/Write access?

Yes, you just have to restore the secondary WITH RECOVERY.

2) Once the primary server comes back online, is it a difficult process to switch
back to the primary database server?

No, you can just re-initialize the process from the new primary. It's:

a full backup;
start log backups (which you should be doing anyway,
 even without log shipping);
then find a server that's up to serve as the new secondary
and set up similar jobs there to perform the restores.

3) Will changing the Recovery model to Full (from simple) have any issues?

Well, you can only log ship a database in full recovery model, so not sure how to
answer.

4) Will my existing backups (using Symantec Backup Exec) be affected by

enabling log shipping and switching to a full recovery model?

Hard to answer without knowing exactly what you are using Symantec for. As
Kin noted, you don't want this thing to try to take log backups outside of your log
shipping mechanism.