Downloaded 27 times
More Related Content
Similar to Sql disaster recovery
Sql disaster recovery
- 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)., • Accordingto : 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 • • • • • • • Typeof 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? • • • • • Considerthe 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 DRPdocument • 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 DRPdocument(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 • Anautomated 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 (Keyterms) • 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.
- 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 • Snapshotreplication 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 ReplicationWorks? 14
- 15. Transactional replication • Youcan 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 disadvantagesof 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 disadvantagesof 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 introducedwith 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 Constantlyredoing 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 yoursystem 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 Lawon 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.
- 24.
Editor's Notes
- #3 A disaster is the tragedy of a natural or human-made hazard that negatively affects society or environment. Disaster recovery is the process, policies and procedures related to preparing for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induceddisaster.“Disaster Recovery” and “Offsite Disaster Recovery” are a subsets of Business Continuity. “Business Continuity” planning includes everything that needs to addressed to allow business to function, including communication, personnel, logistics, etc.
- #7 A service-level agreement (SLA) is a contract between a network service provider and a customer that specifies, usually in measurable terms, what services the network service provider will furnish.
- #11 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.
- #15 By default, all three types of replication use a snapshot to initialize Subscribers. The SQL Server Snapshot Agent always generates the snapshot files, but the agent that delivers the files differs depending on the type of replication being used. Snapshot replication and transactional replication use the Distribution Agent to deliver the files, whereas merge replication uses the SQL Server Merge Agent. The Snapshot Agent runs at the Distributor. The Distribution Agent and Merge Agent run at the Distributor for push subscriptions, or at Subscribers for pull subscriptions. Snapshots can be generated and applied either immediately after the subscription is created or according to a schedule set at the time the publication is created. The Snapshot Agent prepares snapshot files containing the schema and data of published tables and database objects, stores the files in the snapshot folder for the Publisher, and records tracking information in the distribution database on the Distributor. You specify a default snapshot folder when you configure a Distributor, but you can specify an alternate location for a publication instead of or in addition to the default.
- #16 Note Replication is not designed for the maintenance of warm standby servers. With replication, you can use replicated data at the subscriber to generate reports. You can also use replication for other general uses without having to perform processing on the relatively busy publisher.
- #21 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.