Presented by Pieter Vanhove.

1. TECHNET LIVE MEETING
High Availability Solutions in SQL Server 2012
Pieter Vanhove

2. WHO AM I
• Pieter Vanhove
• SQL Server Database Consultant at Kohera
• MCTS, MCITP Database Administrator 2008
• Love to work with SQL HA/DR solutions
• E-mail: pieter.vanhove@kohera.be
• Twitter: http://twitter.com/#!/Pieter_Vanhove
• Blog: http://blogs.sqlug.be/pieter/
• MEET: http://www.microsoft.com/belux/meet/#Pieter+Vanhove

3. AGENDA
• What is High Availability
• Planned vs. Unplanned downtime
• Degraded Availability
• Recovery Objectives
• Justifying Opportunity Costs
• SQL Server AlwaysOn
• AlwaysOn Failover Cluster Instance
• AlwaysOn Availability Group
• Database Mirroring
• Log Shipping
• Compare the different solutions

4. PLANNED VS UNPLANNED DOWNTIME
• Planned maintenance.
• A time window is preannounced and coordinated for planned maintenance
o Software patching
o Hardware upgrades
o Password updates
o Offline re-indexing
o Data loading
o Rehearsal of disaster recovery procedures
• Unplanned outage
• System-level, infrastructure, or process failures may occur that are unplanned or
uncontrollable
• A robust high availability solution
o Detects these types of failures
o Automatically recovers from the outage
o Reestablishes fault tolerance.

5. DEGRADED AVAILABILITY
• Read-only and deferred operation
• Data latency and application responsiveness
• Partial, transient, or impending failures

6. RECOVERY OBJECTIVES
• Recovery Time Objective (RTO)
• This is the duration of the outage. The primary goal is to restore full service to
the point that new transactions can take place
• Recovery Point Objective (RPO)
• A measure of acceptable data loss
• It is the time gap or latency between the last committed data transaction before
the failure and the most recent data recovered after the failure

7. JUSTIFYING OPPORTUNITY COSTS
• Avoiding downtime
• Outage recovery costs are avoided all together if an outage doesn’t occur in the first
place
• Investments include
o The cost of fault-tolerant and redundant hardware or infrastructure
o Distributing workloads across isolated points of failure
o Planned downtime for preventive maintenance
• Automating recovery
• If a system failure occurs, you can greatly mitigate the impact of downtime on the
customer experience through automatic and transparent recovery
• Resource utilization
• Secondary or standby infrastructure can sit idle, awaiting an outage
• It can be leveraged for read-only workloads
• To improve overall system performance by distributing workloads across all available
hardware

8. ALWAYSON FAILOVER CLUSTER

9. WHAT IS FAILOVER
CLUSTER INSTANCE Client PCs
Public Network
San Mirroring
Server B (Passive)
Server A (Active) Virtual SQL Server Instance
Virtual Windows Server
Storage Shared Storage Storage

10. WHAT IS A FAILOVER
Client PCs
Public Network
Server A Passive
Active Virtual SQL Server Instance Server B Passive
 Switch storage
manually
 DNS change
Virtual Windows Server  Attach/Detach
databases
 Recreation jobs
Shared Storage

11. CLUSTER TYPE: ACTIVE/PASSIVE
Client PCs
Public Network
Server A Active Virtual SQL Server Instance Server B Passive
Virtual Windows Server
Shared Storage

12. CLUSTER TYPE ACTIVE/ACTIVE
Client PCs
Public Network
Server A Active Server B Active
Virtual Windows Server
Shared Storage

13. CLUSTER TYPE: ACTIVE/ACTIVE N + 1
Public Network
Server A Active Server B Active
Server C Passive
Shared Storage

14. BENEFITS OF FAILOVER CLUSTER INSTANCE
• Protection at the instance level through redundancy
• Automatic failover in the event of a failure
• Support for a broad array of storage solutions
• Disaster recovery solution using a multi-subnet FCI
• Zero reconfiguration of applications and clients during failovers

15. ALWAYSON AVAILABILITY GROUPS

16. WHAT ARE ALWAYSON AVAILABILITY GROUPS
• HA and DR solution that provides an alternative to database mirroring
• A container for a discrete set of user databases that fail over together
• Multiple possible failover targets
• Secondary replicas support read-only access
An availability group fails over at the level of an availability replica.
Failovers are not caused by database issues

17. TERMS AND DEFINITIONS
• Primary database
• The read-write copy of an availability database
• Secondary database
• A read-only copy of an availability database
• Primary replica
• The availability replica that makes the primary databases available for read-write
connections
• Sends transaction log records for each primary database to every secondary replica
• Secondary replica
• An availability replica that maintains a secondary copy of each availability database
• Serves as a potential failover targets for the availability group
• Availability group listener
• A server name to which clients can connect in order to access a database in a
primary or secondary replica of an AlwaysOn availability group

18. SYNCHRONOUS COMMIT MODE
1 Commit 7 Acknowledge
6 Acknowledge
Constantly
Redoing on
Replica
2 Transmit to
2 Write Replica
to Local 3 Committed 4 Write to
Log in Log Remote Log
5
DB Log Log DB

19. ASYNCHRONOUS COMMIT MODE
1 4 Acknowledge
Commit 7 Acknowledge
Constantly
Redoing on
Replica
2 Transmit to
2 Write Replica
to Local 3 Committed 5 Write to
Log in Log Remote Log
6
DB Log Log DB

20. FAILOVER TYPES
- DBA issues a - Response to a - DBA issues a
manual-failover failure forced-failover
command command
- Primary 
- Primary  Secondary - Primary 
Secondary Secondary
- Synchronous-
- Synchronous- commit mode+ - Asynchronous-
commit mode failover mode set commit mode
to “Automatic”
- Replica must be - Replica is not
synchronized - Replica must be synchronized
synchronized

21. READ-ONLY ACCESS ON SECONDARY
• You can configure read-only access to the availability replica.
• Allows you to offload you read-only workloads from your primary
replica
• Optimizes resources on your primary replica for your mission critial
workloads

22. POSSIBLE SETUP

23. BENEFITS ALWAYSON AVAILABILITY GROUPS
• Supports one primary replica and up to four secondary replicas
• Supports Asynchronous-commit mode and Synchronous-commit
mode
• Read-Only access to the secondary databases
• Performing backup operations on secondary databases
• Provide fast application failover
• Flexible Failover Policy
• Automatic page repair
• Supports Encryption and Compression
• Provides an integrated set of tools

24. PREPARATION
• Install WSFC on each machine and create a single WSFC cluster
• Install SQL Server Instances on each machine
• Enable AlwaysOn through SQL Configuration Manager
• (CREATE ENDPOINT on each instance)

25. DATABASE MIRRORING

26. DATABASE MIRRORING

27. TERMS AND DEFINITIONS
• Principal Server
• Principal server is the server which clients connect to and perform their updates to
the database
• Mirror Server
• Mirror server is performing the same changes on the mirrored database
• Witness server
• The witness server monitors the status of the principal and mirror servers
• The witness does NOT trigger the failover, just helps provide “quorum”
• Quorum
• In the event of one of the principal becoming unavailable, the mirror can only
failover if it can still see the witness, and the witness agrees it cannot see the
principal
• If the mirror fails, principal can only continue if it still sees the witness

28. OPERATING MODES
High Availability High Protection High Performance
 Automatic Detection  No Automatic  No Automatic
 Automatic Failover Detection Detection
 Uses synchronous  Manual Failover  Manual Failover
form of mirroring  Uses synchronous form  Uses asynchronous
 Requires Witness of mirroring form of mirroring
 Principal performance  Does not require  Does not require
is affected by network Witness Witness
speed and distance  Principal performance  Principal performance
is affected by network is NOT affected by
speed and distance network speed and
distance

29. SETUP REQUIREMENTS
• Both the principal and mirror servers must have SQL 2005 + installed
• Both the principal and mirror servers must have space to hold the
database
• For automatic failover, the witness server also must have SQL Server
2005+ installed
• Witness can be any edition, even SQL Server Express
• The principal database must use the Full recovery model
• The mirror database must be “prepared”

30. FAILURE DETECTION
• SQL Server
• Ping each other once a second
• By default if 10 “pings” are missed, then declare a failure
• Outside SQL Server
• Operating System
• Network errors
• IO errors
• Process errors
• Failover speed determined by:
• Failure type
• REDO queue on the mirror

31. BENEFITS DATABASE MIRRORING
• Increases availability of a database.
• High-safety mode with automatic failover, failover quickly brings the standby copy of
the database online (without data loss)
• Increases data protection.
• Database mirroring provides complete or almost complete redundancy of the data
• 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. Automatic Page Repair
• Improves the availability of the production database during upgrades.
• To minimize downtime, you can sequentially upgrade the instances of SQL Server
• Rolling upgrade

32. DATABASE MIRRORING DEPRECATED
This feature will be removed in a future version of Microsoft SQL
Server. Avoid using this feature in new development work, and
plan to modify applications that currently use this feature. Use
AlwaysOn Availability Groups instead.

33. LOG SHIPPING

34. LOG SHIPPING

35. TERMS AND DEFINITIONS
• Primary database
• The database on the primary server that you want to back up to another server.
• Secondary database
• The warm standby copy of the primary database.
o Restoring state
o Standby state
• Monitor server
• When the transaction log on the primary database was last backed up.
• When the secondary servers last copied and restored the backup files.
• Information about any backup failure alerts.

36. TERMS AND DEFINITIONS
• Backup job
• Performs the backup operation
• Logs history to the local server and the monitor server
• Deletes old backup files and history information
• Copy job
• Copies the backup files from the primary server to a configurable destination on the
secondary server
• Logs history on the secondary server and the monitor server.
• Restore job
• Restores the copied backup files to the secondary databases.
• Logs history on the local server and the monitor server
• Deletes old files and old history information.
• Alert job
• Raises alerts for primary and secondary databases when a backup or restore
operation does not complete successfully within a specified threshold.

37. LOG SHIPPING CONCEPT
Monitor Database
Server
Log shipping Log shipping
Primary Database Secondary Database
Server Server
Backup Share
Restore Job
Backup Job

38. FAIL OVER TO A LOG SHIPPING SECONDARY
1. Copy any uncopied backup files from the backup share to the copy
destination folder of each secondary server.
2. Apply any unapplied transaction log backups in sequence to each
secondary database.
3. If the primary database is accessible, back up the active transaction
log and apply the log backup to the secondary databases.
4. After the secondary servers are synchronized, you can fail over to
whichever one you prefer by recovering its secondary database and
redirecting clients to that server instance. Recovering puts the
database into a consistent state and brings it online.

39. COMPARE SOLUTIONS

40. COMPARING FAILOVER
Failover Availability Database
Log Shipping
clustering Groups Mirroring
• SQL Server • Database • Database • Database
Instance Group • Manual or • Manual
• Automated • Manual or automated • Based on
• Within automated • Few seconds configuration
minutes • Few seconds to minutes • Forced
• No to minutes • Application application
application • No redirection redirection
redirection Application required (can required
required redirection be
required automated)

41. COMPARING SECONDARY SERVER
Failover Availability Database
Log Shipping
clustering Groups Mirroring
• Instance • Database • Database • Database
• Multiple nodes • Up to 4 • Principal and • Multiple
• Server in same Secondary Mirror secondary
LAN Replica’s • Span across nodes
• Hot standby • Span across WAN • Span across
server WAN • Hot standby WAN
• Available for • Hot standby • Not available • Warm standby
use • Available for for use • Available for
• Shared storage use • Storage need use
• Status check • Storage need not be shared • Storage need
using not be shared • No status check not be shared
Heartbeat • Status check unless using • No status
WFC witness checking

42. COMPARING
Failover Availability Database
Log Shipping
clustering Groups Mirroring
• All instance • Configured • Configured • Configured
databases are database is database is database logs
shared mirrored or mirrored are applied
• Loss limited to readable • Loss limited to • Loss limited to
last hardened • Loss limited to last mirrored last applied
record last mirrored transaction transaction
• No data copy transaction • Synchronous log backup
across • Synchronous or • Transaction
network or Asynchronous log
Asynchronous mirroring Backup, Copy
commit mode and Restore

43. COMPARING
Failover Availability Database
Log Shipping
clustering Groups Mirroring
• Network • Network • Network • Network
connectivity latency to latency to latency to
needs to meet I/U/D meet I/U/D meet RTO
meet SLA’s SLA’s • Transaction
heartbeat • Data is • Data is Log file
requirements transferred transferred records
• Data is not over network over network transferred
transferred over network
over network

44. WRAP UP
• What is High Availability
• Planned vs. Unplanned downtime
• Degraded Availability
• Recovery Objectives
• Justifying Opportunity Costs
• SQL Server AlwaysOn
• AlwaysOn Failover Cluster Instance
• AlwaysOn Availability Group
• Database Mirroring
• Log Shipping
• Compare the different solutions

45. RESOURCES
• AlwaysOn Team Blog
• http://blogs.msdn.com/b/sqlalwayson/
• SQL Server 2012 Whitepapers
• http://msdn.microsoft.com/en-us/library/hh403491
• MSDN – SQL Server High Availability Solutions
• http://msdn.microsoft.com/en-
us/library/ms190202.aspx#RecommendedSolutions

46. © 2011 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.