Discusses various solutions for recovering data from a SQL Server database if a disaster occur.

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

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
2

3. Terminology (contd).,
• According to :
http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/06/15/an-overviewof-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” .
3

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

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).
5

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

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!!!
7

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
8

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
9

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

11. Log Shipping
11

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

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

14. How Snapshot Replication Works?
14

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

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

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

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

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

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

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

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

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/eBook/Computers%20&%20Internet/Pro%20SQL%20Server%20Disaster%
20Recovery.pdf
23

24. Thank You!
24