Download About Log Shipping (SQL Server) | Microsoft Docs

Table of Contents
Overview
Configure Log Shipping
Add a Secondary Database to a Log Shipping Configuration
Remove a Secondary Database from a Log Shipping Configuration
Remove Log Shipping
View the Log Shipping Report (SQL Server Management Studio)
Monitor Log Shipping (Transact-SQL)
Fail Over to a Log Shipping Secondary
Change Roles Between Primary and Secondary Log Shipping Servers
Log Shipping and Replication
Log Shipping Tables and Stored Procedures
Upgrading Log Shipping to SQL Server 2016 (Transact-SQL)
About Log Shipping (SQL Server)
3/29/2017 • 5 min to read • Edit Online
SQL Server Log shipping allows you to automatically send transaction log backups from a primary database on a
primary server instance to one or more secondary databases on separate secondary server instances. The
transaction log backups are applied to each of the secondary databases individually. An optional third server
instance, 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.
In this Topic:
Benefits
Terms and Definitions
Log Shipping Overview
Interoperability
Related Tasks
Benefits
Provides a disaster-recovery solution for a single primary database and one or more secondary databases,
each on a separate instance of SQL Server.
Supports limited read-only access to secondary databases (during the interval between restore jobs).
Allows a user-specified delay between when the primary server backs up the log of the primary database
and when the secondary servers must restore (apply) the log backup. A longer delay can be useful, for
example, if data is accidentally changed on the primary database. If the accidental change is noticed quickly,
a delay can let you retrieve still unchanged data from a secondary database before the change is reflected
there.
Terms and Definitions
primary server
The instance of SQL Server that is your production server.
primary database
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.
secondary server
The instance of SQL Server where you want to keep a warm standby copy of your primary database.
secondary database
The warm standby copy of the primary database. The secondary database may be in either the RECOVERING state
or the STANDBY state, which leaves the database available for limited read-only access.
monitor server
An optional instance of SQL Server that tracks all of the details of log shipping, including:
When the transaction log on the primary database was last backed up.
When the secondary servers last copied and restored the backup files.
Information about any backup failure alerts.
IMPORTANT
Once the monitor server has been configured, it cannot be changed without removing log shipping first.
backup job
A SQL Server Agent job that performs the backup operation, logs history to the local server and the monitor
server, and deletes old backup files and history information. When log shipping is enabled, the job category "Log
Shipping Backup" is created on the primary server instance.
copy job
A SQL Server Agent job that copies the backup files from the primary server to a configurable destination on the
secondary server and logs history on the secondary server and the monitor server. When log shipping is enabled
on a database, the job category "Log Shipping Copy" is created on each secondary server in a log shipping
configuration.
restore job
A SQL Server Agent job that restores the copied backup files to the secondary databases. It logs history on the
local server and the monitor server, and deletes old files and old history information. When log shipping is
enabled on a database, the job category "Log Shipping Restore" is created on the secondary server instance.
alert job
A SQL Server Agent job that raises alerts for primary and secondary databases when a backup or restore
operation does not complete successfully within a specified threshold. When log shipping is enabled on a
database, job category "Log Shipping Alert" is created on the monitor server instance.
TIP
For each alert, you need to specify an alert number. Also, be sure to configure the alert to notify an operator when an alert
is raised.
Log Shipping Overview
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.
The log can be shipped to multiple secondary server instances. In such cases, operations 2 and 3 are
duplicated for each secondary server instance.
A log shipping configuration does not automatically fail over from the primary server to the secondary
server. If the primary database becomes unavailable, any of the secondary databases can be brought online
manually.
You can use a secondary database for reporting purposes.
In addition, you can configure alerts for your log shipping configuration.
A Typical Log Shipping Configuration
The following figure shows a log shipping configuration with the primary server instance, three secondary server
instances, and a monitor server instance. The figure illustrates the steps performed by backup, copy, and
restorejobs, as follows:
1. The primary server instance runs the backup job to back up the transaction log on the primary database.
This server instance then places the log backup into a primary log-backup file, which it sends to the backup
folder. In this figure, the backup folder is on a shared directory—the backup share.
2. Each of the three secondary server instances runs its own copy job to copy the primary log-backup file to its
own local destination folder.
3. Each secondary server instance runs its own restore job to restore the log backup from the local destination
folder onto the local secondary database.
The primary and secondary server instances send their own history and status to the monitor server
instance.
Interoperability
Log shipping can be used with the following features or components of SQL Server:
Prerequisites for Migrating from Log Shipping to Always On Availability Groups (SQL Server)
Database Mirroring and Log Shipping (SQL Server)
Log Shipping and Replication (SQL Server)
NOTE
Always On availability groups and database mirroring are mutually exclusive. A database that is configured for one of these
features cannot be configured for the other.
Related Tasks
Upgrading Log Shipping to SQL Server 2016 (Transact-SQL)
Configure Log Shipping (SQL Server)
Add a Secondary Database to a Log Shipping Configuration (SQL Server)
Remove a Secondary Database from a Log Shipping Configuration (SQL Server)
Remove Log Shipping (SQL Server)
View the Log Shipping Report (SQL Server Management Studio)
Monitor Log Shipping (Transact-SQL)
Fail Over to a Log Shipping Secondary (SQL Server)
Fail Over to a Log Shipping Secondary (SQL Server)
Management of Logins and Jobs After Role Switching (SQL Server)
See Also
Overview of Always On Availability Groups (SQL Server)
Configure Log Shipping (SQL Server)
3/29/2017 • 5 min to read • Edit Online
This topic describes how to configure log shipping in SQL Server 2016 by using SQL Server Management Studio
or Transact-SQL.
NOTE
SQL Server 2008 Enterprise and later versions support backup compression. When creating a log shipping configuration,
you can control the backup compression behavior of log backups. For more information, see Backup Compression (SQL
Server).
In This Topic
Before you begin:
Prerequisites
Security
To configure log shipping, using:
SQL Server Management Studio
Transact-SQL
Related Tasks
Before You Begin
Prerequisites
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.
Before you configure log shipping, you must create a share to make the transaction log backups available
to the secondary server. This is a share of the directory where the transaction log backups will be
generated. For example, if you back up your transaction logs to the directory c:\data\tlogs\, you could
create the \\primaryserver\tlogs share of that directory.
Security
Permissions
The log-shipping stored procedures require membership in the sysadmin fixed server role.
Using SQL Server Management Studio
To configure 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.
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.)
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.
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.
9. SQL Server 2016 supports backup compression. When creating a log shipping configuration, you can
control the backup compression behavior of log backups by choosing one of the following options: Use
the default server setting, Compress backup, or Do not compress backup. For more information, see
Log Shipping Transaction Log Backup Settings.
10. Click OK.
11. Under Secondary server instances and databases, click Add.
12. Click Connect and connect to the instance of SQL Server that you want to use as your secondary server.
13. In the Secondary Database box, choose a database from the list or type the name of the database you
want to create.
14. 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 and
log files of the secondary database are placed in the same location as the data and log files of the master database.
This location is likely to be different than the location of the data and log files of the primary database.
15. 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.
16. 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.
17. On the Restore tab, under Database state when restoring backups, choose the No recovery mode or
Standby mode option.
18. If you chose the Standby mode option, choose if you want to disconnect users from the secondary
database while the restore operation is underway.
19. If you want to delay the restore process on the secondary server, choose a delay time under Delay
restoring backups at least.
20. Choose an alert threshold under Alert if no restore occurs within.
21. 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.
22. Click OK.
23. Under Monitor server instance, select the Use a monitor server instance check box, and then click
Settings.
IMPORTANT
To monitor this log shipping configuration, you must add the monitor server now. To add the monitor server later,
you would need to remove this log shipping configuration and then replace it with a new configuration that
includes a monitor server.
24. Click Connect and connect to the instance of SQL Server that you want to use as your monitor server.
25. Under Monitor connections, choose the connection method to be used by the backup, copy, and restore
jobs to connect to the monitor server.
26. Under History retention, choose the length of time you want to retain a record of your log shipping
history.
27. Click OK.
28. On the Database Properties dialog box, click OK to begin the configuration process.
Using Transact-SQL
To configure log shipping
1. Initialize the secondary database by restoring a full backup of the primary database on the secondary
server.
2. On the primary server, execute sp_add_log_shipping_primary_database to add a primary database. The
stored procedure returns the backup job ID and primary ID.
3. On the primary server, execute sp_add_jobschedule to add a schedule for the backup job.
4. On the monitor server, execute sp_add_log_shipping_alert_job to add the alert job.
5. On the primary server, enable the backup job.
6. On the secondary server, execute sp_add_log_shipping_secondary_primary supplying the details of the
primary server and database. This stored procedure returns the secondary ID and the copy and restore job
IDs.
7. On the secondary server, execute sp_add_jobschedule to set the schedule for the copy and restore jobs.
8. On the secondary server, execute sp_add_log_shipping_secondary_database to add a secondary database.
9. On the primary server, execute sp_add_log_shipping_primary_secondary to add the required information
about the new secondary database to the primary server.
10. On the secondary server, enable the copy and restore jobs. For more information, see Disable or Enable a
Job.
Related Tasks
Upgrading Log Shipping to SQL Server 2016 (Transact-SQL)
Add a Secondary Database to a Log Shipping Configuration (SQL Server)
Remove a Secondary Database from a Log Shipping Configuration (SQL Server)
Remove Log Shipping (SQL Server)
View the Log Shipping Report (SQL Server Management Studio)
Monitor Log Shipping (Transact-SQL)
Fail Over to a Log Shipping Secondary (SQL Server)
See Also
About Log Shipping (SQL Server)
Log Shipping Tables and Stored Procedures
Add a Secondary Database to a Log Shipping
Configuration (SQL Server)
3/29/2017 • 2 min to read • Edit Online
This topic describes how to add a secondary database to an existing log shipping configuration in SQL Server
2016 by using SQL Server Management Studio or Transact-SQL.
In This Topic
Before you begin:
Security
To add a log shipping secondary database, using:
SQL Server Management Studio
Transact-SQL
Related Tasks
Before You Begin
Security
Permissions
The log-shipping stored procedures require membership in the sysadmin fixed server role.
Using SQL Server Management Studio
To add a log shipping secondary database
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. Under Secondary server instances and databases, click Add.
4. Click Connect and connect to the instance of SQL Server that you want to use as your secondary server.
5. In the Secondary database box, choose a database from the list or type the name of the database you
want to create.
6. On the Initialize Secondary database tab, choose the option that you want to use to initialize the
secondary database.
7. 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.
8. 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.
9. On the Restore tab, under Database state when restoring backups, choose the No recovery mode or
Standby mode option.
10. If you chose the Standby mode option, choose if you want to disconnect users from the secondary
database while the restore operation is underway.
11. If you want to delay the restore process on the secondary server, choose a delay time under Delay
restoring backups at least.
12. Choose an alert threshold under Alert if no restore occurs within.
13. 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.
14. Click OK.
15. Click OK on the Database Properties dialog box to begin the configuration process.
Using Transact-SQL
To add a log shipping secondary database
1. On the secondary server, execute sp_add_log_shipping_secondary_primary supplying the details of the
primary server and database. This stored procedure returns the secondary ID and the copy and restore job
IDs.
2. On the secondary server, execute sp_add_jobschedule to set the schedule for the copy and restore jobs.
3. On the secondary server, execute sp_add_log_shipping_secondary_database to add a secondary database.
4. On the primary server, execute sp_add_log_shipping_primary_secondary to add the required information
about the new secondary database to the primary server.
5. On the secondary server, enable the copy and restore jobs. For more information, see Disable or Enable a
Job.
Related Tasks
Upgrading Log Shipping to SQL Server 2016 (Transact-SQL)
Configure Log Shipping (SQL Server)
Remove a Secondary Database from a Log Shipping Configuration (SQL Server)
Remove Log Shipping (SQL Server)
View the Log Shipping Report (SQL Server Management Studio)
Monitor Log Shipping (Transact-SQL)
Fail Over to a Log Shipping Secondary (SQL Server)
See Also
About Log Shipping (SQL Server)
Log Shipping Tables and Stored Procedures
Remove a Secondary Database from a Log Shipping
Configuration (SQL Server)
3/29/2017 • 1 min to read • Edit Online
This topic describes how to remove a log shipping secondary database in SQL Server 2016 by using SQL Server
Management Studio or Transact-SQL.
In This Topic
Before you begin:
Security
To remove a log shipping secondary database, using:
SQL Server Management Studio
Transact-SQL
Related Tasks
Before You Begin
Security
Permissions
The log-shipping stored procedures require membership in the sysadmin fixed server role.
Using SQL Server Management Studio
To remove a log shipping secondary database
1. Connect to the instance of SQL Server that is currently the log shipping primary server and expand that
instance.
2. Expand Databases, right-click the log shipping primary database, and then click Properties.
3. Under Select a page, click Transaction Log Shipping.
4. Under Secondary server instances and databases, click the database you want to remove.
5. Click Remove.
6. Click OK to update the configuration.
Using Transact-SQL
To Remove a Secondary Database
1. On the primary server, execute sp_delete_log_shipping_primary_secondary to delete the information about
the secondary database from the primary server.
2. On the secondary server, execute sp_delete_log_shipping_secondary_database to delete the secondary
database.
NOTE
If there are no other secondary databases with the same secondary ID,
sp_delete_log_shipping_secondary_primary is invoked from sp_delete_log_shipping_secondary_database and
deletes the entry for the secondary ID and the copy and restore jobs.
3. On the secondary server, disable the copy and restore jobs. For more information, see Disable or Enable a
Job.
Related Tasks
Upgrading Log Shipping to SQL Server 2016 (Transact-SQL)
Configure Log Shipping (SQL Server)
Add a Secondary Database to a Log Shipping Configuration (SQL Server)
Remove Log Shipping (SQL Server)
View the Log Shipping Report (SQL Server Management Studio)
Monitor Log Shipping (Transact-SQL)
Fail Over to a Log Shipping Secondary (SQL Server)
See Also
About Log Shipping (SQL Server)
Log Shipping Tables and Stored Procedures
Remove Log Shipping (SQL Server)
3/29/2017 • 1 min to read • Edit Online
This topic describes how to remove log shipping in SQL Server 2016 by using SQL Server Management Studio or
Transact-SQL.
In This Topic
Before you begin:
Security
To remove log shipping, using:
SQL Server Management Studio
Transact-SQL
Related Tasks
Before You Begin
Security
Permissions
The log-shipping stored procedures require membership in the sysadmin fixed server role.
Using SQL Server Management Studio
To remove log shipping
1. Connect to the instance of SQL Server that is currently the log shipping primary server and expand that
instance.
2. Expand Databases, right-click the log shipping primary database, and then click Properties.
3. Under Select a page, click Transaction Log Shipping.
4. Clear the Enable this as a primary database in a log shipping configuration check box.
5. Click OK to remove log shipping from this primary database.
Using Transact-SQL
To Remove Log Shipping
1. On the log shipping primary server, execute sp_delete_log_shipping_primary_secondary to delete the
information about the secondary database from the primary server.
2. On the log shipping secondary server, execute sp_delete_log_shipping_secondary_database to delete the
secondary database.
NOTE
If there are no other secondary databases with the same secondary ID,
sp_delete_log_shipping_secondary_primary is invoked from sp_delete_log_shipping_secondary_database
and deletes the entry for the secondary ID and the copy and restore jobs.
3. On the log shipping primary server, execute sp_delete_log_shipping_primary_database to delete
information about the log shipping configuration from the primary server. This also deletes the backup job.
4. On the log shipping primary server, disable the backup job. For more information, see Disable or Enable a
Job.
5. On the log shipping secondary server, disable the copy and restore jobs.
6. Optionally, if you are no longer using the log shipping secondary database, you can delete it from the
secondary server.
Related Tasks
Upgrading Log Shipping to SQL Server 2016 (Transact-SQL)
Configure Log Shipping (SQL Server)
Add a Secondary Database to a Log Shipping Configuration (SQL Server)
Remove a Secondary Database from a Log Shipping Configuration (SQL Server)
Monitor Log Shipping (Transact-SQL)
Fail Over to a Log Shipping Secondary (SQL Server)
Disable or Enable a Job
See Also
About Log Shipping (SQL Server)
Log Shipping Tables and Stored Procedures
View the Log Shipping Report (SQL Server
Management Studio)
3/29/2017 • 2 min to read • Edit Online
This topic explains how to view the Transaction Log Shipping Status report in SQL Server Management Studio.
You can run a status report at a monitor server, primary server, or secondary server. To see the most complete
information about your log shipping configuration, view the report at the monitor server instance.
The report displays the status of any log shipping activity whose status is available from the server instance to
which you are connected. If that server instance is involved in multiple configurations in different roles (such as
serving as a monitor for one database and a secondary for another database), the displayed results contain the
information of every configuration from the perspective of each role. If the stored procedure can connect to the
monitor server instance for a given log shipping configuration, the report displays additional status for that
configuration.
For each role performed by the current server instance, you can view the following information:
ROLE
INFORMATION DISPLAYED
Monitor
The name and status of every primary server and secondary
server that uses this server instance as its monitor server.
Primary
For each primary database, the status and name of the
current server instance (as the primary server), along with the
primary database name. The report displays the status of the
backup job (which is stored locally on the primary server).
The report also contains a row for each of the corresponding
secondary servers. If the configuration uses a monitor server
and the stored procedure can connect to the monitor, these
rows display the copy status and restore status for the most
recent log backup.
Secondary
For each secondary database, the status and name of the
current server instance (as the secondary server), along with
the secondary database name.
The report displays the status of the copy and restore jobs at
the secondary server.
The report also contains a row for the corresponding primary
server. If the configuration uses a monitor server and the
stored procedure can connect to the monitor, this row
displays the status of the most recent log backup.
The information displayed depends on whether the server instance is a monitor server, primary server, or
secondary server. If information is not available, the corresponding cells are grayed out.
The report calls sp_help_log_shipping_monitor to get the data. For information about the required permissions,
see sp_help_log_shipping_monitor (Transact-SQL).
To display the Transaction Log Shipping Status report on a server instance
1. Connect to a monitor server, primary server, or secondary server.
2. Right-click the server instance in Object Explorer, point to Reports, and point to Standard Reports.
3. Click Transaction Log Shipping Status.
See Also
Monitor Log Shipping (Transact-SQL)
Monitor Log Shipping (Transact-SQL)
3/29/2017 • 3 min to read • Edit Online
After you have configured log shipping, you can monitor information about the status of all the log shipping
servers. The history and status of log shipping operations are always saved locally by the log shipping jobs. The
history and status of the backup operation are stored at the primary server, and the history and status of the copy
and restore operations are stored at the secondary server. If you have implemented a remote monitor server, this
information is also stored on the monitor server.
You can configure alerts that will fire if log shipping operations fail to occur as scheduled. Errors are raised by an
alert job that watches the status of the backup and restore operations. You can define alerts that notify an
operator when these errors are raised. If a monitor server is configured, one alert job runs on the monitor server
that raises errors for all operations in the log shipping configuration. If a monitor server is not specified, an alert
job runs on the primary server instance, which monitors the backup operation. If a monitor server is not specified,
an alert job also runs on each secondary server instance to monitor the local copy and restore operations.
IMPORTANT
To monitor a log shipping configuration, you must add the monitor server when you enable log shipping. If you add a
monitor server later, you must remove the log shipping configuration and then replace it with a new configuration that
includes a monitor server. For more information, see Configure Log Shipping (SQL Server). Furthermore, after the monitor
server has been configured, it cannot be changed without removing log shipping first.
History Tables Containing Monitoring Information
The monitoring history tables contain metadata that is stored on the monitor server. A copy of information
specific to a given primary or secondary server is also stored locally.
You can query these tables to monitor the status of a log shipping session. For example, to learn status of log
shipping, check the status and history of the backup job, copy job, and restore job. You can view specific log
shipping history and error details by querying the following monitoring tables.
TABLE
DESCRIPTION
log_shipping_monitor_alert
Stores alert job ID.
log_shipping_monitor_error_detail
Stores error details for log shipping jobs. You can query this
table see the errors for an agent session. Optionally, you can
sort the errors by the date and time at which each was
logged. Each error is logged as a sequence of exceptions, and
multiple errors (sequences) can per agent session.
log_shipping_monitor_history_detail
Contains history details for log shipping agents. You can
query this table to see the history detail for an agent session.
log_shipping_monitor_primary
Stores one monitor record for the primary database in each
log shipping configuration, including information about the
last backup file and last restored file that is useful for
monitoring.
TABLE
DESCRIPTION
log_shipping_monitor_secondary
Stores one monitor record for each secondary database,
including information about the last backup file and last
restored file that is useful for monitoring.
Stored Procedures for Monitoring Log Shipping
Monitoring and history information is stored in tables in msdb, which can be accessed using log shipping stored
procedures. Run these stored procedures on the servers indicated in the following table.
STORED PROCEDURE
DESCRIPTION
RUN THIS PROCEDURE ON
sp_help_log_shipping_monitor_primary
Returns monitor records for the
specified primary database from the
log_shipping_monitor_primary table.
Monitor server or primary server
sp_help_log_shipping_monitor_seconda
ry
Returns monitor records for the
specified secondary database from the
log_shipping_monitor_secondary
table.
Monitor server or secondary server
sp_help_log_shipping_alert_job
Returns the job ID of the alert job.
Monitor server, or primary or
secondary server if no monitor is
defined
sp_help_log_shipping_primary_databas
e
Retrieves primary database settings
and displays the values from the
log_shipping_primary_databases
and log_shipping_monitor_primary
tables.
Primary server
sp_help_log_shipping_primary_seconda
ry
Retrieves secondary database names
for a primary database.
Primary server
sp_help_log_shipping_secondary_datab
ase
Retrieves secondary-database settings
from the log_shipping_secondary,
log_shipping_secondary_databases
and
log_shipping_monitor_secondary
tables.
Secondary server
sp_help_log_shipping_secondary_prima
ry (Transact-SQL)
This stored procedure retrieves the
settings for a given primary database
on the secondary server.
Secondary server
See Also
View the Log Shipping Report (SQL Server Management Studio)
Log Shipping Stored Procedures and Tables
Fail Over to a Log Shipping Secondary (SQL Server)
3/29/2017 • 1 min to read • Edit Online
Failing over to a log shipping secondary is useful if the primary server instance fails or requires maintenance.
Preparing for a Controlled Failover
Typically, the primary and secondary databases are unsynchronized, because the primary database continues to
be updated after its latest backup job. Also, in some cases, recent transaction log backups have not been copied
to the secondary server instances, or some copied log backups might still not have been applied to the secondary
database. We recommend that you begin by synchronizing all of the secondary databases with the primary
database, if possible.
For information about log shipping jobs, see About Log Shipping (SQL Server).
Failing Over
To fail over to a secondary database:
1. Copy any uncopied backup files from the backup share to the copy destination folder of each secondary
server.
2. Apply any unapplied transaction log backups in sequence to each secondary database. For more
information, see Apply Transaction Log Backups (SQL Server).
3. If the primary database is accessible, back up the active transaction log and apply the log backup to the
secondary databases.
If the original primary server instance is not damaged, back up the tail of the transaction log of the
primary database using WITH NORECOVERY. This leaves the database in the restoring state and therefore
unavailable to users. Eventually you will be able to roll this database forward by applying transaction log
backups from the replacement primary database.
For more information, see Transaction Log Backups (SQL Server).
4. After the secondary servers are synchronized, you can fail over to whichever one you prefer by recovering
its secondary database and redirecting clients to that server instance. Recovering puts the database into a
consistent state and brings it online.
NOTE
When you make a secondary database available, you should ensure that its metadata is consistent with the
metadata of the original primary database. For more information, see Manage Metadata When Making a Database
Available on Another Server Instance (SQL Server).
5. After you have recovered a secondary database, you can reconfigure it to act as a primary database for
other secondary databases.
If no other secondary database is available, see Configure Log Shipping (SQL Server).
Related Tasks
Change Roles Between Primary and Secondary Log Shipping Servers (SQL Server)
Management of Logins and Jobs After Role Switching (SQL Server)
See Also
Log Shipping Tables and Stored Procedures
About Log Shipping (SQL Server)
Tail-Log Backups (SQL Server)
Change Roles Between Primary and Secondary Log
Shipping Servers (SQL Server)
3/29/2017 • 2 min to read • Edit Online
After you have failed over a SQL Server log shipping configuration to a secondary server, you can configure your
secondary database to act as the primary database. Then, you will be able to swap primary and secondary
databases as needed.
Performing the Initial Role Change
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.
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. For more information, see Fail Over to a Log
Shipping Secondary (SQL Server).
2. Disable the log shipping backup job on the original primary server, and the copy and restore jobs on the
original secondary server.
3. On your secondary database (the database you want to be the new primary), configure log shipping using
SQL Server Management Studio. For more information, see Configure Log Shipping (SQL Server). Include
the following steps:
a. Use the same share for creating backups that you created for the original primary server.
b. 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.
c. In the Secondary Database Settings dialog box, select No, the secondary database is
initialized.
4. If log shipping monitoring was enabled on your former log shipping configuration, reconfigure log shipping
monitoring to monitor the new log shipping configuration. Execute the following commands, replacing
database_name with the name of your database:
a. On the new primary server
Execute the following Transact-SQL statements:
-- Statement to execute on the new primary server
USE msdb
GO
EXEC master.dbo.sp_change_log_shipping_secondary_database @secondary_database = N'database_name',
@threshold_alert_enabled = 0;
GO
b. On the new secondary server
Execute the following Transact-SQL statements:
-- Statement to execute on the new secondary server
USE msdb
GO
EXEC master.dbo.sp_change_log_shipping_primary_database @database=N'database_name',
@threshold_alert_enabled = 0;
GO
Swapping Roles
After you have completed the steps above for the initial role change, you can change roles between the primary
database and the secondary database by following the steps in this section. To perform a role change, follow these
general steps:
1. Bring the secondary database online, backing up the transaction log on the primary server with
NORECOVERY.
2. Disable the log shipping backup job on the original primary server, and the copy and restore jobs on the
original secondary server.
3. Enable the log shipping backup job on the secondary server (the new primary server), and the copy and
restore jobs on the primary server (the new secondary server).
IMPORTANT
When you change a secondary database to the primary database, to provide a consistent experience to users and
applications, you might have to re-create some or all of the metadata for the database, such as logins and jobs, on the new
primary server instance. For more information, see Manage Metadata When Making a Database Available on Another Server
Instance (SQL Server).
Related Tasks
Fail Over to a Log Shipping Secondary (SQL Server)
Management of Logins and Jobs After Role Switching (SQL Server)
See Also
Log Shipping Tables and Stored Procedures
Log Shipping and Replication (SQL Server)
3/29/2017 • 8 min to read • Edit Online
Log shipping involves two copies of a single database that typically reside on different computers. At any given
time, only one copy of the database is currently available to clients. This copy is known as the primary database.
Updates made by clients to the primary database are propagated by means of log shipping to the other copy of the
database, known as the secondary database. Log shipping involves applying the transaction log from every
insertion, update, or deletion made on the primary database onto the secondary database.
Log shipping can be used in conjunction with replication, with the following behavior:
Replication does not continue after a log shipping failover. If a failover occurs, replication agents do not
connect to the secondary, so transactions are not replicated to Subscribers. If a failback to the primary
occurs, replication resumes. All transactions that log shipping copies from the secondary back to the primary
are replicated to Subscribers.
If the primary is permanently lost, the secondary can be renamed so that replication can continue. The
remainder of this topic describes the requirements and procedures for handling this case. The example
given is the publication database, which is the most common database to log ship, but a similar process can
also be applied to subscription and distribution databases.
For information about recovering databases involved in replication without any need to reconfigure
replication, see Back Up and Restore Replicated Databases.
NOTE
We recommend using database mirroring, rather than log shipping, to provide availability for the publication database. For
more information, see Database Mirroring and Replication (SQL Server).
Requirements and Procedures for Replicating from the Secondary If
the Primary Is Lost
Be aware of the following requirements and considerations:
If a primary contains more than one publication database, log ship all of the publication databases to the
same secondary.
The installation path for the secondary server instance must be the same as the primary. User database
locations on the secondary server must be the same as on the primary.
Back up the service master key at the primary. This key will be restored at the secondary. For more
information, see BACKUP SERVICE MASTER KEY (Transact-SQL).
Log shipping does not guarantee against data loss. A failure on the primary database can result in the loss of
data that has not yet been backed up or for backups that are lost during the failure.
Log Shipping with Transactional Replication
For transactional replication, the behavior of log shipping depends on the sync with backup option. This option
can be set on the publication database and distribution database; in log shipping for the Publisher, only the setting
on the publication database is relevant.
Setting this option on the publication database ensures that transactions are not delivered to the distribution
database until they are backed up at the publication database. The last publication database backup can then be
restored at the secondary server without any possibility of the distribution database having transactions that the
restored publication database does not have. This option guarantees that if the Publisher fails over to a secondary
server, consistency is maintained between the Publisher, Distributor, and Subscribers. Latency and throughput are
affected because transactions cannot be delivered to the distribution database until they have been backed up at
the Publisher; if your application can tolerate this latency, we recommend that you set this option on the
publication database. If the sync with backup option is not set, Subscribers might receive changes that are no
longer included in the recovered database at the secondary server. For more information, see Strategies for
Backing Up and Restoring Snapshot and Transactional Replication.
To configure transactional replication and log shipping with the sync with backup option
1. If the sync with backup option is not set on the publication database, execute
sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'
. For more information, see
sp_replicationdboption (Transact-SQL).
2. Configure log shipping for the publication database. For more information, see Configure Log Shipping
(SQL Server).
3. If the Publisher fails, restore the last log of the database to the secondary server, using the
KEEP_REPLICATION option of RESTORE LOG. This retains all replication settings for the database. For more
information, see Fail Over to a Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).
4. Restore the msdb database and master databases from the primary to the secondary. For more
information, see Back Up and Restore of System Databases (SQL Server). If the primary was also a
Distributor, restore the distribution database from the primary to the secondary.
These databases must be consistent with the publication database at the primary in terms of replication
configuration and settings.
5. At the secondary server, rename the computer and then rename the SQL Server instance to match the
primary server name. For information about renaming the computer, see the Windows documentation. For
information about renaming the server, see Rename a Computer that Hosts a Stand-Alone Instance of SQL
Server and Rename a SQL Server Failover Cluster Instance.
6. At the secondary server, restore the service master key that was backed up from the primary. For more
information, see RESTORE SERVICE MASTER KEY (Transact-SQL).
To configure transactional replication and log shipping without the sync with backup option
7. Configure log shipping for the publication database. For more information, see Configure Log Shipping
(SQL Server).
8. If the Publisher fails, restore the last log of the database to the secondary server, using the
KEEP_REPLICATION option of RESTORE LOG. This retains all replication settings for the database. For more
information, see Fail Over to a Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).
9. Restore the msdb database and master databases from the primary to the secondary. For more
information, see Back Up and Restore of System Databases (SQL Server). If the primary was also a
Distributor, restore the distribution database from the primary to the secondary.
These databases must be consistent with the publication database at the primary in terms of replication
configuration and settings.
10. At the secondary server, rename the computer and then rename the SQL Server instance to match the
primary server name. For information about renaming the computer, see the Windows documentation. For
information about renaming the server, see Rename a Computer that Hosts a Stand-Alone Instance of SQL
Server and Rename a SQL Server Failover Cluster Instance.
You might receive an error message from the Log Reader Agent that the publication database and the
distribution database are not synchronized.
11. At the secondary server, restore the service master key that was backed up from the primary. For more
information, see RESTORE SERVICE MASTER KEY (Transact-SQL).
12. Execute sp_replrestart. This stored procedure can be used to force the Log Reader Agent to ignore all the
previous replicated transactions in the publication database log. Transactions applied after the completion of
the stored procedure are processed by the Log Reader Agent. For more information, see sp_replrestart
(Transact-SQL).
13. Restart the Log Reader Agent after the stored procedure executes successfully. For more information, see
Start and Stop a Replication Agent (SQL Server Management Studio).
14. Transactions that have already been distributed to Subscriber might be applied at the Publisher. To ensure
that the Distribution Agent does not fail with an error when attempting to reapply these transactions at a
Subscriber, specify the agent profile titled Continue On Data Consistency Errors.
Log Shipping with Merge Replication
Follow the steps in the procedure below to configure merge replication and log shipping.
To configure merge replication and log shipping
1. Configure log shipping for the publication database. For more information, see Configure Log Shipping
(SQL Server).
2. If the Publisher fails, at the secondary server, rename the computer and then rename the SQL Server
instance to match the primary server name. For information about renaming the computer, see the
Windows documentation. For information about renaming the server, see Rename a Computer that Hosts a
Stand-Alone Instance of SQL Server and Rename a SQL Server Failover Cluster Instance.
3. Restore the last log of the database to the secondary server, using the KEEP_REPLICATION option of
RESTORE LOG. This retains all replication settings for the database. For more information, see Fail Over to a
Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).
4. Restore the msdb database and master databases from the primary to the secondary. For more
information, see Back Up and Restore of System Databases (SQL Server). If the primary was also a
Distributor, restore the distribution database from the primary to the secondary.
These databases must be consistent with the publication database at the primary in terms of replication
configuration and settings.
5. At the secondary server, restore the service master key that was backed up from the primary. For more
information, see RESTORE SERVICE MASTER KEY (Transact-SQL).
6. Synchronize the publication database with one or more subscription databases. This allows you to upload
those changes made previously in the publication database, but not represented in the restored backup. The
data that can be uploaded depends on the way in which a publication is filtered:
If the publication is not filtered, you should be able to bring the publication database up-to-date by
synchronizing with the most up-to-date Subscriber.
If the publication is filtered, you might not be able to bring the publication database up-to-date.
Consider a table that is partitioned such that each subscription receives customer data only for a
single region: North, East, South, and West. If there is at least one Subscriber for each partition of
data, synchronizing with a Subscriber for each partition should bring the publication database up-todate. However, if data in the West partition, for example, was not replicated to any Subscribers, this
data at the Publisher cannot be brought up-to-date. In this case, we recommend reinitializing all
subscriptions so that the data at the Publisher and Subscribers converges. For more information, see
Reinitialize Subscriptions.
If you synchronize with a Subscriber that is running a version of SQL Server prior to SQL Server
2005, the subscription cannot be anonymous; it must be a client subscription or server subscription
(referred to as local subscriptions and global subscriptions in previous releases). For more
information, see Synchronize Data.
See Also
Replication Features and Tasks
About Log Shipping (SQL Server)
Database Mirroring and Replication (SQL Server)
Log Shipping Tables and Stored Procedures
3/29/2017 • 3 min to read • Edit Online
This topic describes all of the tables and stored procedures associated with a log shipping configuration. All log
shipping tables are stored in msdb on each server. The tables below describe which tables and stored procedures
are used on which servers in a log shipping configuration.
Primary Server Tables
TABLE
DESCRIPTION
log_shipping_monitor_alert
Stores alert job ID. This table is only used on the primary
server if a remote monitor server has not been configured.
log_shipping_monitor_error_detail
Stores error detail for log shipping jobs associated with this
primary server.
log_shipping_monitor_history_detail
Stores history detail for log shipping jobs associated with this
primary server.
log_shipping_monitor_primary
Stores one monitor record for this primary database.
log_shipping_primary_databases
Contains configuration information for primary databases on
a given server. Stores one row per primary database.
log_shipping_primary_secondaries
Maps primary databases to secondary databases.
Primary Server Stored Procedures
STORED PROCEDURE
DESCRIPTION
sp_add_log_shipping_primary_database
Sets up the primary database for a log shipping
configuration, including the backup job, local monitor record,
and remote monitor record.
sp_add_log_shipping_primary_secondary
Adds a secondary database name to an existing primary
database.
sp_change_log_shipping_primary_database
Changes primary database settings including local and
remote monitor record.
sp_cleanup_log_shipping_history
Cleans up history locally and on the monitor based on
retention period.
sp_delete_log_shipping_primary_database
Removes log shipping of primary database including backup
job as well as local and remote history.
sp_delete_log_shipping_primary_secondary
Removes a secondary database name from a primary
database.
STORED PROCEDURE
DESCRIPTION
sp_help_log_shipping_primary_database
Retrieves primary database settings and displays the values
from the log_shipping_primary_databases and
log_shipping_monitor_primary tables.
sp_help_log_shipping_primary_secondary
Retrieves secondary database names for a primary database.
sp_refresh_log_shipping_monitor
Refreshes the monitor with the latest information for the
specified log shipping agent.
Secondary Server Tables
TABLE
DESCRIPTION
log_shipping_monitor_alert
Stores alert job ID. This table is only used on the secondary
server if a remote monitor server has not been configured.
log_shipping_monitor_error_detail
Stores error detail for log shipping jobs associated with this
secondary server.
log_shipping_monitor_history_detail
Stores history detail for log shipping jobs associated with this
secondary server.
log_shipping_monitor_secondary
Stores one monitor record per secondary database
associated with this secondary server.
log_shipping_secondary
Contains configuration information for the secondary
databases on a given server. Stores one row per secondary
ID.
log_shipping_secondary_databases
Stores configuration information for a given secondary
database. Stores one row per secondary database.
NOTE
Secondary databases on the same secondary server for a given primary database share the settings in the
log_shipping_secondary table. If a shared setting is altered for one secondary database, the setting is altered for all of
them.
Secondary Server Stored Procedures
STORED PROCEDURE
DESCRIPTION
sp_add_log_shipping_secondary_database
Sets up a secondary database for log shipping.
sp_add_log_shipping_secondary_primary
Sets up the primary information, adds local and remote
monitor links, and creates copy and restore jobs on the
secondary server for the specified primary database.
sp_change_log_shipping_secondary_database
Changes secondary database settings including local and
remote monitor records.
STORED PROCEDURE
DESCRIPTION
sp_change_log_shipping_secondary_primary
Changes secondary database settings such as source and
destination directory, and file retention period.
sp_cleanup_log_shipping_history
Cleans up history locally and on the monitor based on
retention period.
sp_delete_log_shipping_secondary_database
Removes a secondary database and the local history and
remote history.
sp_delete_log_shipping_secondary_primary
Removes the information about the specified primary server
from the secondary server.
sp_help_log_shipping_secondary_database
Retrieves secondary database settings from the
log_shipping_secondary,
log_shipping_secondary_databases, and
log_shipping_monitor_secondary tables.
sp_help_log_shipping_secondary_primary
This stored procedure retrieves the settings for a given
primary database on the secondary server.
sp_refresh_log_shipping_monitor
Refreshes the monitor with the latest information for the
specified log shipping agent.
Monitor Server Tables
TABLE
DESCRIPTION
log_shipping_monitor_alert
Stores alert job ID.
log_shipping_monitor_error_detail
Stores error detail for log shipping jobs.
log_shipping_monitor_history_detail
Stores history detail for log shipping jobs.
log_shipping_monitor_primary
Stores one monitor record per primary database associated
with this monitor server.
log_shipping_monitor_secondary
Stores one monitor record per secondary database
associated with this monitor server.
Monitor Server Stored Procedures
STORED PROCEDURE
DESCRIPTION
sp_add_log_shipping_alert_job
Creates a log shipping alert job if one has not already been
created.
sp_delete_log_shipping_alert_job
Removes a log shipping alert job if there are no associated
primary databases.
sp_help_log_shipping_alert_job
Returns the job ID of the alert job.
STORED PROCEDURE
DESCRIPTION
sp_help_log_shipping_monitor_primary
Returns monitor records for the specified primary database
from the log_shipping_monitor_primary table.
sp_help_log_shipping_monitor_secondary
Returns monitor records for the specified secondary database
from the log_shipping_monitor_secondary table.
Upgrading Log Shipping to SQL Server 2016
(Transact-SQL)
3/29/2017 • 5 min to read • Edit Online
When upgrading from a SQL Server log shipping configuration to a new SQL Server 2016 version, a new SQL
Serverservice pack, or a SQL Servercumulative update, upgrading your log shipping servers in the appropriate
order will preserve your log shipping disaster recovery solution.
NOTE
Backup compression was introduced in SQL Server 2008 Enterprise. An upgraded log shipping configuration uses the
backup compression default server-level configuration option to control whether backup compression is used for the
transaction log backup files. The backup compression behavior of log backups can be specified for each log shipping
configuration. For more information, see Configure Log Shipping (SQL Server).
In This Topic:
Prerequisites
Protect Your Data Before the Upgrade
Upgrading the Monitor Server Instance
Upgrading the Secondary Server Instances
Upgrading the Primary Instance
Prerequisites
Before you begin, review the following important information:
Supported Version and Edition Upgrades: Verify that you can upgrade to SQL Server 2016 from your
version of the Windows operating system and version of SQL Server. For example, you cannot upgrade
directly from a SQL Server 2005 instance to SQL Server 2016.
Choose a Database Engine Upgrade Method: Select the appropriate upgrade method and steps based on
your review of supported version and edition upgrades and also based on other components installed in
your environment to upgrade components in the correct order.
Plan and Test the Database Engine Upgrade Plan: Review the release notes and known upgrade issues, the
pre-upgrade checklist, and develop and test the upgrade plan.
Hardware and Software Requirements for Installing SQL Server 2016: Review the software requirements
for installing SQL Server 2016. If additional software is required, install it on each node before you begin
the upgrade process to minimize any downtime.
Protect Your Data Before the Upgrade
As a best practice, we recommend that you protect your data before a log shipping upgrade.
To protect your data
1. Perform a full database backup on every primary database.
For more information, see Create a Full Database Backup (SQL Server).
2. Run the DBCC CHECKDB command on every primary database.
IMPORTANT
Ensure that you have sufficient space on your primary server to hold the log backup copies for as long as the upgrade of
the secondaries is expected to take. If you are failing over to a secondary, this same concern applies to the secondary (the
new primary).
Upgrading the (Optional) Monitor Server Instance
The monitor server instance, if any, can be upgraded at any time. However, you do not need to upgrade the
optional monitor server when you upgrade the primary and secondary servers.
While the monitor server is being upgraded, the log shipping configuration continues to work, but its status is not
recorded in the tables on the monitor. Any alerts that have been configured will not be triggered while the
monitor server is being upgraded. After the upgrade, you can update the information in the monitor tables by
executing the sp_refresh_log_shipping_monitor system stored procedure. For more information about a monitor
server, see About Log Shipping (SQL Server).
Upgrading the Secondary Server Instances
The upgrade process involves upgrading the secondary server instances of SQL Server to SQL Server 2016 before
upgrading the primary server instance. Always upgrade the secondary SQL Server instances first. Log shipping
continues throughout the upgrade process because the upgraded secondary server instances continue to restore
the log backups from SQL Server primary server instance. If the primary server instance is upgraded before the
secondary server instance, log shipping will fail because a backup created on a newer version of SQL Server
cannot be restored on an older version of SQL Server. You can upgrade the secondary instances simultanously or
serially, but all secondary instance must be upgraded before the primary instance is upgraded to avoid a log
shipping failure.
While a secondary server instance is being upgraded, the log shipping copy and restore jobs do not run. This
means that unrestored transaction log backups will accumulate on the primary and you need to have sufficient
space to hold these unrestored backups. The amount of accumulation depends on the frequency of scheduled
backup on the primary server instance and the sequence in which you upgrade the secondary instances. Also, if a
separate monitor server has been configured, alerts might be raised indicating restores have not been performed
for longer than the configured interval.
Once the secondary server instances have been upgraded, the log shipping agents jobs resume and continue to
copy and restore log backups from the primary server instance to the secondary server instances. The amount of
time required for the secondary server instances to bring the secondary database up to date varies, depending on
the time taken to upgrade the secondary server instance and the frequency of the backups on the primary server.
NOTE
During the server upgrade, the secondary database itself is not upgraded to a SQL Server 2016 database. It will get
upgraded only if it is brought online by initiating a failover of the log shipped database. In theory, this condition could
persist indefinitely. The amount of time to upgrade the database metadata when a failover is initiated is small.
IMPORTANT
The RESTORE WITH STANDBY option is not supported for a database that requires upgrading. If an upgraded secondary
database has been configured by using RESTORE WITH STANDBY, transaction logs can no longer be restored after upgrade.
To resume log shipping on that secondary database, you will need to set up log shipping again on that standby server. For
more information about the STANDBY option, see Restore a Transaction Log Backup (SQL Server).
Upgrading the Primary Server Instance
Since log shipping is primarily a disaster recovery solution, the simplest and most common scenario is to upgrade
the primary instance in-place and the database is simply unavailable during this upgrade. Once the server is
upgraded, the database is automatically brought back online, which causes it to be upgraded. After the database is
upgraded, the log shipping jobs resume.
NOTE
Log shipping also supports the option to Fail Over to a Log Shipping Secondary (SQL Server), and optionally Change Roles
Between Primary and Secondary Log Shipping Servers (SQL Server). However, since log shipping is rarely configured as a
high availability solution anymore (newer options are much more robust), failing over generally will not minimize downtime
because system database objects will not be synchronized and enabling clients to easily locate and connect to a promoted
secondary can be an ordeal.
See Also
Upgrade to SQL Server 2016 Using the Installation Wizard (Setup)
Install SQL Server 2016 from the Command Prompt
Configure Log Shipping (SQL Server)
Monitor Log Shipping (Transact-SQL)
Log Shipping Tables and Stored Procedures