Business Continuity SQL Server 2008 - Dell Executive Summary This whitepaper explores the major business continuity options native to Microsoft® SQL Server 2008. The main considerations

Native Business Continuity Options in Microsoft® SQL Server™ 2008

A Dell Technical White Paper

Database Solutions Engineering By

Murali Krishnan . K

Dell Product Group January 2010

2

Executive Summary

This whitepaper explores the major business continuity options native to Microsoft® SQL Server™ 2008. The main considerations for implementing Backup and Restore, Log Shipping, Replication, Database Mirroring, and Database snapshot features are discussed in detail. Aspects of implementing these Microsoft® SQL Server™ 2008 features are appropriately quantified using pertinent lab exercises. Based on the experiments, the whitepaper provides recommendations for implementing a robust business continuity solution.

In addition to providing information about these technologies, this paper shares the results of laboratory exercises intended to help optimize their relevance to a comprehensive business continuity plan. It examines how differential backups can reduce the backup window, and explores the benefits of compressing transaction log backups in a log shipping process. The paper also compares the performance of various subscription models for database replication, and illustrates the functionality of automatic page repair in database mirroring.

These findings, along with the relevant details regarding each native feature, will enable database administrators and solutions architects to determine where each feature can be used to protect their critical data.

THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND.

© 2009 Dell Inc. All rights reserved. Reproduction of this material in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.

Dell, the DELL logo, PowerEdge, and PowerVault are trademarks of Dell Inc. Quest is a registered trademark of Quest Software, Inc. Microsoft and SQL Server are registered trademarks of Microsoft in the United States and/or other countries.

Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell disclaims proprietary interest in the marks and names of others.

Native Business Continuity Options – Microsoft SQL Server 2008

3

Contents

Executive Summary ....................................................................................................................................... 2

Introduction .................................................................................................................................................. 4

Overview of SQL Server 2008 Business Continuity Options ......................................................................... 4

Common Considerations in Service Level Agreements ............................................................................ 5

Overview of Laboratory Test Methodology .................................................................................................. 5

Test Configuration ..................................................................................................................................... 5

Native Backup and Restore ........................................................................................................................... 7

Test Scenario ............................................................................................................................................. 7

Results and Analysis .................................................................................................................................. 8

SQL Server 2008 Database Recovery Models ............................................................................................... 9

Log Shipping .................................................................................................................................................. 9

Test Scenario ........................................................................................................................................... 10

Results and Analysis ................................................................................................................................ 11

Replication .................................................................................................................................................. 12

Test Scenario ........................................................................................................................................... 14


Database Mirroring ..................................................................................................................................... 16

Database Snapshots .................................................................................................................................... 18

Conclusions and Recommendations ........................................................................................................... 19

References .................................................................................................................................................. 22

Appendix A: Database Mirroring – Automatic Page Repair ........................................................................ 23

Test Scenario ........................................................................................................................................... 23


4

Introduction

Business continuity solutions are an important part of any business, as data is a key component in business processes for all organizations. As businesses grow, the need to safeguard data often becomes more important. Much of this vital data is stored in database systems, such as Microsoft® SQL Server™ 2008. System downtime may be unacceptable and is often costly for organizations; protecting SQL Server data is therefore a critical part of many business continuity plans.

To minimize the risk of downtime, organizations should implement a business continuity strategy. Business continuity planning is the process that an organization uses to recover business operations with minimal data loss in the least amount of time in case of disaster, with cost effective solutions. For example, an online store cannot process orders or an online business cannot sell their product without a functional database. A small amount of database downtime may lead to a significant loss of business opportunity or revenue. Platform malfunctions, operational problems, virus attacks, denial of service incidents, and sabotage are all scenarios that may result in the loss of system availability.

In general, the foundation of a business continuity operation is a highly available system that is easily recoverable when needed. Microsoft® has included many technologies that can be used to enable high-availability and disaster recovery capabilities for a Microsoft® SQL Server™ 2008 database solution. This paper explores these technologies and examines relevant use cases where each of the business continuity techniques is applicable.

Overview of SQL Server 2008 Business Continuity Options

There are many features provided by Microsoft® SQL Server™ 2008 that can be used to implement business continuity plans. This paper explores the following native features:

• Native Backup / Restore

• Log Shipping

• Replication

• Database Mirroring

• Database Snapshots

This whitepaper will exclusively focus on technologies provided by Microsoft® SQL Server™ 2008. Other popular techniques, such as implementing storage-based mirroring or replication, deploying SQL Server in a Windows Server Failover Cluster, or using functionality provided within a virtualized infrastructure are beyond the scope of this paper. Many such techniques have been discussed in other papers that are available on http://www.dell.com/sql.

http://www.dell.com/sql�


5

Common Considerations in Service Level Agreements

The definition of high-availability will differ from one organization to another. Some organization may need business data to be available 24 hours a day, 7 days a week and other firms may need their data only during business hours.

High-availability does not always mean “all the time” operation. But business data should be available when clients need access. Several businesses may need to achieve data availability in the order of “five nines” which means the system should be available to the clients 99.999% of the time, in addition to the in-place data protection strategies. To understand organizational needs for business continuity, many databases and applications specify a Service Level Agreement (SLA). Within the SLA, Recovery Time Objective (RTO) and Recovery Point Objective (RPO) metrics are commonly defined. These factors play a key role in defining the high-availability & disaster recovery plan.

Recovery Time Objective (RTO) defines the tolerable maximum length of time that a system can be unavailable and Recovery Point Objective (RPO) refers to how much data can be lost. These organizational objectives reflect the mission critical nature of the business. For example, a stock exchange system should maintain a near zero RTO and RPO, as they cannot afford to lose any information. But the ecommerce applications may afford to have a non-zero RPO and RTO.

Overview of Laboratory Test Methodology

This section provides the tests and analysis of the native Microsoft® SQL Server™ 2008 business continuity options. The following features were tested using specific use case configurations. Each feature is documented and explained later in paper.

• Partial Differential Backup functionality

• Log Shipping process with Non-compressed backup vs. Compressed backup

• Transaction Replication: Push Subscription vs. Pull Subscription

• Automatic page repair feature in Database Mirroring

Test Configuration

To analyze native Microsoft® SQL Server™ 2008 business continuity options , three dedicated Dell™ PowerEdge™ servers were set up with Microsoft® SQL Server™ 2008 Enterprise Edition. The R710 housed the primary production database from which performance metrics were derived. The other servers performed secondary or stand-by roles, based on the requirements of each use case. The configuration details for these servers are provided in Table 1.

http://infocenter.sybase.com/help/topic/com.sybase.help.ase_15.0.rl15ug/html/rl15ug/rl15ug6.htm�

6

Table 1: Test Configuration

Test Configuration Primary Database Server

One Dell™ PowerEdge™ R710 server with: • Two Intel® Xeon® quad-core 2.40 GHz CPU • 12 GB of RAM

Available Secondary or Stand-by Servers

One Dell™ PowerEdge™ 2950 server with: • Two Intel® Xeon® 2.83 GHz CPU • 16 GB of RAM

One Dell™ PowerEdge™ 1950 server with: • Two Intel® Xeon® 3 GHz CPU • 4 GB of RAM

Storage Array MD1120 with twenty-four 73GB , 15k SAS Drives Database Volumes Two volumes, 700GB each Operating System Microsoft Windows 2008 server x64 SP2

A single instance of Microsoft® SQL Server™ 2008 Enterprise Edition with SP1 was installed on each database server. A sample database was created by the Quest Benchmark Factory Tool, and the data was populated based on the data requirements. Table 2 describes some of the tools that were used to generate and monitor representative databases and workloads.

Table 2: Test Tools

Tools and Usage Benchmark Factory for Databases

Used to populate data as per the test requirement.

SQL Server 2008 Data Collector

The data collector is a new component with Microsoft® SQL Server™ 2008. It collects performance data in the constant or user defined intervals for a given environment. It provides performance counters in the relational database format.

Windows Performance Monitor

The Windows Performance Monitor (perfmon) is a tool provided in Microsoft Windows to track and monitor server activities. The performance monitor was used to capture the server performance counters including Processor - %idle time, Physical Disk - Avg.Disk Queue Length, Avg. Disk sec/Read, Avg. Disk sec/Write , Disk Reads/sec and Disk Writes/sec , when the database was performing data population.


7

Native Backup and Restore

Backup and recovery are critical elements of a business continuity plan. Where other techniques discussed in this paper may facilitate continuing operations in the event the primary database becomes unavailable, they may not be sufficient to protect against the potential for data corruption. Native backup and restore provides a facility to mitigate such a scenario. The different backup types offered by SQL Server 2008 are listed in Table 3.

Table 3: Backup Types

Full / Partial Full Backup captures the entire database, including the required transaction logs. Partial Backup acts similarly, but on a specific file group.

Differential Captures only the data that has changed since the last full or partial backup was taken.

Transaction Log Captures the transaction log that was active and includes the log records that were not previously backed up.

A partial backup enables the backup of data in the primary file group or any read/write file groups. A differential partial backup will backup only the data extents that have changed in the file group since the last full or partial backup.

SQL Server 2008 also provides backup compression, which is an effective method for reducing storage requirements for backup files. This can often also help improve the speed of backup and recovery, but incurs slightly more processor overhead. Backup compression is independent of data compression, and both can be used either individually or simultaneously.

Test Scenario

The test explored the benefits offered by differential backup functionality. A partial differential backup is a copy of all pages modified since the last partial backup. As discussed earlier, a partial backup enables backup for the primary file group and all read/write file groups.

A database was created with three file groups, designated as Primary, Read/Write and Read-only. The file groups were designed to accommodate frequently changing data in the Read/Write file group, less frequently changing data in the Primary file group, and static data in the Read-only file group.

The “Read/Write” file group was configured with partial back up and differential partial backup. For purposes of this test, an SLA that specified a partial backup of the “Read/Write” file group every 12 hours, supplemented by a differential partial backup every hour was assumed. When a recovery is needed, the appropriate partial backup may be used with the subsequent differential partial backups. This SLA effectively provides a maximum RPO of one hour, and a variable recovery time which may require time for restoration of the not only the partial backup, but also up to eleven differential

8

backups. While it is not relevant to this test, the remaining file groups would also need to be protected according to other terms in the SLA, otherwise full recovery of the entire database may not be possible.

In the specific given test scenario, when the “Read/Write” file group was backed up , the partial backup generated 6049 data pages with a file size of 48.2 MB, as shown in Figure 1.

Figure 1: Partial Backup Message

The next differential partial backup generated 265 data pages with a file size of 3.23 MB, as shown in Figure 2.

Figure 2: Differential Partial Backup Message

Results and Analysis

As expected, it was observed that the differential partial backup captures only those data pages that have changed since the last partial backup of a given file group. This can reduce the length of each backup window, and requires less storage space than performing full backups to attain the same RPO objectives. Frequent backups of the data are useful to decrease the risk of data loss, but full backups can be very time-consuming, and divert some processor and storage I/O resources away from handling incoming transactions. Differential backups minimize this impact, but will generally require additional steps and time when recovery is necessary.


9

SQL Server 2008 Database Recovery Models

In Microsoft® SQL Server™ 2008, Understanding the recovery models is essential to developing an effective business continuity strategy. The recovery model determines how the transaction log is managed by SQL server.

Table 4: Recovery Models

Full Database Server fully logs all transaction. It supports point-in-time recovery.

Bulk- Logged Database Server fully logs most of the transactions and minimally logs bulk operation.

Simple Database server automatically truncates the transaction log at regular intervals. If enough space is not allocated for logs, simple recovery model may lead to data loss.

Simple recovery allows log file reuse regardless of whether a transaction log backup exists. Because this could inadvertently lead to data loss, many of the techniques described in this paper cannot be used in conjunction with the simple recovery model. The full recovery and Bulk-Logged recovery models are often preferable; they provide more extensive data protection, but require careful understanding of the log file size and backup policies. If the log files are full, these models may prevent the database from accepting new transactions until a transaction log backup has been performed.

Log Shipping

Log Shipping is a disaster recovery solution that provides quick availability and recovery of the Microsoft® SQL Server™ 2008 database. It acts at the database level and configuration consists of a source database in the primary server and a target database in the secondary (stand by) server. The primary database has to be set to the full or the bulk recovery model to implement log shipping. In log shipping, the source database transaction logs from the primary server are backed up, copied and restored to a target database in the secondary server in constant intervals. In real time scenarios, the log shipping interval should be decided based on the RTO and RPO considerations of the organization. By doing this, the stand by server is updated periodically based on the primary database activities. Optionally a monitor server may be configured with the log shipping configuration. In that case, the history and status of log shipping operations can be offloaded to the monitor server.

When log shipping is enabled, three SQL Server agent jobs are created. The first job is on the primary server to perform backup. The second and third jobs are on the secondary server to copy the transaction logs from the primary server and to restore them in the secondary database. If a monitor server is configured for log shipping, an additional job will be created on the monitor server.

10

Figure 3 shows a log shipping configuration with a primary server and one secondary server; additional secondary servers may be configured if needed. There is no monitoring server in this particular configuration. The following steps were used to perform log shipping:

1. The primary server instance runs the backup job to backup the transaction log on the primary database. The transaction log file is sent to the shared backup folder.

2. The secondary server instance runs the copy job to copy the transaction log files from the primary server share folder to its local folder.

3. The secondary server instance runs the restore job to restore the transactional log backup from the local folder onto the local secondary database with the NORECOVERY option.

Figure 3: Log Shipping

Because log shipping employs transaction log backups, it is interesting to how backup compression may be able to reduce the size of the log backup that is transmitted to the secondary server.

Test Scenario

To analyze the impact of log shipping with compressed backup, the following database configurations were setup:

• A complete log shipping process with non-compressed backup

• A complete log shipping process with compressed backup

The performance counters were captured to calculate CPU utilization and average disk read per second for each test configuration. A TPC-C data load of around 29GB was pumped to the database using benchmark factory for Databases tool in around 1 hour and 45 minutes, using database scale factor 450. After the data population through benchmark factory tool, three of the tables in the schema (17GB of data size in total) were bulk copied to simulate a bulk insert. The log shipping time interval was 15


11

minutes to make sure that enough logs are generated during the time period. This interval plays a critical role in determining the RPO associated with a log shipping implementation. The RTO will be dependent on processes that enable applications to connect to the secondary database, which may require modification of connection strings, etc.


The size of the log files generated during the log shipping interval (15mins) and the corresponding processor utilization were captured. Table 4 shows the maximum size of the log file generated during the test period and the corresponding processor utilizations during the log shipping period.

Table 5: Impact of Backup Compression on Log Shipping

Max Log file size in MB Processor Time Non-Compressed Compressed Non-Compressed Compressed

24820.58 14406.20 11.38 14.78

Figure 4 shows the file size that was generated in the particular log shipping process. In the figure, the X- axis represents the log shipping backup interval and Y-axis represents the file generated by the log shipping process.

Figure 4: Log Shipping – Transaction Log Backup File Size

The data load was high during the eighth interval; this is due to extra work load incurred by simulating a bulk-load operation.

0

5000

10000

15000

20000

25000

30000

1 2 3 4 5 6 7 8 9

File

siz

ein

MB

Time Interval

Transaction Backup File Size

Non-Compressed

Compressed

12

Figure 5 shows the processor time for the log shipping time. In the figure, the X- axis represents the log shipping backup interval, and Y-axis represents the processor time percentage.

Figure 5: Log Shipping – CPU Utilization

The overall effects of these factors are measured based on CPU utilization and the reduction in transaction log size. Based on the test, compression backup increases CPU usage over all but produces backup transaction log comparatively 38% - 64 % smaller than the non- compressed backup transaction log size for the particular workload. Although there is a CPU overhead at the database servers, the compressed log shipping may require less network bandwidth due to the reduced log size. Therefore, the compressed back up options may be favorable for business continuity when the primary and secondary servers are geographically separated, placing bandwidth limitations on the network.

Replication

Replication is useful when it’s desirable to have the same data on multiple database servers. Replication may be configured to be executed continuously, at specified intervals, or on demand. The replication interval should be aligned with the RPO objectives of the organization. An organization with a very small RPO should ideally have a continuous replication configured between the database servers. As with log shipping, the RTO can be influenced by external factors, such as the potential need to configure application servers to connect to an alternate database server. Since replication may be performed across multiple database servers, this model may also be useful for distributing data in branch office scenarios.

0

2

4

6

8

10

12

14

16

18

1 2 3 4 5 6 7 8 9

% C

PU U

tiliz

atio

n

Time Interval

Processor Time (%)

Non-Compressed

Compressed


13

In Microsoft® SQL Server™ 2008, there are three replication models available as shown in Table 6 and many different physical models. A replication model determines what is replicated, and the physical model defines the role and responsibilities of the individual servers.

Table 6: Replication Models

Replication Model Snapshot Replication Takes snapshot of the database and moves it to another database.

This replication type is appropriate for databases where the content rarely changes. This type of replication may also be used to make the history data available for reporting servers.

Transaction Replication Copies the entire database the first time and then synchronizes the database regularly or on demand. This replication type is appropriate for frequently changing databases.

Merge Replication The data are synchronized between multiple servers by exchanging all rows that have changed since the last synchronization. This replication type is appropriate when there is not a constant connection between servers.

Each of the above replication models differ in the method of updating the subscriber databases and the latency involved in the process.

Once the replication model is decided, the required physical model can be defined. Example physical model replication configurations are as listed below:

• Central publisher and multiple subscribers

• Multiple publishers and multiple subscribers

• Multiple publishers and a single subscriber

• Single publisher and a remote distributor

A publisher is defined as a database server where data is available for the replication and a subscriber is a different database server where the data are copied. Figure 6 shows a replication configuration with a publisher and subscriber server; additional subscriber servers can be configured if needed. The distributor service can be configured in the publisher server or on another remote server. For our test, the distributor was configured on the publisher server. In replication, agents are used to pass information between the publisher to the distributor, and from the distributor to the subscriber.

14

Figure 6: Transactional Replication Setup

It is useful where there are multiple copies of a database and the update may be made with any copy of the database with minimum update latency, based on the RPO/RPO considerations.

Test Scenario

In the above replication configuration, the changes made at publisher are sent to subscriber. We can define this process to start from either the publisher or subscriber. Microsoft® SQL Server™ 2008 provides this option by specifying either a push subscription or a pull subscription. In the push subscription, the replication request comes from the publishers, and in the pull subscription it comes from subscriber.

This test compared the performance of push and pull subscription models in a typical transaction replication setup. The publisher is a single instance Microsoft® SQL Server™ 2008 Enterprise Edition with SP1. The subscriber is setup on a different database server, with similar configuration. The replication was set to be performed continuously.

The following database configurations with continuous data population were setup for this test scenario:

• Push subscription with continuous data population

• Pull subscription with continuous data population

In the test, the distributor delivery latency performance counter shows the time in milliseconds elapsed between distributor and subscriber on the transaction delivery. The % processor time , memory - available bytes , network interface - output queue length counters were captured using the performance monitor to analyze the utilizations of CPU , memory and network respectively.


15


The maximum delivery latency and the processor utilizations at the subscriber and publisher are listed in the Table 7. The push and pull subscription delivery latencies data were grouped by the constant time interval of 8 minutes and the average was calculated accordingly. There were no bottlenecks in CPU, memory and Network in the Publisher or the Subscriber servers.

Table 7: Transactional Replication – Pull Subscription vs. Push Subscription

Subscription Model Max Delivery Latency

(in msec) Processor Time

Principal Subscriber Pull Subscription 68775.37 10.33 27.86 Push Subscription 169440.17 7.53 11.80

Figure 7 shows the push and pull subscription delivery latency in the transaction replication. The X- axis represents the replication interval and the Y-axis represents the delivery latency time in milliseconds.

Figure 7: Replication – Delivery Latency with Push and Pull Subscription

In Figure 7, the latency during the seventh interval was high due to extra data load incurred by simulating bulk data population.

From the test and analysis, pull subscription delivery latency may be 40% - 84% lower than push subscription.

Since production server may always be in use with many services and maintenance plan, it is recommended that if the primary server is over loaded with other operations the pull subscription is the appropriate option to enable the faster data replication and to reduce the primary server’s overhead.

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

1 2 3 4 5 6 7 8 9 10

Del

iver

y La

tenc

y

Time Interval

Delivery Latency in Push vs Pull Subscription

Delivery Latency (Push)

Delivery Latency (Pull)

16

Database Mirroring

Database mirroring is a software solution for high-availability at a database level. This feature was introduced in Microsoft SQL Server 2005, and the log transfer mechanism is used to provide database redundancy. Database mirroring enables disaster recovery solutions as the databases are setup on separate servers. With database mirroring, a copy of the critical database may be maintained in another instance and is updated automatically.

In Figure 8, the principal is the primary production database server where the source database is hosted and the mirror is the secondary database server where the mirror database is configured. The principal sends its transaction logs to the mirror server, whose copy of the database is updated either synchronously or asynchronously. The witness is and optional instance that monitors the principal and mirror and enables automatic failover to the mirror if the principal becomes unavailable. In case the mirror fails, the principal will continue functioning, and the database service is still available to the clients. If the witness is lost, the database mirroring session will continue to work but the automatic failover will not occur.

Figure 8: Database Mirroring with a Witness Server


17

Database mirroring has three operating modes, which are discussed in Table 8.

Table 8: Database Mirroring – Operating Modes

Operating Mode Description High Performance (asynchronous) The transaction is written to the principal database and the

transaction log is sent to the mirror server. The transaction is committed in the principal database without waiting for the acknowledgement from the mirrored database.

High Safety without automatic failover (synchronous)

The transaction is written to the principal database and the transaction log is sent to the mirror server. The transaction is committed in the principal database after receiving the acknowledgement from the mirrored database. This makes sure that the principal and mirrored databases are exactly similar, but involves some transactional over head.

High safety with automatic failover (synchronous)

This operating mode will enable the automatic failover but will require a third server to take on the role of a “witness”. This mode also ensures transactions are written to the mirror before being committed on the principal. The witness ensures the automatic failover to the mirror if the principal becomes unavailable. It also ensures in the case of an automatic failover, the mirror is an exact replica of principal.

Database mirroring provides protection against system or disk failure. It also facilitates automatic or manual failover with clients transparently redirected to the mirrored database. Mirroring data can be accessed by creating a snapshot. In addition, the log compression feature in SQL Server 2008 enables the efficient utilization of the network resources for database mirroring.

SQL Server 2008 provides two key enhancements for database mirroring over what was offered in SQL Server 2005. First, all log data is compressed before being transmitted to the secondary server, which can reduce the network bandwidth that is required to support mirroring. Additionally, there is now the ability to use the mirror relationship to correct any torn data pages that are detected on either the primary or secondary database servers. The page repair functionality is explored in more detail in Appendix A.

18

Database Snapshots

A database snapshot is a read-only, static view of a source database at a specific time. A database snapshot is transactionally consistent with the source database at the point of the snapshot's creation.

A database snapshot can be taken only for whole database and not for particular database object since it operates at data page level. A data page is copied to the snapshot when a source database data page is modified for the first time; subsequent data modification in the source database data page will not be copied to the snapshot. In this way, the snapshot will have the same data from the point when it is created. While snapshots cannot protect from storage failures, they can provide insulation against certain types of corruption. As a result, they are often used in conjunction with mirroring and backups to help achieve SLA objectives.

Database snapshots are read-only, but can otherwise be accessed like any other database. In Figure 9, there are three snapshots available for a given database, and a reporting system is extracting data from “Snapshot 3.”

Figure 9: Database Snapshots

Database snapshots are useful for business continuity in the following ways.

• Recovery can be accomplished by using a snapshot to revert the database to the state when it the snapshot was created. Snapshots can be used for recovery to a specific state by creating them in a required point of time. However, if the database is reverted to a particular snapshot then later snapshots from that database will be deleted automatically.

• Snapshots may be created for accessing a mirrored database. Since data modification is continuous in a mirrored database, the new snapshot should be created if the client wants to have access to the new data.

• A Snapshot copy of a database may be used as the source for a backup operation.

Note that source database cannot be deleted if a snapshot is created for the database.


19

Conclusions and Recommendations

Implementing a robust business continuity solution requires a combination of process and technology. It is necessary to create clearly defined set of goals and objectives that ensures that solutions meet an organization’s RPO and RTO. Standby servers are a cost-effective and viable way for business to maintain SLA and BC efficiently.

The granularity of recovery and availability are important factors to be considered in deciding the business continuity options. The Microsoft® SQL Server™ 2008 native business continuity features may be compared as in Table 9.

Table 9: Feature Comparison

Log Shipping

Replication

Database Mirroring

Backup and Restore

Automatic Failover

No No Yes (configuration-

dependent)

No

Granularity of Recovery

Database Database Object Database Database or File group

The overall findings from lab experiments may be summarized as follows:

• Native Backup / Restore option provides the granular level of protection and enables the efficient use of storage capacity with some administrative over head.

• Log shipping feature with compressed backup enhances the network utilization and reduces the storage requirement. But it imposes CPU overhead on the primary database server.

• Replication provides flexible architecture (push and pull subscription) to efficiently utilize the database resources.

• Database mirroring provides automatic failover and the near real time disaster recovery solution, but it requires an additional server.

20

Table 10 outlines several considerations for deploying each of the native business continuity technologies in SQL Server 2008. A comprehensive plan is likely to use a combination of techniques to satisfy SLA requirements.

Table 10: Applicability of SQL Server 2008 Business Continuity Technologies

Feature Advantages / Disadvantages Recommendation Native Backup / Restore

Advantages : • Removable media support and protects against

disk failures. Disadvantages: • For a disaster recovery, a manual restore

process is required.

Backup is important regardless of any additional high-availability solutions that are in place. It is useful when database cannot be restored using any of the other methods.

Log Shipping Advantages : • It allows multiple secondary servers. • It covers all the database objects including

schema changes. • Near real time database that can remain secure

or can be configured to be opened for queries Disadvantages : • There is no automatic failover. • Cannot be configured on individual database

objects (Table, view etc...). • It has network overhead. • In case of missing log files reconfiguration may

be required for servers.

Log shipping acts at the database level and it takes care of schema changes. So if a client application uses multiple databases, then log shipping is the appropriate choice for implementing fail over.

Replication Advantages : • Can be configured on individual database

objects. • Wizard, Monitoring tools for the configuration

and troubleshooting. • Provides near real time disaster recovery. • Allows for geographically separated

configurations. • Supports disconnected architecture. • Allows Load balancing and high-availability Disadvantages: • Reconfiguration is complex.

Replication is a good choice when there is requirement for placing the same data on multiple servers. It is helpful in scenarios when disconnected databases need to be synced.


21

Feature Advantages / Disadvantages Recommendation Database Mirroring

Advantages : • Automatic failover. • Near real time failover of database Disadvantages: • High safety (synchronous) setting requires

network overhead and may slow database write performance.

• Requires additional server for “automatic failover”

Appropriate choice if there is a need to provide database connectivity with minimal down time.

Overall, Microsoft® SQL Server™ 2008 database provides several robust features that enable excellent business continuity solutions, with no additional cost. Each technique incurs some trade-offs between cost, performance, recovery points, and recovery times. The best combination of these technologies for a given database solution is dependent on both operational considerations and SLA objectives.

22

References

Dell Resources for Microsoft SQL Server

http://www.dell.com/sql

Business Continuity Solutions on Dell™ PowerEdge™ Servers - Microsoft® SQL Server™ 2005

http://www.dell.com/downloads/global/solutions/busi_con_sol_sql_opt_final.pdf

NOTE: Includes information about using Windows Server Failover Clustering with SQL Server

Dell Services

http://www.dell.com/services

Microsoft® SQL Server™ 2008 - High-availability Solutions Overview

http://msdn.microsoft.com/en-us/library/ms190202.aspx

Log shipping

http://technet.microsoft.com/en-us/library/bb895393.aspx

Best Practices for Replication

http://msdn.microsoft.com/en-us/library/ms151818.aspx

Database Mirroring Deployment & Administration

http://msdn.microsoft.com/en-us/library/bb934127.aspx

http://sqlcat.com/msdnmirror/archive/2009/02/09/minimize-downtime-with-db-mirroring.aspx

Disaster recovery options

http://support.microsoft.com/kb/822400

http://www.dell.com/sql�

http://www.dell.com/downloads/global/solutions/busi_con_sol_sql_opt_final.pdf�

http://www.dell.com/services�

http://msdn.microsoft.com/en-us/library/ms190202.aspx�

http://technet.microsoft.com/en-us/library/bb895393.aspx�

http://msdn.microsoft.com/en-us/library/ms151818.aspx�

http://msdn.microsoft.com/en-us/library/bb934127.aspx�

http://sqlcat.com/msdnmirror/archive/2009/02/09/minimize-downtime-with-db-mirroring.aspx�

http://support.microsoft.com/kb/822400�


23

Appendix A: Database Mirroring – Automatic Page Repair

SQL Server 2008 database mirroring can be used to fix torn data pages on either the primary or secondary database in a mirrored pair. This provides an additional layer of data security that can protect against certain types of corruption that may otherwise require the database to be restored.

Test Scenario

The automatic page repair feature in database mirroring allows for, database data-page to be recovered if it is corrupted. During the test scenario, a data page was intentionally corrupted to test the automatic database recovery using database mirroring. During the test case execution, DBCC checkDB command was used to check the DB integrity status.

The test methodology and observation are explained as follows:

• A sample database was setup on the principal database server and synchronous mirroring was configured between the principal and secondary servers.

• The failover was done and the mirroring server was made the principal server and the old principal server database was brought in to offline state.

• To simulate a torn page, information for a data page was deleted from the primary data file using a Hex Editor.

• Database Integrity check displays page header information error and incorrect data page Id error, shown in Figure 10.

Figure 10: Database Mirroring – Page Error Message

• The old principal database was brought online and the mirroring session resumed.

• Database failover was performed to make old principal as actual principal server. The Principal and the mirror were synchronized.

• In the process of synchronization the data page information was copied from the mirror server to the principal server and the page error was automatically resolved.


From the test, it demonstrated that database mirroring can trigger automatic page repair in the principal or mirror. When a principal encounters error pages, it sends the information to the mirror whether the same page is valid on its mirror copy. If it is found valid in the mirror database, then the specific page information is sent to principal and the page with the error is replaced. The database mirroring can repair the corrupted pages in either the principal or mirror, given that the other member database has a valid copy of the corrupted page. If a mirror database encounters the corrupt page, the

24

mirroring session is suspended and only resumes once all the corrupt pages have been repaired with copies from principal.

Reviewing the test and analysis, the automatic page repair feature in the mirroring process will take care of page related errors and therefore database integrity was maintained by the mirroring process without any extra effort. It saves a lot time and overheads in the Database maintenance process.

Documents

Business Continuity SQL Server 2008 - Dell Executive Summary This whitepaper explores the major business continuity options native to Microsoft® SQL Server 2008. The main considerations