How to Perform SQL Server Log Shipping

The Need for Standby Servers In a perfect world we wouldn't need standby servers for our SQL Servers. Our hardware would never fail, NT Server 4. or !indows " would never blue screen, SQL Server would never stop runnin#, and our applications would never bal$. In a partially perfect wor$, we could afford very e%pensive clustered SQL Servers that auto&atically failover our wounded and dead production SQL Servers, reducin# our stress and $eepin# our users very happy. 'ut for &ost of us, the closest thin# we can afford to i&ple&ent when it co&es to SQL Server failover are standby servers that we have to &anually fail over. (nd even so&e of us can't afford this. 'ut for this article, I a& #oin# to assu&e that you can afford a standby server. The concept of standby servers is not a new one. It has been around a lon# ti&e and been used by &any )'(s. Traditionally, usin# a standby server for failover has involved &anually &a$in# database and lo# bac$ups on the production server and then restorin# the& to the standby server on a re#ular basis. This way, should the production server fail, then users could access the standby server instead, and downti&e and data loss would be &ini&i*ed. This article is about lo# shippin#, a refined variation of the traditional &anual standby failover server process. Its two &a+or benefits over the traditional &ethods is that it auto&ates &ost of the &anual wor$ and helps to reduce potential data loss even &ore. What is Log Shipping ,ssentially, lo# shippin# is the process of auto&atin# the bac$up of database and transaction lo# files on a production SQL server, and then restorin# the& onto a standby server. 'ut this is not all. The $ey feature of lo# shippin# is that is will auto&atically bac$up transaction lo#s throu#hout the day -for whatever interval you specify. and auto&atically restore the& on the standby server. This in effect $eeps the two SQL Servers in /synch/. Should the production server fail, all you have to do is point the users to the new server, and you are all set. !ell, its not really that easy, but it co&es close if you put enou#h effort into your lo# shippin# setup.

Benefits of Log Shipping

!hile I have already tal$ed about so&e of the benefits of lo# shippin#, let's ta$e a &ore co&prehensive loo$0 Lo# shippin# doesn't re1uire e%pensive hardware or software. !hile it is #reat if your standby server is si&ilar in capacity to your production server, it is not a re1uire&ent. In addition, you can use the standby server for other tas$s, helpin# to +ustify

the cost of the standby server. 2ust $eep in &ind that if you do need to fail over, that this server will have to handle not one, but two loads. I li$e to &a$e &y standby server a develop&ent server. This way, I $eep &y developers off the production server, but don't put too &uch wor$ load on the standby server. Once lo# shippin# has been i&ple&ented, it is relatively easy to &aintain. (ssu&in# you have i&ple&ented lo# shippin# correctly, it is very reliable. The &anual failover process is #enerally very short, typically 34 &inutes or less. )ependin# on how you have desi#ned your lo# shippin# process, very little, if any, data is lost should you have to failover. The a&ount of data loss, if any, is also dependent on why your production server failed. I&ple&entin# lo# shippin# is not technically difficult. (l&ost any )'( with several &onths or &ore of SQL Server 5 e%perience can successfully i&ple&ent it.

Problems with Log Shipping

Let's face it, lo# shippin# is a co&pro&ise. It is not the ideal solution, but it is often a practical solution #iven real6world bud#et constraints. So&e of the proble&s with lo# shippin# include0 Lo# shippin# failover is not auto&atic. The )'( &ust still &anually failover the server, which &eans the )'( &ust be present when the failover occurs. The users will e%perience so&e downti&e. 7ow lon# depends on how well you i&ple&ented lo# shippin#, the nature of the production server failure, your networ$, the standby server, and the application or applications to be failed over. So&e data can be lost, althou#h not always. 7ow &uch data is lost depends on how often you schedule lo# shippin# and whether or not the transaction lo# on the failed production server is recoverable. The database or databases that are bein# failed over to the standby server cannot be used for anythin# else. 'ut databases on the standby server not bein# used for failover can still be used nor&ally. !hen it co&es ti&e for the actual failover, you &ust do one of two thin#s to &a$e your applications wor$0 either rena&e the standby server the sa&e na&e as the failed production server -and the I8 address., or re6point your user's applications to the new standby server. In so&e cases, neither of these options is practical.

Log Shipping Overview

'efore we #et into the details of how to i&ple&ent lo# shippin#, let's ta$e a loo$ at the bi# picture. ,ssentially, here's what you need to do in order to i&ple&ent lo# shippin#0 ,nsure you have the necessary hardware and software properly prepared to i&ple&ent lo# shippin#. Synchroni*e the SQL lo#in I)s between the production and standby servers. 9reate two bac$up devices. One will be used for your database bac$ups and the other will be used for your transaction lo# bac$ups. On the production server, create a lin$ed server to your standby server. On the standby servers, create two stored procedures. One stored procedure will be used to restore the database. The other stored procedure will be used to restore transaction lo#s. On the production server, create two SQL Server +obs that will be used to perfor& the database and transaction lo# bac$ups. ,ach +ob will include &ultiple steps with scripts that will perfor& the bac$ups, copy the files fro& the production server to the standby server, and fire the re&ote stored procedures used to restore the database and lo# files. Start and test the lo# shippin# process. )evise and test the failover process. :onitor the lo# shippin# process.

Obviously I have left out a lot of details, but at least now you $now where we are headed. To &a$e &y e%planations easier to understand in this article, all &y e%a&ples assu&e you will be failin# over only one database fro& the production server to the standby server. In the real world you will probably want to failover &ore than +ust one. Once you have i&ple&ented lo# shippin# for one database, it should be obvious how to i&ple&ent others. ;enerally, I +ust add additional databases to &y already e%istin# scripts and +obs. 'ut if you prefer, you can create separate scripts and +obs for each database you want to failover usin# lo# shippin#. (s you read the details of how I i&ple&ent lo# shippin# below, you &ay thin$ of other ways to acco&plish the sa&e steps. If so, then #reat. I a& sure there are &any different ways to i&ple&ent lo# shippin#, so&e of which are probably an i&prove&ent over &ine. So feel free to i&prove upon &y &ethods.

Hardware and Software Requirements The hardware and software re1uire&ents for lo# shippin# are not difficult. The hardware for the production and the standby server should be as si&ilar as you can afford. If your production server only handles a couple of do*en si&ultaneous users, then you probably don't need to spend a s&all fortune on &a$in# the standby server +ust li$e the production server. On the other hand, if your production server handles 4 si&ultaneous users, or has &ulti6#i#abyte database, then you &ay want to &a$e your standby server as si&ilar to the production server as you can afford. (s far as software is concerned, I +ust try to ensure than I have NT Server and SQL Server at the sa&e level of service pac$s. In addition, the two servers &ust have SQL Server 5 confi#ured si&ilarly. <or e%a&ple, the code pa#e=character set, sort order, >nicode collation, and the local all &ust be the sa&e on both server.

In order to help reduce any potential data loss durin# server failover fro& the production server to the standby server, your production server should have its transaction lo#s stored on a separate physical drive array than the database files. !hile this will boost your server's perfor&ance, the &ain reason for this is to help reduce data loss. <or e%a&ple, if the drive array with your database files on it #oes down, then hopefully the drive array with the lo# files will be O?. If this is the case, then you should be able to recover the transaction lo# and &ove it to the standby server, si#nificantly reducin# any data loss. 'ut if the transaction lo#s are on the sa&e drive array as the database files, and the drive array fails, then you have lost any data entered into the syste& since the last lo# file was shipped to the standby server.

Synchronize SQL Server Login IDs

(t this point, we are #oin# to #et into the details of how to actually set up lo# shippin#. So #et ready to be hit by lots of obscure details. The first step before you can be#in lo# shippin# is to ensure that the SQL Server lo#in I)s are synchroni*ed between the production and standby servers. This is i&portant because SQL Server &aintains separate security a&on# servers, and you will be &a$in# a bac$up of a database on one server and restorin# it to another. In order for the database user I)s -found in each database. to wor$ on the standby server -where the database is restored., there &ust be a &atchin# SQL Server lo#in I) on that server, otherwise users will not be able to lo# into the database on the standby server. There are several ways to do this0

:anually synchroni*e SQL Server lo#in I)s between the two servers. !hile effective, rather borin#. Script the lo#in I)s fro& the production server and then run the script on the standby server to create the lo#in I)s. @ou will have to do this periodically as users are added and deleted. !hile scriptin# wor$s #reat for SQL Server lo#in I)s that use NT (uthentication, it doesn't wor$ so well for lo#in I)s that use SQL Server (uthentication. This is because if you have lo#in I)s usin# SQL Server (uthentication, you will have to $now the user's passwords in order to set the&, or fi#ure out so&e way to #et users to set the passwords the&selves. Lo#in I)s that use NT (uthentication are no proble& because passwords aren't used. 'ac$up the :aster database on the production server and restore it onto the standby server +ust before you be#in the lo# shippin# process. (nd should you ever have to failover your server, you will then have to restore the :aster database a#ain in order to $eep your user accounts in synch.

The option you choose will depend on how the standby server is used. 'ut if you will be usin# the standby server for other databases, such as for develop&ent databases, you won't be able to usin# lo# shippin# on the :aster database. Instead, you will have to use scripts, or &anually $eep the two servers synchroni*ed. (s I have already &entioned, if you have to do this, then you will want to use only lo#in I)s that use NT (uthentication, not SQL Server (uthentication, because of the password's issue. (nother proble& with lo#in I)s usin# SQL Server (uthentication is the fact that when you restore a database to another SQL Server, you &ust synchroni*e the lo#in I)s on the server with the database user I)s in the database. This is not a proble& with user I)s that user NT (uthentication. To synchroni*e the lo#ins I)s and the database users I)s, you &ust run the spAchan#eAusersAlo#in stored procedure. If you want to &a$e lo# shippin# easy, then don't use the standby server for anythin# other than failover, and always use NT (uthentication for your lo#in I)s. !hile you don't have to do either, your life will +ust be a little &ore stress6free. Once you have fi#ured out a way to synchroni*e the SQL Server lo#in I)s, you are ready to be#in the ne%t step.

Create o!r Bac"!p Devices

This step is an easy one. On the production server you will want to create two bac$up devices. One will be used to store the database bac$up, and the other one will be used to store the transaction lo# bac$ups for the database. To $eep thin#s si&ple, I na&e the database bac$up device after the na&e of the

database, so&ethin# li$e, /databaseAna&eAbac$upAdevice/, and I na&e the transaction lo# bac$up device so&ethin# li$e, /databaseAna&eAlo#Abac$upAdevice/. Sure these na&es are a little wordy, but they are self6docu&entin#. 9hoose whatever na&es &a$e the &ost sense for you.

Create a Lin"e# Server

7ere's a step that &ay confuse so&e of you, especially if you have not used lin$ed servers before. ( lin$ed server allows a stored procedure on one server to be called by a script or stored procedure on another server, a&on# other thin#s. !hat you need to do is to create a lin$ed server between your production server and your standby server, so that a script runnin# on the production server can call a stored procedure on the standby server. The reason you need to create a lin$ed server is because we will need to call two different stored procedures on the standby server fro& the production server. These two stored procedures are used to restore either the database or the transaction lo#s auto&atically -&ore infor&ation in the ne%t section.. It is i&portant when you create the lin$ed server that you assi#n the proper level of security. 'elow are two screens showin# how I have set up &y lin$ed servers usin# ,nterprise :ana#er.

Once you have created your lin$ed server, you are ready to create the stored procedures on the standby server that will be called fro& the production server.

Create Store# Proce#!res to $estore o!r Data

The ne%t step is to create two stored procedures on the standby server. One will be used to auto&atically restore the database, and the other one will be used to auto&atically restore the transaction lo#s. @ou can #ive the& any na&es you li$e, but I have been usin# these two na&es for obvious reasons0 restoreAdatabaseAbac$ups restoreAlo#Abac$ups

Of course, you can use any na&es you prefer. @ou will need to create these two stored procedures in a database that will never be overwritten. @ou can also create the stored procedures in a database you created +ust for this purpose. It doesn't &atter as lon# as you won't be overwritin# the&.

Stored Procedure to Restore Database

ac!ups

7ere's the script I use for creatin# the /restoreAdatabaseAbac$ups/ stored procedure0 CREATE PROCEDURE restore_database_backups AS RESTORE DATABASE database_name FROM DISK !"#$mss%&'$backup$database_name$database_name_backup_de()ce*bak! +IT, DBO_O-./0 REP.ACE0 STA-DB/ !"#$mss%&'$backup$database_name$undo_database_name*&d1!0 MO2E !&o")ca&_name! TO !3#$mss%&'$data$database_name*md1!0 MO2E !&o")ca&_name! TO !1#$mss%&'$&o"$database_name_&o"*&d1! +AITFOR DE.A/ !44#44#45! E6EC sp_dbopt)on !database_name!0 !s)n"&e user!0 true !here /databaseAna&e/ refers to the na&e of the database bein# restored and where /lo#icalAna&e/ refers to the lo#ical na&e of the database and lo# files, respectively. Now let's discuss this script one line at a ti&e. The /9B,(T, 8BO9,)>B,/ line should be self6e%planatory for anyone who has ever created a stored procedure. The /B,STOB, )(T('(S,/ line is the co&&and to restore a database. The /<BO: )IS?/ line is used to tell the /B,STOB, )(T('(S,/ co&&and where to find the database bac$up device. @ou will of course have to specify a path that is appropriate for your server, alon# with the appropriate bac$up device na&e. The /!IT7/ line is used to let us $now there are so&e options co&in# up. The /)'OAONL@/ option is optional and sets the database to /)'O >S, ONL@/ after it is restored. I have included it to help $eep out people who should not be in this database once it is restored. The /B,8L(9,/ option tells the /B,STOB, )(T('(S,/ co&&and to replace any pre6 e%istin# database with the sa&e na&e. This is re1uired to prevent errors when restorin# the database over an older version of the database. The /ST(N)'@/ line tells the /B,STOB, )(T('(S,/ co&&and not to rollbac$ any unco&&itted transactions and to allow read6only access to the database. This option re1uires you to specify a file, such as, /undoAdatabaseAna&e.ldf/ to be used to

/undo/ any transactions. Locate this file in an appropriate path. The /:OC,/ lines tells the /B,STOB, )(T('(S,/ co&&and that the physical files that &a$e up the database will be in a different location on the standby server than they were on the production server. @ou &ust specify the path to the physical na&es of the database and lo# files on the standby server. The /!(IT<OB/ line causes the script to pause for 4 seconds before it e%ecutes the ne%t line of code. I have added it here because I found that if you don't, that the previous /B,STOB, )(T('(S,/ co&&and &ay not be 3 D co&plete before the followin# co&&and e%ecutes. If it isn't, an error &essa#e occurs. The /,E,9/ line is used to put the restored database in /SIN;L, >S,B :O),/. ,ach ti&e you restore a database, the /B,STOB, )(T('(S,/ co&&and ta$es the database out of /SIN;L, >S,B :O),/. If you don't set this now, when it co&es ti&e to restore a#ain usin# this stored procedure, you &ay #et an error &essa#e if there are any user connections to the database when the stored procedure runs. !hile this shouldn't nor&ally happen, I have seen it happen, and this line of code prevents the stored procedure fro& failin#. Stored Procedure to Restore Log ac!ups

!ow, that was a lot, but here's &ore. 7ere's the script for creatin# the restoreAlo#Abac$ups stored procedure. Notice how si&ilar it is to the restoreAdatabaseAbac$ups stored procedure.

CREATE PROCEDURE restore_&o"_backups AS RESTORE .O7 database_name FROM DISK !"#$mss%&'$backup$&o"$database_name$database_name_&o"_backup_de()ce*bak! +IT, DBO_O-./0 STA-DB/ !"#$mss%&'$backup$&o"$database_name$undo_database_name*&d1! +AITFOR DE.A/ !44#44#45! E6EC sp_dbopt)on !database_name!0 !s)n"&e user!0 true !here /databaseAna&e/ refers to the na&e of the database bein# restored. Now let's discuss this script one line at a ti&e. The /9B,(T, 8BO9,)>B,/ line should be self6e%planatory. The /B,STOB, LO;/ line is the co&&and to restore a transaction lo#.

The /<BO: )IS?/ line is used to tell the /B,STOB, LO;/ co&&and where to find the transaction lo# bac$up device. @ou will of course have to specify a path that is appropriate for your server, alon# with the appropriate bac$up device na&e. The /!IT7/ line is used to let us $now there are so&e options co&in# up. The /)'OAONL@/ option is optional and sets the database to /)'O >S, ONL@/ after the transaction lo# has been restored. I have included it to help $eep out people who should not be in this database once it is restored. The /ST(N)'@/ line tells the /B,STOB, LO;/ co&&and not to rollbac$ any unco&&itted transactions and to allow read6only access to the database. This option re1uires you to specify a file, such as, /undoAdatabaseAna&e.ldf/ to be used to /undo/ any transactions. Locate this file in an appropriate path. The /!(IT<OB/ line causes the script to pause for 4 seconds before it e%ecutes the ne%t line of code. I have added it here because I found that if you don't, that the previous /B,STOB, LO;/ co&&and &ay not be 3 D co&plete before the followin# co&&and e%ecutes. If it doesn't, an error &essa#e occurs. The /,E,9/ line is used to put the restored database in the /SIN;L, >S,B :O),/. ,ach ti&e you restore a transaction lo#, the /B,STOB, LO;/ co&&and ta$es the database out of /SIN;L, >S,B :O),/. If you don't set this now, when it co&es ti&e to restore a#ain usin# this stored procedure to restore a transaction lo#, you &ay #et an error &essa#e if there are any user connections to the database. !hile this shouldn't nor&ally happen, I have seen it happen, and this line of code prevents this stored procedure fro& failin#. ,nou#h already. (t least this is enou#h of these two stored procedures. >nfortunately, the detail #ets worse before it #ets better. Ne%t, you will learn how to create two SQL Server +obs that perfor& the database and transaction lo# bac$ups. "reate the ac!up #obs Now that we have learned how to restore our databases and transaction lo#s, its about ti&e we learn how to bac$ the& up, &ove the& fro& the production server to the standby server, and then fire a re&ote stored procedure on the standby server to perfor& the necessary restore. This is acco&plished usin# two &ulti6step SQL Server +obs. One +ob, as you &i#ht e%pect, if for bac$in# up the database, and the second +ob is for bac$in# up the transaction lo#s. The Database ac!up #ob

Let's be#in our loo$ at these +obs with the +ob used to bac$up the database on the production server, &ove it to the standby server, and then fire the stored procedure on the standby server to perfor& the database restore. It consists of the four steps outlined in this table0

Step %D 3 " G

Step Name Truncate Lo# 'ac$up )atabase 9opy 'ac$up

Step Type T6SQL Script T6SQL Script Operatin# Syste& 9o&&and T6SQL Script

&n Success ;oto Ne%t Step ;oto Ne%t Step ;oto Ne%t Step

&n 'ai(ure ;oto Ne%t Step Quit !ith <ailure Quit !ith <ailure

Bestore )atabase

Quit !ith Success

Quit !ith <ailure

Let's first tal$ about each step in #eneral, then we will discuss each one in depth. Step 3 is to truncate the transaction lo#. !hy do we want to do thisF The reason for this is that when we perfor& the transaction lo# bac$ups -to be discussed in detail later., we won't at that ti&e truncate the lo#. Instead, we will do it here. If we don't do it here, and we don't truncate the lo# when we bac$ up the lo#, then it will #row forever. ,ven if this step of the +ob should fail, we still want to bac$up the database. That's why I specify /;oto Ne%t Step/ if this step should fail. Step " is to bac$up the database onto its bac$up device. Note that if this step in the +ob fails that we /Quit !ith <ailure/. No point in copyin# a failed bac$up. Step G is copy the bac$up device fro& the production server to the standby server usin# the E9O8@ co&&and.

Step 4 fires the stored procedure on the standby server that is used to restore the database on the standby server.

Now that we have a loo$ at the bi# picture, lets let at the script behind each of these steps. Step $ Script BACKUP .O7 database_name +IT, TRU-CATE_O-./ +AITFOR DE.A/ !44#44#45! !here databaseAna&e is the na&e of your database. The /'(9?>8 LO;/ line is used to truncate the transaction lo# of the database. The /!(IT<OB/ line is used to #ive the previous step ti&e to co&plete before the ne%t step in the +ob e%ecutes.

Bun this script fro& the :aster database.

Step ) Script BACKUP DATABASE database_name TO database_name_backup_de()ce +IT, I-IT +AITFOR DE.A/ !44#44#45! !here databaseAna&e is the na&e of your database, and databaseAna&eAbac$upAdevice is the na&e of the bac$up device used for the database bac$up. The /'(9?>8 )(T('(S,/ does a full bac$up of the database to the na&ed bac$up device. The /!IT7 INIT/ option is used to delete any previous database bac$ups fro& the bac$up device before the bac$up is &ade. The /!(IT<OB/ line is used to #ive the previous step ti&e to co&plete before the ne%t step in the +ob e%ecutes. Bun this script fro& the :aster database.

Step * Script 8cop9 "#$mss%&'$backup$backup_de()ce_name*bak $$standb9_ser(er_name$":$mss%&'$backup$ ;c <or this operatin# syste& co&&and to wor$, the account used to run this +ob &ust have local ad&inistrative ri#hts on both the production and standby servers. @ou will of course have to substitute your paths and file na&es. The /#H/ refers to the local ad&inistrative share on the standby server where the bac$up device is to be copied. The /=c/ option tells the co&&and to continue copyin# even if an error of any $ind occurs. Step + Script E6EC standb9_ser(er_name*master*dbo*restore_database_backups This sin#le line is used to fire the restoreAdatabaseAbac$ups stored procedure on the standby server. Note that I have used a fully 1ualified ob+ect na&e for the stored procedure. @ou will want to do the sa&e.

Bun this script fro& the :aster database. Schedu(ing the Database ac!up #ob

Once this &ulti6step +ob is created, the ne%t step is to schedule it. It is i&portant that this +ob only be scheduled to run once a day. If it does not, it will #et out of synch with the transaction lo# bac$ups, discussed in the ne%t section. Select a ti&e to run it when it will produce the least affect on your users. The Transaction Log ac!up #ob

Now its ti&e to loo$ at the second +ob, the +ob used to bac$up the transaction lo#, &ove the lo# bac$up to the standby server, and then fire the stored procedure used to restore the transaction lo#. It consists of the three steps outlined in this table0
Step %D 3 " G Step Name 'ac$up Lo# 9opy Lo# Bestore Lo# Step Type T6SQL Script Operatin# Syste& 9o&&and T6SQL Script &n Success ;oto Ne%t Step ;oto Ne%t Step Quit !ith Success &n 'ai(ure Quit !ith <ailure Quit !ith <ailure Quit !ith <ailure

Let's first tal$ about each step in #eneral, then we will discuss each one in depth. Step 3 is to bac$ up the transaction lo# onto its bac$up device. Note that if this step fails that we /Quit !ith <ailure/. No point in copyin# a failed bac$up. Step " is copy the bac$up device fro& the production server to the standby server usin# the E9O8@ co&&and. Step G fires the stored procedure on the standby server that is used to restore the transaction lo# on the standby server. Now that we have a loo$ at the bi# picture, lets let at the script behind each of these steps. Step $ Script BACKUP .O7 database_name TO &o"_backup_de()ce +IT, I-IT0 -O_TRU-CATE +AITFOR DE.A/ !44#44#45! !here databaseAna&e is the na&e of your database, and lo#Abac$upAdevice is the na&e of the bac$up device used for the lo# bac$up.

The /'(9?>8 LO;/ co&&and does a transaction lo# bac$up of the database to the na&ed bac$up device. The /!IT7 INIT/ option is used to delete any previous database bac$ups fro& the bac$up device before the bac$up is &ade. The /NOATB>N9(T,/ option is used to tell the /'(9?>8 LO;/ co&&and not to truncate the lo#, which is the default behavior of this co&&and. !e don't want to truncate the lo# each ti&e we do a transaction lo# bac$up because we &i#ht need it for so&e other reason later. The /!(IT<OB/ line is used to #ive the previous ti&e to co&plete before the ne%t step in the +ob e%ecutes. Bun this script fro& the :aster database. Step ) Script 8cop9 "#$mss%&'$backup$backup_de()ce_name*bak $$standb9_ser(er_name$":$mss%&'$backup$ ;c <or this operatin# syste& co&&and to wor$, the account used to run this +ob &ust have local ad&inistrative ri#hts on both the production and standby servers. @ou will of course have to substitute your paths and file na&es. The /#H/ refers to the local ad&inistrative share on the standby server where the bac$up device is to be copied. The /=c/ option tells the co&&and to continue copyin# even if an error of any $ind occurs.

Step * Script E6EC standb9_ser(er_name*master*dbo*restore_&o"_backups This sin#le line is used to fire the restoreAlo#Abac$ups stored procedure on the standby server. Note that I have used a fully 1ualified ob+ect na&e for the stored procedure. @ou will want to do the sa&e. Bun this script fro& the :aster database. Schedu(ing the Log ac!up #ob

Once this &ulti6step +ob is created, the ne%t step is to schedule it. Schedulin# this +ob is &ore co&plicated that schedulin# the database bac$up +ob. There are two $ey decisions you will have to &a$e. <irst, you &ust decide how often you want to do a lo# bac$up. ;enerally, the &ore often, the better, as less data is sub+ect to loss. I #enerally perfor& a lo# bac$up every 34 &inutes. (nother way of sayin# this is that I a& doin# lo# shippin# every 34 &inutes. The second aspect of schedulin# is to prevent your scheduled lo# bac$ups fro& interferin# with your database bac$ups. If they #et out of sync with each other, the transaction lo# restores will fail, and you won't have a current bac$up of your database on your standby server. To prevent any potential conflict, what I do is

schedule the lo# bac$up +ob to stop 34 &inutes before the database bac$up be#ins, and then to restart 34 &inutes after the database bac$up is run. This way, there should be no schedulin# conflicts. Test, Test, and Test Some -ore !e are al&ost done. !hile all the steps are now in place, the last step is to test everythin# over a period of several days to be sure the +obs and stored procedures wor$ properly. Since each +ob $eeps its own success and failure history, it is not to hard to debu# any +ob6related proble&s you run across. 'efore you add lo# shippin# to your production server, I su##est you set it up and test it first on two non6production SQL Servers if you can. This will prevent any of your learnin# &ista$es to brin# down your production server. )on't thin$ that a successful lo# shippin# solution eli&inates the need for storin# bac$ups to tape. 'esides everythin# I have described in this article, I still bac$ up all of &y database and lo# dis$ bac$ups to tape on a daily basis. There is no such thin# as havin# too &any bac$ups. -onitor .verything Once you have your lo# shippin# process in place, be sure to &onitor it for success. 'e sure to set up +ob notifications so that you are notified by e6&ail or pa#er if either of your two lo# shippin# +obs fail.

How to %ailover to the Stan#by Server

Once lo# shippin# is successfully i&ple&ented, you will want to create your own scripts to i&ple&ent an actual failover to the standby server, and then you will want to test your process to see that it wor$s successfully. Since I a& not fa&iliar with your specific environ&ent, I cannot provide you an e%act set of steps to follow when failin# over your production server to your standby server, but what I can do is list so&e of the &ost co&&on thin#s you will need to consider. They include0 (re you able to recover the transaction lo# on the production serverF If so, then you &ay want to run a script si&ilar to this one in order to bac$ it up0 BACKUP .O7 database_name TO database_name_&o"_backup_de()ce +IT, I-IT0 -O_TRU-CATE If you have recovered the transaction lo# on the production server, you &ay want to restore in on the standby server usin# a script si&ilar to this one0 RESTORE .O7 database_name

FROM DISK !d#$s%&'$&o"$database_name_&o"_backup_de()ce*bak! +IT, DBO_O-./0 STA-DB/ !d#$s%&'$undo_database_name_&o"*&d1! !hether or not you were able to recover the transaction lo# or not fro& the production server, you will need to run a script si&ilar to the one below in order to /recover/ the standby server and turn it into your production server. RESTORE DATABASE database_name +IT, RECO2ER/ E6EC SP_DBOPTIO- !database_name!0 !read on&9!0 !1a&se! E6EC SP_DBOPTIO- !database_name!0 !dbo use on&9!0 !1a&se! Once your standby server has been failed over, the ne%t step is to re6point your clients to it. 7ow you do this will depend on your clients. (s a last resort, you can always rena&e your standby server to the na&e of your production server, and chan#e the I8 address, but this solution often creates proble&s of its own. @ou will +ust have to test to find the best way to re6point your clients to your SQL Server. (nother aspect of the failover process you will want to plan for is how you will &a$e the &ove bac$ fro& the standby server to the production server once the production server is wor$in# a#ain.

(s you can see, settin# up lo# shippin# involves a lot of detailed steps. If you want to #ive it a try, try to allocate the lar#est part of a couple of days to i&ple&ent and test it. 'ut once it is #oin#, I thin# you will find it a #reat ti&e saver when your production server #oes down.