- How It Works
- Advantages of Log Shipping
- Disadvantages of Log Shipping
- Log Shipping Setup
- Failover
- Summary
Log Shipping Setup
Log shipping setup is accomplished by creating a maintenance plan for a database that is in Full recovery mode. If you are using Simple or Bulk-logged recovery modes, you cannot use log shipping. Let's quickly run through the steps of the Maintenance Plan Wizard to see how the process works.
To activate the Database Maintenance Plan Wizard, navigate to the Management folder within the current instance of Enterprise Manager, right-click Database Maintenance Plans and choose New Maintenance Plan. The introductory screen simply welcomes you to the wizard and informs you of tasks that you can accomplish using the wizard. The following screen allows you to choose the databases affected by the maintenance plan. As mentioned earlier in this article, you can configure only one database per maintenance plan for log shipping. For this example, I will ship transaction logs of the Northwind sample database. If you are following along, be sure to check the box next to Ship Transaction Logs to Other SQL Servers (Log Shipping), as shown in the following figure.
The next three screens in the Maintenance Plan Wizard are irrelevant for log shipping, so we won't discuss them here. However, be sure to uncheck the box that states Backup Database as Part of the Maintenance Plan. If you have any jobs that back up transaction logs of the database you're getting ready to set up for log shipping, be sure to drop those jobs. The maintenance plan you're setting up for log shipping will take care of transaction log backups for you.
The next screen involved in configuring log shipping allows you to specify the directory where transaction log backups will be stored. For this article, I simply ship transaction logs from one instance of SQL Server to another instance running on the same computer. However, in the real-world scenario, you are more likely to move transaction logs to a separate standby server. Therefore, you should select a shared drive as the destination of your transaction logs so that they can be copied to the standby server. The network share you will use for log shipping must be set up prior to activating the Maintenance Plan Wizard. You should also make sure that the account that runs SQL Server Agent on the standby server has appropriate permissions on the share where you put your transaction log backups. As shown in the following figure, you can also advise SQL Server to delete log backups that are older than a certain number of minutes, hours, days or weeks.
How frequently you remove backup files depends on your needs. Realize that transaction log backups can be used on the primary server in case you need to revive the database and you have a full backup, any differential and log backups taken since the last full backup. So it's advisable to keep all log backups between complete backups of the log-shipped database. For this example, I configure log shipping to delete backups that are one hour or older.
A quick word about other options on this screen: I recommend always specifying the log backup directory explicitly so that there are no surprises. I also recommend leaving the backup file extension at the default: TRN.
The following screen allows you to specify the share name for the folder where log backups will be stored on the primary server.
NOTE
Folder name and share name aren't always the same.
Once you specify the share name and click Next, you see the following screen, which lets you define the destination (standby) server and database.
You need to click the Add button to add the destination of the log-shipped database. This isn't a design flaw; although you can configure only one database at a time for log shipping, you can have MORE than one destination server. This way you can further reduce the chance of downtime by shipping transaction logs to multiple standby servers.
After you click Add, you see a screen where you specify the destination server, database, and other log-shipping options, as shown in the following figure.
First, few options are self-explanatory: You can ship transaction logs to another instance of the same server (as in this example) or to other servers. You can use an existing database or create a new database by specifying where data and log files will be stored. Note, however, that you can use only an existing database that is in No-Recovery or Standby mode. Similarly, if you create a new database, you must leave it in one of these states.
Both of these modes allow you to apply additional transaction logs to the database; however, there is a difference: Standby mode supports read-only access to the database, whereas No-Recovery mode doesn't. Therefore, if you intend to use the standby server for read-only queries, you must select Standby mode. Another option allows you to terminate any users that might be connected to the database when it's time to apply a transaction log backup. Because No-Recovery mode doesn't allow any activity within the database (not even reading), this option is relevant only for Standby mode. I recommend always checking this option; however, it is a double-edged sword: If log shipping finds an active connection when it needs to restore logs, the connection will be terminated. Therefore, if you are using a standby server for reporting, this might mean killing certain "unlucky" reports. On the other hand, if you don't choose this option, transaction log restores will fail because database must be in a single-user mode before log backups can be applied. Be sure to consider your needs carefully before choosing the option of terminating active connections.
The final option enables promoting the standby server to a primary server. So if Server A is failed over to Server B, you can ship transaction log backups from Server B to Server A. This is useful if you use failover for system upgrades and deployments. I will not choose this option for purposes of this example. If you're following along, please choose the same options that I chose and click OK. Note that log shipping allows you to change the options you selected from the Specify Log Shipping Destinations screen, so you're not stuck with the options you chose in the beginning. The same screen allows you to add or remove destination server by clicking Add/Delete, respectively.
For now, click Next and move to the following screen that lets you perform a full database backup.
Figure 6 *
Note that you're allowed to use the most recent full backup you have available. However, to use the latter option, you must NOT have taken any transaction log or differential backups since the last full backup. I recommend taking a full backup each time you configure log shipping. Simply click Next to move on to configuring the schedule for log shipping, as shown in the following figure.
Clicking the Change button allows you to change the default frequency of backups. Copy/Load Frequency specifies how often backup files are copied to the standby server and how often they are restored. Load Delay is the number of minutes or hours between the backup copy and restore jobs. If you want to minimize downtime, you should leave this option at 0 minutes, which happens to be the default. The only time you might want to change this value is when you're concerned with the performance of copy and load jobs. (If they tend to take too long, you might want to allow some time in-between so they don't step on each others' toes.) If you do have a performance problem, I recommend increasing the frequency of backupsthe more often you take backups, the smaller your backups will be. Smaller backups will copy and restore quicker.
The file-retention period is the number of minutes or hours to keep the log backups on the standby server. As was the case with the primary server, how long you keep transaction log backups depends on your needs. I recommend keeping at least 24 hours' worth of backups.
The following figure allows the configuring of the backup alert and the out of sync alert.
You can create an alert if backup or restore jobs fail for the specified number of minutes or hours. If you're familiar with SQL Server alerts, you know that you can have SQL Server email or page you when an alert is generated. You can also have a predefined job that SQL Server will execute when an alert condition occurs. By default, SQL Server advises creating an alert if three executions of backup/restore jobs fail. Typically, this is a good starting point; depending on your needs, however, you might want to configure SQL Server to page you each time log-shipping jobs fail.
The following figure lets you define the monitoring server. You can use primary, destination, or a separate server for monitoring. It shouldn't be hard to guess that using the primary server for monitoring isn't a good ideayou are using the log shipping as a failover solution, so monitoring failover from the server that could potentially fail is tough. Note that the monitoring server can use any edition of SQL Server (excluding MSDE); the Enterprise edition is not required. I recommend using a separate server with the Desktop edition of SQL Server for monitoring. For this example, I chose the standby server and moved on.
The next two figures deal with reporting/tracking log shipping. You could write a report of log shipping activity into a text file or to the sysdbmaintplan_history table in the MSDB database. You can also configure an operator that is emailed each time a log-shipping job succeeds or fails. Realize that sending email or generating a text file each time log shipping succeeds can generate an undue burden on your system. Therefore, I recommend notifying the operator only if the job fails. Furthermore, allow SQL Server to truncate the history of log shipping after a limit of rows in the system table has been reached (by default, this limit is 1000 rows).
After configuring log shipping tracking, you get to review the options you choose and finish the wizard by watching its progress as shown in the following figure.
Now, if you examine the log-shipping destination server (Standby), you'll see the read-only database Northwind1, as shown in the following figure.