Documente Academic
Documente Profesional
Documente Cultură
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
Wars
Strikes Human error Viruses, etc.
4
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
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.
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.
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
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
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
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
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.
Can have a third optional server called Witness server for Auto Failover.
18
Acknowledge
Constantly redoing on mirror
19
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