An Overview of Log Shipping in SQL Server

2005
By Abhijit Jana | 25 Oct 2008
Overview of Log Shipping in SQL Server 2005

See Also
• Articles like this
• Articles by this author

Print Article

Twitter

Digg

Facebook

Del.icio.us

Reddit

Stumbleupon

Newsvine

Technorati

Mr. Wong

Yahoo!

Google

Windows Live

Send as Email
Add to your CodeProject bookmarks

Discuss this article

5
Report this article as inappropriate
Article Browse Code StatsRevisions

4.42 (15 votes)

1 2 345
Sponsored Links
Top of Form
/w EPDw UKMTAy

Table of Contents
• Introduction
• What is Log Shipping?
• Component of Log Shipping
• Log Shipping Prerequisites
• SQL Server 2005 Version that Supports Log Shipping
Introduction
For distributed database application environment, it is always required to synchronize different
database servers, back up, copy Transaction Logs, etc. If we are going to implement using
application we have to put lots of efforts to build up the application. SQL Server 2005 provides
an advanced feature called Log Shipping. Log shipping is an Automated Process for backing
up, restoring, copying the transaction logs and synchronizing the database for distributed
database server application which can improve the application performance and availability of
database. In my recent project, I have done some short of experiment on it. I am going to explain
it in this article.
What is Log Shipping?
Log Shipping is used to synchronize the Distributed Database Server. Synchronize the database
by copying Transaction logs, Backing up, Restoring data. SQL Server used SQL Server Job
Agents for making those processes automatic. Log Shipping does not involve automatic transfer
of server if there is any failure. This means it has just synchronized the databases but if the
primary server fails, it will not redirect your application to a secondary server. This has to be
done manually.
The main functions of Log Shipping are as follows:
• Backing up the transaction log of the primary database
• Copying the transaction log backup to each secondary server
• Restoring the transaction log backup on the secondary database
Components of Log Shipping
For implementing Log Shipping, we need the following components - Primary Database
Server, Secondary Database Server, and Monitor Server.
• Primary Database Server: Primary Sever is the Main Database Server or SQL Server
Database Engine , which is being accessed by the application. Primary Server contains
the Primary Database or Master Database.
• Secondary Database Server: Secondary Database Server is a SQL Server Database
Engine or a different Server that contains the backup of primary database. We can
have multiple secondary severs based on business requirements.
• Monitor Server: Monitor Server is a SQL Server Database Engine which Track the
Log Shipping process.

Figure 1: Log Shipping Database Server Configuration

We can have different SQL Servers for each of these servers or we can use a single server for
these three. In my example, I have used a single server for these three.
You can start Log Shipping by Right Click on Database >Properties >Transaction Log
Shipping > Select Check Box, and Configure your settings.
Figure 2: Enable Log Shipping
Use the following settings for more configurations:

Figure 3: Transaction Log Backup Settings for Primary Server

Configure Secondary Server:
Figure 4: Settings for Secondary Server
Log Shipping Prerequisites
• Must have at least two Database Servers or two SQL Server 2005 Database Engines.
• Configuration user should have Admin privilege on that server
• SQL Server Agent Service Configured properly
• Configuration mode of Primary database should be a Full or Bulk Logged recovery
model.
• Shared folder for copying the transaction logs.
SQL Server 2005 Version that Supports Log Shipping
SQL Server 2005 Version Available
SQL Server 2005 Enterprise Edition Yes
SQL Server 2005 Workgroup Edition Yes
SQL Server 2005 Version Available
SQL Server 2000 Standard Edition Yes
SQL Server 2005 Developer Edition Yes
SQL Server 2005 Express Edition No

Reference
• Log Shipping
History
• Written on 25th October, 2008
Bottom of Form

I tried a lot of combinations in my life in order to find out an effective method for implementing
Transaction Log Shipping between servers which are in a workgroup, not under domain. I
realized the things you learn from article and books are for small and medium sized databases.
When you database become 10 GB or bigger, thing’s become a lot harder than it looks.
Additionally many things changed in SQL Server 2005. So, it’s even more difficult to configure
log shipping properly nowadays.
Here’s the steps that I finally found that works. Let’s assume there are 2 servers with SQL Server
2005. Make sure both servers have latest SP. There’s Service Pack 1 released already.
1. Create a new user Account named “SyncAccount” on both computers. Use the exact same
user name and password.
2. Make sure File Sharing is enabled on the local area connection between the server. Also
enable file sharing in Firewall.
3. Make sure the local network connection is not regular LAN. It must be a gigabit card with
near zero data corruption. Both cable and switch needs to be perfect. If possible, connect both
servers using Fibre optic cable directly on the NIC in order to avoid a separate Switch.
4. Now create a folder named “TranLogs” on both servers. Let’s assume the folder is on
E:\Tranlogs.
5. On Primary Database server, share the folder “Tranlogs” and allow SyncAccount “Full
Access” to it. Then allow SyncAccount FullAccess on TranLogs folder. So you are setting the
same permission from both “Sharing” tab and from “Security” tab.
6. On Secondary database server, allow SyncAccount “Full Access” right on TranLogs folder.
No need to share it.
7. Test whether SyncAccount can really connect between the servers. On Secondary Server, go
to Command Prompt and do this:
8.
9. Now you have a command prompt which is running with SyncAccount privilege. Let’s
confirm the account can read and write on “TranLog” shares on both servers.

10.
11. This is exactly what SQL Agent will be doing during log ship. It will copy log files from
primary server’s network share to it’s own log file folder. So, the SyncAccount needs to be able
to both read files from primary server’s network share and write onto its own tranlogs folder.
The above test verifies the result.
12. This is something new in SQL Server 2005: Add SyncAccount in SQLServer Agent group
“SqlServer2005SqlAgentUser….”. You will find this Windows User Group after installing SQL
Server 2005.
13. Now go to Control Panel->Administrative Tools->Services and find the SQL Server Agent
service. Go to its properties and set SyncAccount as the account on the Logon tab. Restart the
service. Do this on both servers.
14.
15. I use sa account to configure the log shipping. So, do this on both servers:
a. Enable “sa” account. By default, sa is disabled in SQL Server 2005.
b. On “sa” account turn off Password Expiration Policy. This prevents sa password from expiring
automatically.
16. On Secondary server, you need to allow remote connections. By default, SQL Server 2005
disables TCP/IP connection. As a result, you cannot login to the server from another server.
Launch the Surface Area Configuration tool from Start->Programs->MS SQL Server 2005 and
go to “Remote Connection” section. Choose the 3rd option which allows both TCP/IP based
remote connection and local named pipe based connections.
17. On Secondary Server firewall, open port 1433 so that primary server can connect to it.
18. Restart SQL Server. Yes, you need to restart SQL Server.
18. On Primary server, go to Database properties->Options and set Recovery Model to “Full”. If
it was already set to full before, it will be wise to first set it to Simple, then shrink the transaction
log file and then make it “Full” again. This will truncate the transaction log file for sure.
19. Now take a Full Backup of the database. During backup, make sure you put the backup file
on a physically separate hard drive than the drive where MDF is located. Remember, not
different logical drives, different physical drives. So, you should have at least 2 hard drives on
the server. During backup, SQL Server reads from MDF and writes on the backup file. So, if
both MDF and the backup is done on the same hard drive, it’s going to take more than double the
time to backup the database. It will also keep the Disk fully occupied and server will become
very slow.
20. After backup done, RAR the database. This ensures when you copy the database to the other
server there’s no data corruption while the file was being transferred. If you fail to unRAR the
file on the secondary server, you get assurance that there’s some problem on the network and
you must replace network infrastructure. The RAR also should be done on a separate hard drive
than the one where the RAR is located. Same reason, read is on one drive and write is on another
drive. Better if you can directly RAR to the destination server using network share. It has two
benefits:
a. Your server’s IO is saved. There’s no write, only read.
b. Both RAR and network copy is done in one step.
21.
22. By the time you are done with the backup, RAR, copy over network, restore on the other
server, the Transaction Log file (LDF) on the primary database server might become very big.
For us, it becomes around 2 to 3 GB. So, we have to manually take a transaction log backup and
ship to the secondary server before we configure Transaction Log Shipping.

23.
24. When you are done with copying the transaction log backup to the second server, first restore
the Full Backup on the secondary server:
25.
26. But before restoring, go to Options tab and choose RESTORE WITH STANDBY:

27.
28. When the full backup is restored, restore the transaction log backup.

29. REMEMBER: go to options tab and set the Recovery State to “RESTORE WITH
STANDBY” before you hit the OK button.
30. This generally takes a long time. Too long in fact. Every time I do the manual full backup,
rar, copy, unrar, restore, the Transaction Log (LDF) file becomes 2 to 3 GB. As a result, it takes
a long time to do a transaction log backup, copy and restore and it takes more than an hour to
restore it. So, within this time, the log file on the primary server again becomes large. As a result,
when log shipping starts, the first log ship is huge. So, you need to plan this carefully and do it
only when you have least amount of traffic.
31. I usually have to do this manual Transaction Log backup twice. First one is around 3 GB.
Second one is around 500 MB.
32. Now you have a database on the secondary server ready to be configured for Log shipping.
33. Go to Primary Server, select the Database, right click “Tasks” -> “Shrik”. Shrink the Log
File.
34. Go to Primary server, bring on Database options, go to Transaction Log option and enable
log shipping.
35.
36. Now configure the backup settings line this:

37.
38. Remember, the first path is the network path that we tested from command prompt on the
secondary server. The second path is the local hard drive folder on the primary server which is
shared and accessible from the network path.
39. Add a secondary server. This is the server where you have restored the database backup

40.
41. Choose “No, the secondary database is initialized” because we have already restored the
database.
42. Go to second tab “Copy Files” and enter the path on the secondary server where log files will
be copied to. Note: The secondary server will fetch the log files from the primary server network
share to it’s local folder. So, the path you specify is on the secondary server. Do not get confused
from the picture below that’s it’s the same path as primary server. I just have same folder
configuration on all servers. It can be D:\tranlogs if you have the tranlogs folder on D: drive on
secondary server.
43.
44. On third tab, “Restore Transaction Log” configure it as following:

45.
46. It is very important to choose “Disconnect users in database…”. If you don’t do this and by
any chance Management Studio is open on the database on secondary server, log shipping will
keep on failing. So, force disconnect of all users when database backup is being restored.
47. Setup a Monitor Server which will automatically take care of making secondary server the
primary server when your primary server will crash.

48.
49. In the end, the transaction log shipping configuration window should look like this:
50.
51. When you press OK, you will see this:

52. Do not be happy at all if you see everything shows “Success”. Even if you did all the paths,
and settings wrong, you will still see it as successful. Login to the secondary server, go to SQL
Agents->Jobs and find the Log Ship restore job. If the job is not there, your configuration was
wrong. If it’s there, right click and select “View History”. Wait for 15 mins to have one log ship
done. Then refresh and see the list. If you see all OK, then it is really ok. If not, then there are
two possibilities:
a. See if the Log Ship Copy job failed or not. If it fails, then you entered incorrect path. There
can be one of the following problem:
1. The network location on primary server is wrong
2. The local folder was specified wrong
 3. You did not set SyncAccount as the account which runs SQL Agent or you did
but forgot to restart the service.
b. If restore fails, then the problems can be one of the following:
i. SyncAccount is not a valid login in SQL Server. From SQL Server Management Studio, add
SyncAccount as a user.
ii. You forgot to restore the database on secondary server as Standby.
iii. You probably took some manual transaction log backup on the primary server in the
meantime. As a result, the backup that log shipping took was not the right sequence.
53. If everything’s ok, you will see this:
Related posts:
1. Large log file can bring SQL Server down when transaction log shipping runs
2. Cost effective, failsafe, 2 server load balanced web & DB servers
3. 100% CPU, 100% IO, a near death experience for SQL Server 2005 and us
4. What to do when you kill your database with your own hand
5. A significant part of sql server process memory has been paged out. This may result in
performance degradation
Those who believe, and whose hearts find satisfaction in the remembrance of Allah: for without
doubt in the remembrance of Allah do hearts find satisfaction. (Quran 13:28)