Disaster recovery with sql server
•Download as PPTX, PDF•
0 likes•1,151 views
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.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (13)
Similar to Disaster recovery with sql server
Similar to Disaster recovery with sql server (20)
Disaster recovery with sql server
- 2. Agenda Definitions Failover Cluster Database Snapshots Log shipping Database Mirroring
- 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.
- 11. Log Shipping
- 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.
Editor's Notes
- 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.