Sunteți pe pagina 1din 24

SQL Server Disaster Recovery

http://www.sql-programmers.com/

Terminology
For clarity, well 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

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

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

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

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 DBAs, or other key people. Know your SLA(service-level agreement)s and choose appropriate technology.

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

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

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

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

11

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

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

How Snapshot Replication Works?

14

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

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

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

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

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

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

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. Dont ignore any runtime errors.
21

Summary
Murphys 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

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

Thank You!

24

S-ar putea să vă placă și