assaf fraenkel principal consultant microsoft consulting services high availability with sql 2005...

Download Assaf Fraenkel Principal Consultant Microsoft Consulting Services High Availability with SQL 2005 זמינות יתרה והמשך פעילות עסקית

Post on 22-Dec-2015




1 download

Embed Size (px)


  • Slide 1
  • Assaf Fraenkel Principal Consultant Microsoft Consulting Services High Availability with SQL 2005
  • Slide 2
  • Availability Stack Majority of downtime is ascribed to operators Application Software can have dramatic impact on fault tolerance System Software can help at all levels Hardware is very reliable at this point Hardware SystemSoftware ApplicationSoftware Operators
  • Slide 3
  • Barriers To Availability SS 2005 gives you greatly improved tools to overcome these barriers Database Server Failure or Disaster User or Application Error Data Access Concurrency Limitations Database Maintenance and Operations Upgrades Only some are addressable by DBMS technology Be sure to consider people, planning, and procedures
  • Slide 4
  • Availability Solutions How Do You Compare the Alternatives (1/2) Time to Fail Over Automatic or Manual Detection Automatic or Manual Failover Number of Failures it can survive Data Currency / Loss
  • Slide 5
  • Availability Solutions How Do You Compare the Alternatives (2/2) Granularity of Data: Instance, Database, Table, Row Cost of redundant system(s), additional hardware, additional management Complexity Data Consistency Transparency to clients
  • Slide 6
  • Availability Technologies in SQL Server 2005
  • Slide 7
  • Basic: No failover and a potential data loss Backup / restore Detach / copy / attach Better: Manual failover - potential data loss Peer-to-Peer Replication Log Shipping Database Mirroring - high performance mode Best: Automatic failover - zero data loss Database Mirroring - high availability mode Failover Clustering
  • Slide 8
  • Backup / Restore Detach / Copy / Attach Cold Standby Solutions Backup / Restore and Detach / Copy / Attach
  • Slide 9
  • Both Provide Manual detection and failover Potential for some work loss Whole-database scope Standard servers Limited reporting on standby Duplicate copy of database Client must know where to re-connect Slowest failover Most downtime Cold Standby Solutions Backup / Restore and Detach / Copy / Attach
  • Slide 10
  • Backup / Restore Whats New in SQL Server 2005 Fine-Grained Online Repair Online Restore Database remains online; Only data being restored is offline Piecemeal Restore Online restore of filegroups by priority Page-level Restore Can restore individual pages to repair errors found by page checksum or torn pages Instant File Initialization Skips file zeroing, fast DB create / restore Data backups do not block log backups Restore read-only filegroups without applying logs Backup / Restore includes FullText data
  • Slide 11
  • Warm Standby Solutions Replication and Log Shipping Replication Log Shipping
  • Slide 12
  • Warm Standby Solutions Replication Multiple copies and Manual failover Primarily used where availability is required in conjunction with scale out of read activity Failover possible; a custom solution Not limited to entire database; Can define subset of source database or tables Copy of database is continuously accessible for read activity Latency between source and copy can be as low as seconds Replication
  • Slide 13
  • Peer-to-Peer Transactional Replication All participants are peers Schema is identical on all sites Publish the updates made on their data Subscribe to others to pick up their changes No hierarchy as in normal transactional replication A given set of data can be updated at only one site at a time Data ownership is purely logical; doesnt prevent conflicts SQL Server prevents a change from round-tripping Enables load-balancing and high availability Warm/hot standby - Small possibility of data loss Peer-to-Peer Transactional Replication
  • Slide 14
  • Warm Standby Solutions Log Shipping Multiple copies and Manual failover Basic idea: Backup, Copy & Restore Log will always be supported But no more investment in the scripts Database scope Database accessible but read-only Users must exit for next log to be applied Data backups no longer block log backups Log Shipping
  • Slide 15
  • Hot Standby Failover Solutions Failover Clustering and Database Mirroring Both Provide Automatic detection Automatic, fast failover Manual failover Transparent client redirect Zero work loss Database Mirroring Failover Cluster
  • Slide 16
  • Zero work loss, zero impact on throughput Instance Failover instance fails as a unit Single copy of instance databases Standby is not available for reporting, queries, etc. May support other instances Failover Clustering Microsoft Server Cluster Failover Cluster * Inst1
  • Slide 17
  • Failover Clustering SQL Server 2005 More nodes Match operating system limits Supported scenarios: Multiple Active Instances, N+1, N+I Two-node Failover Clustering is available in SQL Server 2005 Standard Edition Unattended setup Support for mounted volumes (Mount Points) All SQL Server data services participate Database Engine, SQL Server Agent, Full-Text Search Analysis Services supports multiple instances N+1: N Active, 1 Inactive Instances * Inst1 Inst2 * Multiple Active Instances N+I: N Active, I Inactive Instances
  • Slide 18
  • Database Mirroring New for SQL Server 2005 Hot Standby Database Failover Very fast failover Less than five seconds in most cases Zero data loss Automatic or manual failover Automatic re-sync after failover Automatic, transparent client redirect Database Mirroring
  • Slide 19
  • Fault Tolerant Virtual Database Principal Clients Witness Mirror
  • Slide 20
  • Witness and Quorum Sole purpose of the Witness is to provide automatic failover To survive the loss of one server you must have at least three Witness is an instance of SQL Server 2005 Perhaps even SQL Server Express on WinXP Consumes very little resources Can be witness for multiple sessions Witness
  • Slide 21
  • Database Mirroring How it works Mirror Principal Witness Log ApplicationSQL Server 2 2 4 5 1 Data Log 3>2>3 Mirror is always redoing it remains current Commit
  • Slide 22
  • Safety / Performance There is a trade-off between performance and safety Database Mirroring has two safety levels FULL commit when logged on Mirror Allows automatic failover No data loss OFF commit when logged on Principal System does its best to keep up Prevents failover; to make mirror available Must force service Or terminate Database Mirroring session
  • Slide 23
  • Database Mirroring Modes High-Availability Mode Safety Full; Synchronous operation Database is available whenever a quorum exists Automatic failover High-Protection Mode Safety Full; Synchronous operation No witness quorum provided by partners If Principal loses quorum, it stops servicing the database Ensures high protection; database is never in exposed state Manual failover only; no automatic failover A transition mode; should not be in this mode for long High-Performance Mode Safety Off; Asynchronous operation Manual failover only Supports only one form of role switching: forced service (with possible data loss)
  • Slide 24
  • Database Mirroring High Availability Mode Principal Clients Witness Mirror X High Protection Mode High Performance Mode
  • Slide 25
  • Transparent Client Redirect No changes to application code Client automatically redirected if session is dropped Client library is aware of Principal and Mirror servers Upon initial connect to Principal, library caches Mirror name When client attempts to reconnect If Principal is available, connects If not, client library automatically redirects connection to Mirror
  • Slide 26
  • Database Mirroring Impact to transaction throughput Depending on environment Depending on workload Zero to minimal Hardware Works with standard computers, storage, and networks No shared storage components, virtually no distance limitations My Tips: 1GB Network, Disk for the Log Database Mirroring
  • Slide 27
  • Initiating a Database Mirroring Session Create endpoints for communication CREATE ENDPOINT CREATE ENDPOINT On the principal server, back up the database BACKUP DATABASE AdventureWorks TO DISK = 'c:\AdventureWorks.bak' On the future mirror server, restore the database RESTORE DATABASE AdventureWorks FROM DISK = 'z:\AdventureWorks.bak' WITH NORECOVERY On the mirror, set the principal server as a failover partner ALTER DATABASE AdventureWorks SET PARTNER = 'sqlDbEngine05\MSSQLSERVER' On the principal server set the mirror server as the second failover partner ALTER DATABASE AdventureWorks SET PARTNER = 'sqlDbEngine06\MSSQLSERVER' To fail over: On the principal ALTER DATABASE db SET PARTNER FAILOVER To view metadata SELECT * FROM SYS.DATABASE_MIRRORING SELECT * FROM SYS.DATABASE_MIRRORING_ENDPOINTS SELECT * FROM SYS.DATABASE_MIRRORING_WITNESSES
  • Slide 28
  • 3 rd Party Business Continuance Solutions Many solutions by many companies with many different names Most replicate data and log changes by one of these methods Looking into SQL Servers log files and translating log records into logical operations Intercepting IOs and duplicating them, either to another disk set or simply recording them Replicating the writes at the storage level Local copies / mirrors for snapshot backups, etc. Remote copies / mirrors for disaster recovery and Geographically-Dispersed Clusters
  • Slide 29