Step-by-Step Guide to Log Shipping for SAP Customers using Microsoft SQL Server 2000

By Ramesh Meyyappan Microsoft Corporation Published: February 2002

Abstract This guide walks you through the Log Shipping Wizard, which enables setting up a standby database on secondary server. It is intended for Database Administrators, SAP Basis Consultants.

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. 2001 Microsoft Corporation. All rights reserved. Microsoft, Outlook, PowerPoint, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Other product and company names mentioned herein may be the trademarks of their respective owners. M7icrosoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA

Contents
Contents........................................................................................................................................3 Introduction...................................................................................................................................4 Log Shipping Architecture...........................................................................................................5
Primary server............................................................................................................................................5 Secondary server.......................................................................................................................................5 Monitoring server.......................................................................................................................................5 Log Shipping with SAP..............................................................................................................................6

Requirements................................................................................................................................7 Preparation for setting up Log Shipping....................................................................................9 Setting up Log Shipping.............................................................................................................23 Understanding the Log Shipping process................................................................................40 Monitoring the Log Shipping Processes..................................................................................42 Modifying the Log Shipping Plan..............................................................................................45 Planned promotion of secondary to primary............................................................................59 Adding back the old primary production database server after maintenance......................73 Unplanned promotion of secondary to primary.......................................................................87 Adding an operator for notification...........................................................................................88 Related Links...............................................................................................................................93

Introduction Log Shipping is designed as an inexpensive high-availability solution that can be used to protect a database against the failure of the primary production database server. You can also use Log Shipping in addition to failover clustering to protect against site-level disasters as well as local server failure. Log Shipping enables you to maintain a copy of the production database on one or more secondary servers and to easily promote one of the secondary standby database servers to become the new primary production database server. Log Shipping uses SQL Server backup and restore capabilities to provide database redundancy between the production database on a primary server and a standby database on one or more secondary servers. Log Shipping requires an administrator to detect a failure and initiate a role change. A role change promotes a secondary standby database server to a primary production database server by recovering the production database on the secondary standby database server. The role change process is not automatic and takes at least several minutes to complete. It can take significantly longer with large databases. After a role change, SAP Profile parameters should be modified on the Central Instance and Application Servers so they can connect to the standby database. Unlike with failover clustering, virtual server names and IP addresses are not incorporated into Log Shipping. Hardware upgrades can be performed with minimal downtime without loss of data by promoting the secondary standby database server to primary production database server during the hardware upgrade On disaster scenario, where the primary production database server fails. There is a possibility of data loss, this depends how often the transaction logs are backed up and copied to the secondary standby database server, more often means less data loss. Log Shipping is a less expensive high availability solution compared to Failover Clustering, but unlike failover clustering, Log Shipping requires manual process to promote a secondary standby database server to primary production database server. With Log Shipping, proximity is not a limitation; you can place a secondary standby database server in a geographically remote location to protect against a catastrophic disaster. Secondary standby database servers do not need to be identical to the primary production database server, although differences in the amount of memory, the number and speed of the processors, and the robustness of the storage system can affect SQL Server performance after a role change.

Log Shipping Architecture SQL Server 2000 Enterprise Edition has built-in support for Log Shipping; the architecture consists of a primary server, one or more secondary servers, and a monitoring server. These servers perform the following roles: Primary server The primary server is a server running SQL Server 2000 and containing the production database. You create and use a full database backup of this database to initialize a standby database on each secondary server. SQL Server Agent jobs make periodic transaction log backups of the production database to capture changes made to the production database. Secondary server Secondary servers are servers running SQL Server 2000 and containing an unrecovered copy of the production database from the primary server. SQL Server Agent jobs periodically copy transaction log backups from the primary production database server and restore these transaction log backups, without recovery, on each of the secondary servers. The restoration process updates the standby database on each secondary server with new transactions from the primary production database server. A standby database can be recovered, and the secondary server can replace the primary production database server if the primary production database server fails or must be taken offline for planned maintenance. More than one secondary server is useful to hold the production database at various point-in-times on these standby databases. For example secondary server SERVERBAK1 can be configured to have a load delay of 0min. while secondary server SERVERBAK2 can be configured to have a load delay of 3hrs. In the above scenario, when a table is deleted in primary server, the secondary server SERVERBAK2 will still hold the table until 3hrs past table deletion There can also be a secondary server just for the purpose of data protection; all secondary standby database servers need not be configured to take over primary role on a primary server failure. Monitoring server A monitoring server is a server running SQL Server 2000 that monitors the status of the Log Shipping jobs on the primary production database server and on each secondary standby database server. To enable you to detect a failure to the primary server or to any secondary servers, use a server other than the primary server or a secondary server as the monitoring server. In case a third server is not available for setting up monitoring server, it is recommended to use secondary server as the monitoring server

Log Shipping with SAP Log Shipping built-in support is only available with SQL Server 2000 Enterprise Edition. Since SAP Customers are usually using SQL Server 2000 Enterprise Edition in the SAP System Landscape this is not an issue. When a SAP customer chooses a secondary server which is not part of the SAP System Landscape, then they have to acquire an additional SQL Server 2000 Enterprise Edition for this purpose. Example: 1. Customer uses the development database server as the secondary server for the production database; in this case there is no need to acquire a SQL Server 2000 Enterprise Edition. 2. Customer uses the database server not part of SAP System Landscape as the secondary server for the production database; in this case there is a need to acquire a SQL Server 2000 Enterprise Edition.
Central Instance and Database is running on different servers

In this case, when the primary server or the production database fails, the standby database is promoted as production database. It is necessary to update the SAP Profile to adjust the database server parameter to point to the new primary production database server. This will not require a new License Key as the Central Instance server has not moved.
Central Instance and Database is running on the same server

In this case, when the server fails, the standby database is promoted as production database. The Central Instance can be installed on the same server or on a different server, the SAP Profile parameter need to be adjusted to point to the new primary production database server. This will require a new License Key as the Central Instance server has moved to a different server. When only the production database fails but the Central Instance is still available, the standby database is promoted as production database. It is necessary to update the SAP Profile to adjust the database server parameter to point to the new primary production database server. This will not require a new License Key as the Central Instance server has not moved.

Requirements
General requirement

The secondary server hosting the standby database should have SQL Server 2000 Enterprise Edition installed. Scheduled transaction log backup should be stopped irrespective whether it is scheduled from SQL Server Enterprise Manager or DB13 or from other 3rd party backup tools. Once the Log Shipping is set up, SQL Server will create a new job and perform transaction log backup. It is recommended to perform file level backup of the transaction log backup files using Windows Backup or 3rd party backup tools. There is no need to alter full database backup or differential backup schedules, but it is recommended to schedule Log Shipping transaction log backup to avoid the overlap with full database backup or differential backup schedules. Enough disk space on the secondary server to hold the standby database. The standby database will be identical in size to the production database, including the number of files. But the disk structure need not be the same as primary server, but should be able to hold all the files. Processor capacity on the secondary server should be able to keep with the transaction log application without lag. In primary production database server, the processor is utilized for Selects and Inserts/Update/Deletes. In secondary server only Inserts/Update/Deletes are performed, so the processor requirement is not that high, but in case this standby database is promoted as production database, then it should have enough resources to handle the load. Extra disk space on the primary server is needed to keep the transaction log backup on disk. It is recommended to keep this transaction log until they are archived into tapes, usually 1 week to 4 weeks of transaction logs. Extra disk space on the secondary server is needed to keep the transaction log copied from the primary server on disk. It is recommended to keep this transaction log until they are applied to the standby database, usually 1-2 days of transaction logs. Apply latest SQL Server Service Packs on the primary production database server and the secondary standby database servers.
Central Instance and Database is running on different servers

The secondary server hosting the standby database should have identical SQL Server setting like the primary production database server. To achieve this, we recommend a Database Instance only installation of SAP on this secondary server with the same SID as the production SID. Then delete the newly created database on this secondary standby database server before starting the Log Shipping setup.

It is also possible to manually prepare the secondary standby database server without performing a database only installation of SAP; in this case you have to configure the secondary standby database server to have same settings like the primary production database server. Like using SQL Server installing setting of binary sort order with 850 code page, setting tempdb size, changing SQL Server configuration parameter, mapping domain accounts sidadm and SAPServiceSID in SQL Server etc. Domain accounts sidadm and SAPServiceSID should have administrative privilege in this secondary standby database server. In case you choose an already existing database server in the SAP System Landscape as a secondary server for hosting the standby database, like development server, there is little preparation needed. There is no need to perform a dummy Database Instance only installation of SAP, instead make sure the domain accounts sidadm and SAPServiceSID have administrative privilege in this secondary standby database server, map domain accounts sidadm and SAPServiceSID in SQL Server, expand tempdb to accommodate primary production database server tempdb requirement. If you are using a separate instance other than an existing SQL Server Instance, you have to prepare the SQL Server Instance either manually or by performing a Database Instance only installation of SAP.
Central Instance and Database is running on the same server

The secondary server hosting the standby database should have identical SQL Server setting like the primary production database server. To achieve this, we recommend a Central and Database Instance installation of SAP on this secondary server with the same SID as the production SID. Then delete the newly created database on this secondary standby database server before starting the Log Shipping setup. Although using an already existing database server in the SAP System Landscape is possible, we recommend using another server for your Central Instance. In case you want to do this, test and document the procedure clearly as you need different SAP System Number.

Preparation for setting up Log Shipping This session walks you through the steps required to setup Log Shipping. The screenshots are taken from a SAP system with the following settings Primary Server name: SAPSQLA Secondary Server name: SAPSQLB SAPSID: RED Windows Domain: SAPSQLRED
Configuring service accounts for SQL Server

Grant Local Administrative privilege for the production SID accounts, DOMAIN\SAPSID and DOMAIN\SAPServiceSID, in the secondary servers and monitor server. Configure Microsoft SQL Server and SQL Server Agent to use DOMAIN\SAPSID user account. This should be performed both on the primary production database server and secondary standby database server. In case your secondary standby database server is same as development database server, use DOMAIN\SAPSID for the Development SID to start Microsoft SQL Server and SQL Server Agent service. In case there is a separate monitor server, also configure Microsoft SQL Server and SQL Server Agent service to use the DOMAIN\SAPSID and DOMAIN\SAPServiceSID accounts. Configure the Microsoft SQL Server and SQL Server Agent service to start automatically. Therefore open the service properties dialog box and change the service user account in the Log on tab. The next pictures show examples for changing the service user accounts of MSSQLSERVER and SQLSERVERAGENT service to the user account SAPSQLRED\redadm.

Directory for storing transaction log files in Primary Server

Create a directory in the primary production database server to store the transaction log files. It is recommended to create this directory on a separate drive that is independent of pagefile, tempdb, data and transaction log file location. Free space available in this drive should be able to accommodate few weeks of transaction log depending on the tape archive settings. Name the directory as PrimaryTLogs.
Network Share for the above directory in Primary Server

Create a Network share for the above directory on the primary production database server. This is the Network share where the secondary standby database server will copy the transaction log backup files periodically.

Directory for storing transaction log files in Secondary Server

Create a directory in the secondary standby database server to store the transaction log files. Free space available in this drive should be able to accommodate few days of transaction log backup files. Name the directory as SecondaryTLogs.
Network Share for the above directory in Secondary Server

Create a Network share for the above directory on the secondary standby database server. This is the Network share where the other secondary servers will copy the transaction logs once this secondary standby database is promoted as primary production database.

Register the Primary, Secondary and Monitor Server in Enterprise Manager

Start SQL Server Enterprise Manager and register Primary, Secondary and Monitor Server. If there is a (local) server registered, delete the registration by right clicking on the (local) and choosing Delete SQL Server Registration Right click on the SQL Server Group and choose New SQL Server Registration. Follow the wizard, choose the Primary, Secondary and Monitor Server and accept all defaults. Do not choose (local), choose the local server by name.

Check for SQL Server Enterprise Edition

Right click on each server in the SQL Server Enterprise Manager and choose Properties, look in General tab under Product if it is SQL Server Enterprise Edition.

Backup the production database

Make sure the transaction log backup is not scheduled from SQL Server Enterprise Manager or DB13 or 3rd party backup tools. Backup the production database on a tape or disk.

Restore the production database on the secondary standby database server

Make sure the SQL Server and database settings are correct as discussed in the Requirement section. Create necessary directories in the secondary standby database server, it is recommended to name these directories as standby so it is easy to administer. Make sure to choose Leave database nonoperational but able to restore additional transaction logs option. Once the restore is complete, the database will show (loading) as status.

Setting up Log Shipping

Start Database Maintenance Plan on primary production database server

Right click New Maintenance Plan from Database Maintenance Plan under Management on the primary production database server.

Select Databases

Check Ship the transaction logs to other SQL Servers (log shipping) box and also check the SID database in the These databases" database grid.

Update Data Optimization Information

Do not choose any check boxes in the Update Data Optimization Information screen.

Database Integrity Check

Do not choose any check boxes in the Database Integrity Check screen.

Specify the database Backup Plan

Uncheck all the checkbox in the Specify the database Backup Plan screen. If you need a backup schedule for full database backup, define a different maintenance plan and dont use this.

Specify Transaction Log Backup Disk Directory

Choose Use this directory and select the PrimaryTLogs directory. Also check Remove files older than box and mention the period after which SQL Server can delete the old transaction log files. Make sure you archive these transaction log backup files to tape before they are deleted.

Specify the Transaction Log Share

Choose the network share for the PrimaryTLogs directory.

Specify the Log Shipping Destination

Choose add and define the secondary standby database server details. Choose the secondary standby database server name in the Server Name. If the secondary server does not appear, it means it is not registered in the SQL Server Enterprise Manager. Then choose the SecondaryTLogs directory located in the secondary standby database server as the Transaction Log Destination Directory. In the destination Database choose Use existing database (No initialization) and choose the SID database. Instead, it is also possible to choose Create and initialize new database, but this will create the database on a location that does not accommodate SAP database directory structure. Since you restored the database already, it is enough that you select Use existing database (No initialization) and choose the SID database. Choose No recovery mode or Standby mode. In either mode you cannot start SAP until the database is promoted to primary. With No recovery mode you have no read access to the database and with Standby mode you have read access to the database. Irrespective whether there is read access or not you cannot start SAP until the database is promoted to primary.

With No recovery mode, the promotion to primary might take few extra minutes, but does not allow read access to the database. Additional transaction log applications will be quick as there is no need to save and apply incomplete transactions for every transaction log restore. With Standby mode, the promotion to primary is quick, but the database offers read access. But additional transaction log applications might be slow (as there is a need to save and apply incomplete transactions for every transaction log restore, these incomplete transactions can be gigabytes in size and can make the transaction log much slower), in some cases this can even create a lag in application that the secondary standby database server is never able to catch-up. Check the Terminate users in database option. Check the Allow database to assume primary role, this is required where this secondary standby database server might be promoted as primary production database server. If you have more than one secondary, you might choose not to check this box on some secondary standby database server which is hosted for data protection and not for promotion. Choose the Network share for the SecondaryTLogs in the Transaction Log Backup Directory.

If you want to set up additional secondary standby database servers, choose add and define them.

When you click next in the Specify the Log Shipping Destination screen, you will get the below message, choose Yes and continue. The message mentions that the secondary database that you restored is in Loading state and not Read-Only state this is okay, as the Log Shipping wizard will change the mode if necessary.

Log Shipping Schedule

Backup schedule: How often the transaction log is backed up on the primary production database server. The transaction that have been committed but not backed up and copied to the secondary standby database server is lost on a disaster scenario. Depending on the requirement, this can be set to 5 or 15 minute or 1 hour. Do not set this value to less than 2 minute. Copy Frequency: How often the transaction log backup files are copied to the secondary standby database server. You can execute the copy process for transaction log copying more often then executing the transaction log backup on the production database server. For example if the transaction log backup runs once the hour, the copy process will try to

copy once the hour too and miss the file as it is in use. It is better to copy few minutes later or copy more frequently than the transaction log backup. Load Frequency: How often the transaction log backups are applied to the secondary standby database. Since the transaction log backup files are copied at Copy Frequency, this can be set to the same value as Backup schedule as there is no effect on data loss. Even though you have to give the same value for Copy/Load Frequency, you can customize individually when you edit the Log Shipping maintenance plan later. Load Delay: How much delay has to be introduced in applying the transaction log backup. If the delay is 3 hours, then a table that is deleted in primary production database server will be available in the secondary standby database for 3 more hours. Usually the Load Delay is set to 0 minutes. File Retention Period: Applied transaction log files will be deleted from the secondary standby database server. This setting decides when will these files deleted. The usual File Retention Period is 1 or 2 days. If you change the transaction log backup process to back up more frequently, there will be more files that need to be copied; this is not an issue as they are managed automatically. For example if you back up transaction log every hour, you get 24 transaction log backup files in a day, instead if you back up log every 5 minutes, you have 288 transaction log backup files in a day.

Log Shipping Thresholds

Backup alert threshold: You can set a threshold for transaction log backup on primary production database server. When the transaction log backup lags behind this threshold you can have notification, like email. Usually this is set to 3 times higher than the backup schedule in the previous screen. Out of sync alert threshold: You can set a threshold for transaction log restore on secondary standby databases. When the transaction log is not restored by this threshold you can have notification. Usually this is set to 3 times higher than the backup schedule in the previous screen.

Log Shipping Monitor server

Choose the Log Shipping Monitor server. It is preferable to have a separate monitoring server, but if this is not possible you can choose either primary or secondary server as monitor server. We recommend a separate 3rd server as monitoring sever or to use secondary server.

Reports and history

In the next two screens you can choose to have reports and history saved. If you choose, use a different directory than the PrimaryTLogs directory, like a report directory so these file need not be archived along with the transaction log backup files. Also make sure you choose to delete older reports after certain number of weeks.

Saving the maintenance plan

In the next two screens, give a name for this Log Shipping maintenance plan and click finish.

Understanding the Log Shipping process

SQL Server Agent Jobs created by Log Shipping Wizard

There will be 6 jobs created by Log Shipping Wizard. 1. Transaction log backup job on primary: This job is created on the primary production database server to backup transaction log you can look at the jobs under SQL Server Agent jobs on the primary server.

2. Copying job: This job is created on the secondary standby database server to copy the transaction log backup files from primary production database server share to secondary standby database server transaction log directory. 3. Transaction log restore job: This job is created on the secondary standby database server to restore the transaction log backup files into the secondary standby database. 4. Backup Alert job: This job is created in the monitor server to generate alert when transaction log backup does not complete within the threshold. You can set up an operator to be notified if this job fails. 5. Restore Alert job: This job is created in the monitor server to generate alert when transaction log restore does not complete within the threshold. You can set up an operator to be notified if this job fails 6. Transaction log backup job on secondary: This job is created on the secondary standby database server to backup transaction log on the secondary standby database. This job is disabled; it will be automatically enabled when this secondary standby database is promoted to primary production database.

Read-Only secondary standby database

Once the Log Shipping is set up the secondary standby database will be marked ReadOnly. The status will change to normal when this secondary standby database is promoted to production database.

Monitoring the Log Shipping Processes

Log Shipping Monitor

Log Shipping Monitor will be located on the monitor server. Here you can have a look at the status of the Log Shipping. You double click on the Log Shipping entry to see detailed information on the activities, like when was the last transaction log backup, copy and transaction log restore. Here you can also change the alert schedule. To have more detailed information on job status, you can also have a look at the individual jobs and their history. If there is a failure, it will be flagged in this screen.

Files that are backed up and copied

Per schedule the transaction log is backed up on the primary production database server into the PrimaryTLogs directory.

Per schedule the above files are copied from the PrimaryTLogs directory into SecondaryTlogs directory.

Modifying the Log Shipping Plan

On the primary production database server

The Log Shipping plan is maintained on the primary production database server. You can modify the plan to change: 1. Transaction log backup schedule: Do not change the directory when the transaction log backups are kept without changing the network share as this will break the copy process. 2. Add new secondary 3. Modify existing secondary to change, directory and network share. To change from Standby to No Recovery mode. To modify the copy and load frequency. Also to change Out of Sync Threshold and Load Time Delay.

On the secondary standby database server

A Log Shipping Plan is also maintained on the secondary standby database server where the schedule for the transaction log backup is defined for the secondary standby database, which will take effect once this database is promoted to primary production database.

Modify the Log Shipping transaction log backup schedule

To avoid full backup overlapping the Log Shippings transaction log backup schedule, modify the Log Shipping transaction log backup schedule by editing the Log Shipping maintenance plan.

Planned promotion of secondary to primary In case of planned promotion of secondary standby database server to primary production database server there is no loss of committed data. This requires 5 to 10 minutes of downtime before the secondary is promoted to primary and operational again. The following Steps are needed. 1. Stop SAP. 2. Make sure the SID database is not in use by looking at the SQL Server Enterprise Manager, Management, Current Activity, Process Info here there should be no connection using the SID database, if yes, clear up the connection.

3. Execute the following statement using SQL Server Query Analyzer on the primary production database server execute the above command under the msdb database and not under the SID or master database. This statement will back up the transaction log on the primary production database server to include all changes and will change the primary production database status to (Loading). The statement will also disable the transaction log backup job in the primary production database server and remove the primary production database server from the Log Shipping process.

EXEC sp_change_primary_role @db_name = 'SID', @backup_log = 1, @terminate = 0, @final_state = 2, @access_level = 1 GO 4. Disable the SQL Server and SQL Server Agent service on the primary production database server.

5. Execute the following statement using SQL Server Query Analyzer on the secondary standby database server execute the above command under the msdb database and not under the SID or master database. This statement will copy the transaction log backup files from the primary production database server and apply it to the secondary standby database. This will change the status of the secondary standby database to primary production database and hence remove the Read-Only status and also enable the transaction log backup job on this new primary production database to the SecondaryTLogs directory. This will also delete the copy and restore job on the secondary standby database server. EXEC sp_change_secondary_role @db_name = 'SID', @do_load = 1, @force_load = 1, @final_state = 1, @access_level = 1, @terminate = 1, @stopat = NULL GO

6. Execute the following statement using SQL Server Query Analyzer on the monitor server execute the above command under the msdb database and not under the SID or master database. This statement will inform all other secondary that there is a new primary production database server and where to copy the transaction logs files from. Perform this step even if you have no other secondary servers. EXEC sp_change_monitor_role @primary_server = 'SAPSQLA', @secondary_server = 'SAPSQLB', @database = 'SID', @new_source = '\\Sapsqlb\SecondaryTLog' GO

7. Change SAP Profile parameter to point to the new primary production database server.

8. Instead of changing the SAP profile parameter in the above step, there is also a possibility to create a SQL Server Alias using the SQL Server Client Network Utility to point to the new primary production database server. In this case there is no need to adjust the profile parameter, but we recommend changing the profile parameter than using this SQL Server Alias method. Start the SQL Server Client Network Utility, choose Aliases tab, choose add, choose TCP/IP, enter New primary production database server name in the Server name tab and enter the old primary production database server name in the Server alias tab.

9. Start SAP 10. You will see in st04 the DB Server has changed also you will notice there is no more transaction log backup at the old primary production database server and now the transaction log backups occur in the new primary production database server.

11. In case you installed and now have a new Central Instance on this new primary production database server adjust the profile you copied from the old primary production database server and update the License Key from SAP.

Adding back the old primary production database server after maintenance Enable SQL Server and SQL Server Agent service on the old primary production database server. Delete the old transaction log backup files from the old primary production database server that are located in the PrimaryTLogs directory (you can also move them temporarily). The Log Shipping plan has been moved from the old primary production database server to the new primary production database server during promotion. You can see there is no more Log Shipping tab on the Log Shipping maintenance plan.

Edit the Log Shipping plan and add the old primary production database server as a secondary standby database server. Choose existing database as there is no need to restore the database. SQL Server will copy new transaction logs from the new primary production database server to old primary production database server and apply them and make the database new secondary standby database.

SQL Server Agent jobs, to copy and to restore, are created on the new secondary standby database server and the transaction log backup files are periodically copied and applied on the new secondary standby database server.

You can check the status of the Log Shipping in the Log Shipping monitor. Here you can see that the transaction logs are shipped from new primary production database server to the new secondary standby database server.

You can double click on the entry and check the backup, copy and restore logs.

Repeat the above step of promoting the new secondary standby database server to primary production database server and this will complete the planned promotion process.

Unplanned promotion of secondary to primary In this case you have a potential data loss, the transactions that are not copied from the primary production database server to secondary standby database server is lost. This is also a reason why you should think about backing up the transaction log and copying the files more often. The steps are the same as planned promotion of secondary to primary, except you cannot perform step number 1, 2, 3 and 4 as the primary is not available. After completing the rest of the steps, you will have promoted the secondary standby database to primary production database. When you bring the original primary production database server online, delete the old primary production database which is out of date since SAP is new using the new primary production database server. Restore the latest full backup of the new primary production database to the new secondary standby database server and choose the option Leave database non-operational but able to restore additional transaction logs. From the new primary production database server Log Shipping maintenance plan, add this as a secondary and follow the steps mentioned in adding back the old primary production database server after maintenance.

Adding an operator for notification You can add an operator to get notification when the transaction log backup at the primary production database server or transaction log restore at the secondary standby database server past the threshold. In the SQL Server Enterprise Manager, go to Management, SQL Server Agent, Operators and define an operator. Then add the operator to be notified when the Backup Alter or Restore Alert job fails. When the job fails the operator will get the notification. The job history will show that the operator was notified when the job failed.

Related Links Microsoft SQL Server at http://www.microsoft.com/sql