Hello, DBA Newbie here... I have a log shipping scenario setup between two SQL Server 2005 servers.

I would like to bring the secondary databases online, move connections to this server and take the primary offline, but I'm not quite sure how to do that. There are 12 databases that are all in Standby / Read-Only mode on the secondary server. Would the below be appropriate steps? 1) disconnect users from the primary so no new updates are made 2) log ship the final trn logs (jobs run every 15 minutes, but I could manually run the jobs to create, copy and restore) 3) bring secondary DBs out of Standby / Read-Only mode using the below on each of the 12 DBs: restore database DATABASENAME with recovery; 4) take off line the primary server's DBs Any other steps or SQL commands I'm missing? Thanks, Shawn Posted Tuesday, May 25, 2010 8:05 AM Hi, Yes; And make sure to transfer the logins and map them accordingly on the databases. Thank you Renuka__

Dear All, I have configure the Log shipping on my Two SQL Server 2005 Machine. Every Thing goes fine , All log file are transferring from Primary to secondary server , I have made some change in the Primary Server ie ( Creation of Table , Insert Some Value in that table ) Now i want to restore my Secondary Database. The Secondary database is showing in Restoring state , Please help me that how can i restore my secondary database..

Thank in Advance Basit Khan Jn DBA GLT Mumbai Hi, The changes you mentioned (Creation of Table , Insert Some Value in that table ) will be reflected through log shipping. Once you recover the database (from restoring mode), the logshipping is broken and it needs to re-configured again. If that is OK, apply the last transaction log backup file manually at the secondary server 'WITH RECOVERY' option. If the it is already applied, then issue the command RESTORE DATABASE 'DB NAME' with RECOVERY GO The database will be online. Make sure to check and the logins once the DB comes online. Thank you Renuka, Thanks for the reply. My conversion from the Primary to Secondary server went well this morning!! Shawn Dear Renuka... I have Restore the Secondry database with the Query as you have said . The Database restore succesfully ... but the change that i have made in the primary databse has not refecled.. As i have created a "Name" table in primary database all log of Primary database are copy to secondry DB. Now when i use select statement in Secondry DB it give a error : Msg 208, Level 16, State 1, Line 1 Invalid object name 'Name' Can you tell me why the change has not replicate in Secondry DBDear Renuka... I have Restore the Secondry database with the Query as you have said . The

Database restore succesfully ... but the change that i have made in the primary databse has not refecled.. As i have created a "Name" table in primary database all log of Primary database are copy to secondry DB. Now when i use select statement in Secondry DB it give a error : Msg 208, Level 16, State 1, Line 1 Invalid object name 'Name' Can you tell me why the change has not replicate in Secondry DB Thanks Reunka , For your Kind Help... Basit. Now there is no logshipping between pri & sec. U have to reconfigure it. @Basit - There are all possibility that the jobs failed or log sequence was broken.Assuming that you have already stopped the log shipping what ideally you should do is take a differential followed with log backup with norecovery...and once that is done restore it on the secondary ...it should bring your secondary in line with prod and then you can complete the swing activity... In general you should follow the following steps for effective logshipping swing. 1. Ensure all scheduled backups have completed successfully 2. STOP/DISABLE LOG SHIPPING BACKUP JOBS 3. RUN (LOG SHIPPING) TRAN LOG COPY AND RESTORE JOBS ON Secondary until the last log is applied then DISABLE all copy & restore jobs. 4. REMOVE THE LOG-SHIPPING FROM PRIMARY SERVERS MAINTENANCE PLANS for the required Db's i. Go to maintenance jobs folder ON Primary ii. delete destination server information from inside the maintenance job for each DB. iii. remove logshipping & delete maintenance job 5. Kill all users IN Required database on primary server 6. BACKUP LAST TRAN LOG On Primary Server and place them is easy accessible folder Eg.(\\Primary Server Name\C$\MSSQL\Backup\FTRN) eg. BACKUP LOG Check21DB TO DISK = 'C:\MSSQL\BACKUP\FTRN\' WITH norecovery

7. COPY LAST LOGS TO Secondary Server to say FTRN folder (\\Secondary Server \C$\MSSQL\Backup\FTRN) E.g xp_cmdshell 'copy \\PriamryServer \C$\MSSQL\BACKUP\FTRN\*.trn \\SecondaryServer\C$\MSSQL\Backup\FTRN' 8. RESTORE the above LAST LOGs for each database ON Secondary with recovery RESTORE LOG DBNAME FROM DISK = '\\SecondaryServer\C$\MSSQL\Backup\FTRN\xxx.trn' WITH RECOVERY and once all the logs have been applied you can make setup Log shipping on Secondary.[/font] ~RD

http://blogcastrepository.com/blogs/noel-davies_uk_ltd/pages/SQL-LogShipping.aspx All about SQL Server Log Shipping Log shipping is one of the failover solutions offered by SQL Server 2000. In this context, failover means substituting primary server with a backup (sometimes also referred to as standby) server if the primary hardware becomes unusable. Failover solutions can also be used to provide close to 100% uptimeduring primary database or server maintenance and during software upgrades you could use the standby server to continue serving your customers. Failover solutions can be automatic or manual. With automatic failover, the backup server detects when the primary server is not available and takes over without any intervention from the database administrator. An example of an automatic failover solution is clustering. With manual failover, the database administrator (DBA) has to perform some steps to bring the standby server online. In SQL Server 2000, log shipping is a form of manual failover. NOTE Only Enterprise and Developer editions of SQL Server support log shipping.

How It Works
Log shipping implementation is straightforward: 1. Full backup of the database is taken on the primary server and copied to the standby server. 2. Standby server maintains a copy of the database. 3. The database is not operational; it can stay in either read-only mode or norecovery mode. 4. Transaction log for the "log-shipped" database is backed up on the primary server periodically. Note that only databases that are in FULL recovery mode can be logshipped. Transaction log backups are placed on a shared drive; standby server's SQL Server Agent account must have access to this shared drive. 5. Transaction log backups are copied to the standby server. 6. Transaction log backups are applied to the database on the standby server in the order that they were taken on the primary server. 7. Either primary server, standby server, or a separate server can be used to monitor log shipping. If you use a separate server for monitoring, it does NOT have to have Enterprise Edition of SQL Server; any edition (other than MSDE) will do. If the primary server becomes unavailable due to disk failure or some other reason, DBA can take the following steps to fail the database over to the standby server: 1. Perform one last backup of the transaction log on the primary server (if possible). 2. Copy all transaction log backups to the standby server and apply them in the same order they were taken on the primary server. The last transaction log backup should be restored by using the WITH RECOVERY clause so that the standby database becomes operational. 3. Transfer any logins that exist on the primary server to the standby server. Only the logins that must have access to the log-shipped database must be transferred. This step might be further complicated if logins with the same name exist on both servers. In such cases, the DBA needs to ensure that appropriate mappings exist between SQL Server logins and database users on the standby server. During the initial configuration of log shipping, you can allow the standby database to assume the primary role. That means you can ship transaction logs from the standby server to the primary server after you have failed the primary database over. So if primary server (server A) fails over to standby server (server B), servers can switch roles so that you can fail server B back to server A if needed.

Advantages of Log Shipping

Although log shipping requires the DBA's help to work, it does offer some advantages over other forms of failover: 1. Easy setup. Log shipping can be configured by using the Database Maintenance Plan Wizard. With a few mouse clicks and some careful planning, you can have a dependable failover solution. 2. Standby databases can be available for read-only queries. In some environments, standby servers are used for reporting. Note, however, that a logshipped database will NOT be available while transaction logs are applied to it. Therefore, if you take transaction log backups every hour, and if applying the backup to the standby server takes 10 minutes, the log-shipped database will be available for queries only 50 minutes out of every hour. 3. Low maintenance. Log shipping usually works well; if one of the steps fails SQL Server picks up exactly where it left off and very little troubleshooting is required. 4. Multiple standby servers can be configured. You can ship the transaction logs from the primary server to multiple standby servers. This way, you further reduce the chances of downtime. In addition, each standby server can be used for a different purposeone server can be used for reporting and another one for providing high availability.

Disadvantages of Log Shipping

Unfortunately, log shipping does have a few issues that the DBA should be aware of prior to relying on this method of failover: 1. Possible data loss when the primary server fails. If the primary server becomes completely unusable, transactions that occurred after the last transaction log backup that was copied to the standby server are lost. For example, suppose that server A fails at 5 a.m. and you cannot get to it at all. If the last backup copied to server B was taken at 4:45 a.m., all transactions that occurred between 4:45 a.m. and 5 a.m. are lost forever. 2. Some manual DBA work is required to bring the standby server online, as discussed in this article. 3. Log shipping setup cannot be scripted. This means that you cannot mimic the production environment for testing purposes without going through the wizard screens. 4. The Enterprise edition of SQL Server 2000 is required on primary and standby servers. If you run any other version/edition of SQL Server, you're out of luck. The Developer edition can be used to learn how to set up log shipping, but it cannot be used in a production environment. Note however, that log shipping is

merely an automated way of copying transaction log backups, so a savvy DBA can easily set up jobs to accomplish the same functionality. 5. Difficult troubleshooting. Log shipping usually works very well, but if there are problems, they're difficult to troubleshootdocumentation is sparse and typically not helpful for solving a particular problem. Fortunately Microsoft's Knowledge Base articles have good information for troubleshooting log-shipping issues. 6. Each database that needs to be log-shipped must be set up through a separate maintenance plan.

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. Figure 1 --> 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. Figure 2 --> 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 logshipped 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. Figure 3 --> Once you specify the share name and click Next, you see the following screen, which lets you define the destination (standby) server and database. Figure 4 --> 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. Figure 5 --> 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. Figure 7 --> 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. Figure 8 --> 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 logshipping 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. Figure 9 --> Now, if you examine the log-shipping destination server (Standby), you'll see the readonly database Northwind1, as shown in the following figure. Figurte 10 -->

Failover
Suppose that our primary database became unavailable because of a disk failure at 3:31 p.m. and we needed to fail over to the standby server. The last transaction log backup of the primary database was taken at 3:30 p.m. Let's presume that no further transaction log backups can be taken on the primary serverthat means that transactions that occurred from 3:30 p.m. to 3:31 p.m. are lost forever.

The last backup that was applied to the standby server was the backup of 3:15 p.m. We can copy the backup from 3:30 p.m. to the standby server and execute the following command from the Query Analyzer:
RESTORE LOG northwind1 FROM DISK = 'c:\Program Files\Microsoft SQL Server\MSSQL$Subscription_srv\Log\Northwind_tlog_200407111530.TRN' WITH RECOVERY

Notice that transaction log backups have the naming convention 'database_name_tlog_Year_Month_Day_Hour_Minute'. Also note that the time when backup was taken is tracked by using a 24-hour clock, so you can differentiate backups taken during a.m. or p.m. hours. The most important piece of the statement above is the WITH RECOVERY clause. This clause makes the database operational; after the database is recovered, you can no longer apply additional transaction log backups to itthe database is accessible by all users. Now, suppose that we could take one final backup of the transaction log on the primary server at 3:31 p.m. If that were the case, no transactions would be lost; we would restore the backup from 3:30 p.m. by using the NO RECOVERY clause and restore the backup from 3:31 p.m. by using the WITH RECOVERY clause. All logins that need to have access to the database must exist on the standby server. If you have a handful of logins in your database, I recommend simply adding them to the standby server manually. If you have dozens of logins, you might wish to use the transfer logins task within Data Transformation Services (DTS). That's all there is to fail over to the standby server as far as SQL Server is concerned. Next, you must configure your data sources to point to the backup server instead of primary server to make sure that your application(s) works. NOTE Important Reminder: If you have the same login on two servers, they're not guaranteed to have the same security identifier (SID). The SID is stored in the sysxlogins system table in master database and is assigned automatically by SQL Server. Within each database SQL Server, logins are mapped to the database userssuch mappings are recorded in the sysusers system table that exists in every database. When you fail log-shipped databases over to the standby server, you need to ensure that appropriate mappings exist for every login that needs access to the database you failed over. You can accomplish this manually by updating the SID of the sysusers table and making it the same as SID in sysxlogins. Better way to perform the same task is to use the system stored procedure sp_change_users_login. I don't have room to discuss the details of this procedure in this introductory article; however, you can find details in SQL Server online documentation.