This document discusses various disaster recovery strategies for databases, including definitions, preparing disaster recovery plans, failover clustering, log shipping, and database mirroring. It provides details on how each strategy works, key terms, and general recommendations for testing and maintaining disaster recovery plans. Log shipping is described as shipping transaction log backups from a primary to secondary server to maintain an unrecovered copy, while database mirroring transfers log records in real-time between a principal and mirror database.
3. Definitions
“Disaster recovery planning is the work that is
devoted to preparing all the actions that must
occur in response to a disaster. The planning
includes the selection of a strategy to help
recover valuable data. The selection of the
appropriate disaster recovery strategy depends
on your business requirements.”
5. Prepare a DRP document
Include every possible information:
System architecture (How the
system/application works)
How many systems are involved and what their
names are.
Their IP Addresses, drive information, file
locations
Software installed, Contact information of
DBA‟s, or other key people.
Know your SLAs and choose appropriate
technology.
6. Prepare a DRP document(cont.)
Include every possible information…
Step by step guide on how to recover each of
your system based on different disaster
scenarios (Including timelines for recovery)
Security information, jobs/schedule
information, etc.
Make it a reminder for self that any system
changes should be updated in this guide.
Test, test and test!!!
8. Log Shipping
An automated method of maintaining a
warm standby server
Based on SQL Server's backup and restore
architecture. Uses the transaction log to
track changes
Relatively low-tech and inexpensive
„Ships' (copies and restores) a production
server's transaction logs to a standby server
9. Log Shipping (Key terms)
Primary Server:
Contains your primary database.
SQL Server Agent makes periodic transaction
log backups to capture changes.
Secondary Server
Contain an unrecovered copy of the production
database.
One standby server can contain standby
databases from multiple primary servers.
10. Log Shipping (Key terms) cont…
Monitor Server (Optional)
Monitors the status of the log-shipping jobs on
the primary and each standby server.
One monitoring server can monitor multiple
primary-standby server pairs.
Should use a server other than the primary or
the standby to detect problems on either
server.
12. Database Mirroring
Newly introduced with SQL Server 2005.
Maintains a copy of the principal database
as a mirror.
Transfers log records from principal to
mirror server instance.
Works with all hardware that supports SQL
Server 2005.
Automatic client redirection (using .NET 2.0)
Can have a third optional server called
Witness server for Auto Failover.
13. Database Mirroring -Synchronous
Commit
Write to
local log
Transmit to mirror
Write to
remote log
Log
Acknowledge
Committed
in log
Constantly
redoing on mirror
Acknowledge
DBDB Log
1
2
2
3
4
5
6
7
14. Database Mirroring Enhancements
Enhancements in SQL 2008
Compression of stream data for which at least
a 12.5 percent compression ratio can be
achieved.
Automatic Recovery from Corrupted Pages.
Page read-ahead during the undo phase.
Improved use of log send buffers.
15. General Recommendations
Backup your system databases after
modifications.
Test if backups are restorable.
Practice / Test your disaster recovery plans.
Documentation is not only for you.
Keep dedicated DR Server ready.
Use BACKUP CHECKSUM features.
Run DBCC CHECKDB regularly.
Don‟t ignore any runtime errors.
Notas del editor
Failover clusteringMicrosoft SQL Server failover clustering is designed to failover automatically if a hardware failure or a software failure occurs. You can use SQL Server failover clustering to create a failover cluster for a single instance of SQL Server 2000 or for multiple instances of SQL Server 2000. Failover clustering allows a database system to automatically switch the processing of an instance of SQL Server from a failed server to a working server. Therefore, failover clustering is helpful if an operating system failure occurs or if you perform a planned upgrade of the database system resources. Also, failover clustering increases server availability with no downtime.Because failover clustering is designed for high server availability with almost no server downtime, the clustered nodes should be geographically close to each other. Failover clustering may not be useful if a disk array failure occurs.
Can be done between 32 bit and 64 bit
The primary server in a log shipping configuration is the instance of the SQL Server Database Engine that is your production server. The primary database is the database on the primary server that you want to back up to another server. All administration of the log shipping configuration through SQL Server Management Studio is performed from the primary database.The secondary server in a log shipping configuration is the server where you want to keep a warm standby copy of your primary database. A secondary server can contain backup copies of databases from several different primary servers. For example, a department could have five servers, each running a mission-critical database system. Rather than having five separate secondary servers, a single secondary server could be used. The backups from the five primary systems could be loaded onto the single backup system, reducing the number of resources required and saving money. It is unlikely that more than one primary system would fail at the same time. Additionally, to cover the remote chance that more than one primary system becomes unavailable at the same time, the secondary server could be of higher specification than the primary servers.The secondary database must be initialized by restoring a full backup of the primary database. The restore can be completed using either the NORECOVERY or STANDBY option. This can be done manually or through SQL Server Management Studio.
The optional monitor server tracks all of the details of log shipping, including: > When the transaction log on the primary database was last backed up. >When the secondary servers last copied and restored the backup files.>Information about any backup failure alerts.The monitor server should be on a server separate from the primary or secondary servers to avoid losing critical information and disrupting monitoring if the primary or secondary server is lost. A single monitor server can monitor multiple log shipping configurations. In such a case, all of the log shipping configurations that use that monitor server would share a single alert job.
The following figure shows a log shipping configuration with the primary server instance, three secondary server instances, and a monitor server instance. The figure illustrates the steps performed by backup, copy, and restore jobs, as follows:1. The primary server instance runs the backup job to back up the transaction log on the primary database. This server instance then places the log backup into a 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.2. Each of the three secondary server instances runs its own copy job to copy the primary log-backup file to its own local destination folder.3. Each secondary server instance runs its own restore job to restore the log backup from the local destination folder onto the local secondary database.
Auto Page RepairA database mirroring partner running on SQL Server 2008 Enterprise or later versions automatically tries to resolve certain types of errors that prevent reading a data page. The partner that is unable to read a page requests a fresh copy from the other partner. If this request succeeds, the unreadable page is replaced by the copy, which usually resolves the error.
Practice or test your disaster recovery plans at least once every six months.