SQL Disaster Recovery

1. SQL Server Disaster Recovery http://www.sql-programmers.com/

2. Terminology • For clarity, we’ll use the following definitions: • Disaster: an event that results in serious loss of data or service • Disaster Recovery: A process that allows continuation of business following a disaster, including manual methods • Offsite Disaster Recovery: A process that allows disaster recovery at a remote location (usually entire site) • Business Continuity: A process that includes disaster recovery and offsite disaster recovery as well as using systems to avert disasters, such as fault-tolerant hardware and software

3. Terminology (contd)., • According to : http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/06/15/an-overview-of-ha-dr-solutions-available-for-sql-server.aspx : “Disaster recovery efforts address what is done to re-establish availability after an outage. It refers to restoring your systems and data to a previous acceptable state in the event of partial or complete failure of computers due to natural or technical causes” .

4. Types of Disasters • Type of disasters • Natural Disasters: • Tsunami, • Fire • Power outage/failure • Organized disruptions • Theft • System failures • Legal issues • Wars • Strikes • Human error • Viruses, etc.

5. Why Disaster Recovery? • Consider the value of your data to your organization: • What would be the result if an hour's worth of database changes were lost? • A day's worth? • What about a complete loss of the database? • More than likely, your answers to the previous questions illustrate the need for a comprehensive disaster recovery plan (DRP).

6. 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 SLA(service-level agreement)s and choose appropriate technology.

7. 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) • Make sure you discuss DRP guide with all the parties involved. • Security information, jobs/schedule information, etc. • Make it a reminder for yourself that any system changes should be updated in this guide. • Test, test and test!!!

8. Database Snapshots • Read-only, consistent view of a database • Specified point-in-time • Modifying data • Copy-on-write of affected pages • Reading data • Accesses snapshot if data has changed • Redirected to original database otherwise

9. 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

10. 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.

11. Log Shipping

12. SQL Server Replication • Replication is a set of technologies for copying and distributing data and database objects from one database to another and then synchronizing between databases to maintain consistency. • Data replication is used to move the data from one server to another server in a consistent state. • Snapshot replication is used to copy an entire set of data from the publisher to the subscriber at the scheduled time. • Transactional replication is typically used in server-to-server scenarios that require high throughput, including: improving scalability and availability; data warehousing and reporting; integrating data from multiple sites; integrating heterogeneous data; and offloading batch processing.

13. Snapshot Replication • Snapshot replication distributes data exactly as it appears at a specific moment in time and does not monitor for updates to the data. Using snapshot replication by itself is most appropriate when one or more of the following is true: • Data changes infrequently. • It is acceptable to have copies of data that are out of date with respect to the Publisher for a period of time. • Replicating small volumes of data. • A large volume of changes occurs over a short period of time.

14. How Snapshot Replication Works?

15. Transactional replication • You can also use transactional replication to maintain a warm standby server. Transactional replication replicates the data on one server (the publisher) to another server (the subscriber) with less latency than log shipping. You can implement transactional replication at the database object level such as the table level. Therefore, Microsoft recommends that you use transactional replication when you have less data to protect, and you must have a fast recovery plan.

16. Advantages and disadvantages of using transactional replication • Advantages • You can read data on a subscriber while you apply changes. • Changes are applied with less latency. Note : This advantage may not be applicable if either of the following is true: • Replication agents are not set to Continuous. • Replication agents are stopped because of errors that may occur during replication.

17. Advantages and disadvantages of using transactional replication • Disadvantages • Schema changes or security changes that are performed at the publisher after establishing replication will not be available at the subscriber. • Typically, switching servers erases replication configurations. Therefore, you have to configure replication two times: When you switch to the subscriber. • When you switch back to the publisher. • If a disaster occurs, you must manually switch servers by redirecting all the applications to the subscriber.

18. 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.

19. Database Mirroring -Synchronous Acknowledge Commit Acknowledge Constantly redoing on mirror Transmit to mirror Write to local log Committed in log Write to remote log

20. 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.

21. Best Practices • 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.

22. Summary • Murphy’s Law on Disaster… • If there is a possibility of several things going wrong, the one that will cause the most damage will be the one to go wrong. • If you fail to plan, you are planning to fail. • Off-site backups always help. • Auto page repair is a band-aid.

23. References • http://www.sql-programmers.com/sql-disaster-recovery.aspx • http://support.microsoft.com/kb/822400 • http://databases.about.com/od/sqlserver/a/disaster.htm • http://msdn.microsoft.com/en-us/library/ms151198.aspx • http://203.158.253.140/media/e-Book/Computers%20&%20Internet/Pro%20SQL%20Server%20Disaster%20Recovery.pdf

24. Thank You!