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

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

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

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

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

6. Availability Technologies in SQL Server 2005

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

8. Backup / Restore Detach / Copy / Attach Cold Standby Solutions Backup / Restore and Detach / Copy / Attach

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

10. Backup / Restore What’s 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

11. Warm Standby Solutions Replication and Log Shipping Replication Log Shipping

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

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; doesn’t 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

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

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

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

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

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

19. Fault Tolerant Virtual Database Principal Clients Witness Mirror

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

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

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

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)

24. Database Mirroring High Availability Mode Principal Clients Witness Mirror X High Protection Mode High Performance Mode

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

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

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

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 Server’s 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

29. Microsoft SQL Server Core I/O Requirements I/O- and Storage-Level Replication See whitepaper SQL Server 2000 I/O Basics on TechNet http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObas ics.mspx http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObas ics.mspx To ensure correct operation the underlying I/O and storage system must meet the Core I/O Requirements Stable Media – once ‘write’ is acknowledged, must be guaranteed Write Ordering –writes must preserve ordering across devices Torn I/O Prevention – writes must be done as a unit; not split Applies to both local storage and any I/O-level or storage-level replication scheme, synchronous or asynchronous Guarantees that what appears at secondary site is an image that actually appeared at some point in time at the primary Asynchronous replication allows potential loss of committed transactions

30. Geographically-Dispersed Clusters and Storage-level Replication Solutions from many Microsoft partners replicate the local I/Os on a remote system Hardware and software methods Synchronous and asynchronous solutions Solutions must meet Core I/O Requirements Many solutions use MSCS to provide automatic failover Other solutions are primarily to duplicate the data at a remote site, often with an independent SQL Server Similar to Log Shipping or Detach / Attach Geographical Failover Cluster

31. Complementary Technologies Technologies can be Combined Maximize availability for Scale out Offload primary data platform Heavy reporting Mobile/disconnected users Autonomous business units that share data Maximize availability of critical systems Designed for failover Fast, automatic Zero data loss Transactionally current Masks planned and unplanned downtime Replication Failover Solutions

32. Example Fault-Tolerant Publisher and Distributor Subscribers Complementary Technologies Failover Solution + Replication Distributor Publisher

33. Combining HA Technologies Principal Server can be a Failover Cluster Failover to mirror will occur before failover within the cluster So Principal will come back up as the Mirror Mirror can be a Failover Cluster as well PrincipalMirror Failover Cluster

34. Barriers To Availability As addressed in SQL Server 2005 Database Server Failure or Disaster ------------------------------------------------------------ Application or User Error Database Snapshots Data Access Concurrency Limitations Database Maintenance and Operations Upgrades

35. Barriers to Availability This job would be great if it weren’t for… …the users …the staff …us People I’m going to modify this data…right … here !

36. Database Snapshot New in SQL Server 2005 Database Snapshots allow recovery from user errors by allowing the database to go back in time Works with Single server Database Mirroring Failover Cluster Does not work with Log Shipping secondary

37. Database Snapshot How it really works mydbSnap – Read-Only Database Snapshot USE mydbSnap SELECT (pages 4, 6, 9, 10, 14) 1 Page 2345678910111213141516 CREATE DATABASE mydbSnap AS SNAPSHOT OF mydb mydb – Database USE mydb UPDATE (pages 4, 9, 10) 4 910 12345678910111213141516

38. Database Snapshot Snapshot of an entire database at a point in time Created instantly Read only Snapshot must be created before the error Base database continues to change Database Snapshot does not restrict the base database Multiple Snapshots are allowed Database Snapshots can exist forever Constrained by resources

39. Database Snapshot Uses Static, time-consistent copy for reports With Database Mirroring enables reporting on the standby No increase in failover time Recover from User, Application, or DBA error Revert database to previously created Database Snapshot Takes the database back in time Very fast, no restoring of backups required

40. Database Snapshot Technology Extremely space efficient Does not require a complete copy of the data Shares unchanged pages of the database Requires extra storage only for changed pages Uses a “copy-on-write” mechanism Database Snapshot may affect performance on the base database

41. Database Snapshot Syntax Examples To create a database snapshot CREATE DATABASE mydbSnap0600 ON ( ) AS SNAPSHOT OF mydb To drop a database snapshot DROP DATABASE mydbSnap0600 To revert a database to a snapshot RESTORE DATABASE mydb FROM DATABASE_SNAPSHOT = 'mydbsnap0600'

42. Reporting on a Mirror Use Database Snapshots on Mirror Mirror Principal Reporting Clients Database Mirroring OLTP Clients Snapshot1 at 1PM Witness Snapshot2 at 2PM

43. Barriers To Availability As addressed in SQL Server 2005 Database Server Failure or Disaster Application or User Error Data Access Concurrency Limitations Snapshot Isolation Online Index Operations Database Maintenance and Operations Upgrades

44. Snapshot Isolation New in SQL Server 2005 Two new ‘snapshot isolation’ levels Increased data availability for read applications Allows non-blocking consistent reads in an online transaction processing (OLTP) environment Writers do not block readers; readers do not block writers Consistency of aggregates without using higher isolation levels AVG, COUNT, SUM, etc.

45. Snapshot Isolation New in SQL Server 2005 Increases concurrency and data availability while reducing deadlocks Non-blocking consistent reporting and ad-hoc queries Uses row-level versions on update and delete to keep copies of the versions of the row other users might want to see Doesn’t lock the row Permits writes, which can cause conflicts BUT…includes mandatory conflict detection

46. Snapshot Isolation Statement-Level ‘Snapshot Isolation’ Read Committed Snapshot – Statement-level SET TRANSACTION ISOLATION LEVEL READ COMMITTED While READ_COMMITED_SNAPSHOT database option is set to ON, automatically get non-locking READ COMMITTED Can greatly reduce locking / deadlocking without changing applications Override with READCOMMITTEDLOCK hint The query scan will run under the original flavor of locking-based read committed isolation When referencing a row modified by another transaction will retrieve the committed version of the row that existed when the statement started Writers do block writers

47. Snapshot Isolation Transaction-Level ‘Snapshot Isolation’ ‘Snapshot Isolation’ – Transaction-level SET TRANSACTION ISOLATION LEVEL SNAPSHOT Uses row-level versioning Read operations do not acquire locks When referencing a row modified by another transaction will retrieve the committed version of the row that existed when the snapshot transaction started

48. Snapshot Isolation Database-Level Settings Snapshot Isolation must be enabled at the database level ALTER DATABASE mydatabase SET ALLOW_SNAPSHOT_ISOLATION ON To default all Read Committed operations to use Read Committed Snapshot ALTER DATABASE mydatabase SET READ_COMMITTED_SNAPSHOT ON All row versions are stored in tempdb

49. Online Index Operations Online Index Operations allow concurrent modification of the underlying table or index Updates, Inserts, Deletes Online Index Maintenance Create, Rebuild, Drop Index-based constraints (PrimaryKey, Unique) Data definition language (DDL) is simple Online/Offline are both supported Updates incur some additional cost during an online index operation Maintains old and new indexes

50. Barriers To Availability As addressed in SQL Server 2005 Database Server Failure or Disaster Application or User Error Data Access Concurrency Limitations Database Maintenance and Operations Upgrades

51. Fast Recovery Restart of a Database SQL Server 2000 Database is available after Undo completes SQL Server 2005 Database is available when Undo begins UndoRedo AvailableUndoRedoAvailable Time

52. Database Maintenance & Operations Partial Availability Database is available if primary filegroup is available Online Restore Restore while database remains available Works with all recovery models Backup and Restore Data backups don’t block log backups Full-Text Catalog is backed up and restored as part of the database

53. Media Reliability Features Backup Media Mirroring Can write backups to 4 destinations Enhanced Verification of Backups RESTORE VERIFYONLY now checks everything it can, short of writing the data Database Page Checksums and Backup Checksums Detects disk I/O errors not reported by the hardware or operating system Continue Past Errors Encountered by Restore Allows the restore sequence to continue as far as possible… …then repair the database

54. More Operational Improvements… Dedicated Administration Connection Provides DBA access to server regardless of load No server restart to kill a runaway session More configuration is dynamic No server restart for CPU affinity, AWE Address Windowing Extensions (AWE) Changes to physical size don’t require downtime Dynamically configurable (Min / Max) Dynamically adjusts to “hot-add” memory AWE is available in Standard Edition (Win2003) Instant file initialization With appropriate security, can bypass zeroing For create database, add file, file grow, restore

55. Barriers To Availability As addressed in SQL Server 2005 Database Server Failure or Disaster Application or User Error Data Access Concurrency Limitations Database Maintenance and Operations Upgrades

56. Upgrade Enhancements Software Upgrade Re-architected – greatly reduces down time Side-by-side installation Resource database is pre-built No maintenance is needed; new is substituted for old one DBA can ignore the mssqlsystemresource.mdf and ldf Phased Engine and Databases (< 3 minutes) Other components complete upgrade online after databases are available (Replication, Workbench, etc.) Hardware Upgrade Hot-add memory supported without server restart Database Mirroring minimizes downtimes for other hardware upgrades, excluding disk

57. SQL Server 2005 Capabilities by Edition EnterpriseStandard Workgroup, Express Failover Clustering Yes2-nodeNo Database Mirroring Yes Safety Full Witness only Database Snapshots YesNoNo Snapshot Isolation YesYesYes Online Index Operations YesNoNo Fast Recovery YesNoNo Dedicated Admin Conn. YesYes No on Exp Table Partitioning YesNoNo Log Shipping YesYes No on Exp Peer-to-Peer Replication YesNoNo

58. New York! New York! איך ממלאים משוב? ב - email בסוף כל יום ב -Beat Center מה מקבלים? חולצת Feel The Beat השתתפות בהגרלת כרטיסי טיסה מכשירי i-mate ועוד... (לממלאים משוב לכל יום)

59. The Prime Grill - Steakhouse Assaf Fraenkel 60 east 49 th st. New York, NY 2126929292 הסטייקים הכשרים הטובים בניו- יורק ועוד במנהטן!!

60. הרצאות מומלצות בנושא HA היום ב 11:30 עמי לוין בנושא Isolaion Level מחר ב 8:30 מאיר דודאי בנושא replication

61. SQL Server 2005 Delivers Availability Makes High Availability accessible More choices Hardware requirements Database administration Application development Richer Solutions  Manageable  Lower Cost Failover Distributed environments Online management Better concurrency Partial availability VLDB

62. Summary – What is Availability?