See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/299384815

Improving the Performance of Servers by Implementing the Manual Log

Shipping for Large Databases

Article · May 2012

CITATIONS READS

0 482

4 authors, including:

Vinit Kumar Lohan

Vaish College of Engineering
10 PUBLICATIONS   7 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Performance Measurement of WSN View project

All content following this page was uploaded by Vinit Kumar Lohan on 23 March 2016.

The user has requested enhancement of the downloaded file.

 41
IJCSMS International Journal of Computer Science & Management Studies, Vol. 12, Issue 02, April
2012 ISSN (Online): 2231 –5268
www.ijcsms.com

Improving the Performance of Servers by Implementing

the Manual Log Shipping for Large Databases
1 2 3 4
Anil , Parveen Yadav , Balraj Sharma , Vinit Kumar
1
M.Tech C.S.E, BITS, Bhiwani, Haryana-127021, India
anilverma.bits@gmail.com
2
Assistant Professor, BITS, Bhiwani Haryana-127021, India
par.biran@gmail.com
3
Assistant Professor, BITS Bhiwani, Haryana-127021, India
balrajbhardwas@gmail.com
4
Assistant Professor, VCE, Rohtak-124001, India
lohanvinit@gmail.com
Abstract to build up the application. SQL Server 2005 provides an
Business success, the need to ensure 24x7availability is greater advanced feature called Log Shipping. Log shipping is an
than it has ever been. One common method for as database Automated Process for backing up, restoring, copying the
systems become more and more critical to providing 99.99%, or transaction logs and synchronizing the database for
"4-nines" availability, is to implement a "warm" standby distributed database server application which can improve
database server. The use of standby servers is not a new
the application performance and availability of database.
concept; database administrators (DBAs) have been using them
for years. Typically, standby servers require the DBA or Log Shipping is used to synchronize the Distributed
operator to create backups of the database and logs on the Database Server. Synchronize the database by copying
primary system and then restore these backups on a standby Transaction logs, Backing up, Restoring data. SQL Server
server on a regular basis. If the primary server fails, the down used SQL Server Job Agents for making those processes
time is isolated to the amount of time required to process the log automatic. Log Shipping does not involve automatic.
files since the last backup was restored on the standby server. Transfer of server if there is any failure. This means it has
Log shipping allows you to automatically send transaction log backups just synchronized the databases but if the primary server
from a primary database on a primary server instance to one or more
fails, it will not redirect your application to a secondary
secondary databases on separate secondary server instances. The
transaction log backups are applied to each of the Secondary databases
server. This has to be done manually.
individually. An optional third server instance is known as the monitor The main functions of Log Shipping are as follows:
server records. The history and status of backup and restores operations • Backing up the transaction log of the primary
and, optionally, raises alerts if these operations fail to occur as database
scheduled. • Copying the transaction log backup to each
We can improve the functionality of our Log Shipping secondary server
manually so that back up is made quickly and making it quick, • Restoring the transaction log backup on the
we insert some manual codes. Implementing Log Shipping for
secondary database
small databases is relatively straightforward as one can easily
do it using the GUI but for large database, the GUI is not a The figure 1 shows a log shipping configuration with the
good option as the database on the destination server will be primary server instance, three secondary servers.
always out of sync. So a question arises how do we accomplish Instances and a monitor server instance. The figure
this task? In this paper, we are going to explain you the detailed illustrates the steps performed by backup, copy, and restore
steps which we followed to implement the log shipping for our jobs, as follows:
large databases manually and improving the performance of our 1. The primary server instance runs the backup job to back
servers. up the transaction log on the primary database. This
Keywords: Replication, backup, recovery, hot backups, online server instance then places the log backup into a primary
backups, dynamic changes, reconciliation.
log-backup file, which it sends to the backup folder. In
this figure, the backup folder is on a shared directory—
the backup share.
1. Introduction
2. Each of the three secondary server instances runs its
For distributed database application environment, it is own copy job to copy the primary log-backup file to its
always required to synchronize different database servers, own local destination folder.
back up, copy Transaction Logs, etc. If we are going to
implement using application we have to put lots of efforts

IJCSMS
www.ijcsms.com
 42
IJCSMS International Journal of Computer Science & Management Studies, Vol. 12, Issue 02, April
2012 ISSN (Online): 2231 –5268
www.ijcsms.com

3. Each secondary server instance runs its own restore A SQL Server Agent job that performs the backup
job to restore the log backup from the local destination operation, logs history to the local server and the monitor
folder onto the local secondary database. server, and deletes old backup files and history information.
The primary and secondary server instances send their own When log shipping is enabled, the job category "Log
history and status to the monitor server instance. Shipping Backup" is created on the primary server instance.

2. Terms and Definitions and Architecture

2.8 Copy job
2.1 Log shipping

Log shipping is an Automated Process for backing up, A SQL Server Agent job that copies the backup files from
restoring, copying the transaction logs and the primary server to a configurable destination on the
synchronizing the database for distributed database secondary server and logs history on the secondary server
and the monitor server. When log shipping is enabled on a
server application which can improve the application
database, the job category "Log Shipping Copy" is created
performance and availability of database. on each secondary server in a log shipping configuration.

2.2 Primary server 2.9 Restore job

The instance of SQL Server is a production server.

A SQL Server Agent job that restores the copied backup
2.3 Primary database files to the secondary databases. It logs history on the local
server and the monitor server, and deletes old files and old
The database on the primary server is to be back up to history information. When log shipping is enabled on a
another server. All administration of the log shipping database, the job category "Log Shipping Restore" is created
configuration through SQL Server Management Studio is on the secondary server instance.
performed from the primary database. 2.10 Alert job
A SQL Server Agent job that raises alerts for primary and
secondary databases when a backup or restore operation
2.4 Secondary server
does not complete successfully within a specified threshold.
When log shipping is enabled on a database, job category
The instance of SQL Server where we want to keep a warm "Log Shipping Alert" is created on the monitor server
standby copy of your primary database. instance.
The following figure shows a log shipping configuration
2.5 Secondary database with the primary server instance, three secondary server
instances, and a monitor server instance. The figure
The warm standby copies the primary database. The illustrates the steps performed by backup, copy, and restore
secondary database may be in either the RECOVERING jobs, as follows:
state or the STANDBY state, which leaves the database 1. The primary server instance runs the backup job to
available for limited read-only access. back up the transaction log on the primary database.
This server instance then places the log backup into a
2.6 Monitor server primary log-backup file, which it sends to the backup
folder. In this figure, the backup folder is on a shared
directory—the backup share.
An optional instance of SQL Server that tracks all of the
2. Each of the three secondary server instances runs its
details of log shipping, including:
own copy job to copy the primary log-backup file to
• When the transaction log on the primary database its own local destination folder.
was last backed up. 3. Each secondary server instance runs its own restore
• When the secondary servers last copied and job to restore the log backup from the local
restored the backup files. destination folder onto the local secondary database.
• Information about any backup failure alerts. The primary and secondary server instances send their own
history and status to the monitor server instance.
2.7 Backup job

IJCSMS
www.ijcsms.com
 43
IJCSMS International Journal of Computer Science & Management Studies, Vol. 12, Issue 02, April
2012 ISSN (Online): 2231 –5268
www.ijcsms.com
This topic discusses considerations for combining log
shipping and database mirroring.
The principal database in a mirroring session can also act as
the primary database in a log shipping configuration, or vice
versa, as the log shipping backup share is intact. The
database mirroring session run in any operating mode,
whether synchronous (with transaction safety set to FULL)
or asynchronous (with transaction safety set to OFF).
Typically, when combining log shipping and database
mirroring, the mirroring session is established before log
shipping, although this is not required. Then the current
principal database is configured as the log shipping primary
(the principal/primary database), along with one or more
remote secondary databases. Also, the mirror database must
be configured as a log shipping primary (the mirror/primary
database). The log shipping secondary databases should be
on different server instances than either the
Fig. 1 Sequential Log Shipping principal/primary server or mirror/primary server.

During a log shipping session, backup jobs on the primary

database create log backups in a backup folder. From there,
the backups are copied by the copy jobs of the secondary
servers. For the backup jobs and copy jobs to succeed, they
must have access to the log shipping backup folder. To
maximize availability of the primary server, we recommend
that you establish the backup folder in a shared backup
location on a separate host computer. Ensure that all the log
shipping servers, including the mirror/primary server, can
access the shared backup location (known as a backup
share).
To allow log shipping to continue after database mirroring
fails over, you must also configure the mirror server as a
primary server, using the same configuration you use for the
primary on the principal database. The mirror database is in
the restoring state, which prevents the backup jobs from
backing up the log on the mirror database. This ensures that
the mirror/primary database does not interfere with the
Fig 2 Automatic Log Shipping principal/primary database whose log backups are currently
3. DatabaseMirroring and Log Shipping being copied by secondary servers. To prevent spurious
(SQL Server) & manually Log shipping alerts, after the backup job executes on the mirror/primary
A given database can be mirrored or log shipped; it can also database, the backup job logs a message to the log.
be simultaneously mirrored and log shipped. To choose
what approach to use, consider the following: Shipping monitor history detail table, and the agent job
• How many destination servers do you require? returns a status of success.
If you require only a single destination database, database The mirror/primary database is inactive in the log shipping
mirroring is the recommended solution. session. However, if mirroring fails over, the former mirror
If you require more than one destination database, you need database comes online as the principal database. At that
to use log shipping, either alone or with database mirroring. point, that database also becomes active as the log shipping
Combining these approaches gives you the benefits of primary database. The log shipping backup jobs that were
database mirroring along with the support for multiple previously unable to ship log on that database, begin
destinations provided by log shipping. shipping log. Conversely, a failover causes the former
• If you need to delay restoring log on the destination principal/primary database to become the new
database (typically, to protect against logical errors), use mirror/primary database and enter the restoring state, and
log shipping, alone or with database mirroring. backup jobs on that database cease to backup log.

IJCSMS
www.ijcsms.com
 44
IJCSMS International Journal of Computer Science & Management Studies, Vol. 12, Issue 02, April
2012 ISSN (Online): 2231 –5268
www.ijcsms.com

To run in high-safety mode with automatic failover the

mirroring session is configured with an additional server
instance known as the witness. If the principal database is
lost for any reason after the database is synchronized and if
the mirror server and witness can still communicate with
each other, automatic failover occurs. An automatic failover
causes mirror server to assume the principal role and bring
its database online as the principal database. For more
information, see Automatic Failover (Database Mirroring).
If the log shipping backup location is accessible to the new
principal/primary server, its backup jobs begin to ship log
backups to that location. The database mirroring
synchronous mode guarantees that the log chain is
unaffected by a mirroring failover and that only valid log is
restored. The secondary servers continue to copy log
backups without knowing that a different server instance has
become the primary server.
When using a local log shipping monitor, no special
considerations are necessary to accommodate this scenario.
For information about using a remote monitoring instance
with this scenario, see, "The Impact of Database Mirroring
on a Remote Monitoring Instance," later in this topic.

3.1 Failing over from the Principal to the

Mirror Database

The following figure shows how log shipping and database

mirroring work together when mirroring is running in high-
safety mode with automatic failover. Initially, Server A is Fig 3 Mirroring Failure
both the principal server for mirroring and the primary
server for log shipping. Server B is the mirror server and is For more information about monitoring, see Monitor Log
also configured as a primary server, which is currently Shipping (Transact-SQL).
inactive. Server C and Server D are log shipping secondary Setting Up Mirroring and Log Shipping Together
servers. To maximize availability of the log shipping
session, the backup location is on a share directory on a To set up database mirroring and log shipping together, the
separate host computer. following steps are required:
After a mirroring failover, the primary server name defined 1. Restore backups of the principal/primary database with
on the secondary server is unchanged. NORECOVERY onto another server instance to be
later used as database mirroring mirror database for the
3.2 The Impact of Database Mirroring on a Remote principal/primary database. For more information, see
Monitoring Instance Prepare a Mirror Database for Mirroring (SQL Server).

When log shipping uses with a remote monitoring instance, 2. Set up database mirroring. For more information, see
combining the log shipping session and database mirroring Establish a Database Mirroring Session Using
affects the information in the monitor tables. The Windows Authentication (SQL Server Management
information about the primary is a combination of the one Studio) or Setting up Database Mirroring (SQL Server).
configured at the principal/primary and the monitor
configured on each secondary. 3. Restore backups of the principal/primary database to
To keep monitoring as seamless as possible, when you use a other server instances to be later used as log shipping
remote monitor, we recommend that you specify the original secondary databases for the primary database.
primary name when configuring the primary at the 4. Set up log shipping on the principal database as the
secondary. This approach also facilitates changing the log primary database for one or more secondary databases.
shipping configuration from Microsoft SQL Server Agent. You should set up a single share as the backup directory (a
backup share). This ensures that after role switching

IJCSMS
www.ijcsms.com
 45
IJCSMS International Journal of Computer Science & Management Studies, Vol. 12, Issue 02, April
2012 ISSN (Online): 2231 –5268
www.ijcsms.com
between the principal and mirror servers, backup jobs server B was taken at 4:45 a.m., all transactions that
continue to write to the same directory as before. A best occurred between 4:45 a.m. and 5 a.m. are lost forever.
practice is to ensure that this share is located on a different • Some manual DBA work is required to bring the
physical server from the servers hosting the databases standby server online, as discussed in this article.
involved in mirroring and log shipping. • Log shipping setup cannot be scripted. This means that
5. Manually failover from the principal to the mirror. you cannot mimic the production environment for
To perform a manual failover: testing purposes without going through the wizard
• Manually Fail Over a Database Mirroring Session screens.
(SQL Server Management Studio) • The Enterprise edition of SQL Server 2000 is required
• Manually Fail Over a Database Mirroring Session on primary and standby servers. If you run any other
(Transact-SQL) version/edition of SQL Server, you're out of luck. The
6. Set up log shipping on the new principal (previously Developer edition can be used to learn how to set up
mirror) as the primary database. log shipping, but it cannot be used in a production
7. You must use the same backup share that you used in environment. Note however, that log shipping is merely
step 4. an automated way of copying transaction log backups,
8. The Transaction Log Shipping interface in SQL Server so a savvy DBA can easily set up jobs to
Management Studio supports only one primary accomplish the same functionality.
database per log shipping configuration. Therefore, you Difficult troubleshooting Log shipping usually works very
must use stored procedures to set up the new principal well, but if there are problems, they're difficult to
as primary. troubleshoot—documentation is sparse and typically not
9. Perform another manual failover to fail back to the helpful for solving a particular problem. Fortunately
original principal. Microsoft's Knowledge Base articles have good information
for troubleshooting log-shipping issues.
4. Advantage Each database that needs to be log-shipped must be set up
through a separate maintenance plan.

• Provides a disaster-recovery solution for a single

primary database and one or more secondary 6. Conclusions
databases, each on a separate instance of SQL
Server. The objective of this work is to identify the possibilities in
• Supports limited read-only access to secondary the technology and to write an algorithm to make the log
databases (during the interval between restore shipping from production database at one location to the
jobs). standby database at remote geographic location fastest.
• Allows a user-specified delay between when the The approach behind this research will be two pronged and
primary server backs up the log of the primary compressing the redo logs to the optimum in advance.
database and when the secondary servers must Doing the shipping of compressed logs parallel to the
restore (apply) the log backup. A longer delay can remote standby database location and uncompressing them
be useful, for example, if data is accidentally to the original forms so that they can be applied on the
changed on the primary database. If the accidental standby database.
change is noticed quickly, a delay can let you
retrieve still unchanged data from a secondary References
database before the change is reflected there. [1] Microsoft SQL Server 2008 R2 Unleashed by Ray Rankins, Paul
T. Bertucci, Chris Gallelli and Alex T. Silverstein.

5. Disadvantages of Log Shipping [2] Inside SQL Server book

Unfortunately, log shipping does have a few issues that the [3] High Availability with SQL Server 2008
DBA should be aware of prior to relying on this method of
failover: [4] Beginning SQL Joes 2 Pros: The SQL Hands-On Guide
• Possible data loss when the primary server fails. If the for Beginners (SQL Exam Prep Series 70-433 Volume 1
primary server becomes completely unusable, of 5) (Sql Design Series) by Rick A Morelan
transactions that occurred after the last transaction log
backup that was copied to the standby server are lost. [5] Microsoft SQL Server 2008 Reporting Services by
For example, suppose that server A fails at 5 a.m. and Brian Larson
you cannot get to it at all. If the last backup copied to

IJCSMS
www.ijcsms.com

View publication stats