* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download About Log Shipping (SQL Server) | Microsoft Docs
Survey
Document related concepts
Microsoft Access wikipedia , lookup
Oracle Database wikipedia , lookup
Ingres (database) wikipedia , lookup
Concurrency control wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Team Foundation Server wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Relational model wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Database model wikipedia , lookup
ContactPoint wikipedia , lookup
Transcript
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