Log shipping has been a mechanism for maintaining a warm standby server for years. Though SQL Server supported log shipping with SQL Server 2000 as a part of DB Maintenance Plan, it has become a built-in feature of SQL Server 2005. This article gives brief introduction to SQL Server 2005 Log Shipping, configuration of it, monitoring of it and failing over at the disaster. This article Includes: Introduction to SQL Server 2005 Log Shipping Configuring SQL Server 2005 Log Shipping Monitoring SQL Server 2005 Log Shipping Failing over the database Other constraints Introduction to SQL Server Log Shipping Log shipping is a automated process of backing up the transaction log of the primary database and restoring the backup at one or many databases that are considered as standby servers. You may have noticed/read that some consider the log shipping as a high availability solution and some consider this as a disaster recovery solution. My belief is that we can consider that log shipping supports both but not in grand scale like SQL Server Clusters and Database Mirroring. In reality, it more closes to disaster recovery and best for non-mission-critical databases. Note that Database Mirroring has been implemented based on log shipping and it provides both high availability and disaster recovery. The typical log shipping configuration looks like below; The following are key points to remember when implementing log shipping; The SQL Servers involve with log shipping must have SQL Server 2005 enterprise, standard, workgroup or developer edition installed. (This was limited to Enterprise Edition with SQL Server 2000) Log shipping does not require the standby server to be located close to the primary server. Standby server can be configured any isolated location where it can be accessed the shared folder. Standby server does not require to have same configuration as primary server. Though it can be with low configuration, it is highly recommended to have as same configuration as primary server. Log shipping does not work with Simple recovery model. Either Full or Bulk-logged is required. SQL Agent must be running at both primary server and secondary server. The user account that the SQL agent service is run at primary server requires read/write permission to the backup folder.
The user account that the SQL agent service is run at secondary server requires read permission to the backup folder and read/write permission to the destination folder. Configuring SQL Server 2005 Log Shipping Configuring log shipping with SQL Server 2005 is not a difficult task. This can be simply setup via the property window of the source database. Open the SSMS and expand the server instance. Expand databases and select a database for log shipping. If you do not have one, create a database called "source" and add some tables. Get the properties of source database. Select Transaction Log Shipping page. Check the "Enable this as a primary database in a log shipping configuration" checkbox. This enables Backup Settings button. See the image below that shows the property window. Click on "Backup Settings". It opens "Transaction Log Backup Settings" window that allows you to set the path of the backup folder and schedule of the backup operation. Follow the procedures below for filling the input boxes. Fill the first input box with the network path (UNC) of the backup folder. If the backup folder you have configured is located in the primary server, fill the second input box with the local path of the folder. The setting "Delete files older than" allows us to set the number of days (or hours, or minutes) that backup file should be remained in the folder. Change if the default cannot be accepted.
The setting "Alert if no backup occurs within" allows to set the time period for alerts that should be fired if the database backup does not perform within the given timeframe. Leave them with default values unless you need to set different values. The "Edit Job" allows to change the job that is automatically added to the primary server that does the backup operation. You can change the name and the schedule of it by clicking "Edit Job..." button. Here is the window we just filled. Click "OK" to save the setting of "Transaction Log Backup Settings". Next is adding standby servers. Note that we can have more than one standby server. Here are the steps for adding standby server. Click on "Add" button in the "Database Properties - Transaction Log Shipping" window. It opens "Secondary Database Settings" window. Click on "Connect" button for connecting the standby server. It opens standard connection window, supply required credentials and connect to the server. Once connected, the destination database can be selected from the "Secondary database" dropdown. Note that you can edit the drop-down too. Use this facility if the target database is not exist. We'll create a new database as the destination database; type "Target" in the drop-down. The Initialize secondary database tab
There are three tabs in the "Secondary Database Settings" window. The first one is, "Initialize Secondary Database" that allows us to initialize the destination database. Let's initialize the destination. Here are the steps; If you do not want get involved with backing up the primary database and restoring on the destination process, Select the first option. It does everything you need. If you have already taken a full backup of primary database, you can give instruction for using it for initialization process. Select the second option and give the path of the full backup file. Select the third option if you have already configured the destination database. The "Restore Options..." allows you to set the physical paths of data and log files of destination database. Paths will be used for creating the database if it is not exist. Note: You may decide to restore the full backup manually if the primary database is very large. If you are restoring (or have restored) the full backup manually (third option), make sure you use "NORECOVERY" with restore operation. Since we have decided to create a new database called "Target", select the first option and specify paths for database files. Your screen may look like below;
The copy files tab This is where you specify the destination folder that is usually a local folder of standby server and the job that does the copying file operation from the backup folder to destination folder. The assigned account for the SQL agent needs read/write permission for this folder. Follow the instructions; Click on the second tab "Copy Files" on "Secondary Database Settings". Enter the network path (UNC) of the destination folder. The "Delete copied files after" allows us to instruct to the server that how long that the backup file is remained after it is sent over. For example, if you set to 72 hours (default), the backup file will be deleted from the destination folder after 72 hours from the time it saves. Keep the default. The "Copy job" section represents the SQL agent job that does the copy operation. If need to change the name or schedule, click on "Schedule" and edit them. This is the filled window for "Copy Files".
The restore transaction log tab This is the section where we instruct to the server that how the transaction log needs to be restored at the destination. The first setting is the "State" of the database after the restore operation; either "No Recovery" or "Standby" mode. No Recovery mode You will be selecting "No Recovery" mode to achieve the high availability. This transaction log restore operation is bit different with typical restore operation. With typical restore operation, it rolls back all incomplete transaction after restoring the database. With log shipping, once the state is set to the "No Recovery", it does not roll back incomplete transactions, they are remained. One disadvantage of this state is, users cannot use the standby server for querying. Standby mode If you look for ways of achieving scaling out, this option would help you. This mode allows users to query the standby database that helps you to reduce the workload in the primary database. Note that users cannot run action queries, it only accepts read-only queries. This mode does remove the incomplete transactions but they are saved in a file called "Transaction Undo File" to maintain the transactional integrity. Use following directions for setting the "Restore Transaction Log". Select "No recovery mode" because we try achieve the availability. If require, you can select "Standby mode" instead. If so, make sure you check the "Disconnect users in the database when restoring backups" checkbox. Though it is optional, do check it because leaving unchecked may interrupt the restore operation. The drawback of it is, all the users connected get disconnected. The property "Delay restoring backup at least:" tells to server that how long to be waited before applying the received log backup. The default that is zero, instructs to the server to apply the file immediately. You may be setting a value like 5 minutes for avoiding man-made mistake to be applied immediately to the standby database. The "Alert if no restore occurs within:" indicates the time period to be waited for alerting if no restore operations occur during the given time frame. The "Restore Job" section represents the job that does the restore operation at the standby server. If you need to change the name or the schedule, click on "Schedule" button and change the settings. The typical "Restore Transaction Log" would like this. Click "OK" after setting it.
Again, click "OK" for save the settings of the log shipping. Once clicked, it starts the full backing up process of the primary database, initializing the secondary database and creating jobs at both primary server and secondary server. The end screen looks like below.
Close the window and go to standby instance. Check whether the new database has been created. You may notice that the state of the secondary database is set as "Restoring...". This is because we selected the database state as "No Recovery mode" not "Standby". If you configure the secondary database as "Standby mode", the state of the "Target" database would be "Standby / Read-Only". Monitoring SQL Server 2005 Log Shipping All log shipping processes are done via SQL Server agent jobs. SQL Server agent stores all current job activities and history of activities in "msdb" database, hence all log shipping related jobs execution information are stored too. Backup job that performs the transaction log backup is executed by SQL Server agent of the primary server. Because of that, status and the historic information about backup job are stored in the msdb database of primary server. Status and historic information regarding copy and restore job are stored in the standby server because they are executed by the agent of standby server. In addition to that, log shipping process stores related information in tables called log_shipping_monitor_error_detail and log_shipping_monitor_history_detail in the local servers where the job are executed. Since the jobs are distributed among servers, it is impossible to get the entire picture of the log shipping process. The status of the configuration can be seen by generating the report "Transaction log shipping status report". Click on the SQL instance of the primary server and click the menu item "Reports -> Standards reports -> Transaction log shipping status report". You will see a report like below. This report gives us the status of only the primary database. You can run the same at secondary server and get the status of it too. Can't we have everything in one location? Yes, log shipping lets us to have one instance configured as a monitor. Once configured, process writes information on both local and monitor servers' log_shipping_monitor_error_detail and log_shipping_monitor_history_detail tables. Here are the procedure for setting it up. Note that you cannot add a monitor after enabling log shipping, hence we need to re-configure log shipping with a monitor. Get the properties of "Source" database and get log shipping properties. Uncheck the checkbox "Enable this as a primary database in a log shipping configuration". Follow the procedures again and configure log shipping as we did earlier. Do not click "OK" of database properties. Check on "Use a monitor server instance" and click on "Settings..." button. It opens "Log Shipping Monitor Settings" window. Connect to the instance that you choose as the monitor by giving the correct credentials. Do not select either primary server or standby server as monitor server unless you have no other option. It recommended to have a separate server for monitoring.
Next instruct how the log shipping jobs connect with the monitor instance. You can impersonate the agent account that is used for jobs and set it for authentication. Another option is, set a SQL account for authentication. Change "History retention" if you want to increase. You may end up with a window like this. Done! Click "OK" to save the settings. Click "OK" of database properties too. It configures the log shipping. Now we have configured the monitoring server. By running the "Transaction log shipping status report" on monitor server, you can see the status of the both servers.
Failing over the database Failing over the database can be simply done in log shipping environment. There are two way of doing this, based on the availability of the primary database. If the primary server is not available; Check whether all files in the destination folder have been applied to the secondary database. If not, restore them with "NORECOVERY". Finally, execute the restore command with "RECOVERY". RESTORE LOG Target WITH RECOVERY If the primary server is still available; Disable the log shipping setting in the primary server. Get the properties of the database and select log shipping section. Open "Transaction Log Backup Settings" by clicking the "Backup Settings...". Check the checkbox called "Disable this job". If possible, backup the tail of the transaction log. This may contains some transactions before the failure. BACKUP LOG Source TO DISK = '\\DINESH-PC\LogShippingFolder\Tail.trn' WITH NO_TRUNCATE, INIT Apply the backup into the standby database with "RECOVERY". RESTORE LOG Target FROM DISK 'E:\LogShippingFolder\Tail.trn' WITH RECOVERY Though we have brought the secondary database online, secondary server may not contains all the logins that were exist in the primary server. Therefore you need to keep a copy of all logins separately. The copy has to be taken as a part of log shipping process at the initialization. This can be done simply by using bcp. You may add this procedure to a job and execute regularly. bcp master..syslogins out e:\logshippinginfo\syslogins.dat -N -S -T At the failing over, once the database is recovered, apply the syslogins.dat to the secondary server. EXEC sp_resolve_logins @dest_db = 'Target', @dest_path = 'E:\LogShippingFolder', @filename = 'syslogins.dat'
Now the secondary serve is ready. Final step of fail over is, route the application to the new database server. Once it is done, application can use the secondary database as primary server till the primary server brings back online. Other constraints Here are some of other constraints you may need consider at the log shipping implementation. If you have already set a maintenance plan that does the transaction log backup of the primary database, it may break the log shipping process. Avoid it if possible. If it cannot be avoided, consider the backup files saved in the backup folder as source files. SQL Server 2000 cannot be a part of SQL Server 2005 log shipping process. It is not compatible. If a monitor server is required, do it while configuring the log shipping. Later implementation of a monitor requires re-configuring the log shipping again.