Admin High Availability

  • 785 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
785
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
30
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Amit Bansal CTO eDominer Systems P Ltd | Peopleware India
  • 2. Who is Amit Bansal? CTO, eDominer Systems & Peopleware India Conducted more than 200 workshops on SQL Server & BI for top notch IT companies world wide Microsoft MVP for SQL Server Microsoft Certified Trainer Advisory Council member Speaker at TechED India, TechED US & TechED Europe Technical Reviewer – MSL courses on SQL Server SME – SQL Server 2008 certifications UG Lead (Delhi NCR) – Culminis Manager – www.WeTogether.in, www.DelhiDevs.com, www.BlogB oard.in
  • 3. Agenda? --- TODO Intro to High-Availability/DR Key Terms Always On Technologies Overview, Planned / Unplanned downtime When to use Enhancements in SQL Server 2008 Combining Technologies Summing it up
  • 4. What is Availability? Availability is defined by an implicit or explicit application specific Service Level Agreement Example The ordering system is considered available when orders can complete in less than one minute. The maximum downtime acceptable is five minutes per month. Downtime = the amount of time when the SLA is not met Typically uptime is tracked (i.e. 99.993%), which doesn’t include the “planned” downtime The SLA should be used during design, deployment, and production monitoring phases of the application lifecycle
  • 5. Intro to Disaster Recovery Processes and procedures designed to restore business operations due to a natural or human- induced disaster Typically involves providing redundancy spanning multiple sites or across geographic regions
  • 6. Key Terms SLA Metrics: Recovery Point Objective (RPO) = data loss How much data can you lose? guided by criticality of application data Recovery Time Objective (RTO) = downtime How much downtime can you tolerate? guided by availability requirements Local High-Availability (Local HA) Site Disaster Recovery (Site DR)
  • 7. Always On Technologies Unplanned Downtime SAN/RAID Backup and Restore Log Shipping Database Mirroring Failover Clustering Replication Planned Downtime Rolling Upgrades and Patching Online Operations Resource Governor Database Snapshots
  • 8. Always On Availability Scenarios System Administration Upgrades, Index rebuilds… Logical Errors (User or Application) Incorrect data modifications, accidental changes… Site Disaster Hurricanes, fires… Hardware Failures Memory, network, disks… Software Failures Bugs
  • 9. Categorizing Availability On Solutions High Availability Solution Requirement System Administration Online management Recovery from application or Logical recovery user errors Site disaster protection Database or storage mirroring Database workload scale out Replication with redundancy
  • 10. Online Management Downtime Scenarios Applying a patch or upgrade Moving a table as part of system maintenance Deploying a new version of an application Recovering from a corrupted data file Always On Solutions Rolling Upgrades utilizing Database Mirroring, Log Shipping, or Replication Fast recovery Online alter table, index create, index rebuild Online granular restore
  • 11. Categorizing Availability On Solutions High Availability Solution Requirement System Administration Online management Recovery from application or Logical recovery user errors Site disaster protection Database or storage mirroring Database workload scale out Replication with redundancy
  • 12. Recovery from User or Application Errors Downtime Scenarios A table is accidentally dropped An application makes incorrect updates to data A user possibly made unauthorized changes to data Always On Solutions View point in time snapshots of the system Take database snapshots at intervals Log ship to another site using restore delay/standby options Compare table to older version using tablediff utility Track history of DML statements Use SQL Trace or customized replication
  • 13. Log Shipping How it works Update orders set…. Primary Instance Secondary Instance Primary Secondary DB Log Log DB Backup Restore Transaction Log Backup Transaction Log Backup Log Backup Transaction Log Backup Transaction Log Backup Transaction Log Backup Transaction Log Backup Copy Transaction Log Backup Transaction Log Backup
  • 14. SQL Server - Database Snapshots Create database “HADB Snapshot” on ( filename=<files>) as snapshot of “HADB” Update orders Select from orders set…. where… Maintains the original HADB snapshot view HADB of the database Snapshot from the time of creation Database Pages Database Files V2 V1 Instance
  • 15. Tablediff command line utility Program FilesMicrosoft SQL Server90COMtablediff.exe Tablediff identifies the data usage: tablediff -- Source Options -- differences between two -sourceserver -sourcedatabase Source Host Source Database tables -sourceschema -sourcetable Source Schema Name Source Table or View -sourceuser Source Login Tables must have same -sourcepassword Source Password schema but can be on -sourcelocked Lock the source table/view durring tablediff different servers -- Destination Options -- -destinationserver Destination Host Use the –f option to generate -destinationdatabase -destinationschema Destination Database Destination Schema Name a SQL Server script to fix the -destinationtable -destinationuser Destination Table or View Destination Login out of sync destination version -destinationpassword -destinationlocked Destination Password Lock the destination table/view durring tablediff The diff algorithm uses an -- Misc Options -- -t Timeout efficient hash technique -c Column Level Diff -f Generate Fix SQL (You may also specify a file name and path) -q Quick Row Count -et Specify a table to put the errors into -dt Drop the error table if it exists -o Output file -b Number of bytes to read for blob data types (Default 8000) -strict Strict compare of source and destination schema -rc Number of retries -ri Retry interval
  • 16. Categorizing Availability On Solutions High Availability Solution Requirement System Administration Online management Recovery from application or Logical recovery user errors Site disaster protection Database or storage mirroring Database workload scale out Replication with redundancy
  • 17. Site Disaster Protection Downtime Scenarios Earthquake, fire, or flood causes datacenter outage Always On Solutions Database Mirroring to a secondary site Optimized solution - allows very fast failover times to the secondary site Optionally add log shipping for additional site protection Third party geo-clustering solutions for data center storage level redundancy Find SQL Server Always On reviewed solutions at the Microsoft Always On website: www.microsoft.com/SQL/AlwaysOn
  • 18. Database Mirroring Synchronous mode Mirror is always Application Witness redoing—it remains Commit current Principal Mirror 1 5 2 SQL Server SQL Server 2 >2 4 3 >3 Log Data Log Data
  • 19. Database Mirroring – trade offs Hot-standby + Fastest failover (best RTO) Synchronous + No data loss (RPO=0) - Performance impact for commit Limited to one mirror per database Performance impact increases with number of mirrored databases No read access to mirror
  • 20. Automatic Page Repair in DB Mirroring Name Title Company
  • 21. Categorizing Availability On Solutions High Availability Solution Requirement System Administration Online management Recovery from application or Logical recovery user errors Site disaster protection Database or storage mirroring Database workload scale out Replication with redundancy
  • 22. Database Scale Out with Redundancy Scenario Real time reporting on one or more secondary servers that can also be used for disaster recovery Tier of identical databases for scaling out applications which are partitioned by site Solutions Transactional Replication Peer to Peer Replication
  • 23. Database Scale Out with Redundancy Transactional Replication Peer to Peer Replication Reporting + Redundancy Scale Out* + Redundancy Boston New York England Shanghai New Jersey Tokyo Seattle *Application data modifications must be partitioned by site to prevent conflicts
  • 24. Peer-to-Peer Replication – Enhancements in SQL Server 2008
  • 25. Combining Technologies Database Failover Clustering Replication Scale Out Failover Clustering Local server redundancy For Queries Database Mirroring Primary disaster site for databases Database Mirroring Hot Log Shipping Standby Additional disaster sites for databases App/user error recovery Production Database Replication Log Shipping Warm Database reporting and read scale out Standby with redundancy Always On Partner Solutions Log Shipping With Restore Delay App/User Highest hardware reliability Error Recovery
  • 26. Summary - Unplanned Downtime Redundancy Stack Application Query (Logical) • Replication SQL Server Instance • Failover Clustering • Database Mirroring Log/Database • Log Shipping (Physical) • Backup and Restore Hardware • SAN/RAID
  • 27. © 2009 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.