Hardware considerations for simpler SQL

Server failovers
Greg Robidoux, Edgewood Solutions
05.25.2006

In the first part of this tips series, Edgewood Solutions' Greg Robidoux discusses
hardware considerations for simpler failovers. In future tips, he'll discuss software
and other supporting data needed for failover.

Failing over to another system in a disaster recovery situation is the last thing you
want to do. Although you won't have to do this often, you may need to eventually --
and it's better to be prepared than not.
You may assume that the simpler the implementation the simpler the failover
process will be. From a hardware perspective that may be the case, but from a SQL
Server performance and high availability standpoint, simple is probably not the way
to go.
In the following tip I'll describe what a simple SQL Server hardware implementation
would look like and why that may be an ideal configuration for failover but not for
performance and availability. I'll also discuss failover methods. Use the following
table of contents to navigate this tip.
TABLE OF CONTENTS
Simple hardware implementation for simple failover
Hardware and performance
Hardware and high availability
Primary hardware components for failover
Additional failover considerations

Simple hardware implementation for simple failover

From the most basic standpoint your simplest hardware implementation would
consist of something like the following:
• one physical server;
• one disk array made up of one or multiple disks;
• one controller;
• one network card;
• one or more CPUs;
• operating system software;
• SQL Server software;

Santosh Kumar Vellala Source: www.whatis.com

 • various service packs to keep the OS and SQL Server up to date;
• and that's about it!
This configuration is nice and simple, but lacks quite a bit in the high availability
and performance area. So we need to think about what we are trying to achieve:
1. Make the failover simple
2. Make sure failover does not occur and, in the remote chance that it does,
make it easier to failover to another server.
My choice, which I'm sure is also yours, is option number two.
So let's think about your hardware implementation from two different angles:
performance and high availability.
Hardware and performance
In order to improve performance, most technical advice written about SQL Server
and database systems tells you to spread I/O across as many disks as possible and
separate different I/O functions, such as data, transactions, tempDB, paging file,
work space, etc. In addition to breaking apart I/O functions, you must ensure
different databases are not contending with the same physical I/O, which would
require greater physical separation between them. So, you must first separate I/O
for one database with data, logs, etc., and you may then need to separate disk I/O
among multiple databases running on the same server.
You also have indexes and data that could be separated to further increase I/O, and
you must consider controllers and their configurations to make sure they are not
creating bottlenecks.
The overall disk configuration really depends on the type of application and
database usage for your server. If your database needs do not warrant separating
all disk activity, don't make the hardware overly complex by separating all disk
activity.
Unfortunately there may not be a simple hardware configuration for failover.
Performance impacts users every day, and they are well aware of performance
changes. Systems must be tuned and hardware configured to maximize the user
experience.
Hardware and high availability
On the other side we have high availability. In most cases a full-blown HA solution is
often not implemented; instead a manual process is used to fail over to a secondary
system. Although there have been several options available for quite some time, I
am just now starting to see a market shift toward implementing complete failover
solutions to minimize downtime as much as possible. Such interest may be driven
by new database mirroring features in SQL Server 2005 and people's desire for
greater HA capabilities or the fact that more and more enterprise applications are
being migrated to SQL Server and there is a business need for HA.
Several failover options exist, from free to expensive and simple to complex. Some
are built into SQL Server and others are add-ons.
• Log shipping (free/simple)
This option has been pretty widely used for quite some time now. There are
built-in capabilities in SQL Server 2000 Enterprise Edition, but this is method

Santosh Kumar Vellala Source: www.whatis.com

 could easily be recreated in any version. SQL Server 2005 now has built-in
tools for both Standard and Enterprise. The downside is that there is a lot of
manual work for the failover.
• Hardware clustering (expensive/complex)
This option offers automatic failover, but also comes at a cost.
• Software clustering (expensive/complex)
This is another option that offers automatic failover at a cost.
• Backup and restore (free/simple)
This is a manual process for failover. It doesn't cost anything, but definitely
provides no automation.
• Replication (free/complex)
This option is not the best option for a failover server. There are a lot off
moving parts with replication and it is a lot of work to keep database changes
in synch. If you employ this option there is still a lot of manual work required
for failover.
• Database mirroring (free/simple-complex)
This is a new feature in SQL Server 2005. This option automates the failover
for you, but other will need to be handled manually.

Primary hardware components for failover

So what does make for a simple failover?
There are four primary SQL Server hardware components that come into play:
memory, processors, network and disk I/O. These four items are core to your
server's performance. From the memory, processor and network standpoint, in
general, there is not much you need to do. SQL Server will take advantage of what
is available. The faster the components the better the performance, so going from
the primary server to the failover server is straight forward.
It's disk configuration that makes failover more complex. The failover option you
choose determines what you must do for a successful failover. Disk configuration
may be as simple as one large partition where all data, logs, work files, etc., are
stored, to something as complex as having all disk activity separated on different
arrays, drive letters, file shares, etc. Some other things that may make this
configuration more complex are the use of one or more of the following:
• storage area network (SAN)
• network-attached storage (NAS)
• different RAID configurations
• filegroups on different physical drives
• file shares
In addition to data layout, data movement from the primary server to the secondary
server should be a concern. If you have very large databases that need to be moved
it will take some time to migrate data across the network. Having GB network cards
and a network to support the movement of the data is also key, otherwise you could
be waiting several hours just to move data from one server to another. If the
bandwidth is already saturated, then the copy of the backup file will be very slow.
Most companies have a management LAN or VLAN to support network traffic
between machines.

Santosh Kumar Vellala Source: www.whatis.com

Also consider the speed of your disk drives and how fast they can write data. The
fastest drives available now are 15K SCSI drives. These drives will allow for faster
data manipulation, which will also improve disk I/O.
Additional failover considerations
Up until this point, the difficult decision has been how to lay out data across disks.
The real complex part is the software and other supporting data needed for failover.
Since this tip is about the hardware, we will not go into those points just yet, but
some of these things include:
• Other software applications
• Service packs
• Security settings
• Server names
• IP addresses
• OS versions
• Logins
• Jobs, alerts and operators
• DTS (Data Transformation Services) or SSIS (SQL Server Integration Services)
packages
• Application changes to point to failover server
Summary
In putting together a failover solution hardware is not the biggest issue. It is
important to have comparable hardware for the failover, but more importantly you
should consider what you are trying to prevent, make sure the systems can perform
at their maximum ability and then think about what is the best solution for a
failover. Is it clustering, database mirroring, log shipping, replication or some other
technique?
You must also think about how long the failover process will take and how long your
end users can be down. This will be the driving factor to determine what solution
simple or complex, free or not, that makes the most sense for your environment.
ABOUT THE AUTHOR:
Greg Robidoux is the president and founder of Edgewood Solutions LLC, a
technology services company delivering professional services and product solutions
for Microsoft SQL Server. He has authored numerous articles and has delivered
presentations at regional SQL Server users' groups and national SQL Server events.
Robidoux, who also serves as the SearchSQLServer.com Backup and Recovery
expert, welcomes your questions.

Santosh Kumar Vellala Source: www.whatis.com

Disaster recovery features in SQL Server
2005
By Hilary Cotter
05.10.2007
Disaster recovery refers to the ability of a company to continue operations after an
event interrupts normal business functions. For example, many businesses in New
York City faced considerable disruption during the power failure in the summer of
2003, and of course in the aftermath of September 11, 2001. Business continuity is
critical for a company's viability, especially for RDBMs as according to Gartner Inc.,
(Online Server Backup: Niche, Glitch or Killer App? by Adam W. Couture, January,
2002) a market research firm in Stamford, Conn:
• 50% of companies would close within two years if their data is not restored
within 24 hours after a disaster occurs.
• As many as 95% would close within two years if their data is not restored
within 72 hours after a disaster. Gartner's research further reveals that a
whopping 77% of backups are unusable when needed.
• According to other reports,(Enterprise Storage Group, "The Evolution of
Enterprise Data Protection", January 2004) 25% of 500 companies surveyed
will face a significant data disruption event.
Not having any disaster recovery plans in place is essentially playing Russian
roulette with your company's future – let alone your own job. It is essential that
whatever disaster recovery plan you implement, you test it and ensure that all
people incorporating the disaster recovery operation are well practiced at the plan,
in order to minimize downtime. Not having tested your disaster recovery plan
means you really only have a "disaster recovery hope" (to quote SQL Server MVP
Geoff Hiten).
SQL Server 2005 disaster recovery options
SQL Server disaster recovery plan goals
Mirrored backup media sets
Backup and restore
Log shipping for point in time recovery
Replication in SQL Server 2005
Database mirroring
SQL Server disaster recovery plan goals
Disaster recovery goals vary from industry to industry:
• Some companies can tolerate less data loss than other companies; most
financial institutions can tolerate no data loss.

Santosh Kumar Vellala Source: www.whatis.com

 • Some industries have very stringent requirements on availability but more
relaxed requirements on data loss; some media outlets must provide
continuous service in the event of a disaster as the public turns to them for
news about the disaster. But they can tolerate data loss, as everyone is
interested in new news (of the disaster), not old news, and the same news
about the disaster is continually entering their system.
• Some companies only require essential business functions restored and other
companies require plans for their entire enterprise; I consulted for one
retailer whose DR plans do not include their ecommerce site.
In general the goals are to:
• Minimize disruptions.
• Minimize the extent of disruption.
• Minimize the economic impact of the disruption.
• Have a disaster recovery site with all dependencies in place to provide
failover.
• Have personal trained personnel and practiced to provide business continuity
from the disaster recovery site.
• Provide for smooth and rapid restoration failback to the normal place of
operation.
SQL Server 2005 has expanded the portfolio of options for disaster recovery in SQL
Server 2005. The following components are available in SQL Server for Disaster
Recovery:
• Mirrored backup media sets
• Backup and restore
• Log shipping
• Database mirroring
• Replication

Mirrored backup media sets

New in SQL Server 2005 is the ability to do mirrored tape backups. You can
simultaneously write your backup to up to four tape devices. This means you could
backup your database locally to your multiplex tape unit, while at the same time
write your backup to your DR site. The slowest link will throttle your overall
throughput of your backup solution, so the WAN link to your DR site may slow down
the speed of your local backup, if you are using mirrored tape backups. If you use
mirrored backups, all of your backup devices must use identical hardware. For more
information on this feature consult Microsoft's article Using Mirrored Backup Media
Sets.
Mirrored backup media sets can provide complete point in time recovery and can be
used with very large databases (VLDBs). SQL Server 2005 will also allow for log
backups to occur during a database backup. In SQL 2000, these log backups were
paused until the full-backup was done. If you were required to do a point in time
recovery of your database that crashed during a backup, your exposure to data loss
could be significant. The reason being you would have to restore the last backup
(yesterday's perhaps), and then the transaction log backups that occurred since the
last backup completed, and until the next backup started. Consider a database
backup starts at midnight and takes eight hours to complete and the transaction log
dumps every hour. Should a database failure occur at 7:30 a.m., you would have to

Santosh Kumar Vellala Source: www.whatis.com

restore yesterday's backup as well as all the transaction log backups. The latest
time you could restore your database to would be yesterday at 11:00 pm. In SQL
Server 2005, the latest you could restore your SQL Server 2005 database to would
be 7:00 am this morning.
SQL Server 2005 advantages
• Multiple copies of your backup for redundancy.
• Less exposure to data loss with the ability to do log backups during a full
database backup.
When to use mirrored backup media sets
• When you have VLDBs with point in time recovery requirements, have a high
bandwidth link to your DR site and identical tape devices in all locations.

Backup and restore

SQL Server 2005 offers many new features for DR plans that use database backups
and restore. If your disaster recovery goals are not time critical (you don't need
point in time recovery), a disaster recovery plan using a backup and restore of a
full, differential, or partial database backup can be the optimal choice.
For smaller databases, a full or differential backup may satisfy all of your DR goals,
however, if your databases get larger you may need to incorporate a partial backup
strategy. This would involve backing up your read-only filegroups of files on a
different frequency than your read-write file groups. In SQL 2000, such a strategy
would require a complete set of all read-write file group and log backups since you
performed your last read-only file group backup. This requirement is relaxed in SQL
2005 and you will only need the last backup of the read-only file group, the last
backup of the read-write file group(s), and the log backup chain since the last
backup of the read-write file group. Consult the Microsoft article Performing
Piecemeal Restores for more information on this feature.
SQL Server 2005 also has the ability to continue to backup or restore a database
transaction log, or file group after a failure of the database media or the backup
media. This means that if your database files get damaged you may still be able to
backup the tail of the log, or if your database backup is damaged you will be able to
continue the restore after the error has been detected.
Consult the article How to: Specify Whether BACKUP Continue or Stops on
Encountering an Error for more information on this feature.
SQL Server 2005 advantages
• More granular backups and restores.
• Ability to continue the backup or restore of a database and transaction log,
should a failure occurs in the database files or backup media.

Log shipping for point in time recovery

If your DR plan requires point in time recovery log shipping may be your best
option. Log shipping is a continuous backup and restore. However log shipping does
have significant exposure to data loss. At best, this exposure is the shortest length
of time required to complete your transaction log dump and copy it over to the
standby server. Use log shipping when you have point in time recovery
requirements and you have a small number of databases you need to log ship. Log
shipping is not scalable to large databases or a large number of databases because

Santosh Kumar Vellala Source: www.whatis.com

the bandwidth requirements are large and log shipping can become complex when
you are log shipping large numbers of databases. SQL Server 2000 has a log
shipping wizard in the Enterprise Edition, but this wizard is now included in all
editions of SQL Server 2005 (except the express and CE editions).
SQL Server 2005 advantages
• The wizard now ships in all editions of SQL Server (except the express and CE
editions).
• The ability to continue to dump the transaction logs during a database
backup will reduce your exposure to data loss.
When to use log shipping
• Is generally used for small numbers of databases or small databases.
• Use when you do not have real time synchronization requirements, and can
tolerate some exposure to data loss.

Replication in SQL Server 2005

Replication will replicate all or selected transactions which occur on your source
server to your destination server (DR site). It can also modify the data as it is
replicated to the DR site.
Replication will require SQL Server licenses on the SQL Servers in your DR site. Log
shipping and a backup and restore solution will not, as long as the SQL Servers
solely have a standby role. Replication will not detect the addition of new database
objects or logins.
Replication can be configured in a DR topology for easy failover and failback,
however, in SQL 2000 you will need to do significant work to set it up, and it is not
resilient to schema modifications.
SQL Server 2005 will replicate most DDL (Data Definition Language) transparently,
and the peer-to-peer replication model allows for a configuration of a DR node in a
write-anywhere topology. However, it is not really resilient to conflicts or schema
changes--Microsoft recommends that all schema changes and DML occur on one
node in the topology. Replication generally offers very low latencies, however,
under some database loads the latency can exceed that of log shipping.
Transactional replication is included in all SQL Server 2005 Editions (except express
and CE editions); peer-to-peer is only supported on SQL Server 2005 Enterprise
Edition.
SQL Server 2005 advantages
• Peer-to-peer replication model simplifies the creation of bi-directional nodes
with simple failover and failback.
• The ability to replicate some DDL changes to your replication topology
simplifies the maintenance of your replication solution.
When to use replication
• Replication can offer lower latencies and can provide lower exposure to data
loss than log shipping or a backup and restore DR solution.
• Replication can replicate a subset of your data and can modify it to have
different values or a different schema on the DR site.

Database mirroring

Santosh Kumar Vellala Source: www.whatis.com

SQL Server 2005 offers database mirroring which ships in the Standard and
Enterprise Editions. Database mirroring is continuous log shipping and can have
very low latencies. It has two modes high safety (essentially a split write) and high
performance which is an asynchronous commit operation on the DR site. High
safety does have larger latencies than high performance, but your exposure to data
loss is extremely low, if at all. To make database mirroring in high safety mode work
optimally, Microsoft recommends you have a very good network in place, have long
running transactions and have many connections to the database. Database
mirroring can also be configured for automatic failover. When used in a DR capacity,
it will require licenses in place on both the production and DR site.
Database mirroring does consume host-based resources and is not scalable to large
numbers of databases on a single server. It can only be used in full-recovery model.
SQL Server 2005 advantages
• Database mirroring was not a feature of SQL Server 2000, and is essentially
real time log shipping, and as such offers lower exposure to data loss than
log shipping and lower latencies than all of the technologies discussed above.
• Database mirroring can offer automatic failover which is generally not part of
a DR solution; however it does not have a distance limitation like clustering.
When to use database mirroring
• Use database mirroring when your DR goals include very low latencies, lower
than log shipping or replication.

Summary
In this article we've looked at some technologies included in SQL Server 2005 that
can be integrated into a Disaster Recovery plan. Each technology has its own
strengths and limitations, and one technology may be a better fit for your DR goals.

Santosh Kumar Vellala Source: www.whatis.com

Choosing a SQL Server disaster recovery
solution
Hilary Cotter, Contributor
03.18.2009

No one understands the importance of tested backups more than database

administrators (DBAs). For most organizations, however, relying on tape backups for
disaster recovery is neither appropriate nor reliable. In this article, we consider the
pros and cons of various disaster recovery solution options.
Before you select a disaster recovery technology, determine your goals. Some
companies, such as those in the financial sector, cannot tolerate any data loss. For
others, high availability is primary: News outlets and communications companies
will experience peak demand during disasters.
Essentials for SQL Server disaster recovery
Your disaster recovery plan should be complete and include all dependencies. While
the ability to restore an up-to-date SQL Server is essential, you must also ensure
that all dependencies of that SQL Server are in place. Windows accounts, file
system dependencies, applications and other aspects of the server must be present,
as many disaster recovery plans have failed because the site's hardware
dependencies are not in place. This includes tape drives in a different location,
missing passwords for password-protected tapes or the wrong version of either the
firmware or the tape drive itself.
Your plan should also be as simple and nonintrusive as possible. Some disaster
recovery technologies limit what can be done on the source server, such as whether
you can change the recovery model while using database mirroring. Others require
significant steps to ensure that a disaster recovery site is up to date: Replication
and log shipping will not replicate logins, and additional processes are necessary to
ensure that all logins are in place and current at the disaster recovery site.
Other solutions may require significant time before a site is operational, as some
software database mirroring solutions take time to quiesce before a database is
accessible. Executing a disaster recovery plan is a complex operation involving
many steps; a simple plan with fewer moving parts limits that complexity and
increases the reliability of a disaster recovery plan.
Including a plan for failback is also important. Once the disaster recovery site is
operational and running, it will contain changes. When you are ready to return to
your original site, these changes will have to move with you.
Your site also needs adequate network bandwidth to support the data flow that
keeps it synchronized. This must take into account that in the event of a disaster
the site has adequate hardware to support the load placed on it. A large media
corporation's disaster recovery site, for example, can support a much larger load
than its main data center. The reasoning is that during a disaster the public will use
the company's resources more frequently than it would during a normal news cycle.
Conversely, a luxury jewelry retailer designed its site to support only the minimum

Santosh Kumar Vellala Source: www.whatis.com

business-critical functions. The retailers realized that, in the event of a disaster,
most customers would not shop for luxury goods.
Finally, the disaster recovery plan should be up to date. Having a site in place with
older versions of your databases is useless to the current versions of the
applications that access this data. A large online trading site with which I consulted
does its development and quality assurance on its disaster recovery site, to ensure
that the site remains an exact copy of its data center.
Disaster recovery solution options
The following is a list of the various database disaster recovery options available
and their pros and cons:
Backup and restore
The backup and restore option is conceptually simple and includes all
database objects, but at the same time, it is not scalable for large databases.
Transferring a database to a disaster recovery site can also take time and
therefore creates a high risk of data loss.

Log shipping
The log shipping option also includes all database objects and is easily
understood by DBAs. The exposure to data loss, when scheduled, is roughly a
minimal five minutes. On the downside, you are vulnerable to events that
break the log shipping chain, such as changing the database recovery model.
Log shipping is also not scalable, and you cannot back up the transaction log
while the database itself is being backed up.

Database mirroring
The low latency and automatic redirection of clients to the standby site is a
plus, but database mirroring is practical only for workloads that use the high-
performance mode that is available only in SQL Server's Enterprise Edition.
The success of your mirroring technology therefore depends on the speed
and available bandwidth of your network.
Database mirroring also requires your database to remain in full recovery
mode. Those using SQL Server 2008, however, can compress their database
mirroring traffic, resulting in less bandwidth consumption for your mirroring
sessions.

Replication
The replication option can selectively replicate a subset of the data or
objects. With bi-directional transactional replication or peer-to-peer
replication, failover and failback are also unproblematic. Latency, however,
can be very high during batch operations, and not all database objects are
replicated.
With SQL Server 2005 using bi-directional transactional replication or peer-to-
peer replication, you may need to disconnect users from your database as
you make schema changes, although SQL Server 2008 does not require this.
peer-to-peer replication is an Enterprise Edition-only feature, and bi-
directional transactional replication can be set up only using stored
procedures.

Santosh Kumar Vellala Source: www.whatis.com

 Software database mirroring
Solutions such as software database mirroring typically work at the file
system level. They filter changes to the file system and replicate the ones
you select to be mirrored. If desired, you can mirror all changes to your
database's MDFs, NDFs, and LDFs. The software database mirroring solution
then copies these changes to the destination. They can typically also do
compression on the fly.
These technologies tend to be low cost, low bandwidth and highly reliable,
with simple failover and failback. Nevertheless, older versions of the software
would require some recovery time before the destination server was
available, and Microsoft may not support database problems occurring with
these technologies.

Hardware database mirroring

Finally, hardware database mirroring solutions involve a split write: An
application issues a write operation on the source server, which is written to
the destination server, and the application can then continue with the next
operation. This is a robust option that provides no data loss. The disaster
recovery site, however, is not accessible while being mirrored to. These
solutions are also costly and involve latency.
ABOUT THE AUTHOR:
Hilary Cotter has been involved in IT for more than 20 years as a Web and
database consultant. Microsoft first awarded Cotter the Microsoft SQL Server MVP
award in 2001. Cotter received his bachelor of applied science degree in mechanical
engineering from the University of Toronto and studied economics at the University
of Calgary and computer science at UC Berkeley. He is the author of a book on SQL
Server transactional replication and is currently working on books on merge
replication and Microsoft search technologies. Cotter can be contacted at
hilary.cotter@gmail.com.

Santosh Kumar Vellala Source: www.whatis.com