1. Oracle DBAs Deploying Highly Available SQL Server Systems
Joe Yong
Chief Architect
Scalability Experts Inc.

2. About This Session Goals Non-goals Pre-requisites
Overview of SQL Server 2005 High Availability features
Drilldown on HA implementation strategies
Non-goals
Deep dive into SQL Server
Chest thumping
Make you a HA expert
Pre-requisites
Experience as an Oracle DBA, Architect or Developer DBA
Basic experience in designing, deployment and managing database systems that require medium to high levels of availability

3. Agenda What is High Availability SQL Server 2005 HA overview
Solutions to common scenarios
Case study
Summary

4. What is High Availability
Uninterrupted usability
A running server is not necessarily available
Is a factor of technology, people and processes
Often measured as a percentage in “uptime” over 1 year
Eg % uptime = 5.25 minutes downtime a year
Should includes both planned and unplanned downtime but many only measure unplanned
You may not own every part of the equation but if you have to specify your SLA
Example
Online ordering system requires orders to be confirmed in 30 seconds
Availability is impacted by application scalability, network and database
Don’t forget security impact on HA

5. Agenda What is High Availability SQL Server 2005 HA technologies
Hot Standby
Failover Clustering
Database Mirroring
Warm Standby
Database Mirroring – High Protection / Performance mode
Replication
Log Shipping
Cold Standby
Backup/restore
Online operations
Solutions to common scenarios
Case study
Summary

6. Microsoft Failover Clustering Overview
* Inst1
Microsoft Failover Clustering Overview
Hot Standby – Automatic failover
Protects against local, limited disasters
Built on Microsoft Server Clusters (MSCS)
Multiple nodes provide availability, transparent to client
Supports 2, 4, or 8 nodes depending on OS edition
Automatic detection and failover
Requires cluster certified hardware; see Windows Catalog: Clustered
Supports many scenarios: Multiple Active Instances, N+1, N+I
Up to 25 SQL Server instances per cluster
NOT a load balancing solution
Multiple Active Instances
N+1: N Active, 1 Inactive Instances
Inst2 *
* Inst1
N+I: N Active, I Inactive Instances
* Inst1
Inst3 *
Inst2 *

7. Microsoft Failover Clustering Detail

8. Geographically Dispersed Clusters
Same functionality and behavior as “standard” failover cluster
Protects against local, total and extended disasters
Requires specially certified cluster hardware from qualified vendors
Requires guaranteed 500ms maximum round trip latency between nodes
SQL Server does not differentiate between standard and geo-cluster
Mirror
Network N1 N4 N3 N2 D3 D1
Storage Controller S1 D2 D4
Storage Controller S2
Site 1
Site 2

9. High Availability Toolbox
Disaster Recovery Features
Failover Clustering
Local limited disasters 
Local disasters
With geo-clusters
Extended disasters
Limited
Rapid failover
Failure detection
Automatic switchover
Specialized hardware
Secondary workload on standby (reporting) 
Meta data support
Performance impact
None
Protect against storage failure
Locations

10. Agenda What is High Availability SQL Server 2005 HA technologies
Hot Standby
Failover Clustering
Database Mirroring – High Availability mode
Warm Standby
Database Mirroring – High Protection / Performance mode
Replication
Log Shipping
Cold Standby
Backup/restore
Online operations
Solutions to common scenarios
Case study
Summary

11. Database Mirroring Overview
Hot Standby
Provides a fault-tolerant database
Building block for complex topologies
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
Works with standard certified servers, storage and networks
No location limitations
No shared components; two separate copies of data

12. Database Mirroring How does it work?
4/25/2017 6:08 PM
Database Mirroring How does it work?
Mirror is always redoing – it remains current
Application
Witness (optional)
Commit 1 5
Principal
Mirror 2
SQL Server
SQL Server 4 2
>2 3
>3
Log
Data
Log
Data

13. Database Mirroring Witness
Only required for automatic failover;
Just another instance of SQL Server 2005
Can serve multiple sessions
Prevents “split brain” scenario
If partners do not see each other, is it due to network failure or server failure?
To become Principal automatically, a server must talk to at least one other server
Witness ONLY answers the question “Who do you see?”, does not promote a server to be Principal

14. Database Mirroring High Availability mode
Safety Full; synchronous operation
Commit when logged on Mirror
Allows automatic failover
No data loss
Database available whenever quorum exists
Formed by any two servers from the three; Principal, Mirror, Witness
Witness is present – automatic Failover

15. Database Mirroring Transparent Client Redirect
SQLConnection object that targets a mirrored database
No application code change required
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
If Principal is down upon first connect attempt, connection fails
Workaround via explicit coding or NLB type solution
Supports .NET and SNAC providers

16. High Availability Toolbox
Disaster Recovery Features
Failover Clustering
Database Mirroring – HA mode
Local limited disasters 
Local disasters
With geo-clusters
Extended disasters
Limited
Rapid failover
Failure detection
Automatic switchover
Specialized hardware 
Secondary workload on standby (reporting)
With DB snapshot
Meta data support
User DB only
Performance impact
None
Minimal ~ low
Protect against storage failure
Locations
Unrestricted

17. Agenda What is High Availability SQL Server 2005 HA technologies
Hot Standby
Failover Clustering
Database Mirroring – High Availability mode
Warm Standby
Database Mirroring – High Protection / Performance mode
Replication
Log Shipping
Cold Standby
Backup/restore
Online operations
Solutions to common scenarios
Case study
Summary

18. Database Mirroring High Protection mode
Safety Full; synchronous operation
Commit when logged on Mirror
No automatic failover; manual failover only
Database quorum formed by Principal and Mirror
If Principal loses quorum, it stops servicing the database
Ensures high protection; database is never in ‘exposed’ state
No Witness present – no automatic failover

19. Database Mirroring High Performance mode
Safety Off; asynchronous operation
Commit when logged on Principal
No automatic failover; manual failover only
Possible data loss
If Mirror becomes unavailable; Principal continues working
If Principal becomes unavailable; Mirror can assume workload
Manual failover to Mirror is required
No Witness present; no automatic failover

20. High Availability Toolbox
Disaster Recovery Features
Failover Clustering
Database Mirroring – HA mode
Database Mirroring – H P/P mode
Local limited disasters 
Local disasters
With geo-clusters
Extended disasters
Limited
Rapid failover
Failure detection
Automatic switchover 
Specialized hardware
Secondary workload on standby (reporting)
With DB snapshot
Meta data support
User DB only
Performance impact
None
Minimal ~ low
Minimal
Protect against storage failure
Locations
Unrestricted

21. Agenda What is High Availability SQL Server 2005 HA technologies
Hot Standby
Failover Clustering
Database Mirroring – High Availability mode
Warm Standby
Database Mirroring – High Protection / Performance mode
Replication
Log Shipping
Cold Standby
Backup/restore
Online operations
Solutions to common scenarios
Case study
Summary

22. Transactional Replication
Requires consideration at design time; cannot just “flip the switch”
High performance – latency measured in seconds
Some (minimal) load on the server
Can be implemented at database or table level
Failover possible; custom designed solution
Two types
Standard transactional replication
Easy to design, setup & manage
Subscriber (standby) can be used for reporting
Peer-to-peer transactional replication
Multi-master model; schema is identical on all sites
Supports distributed applications with data partitioning; enables load balancing
Does not handle conflicts; design to avoid/prevent conflicts

23. Peer-To-Peer Transactional Replication How does it work?
4/25/2017 6:08 PM
Peer-To-Peer Transactional Replication How does it work?
“West”
“East”
Distribution
Agent
Dist DB
Logreader
Distribution
Agent
Dist DB
Logreader
“South”
Distribution
Agent
Dist DB
Logreader

24. High Availability Toolbox
Disaster Recovery Features
Failover Clustering
Database Mirroring – HA mode
Database Mirroring – H P/P mode
Transactional Replication
Local limited disasters 
Local disasters
With geo-clusters
Extended disasters
Limited
Rapid failover 
Failure detection
 Can automate in application
Automatic switchover
Specialized hardware
Secondary workload on standby (reporting)
With DB snapshot
Meta data support
User DB only
Some
Performance impact
None
Minimal ~ low
Minimal
Low
Protect against storage failure
Locations
Unrestricted

25. Agenda What is High Availability SQL Server 2005 HA technologies
Hot Standby
Failover Clustering
Database Mirroring – High Availability mode
Warm Standby
Database Mirroring – High Protection / Performance mode
Replication
Log Shipping
Cold Standby
Backup/restore
Online operations
Solutions to common scenarios
Case study
Summary

26. Log Shipping
Backup transaction log, copy to secondary server, restore transaction log backup
Failover is manual
Meta data management may be necessary
Read operations on secondary is permitted
Users are disconnected when log restore occurs
Can maintain multiple secondary servers
Optional Monitor server
Records history and status of backup/restore jobs
May be setup to raise alerts when jobs fail

27. High Availability Toolbox
Disaster Recovery Features
Failover Clustering
Database Mirroring – HA mode
Database Mirroring – H P/P mode
Transactional Replication
Log Shipping
Local limited disasters 
Local disasters
With geo-clusters
Extended disasters
Limited
Rapid failover 
Failure detection
 Can automate in application
Automatic switchover
Specialized hardware
Secondary workload on standby (reporting)
With DB snapshot
 With limitations
Meta data support
User DB only
Some
Performance impact
None
Minimal ~ low
Minimal
Low
Protect against storage failure
Locations
Unrestricted

28. Agenda What is High Availability SQL Server 2005 HA technologies
Hot Standby
Failover Clustering
Database Mirroring – High Availability mode
Warm Standby
Database Mirroring – High Protection / Performance mode
Replication
Log Shipping
Cold Standby
Backup/restore
Online operations
Solutions to common scenarios
Case study
Summary

29. Backup and Restore Slowest recovery (but also simplest)
Recommended as secondary or tertiary protection layer
Manual failure detection and switchover
Data loss possible
Recommend maintaining active backups on disk; duplicate, archive and offsite backups on tape
Various levels
Database – full, differential, partial, differential partial, copy-only
File & filegroups – “full”, differential
Transaction log

30. Backup and Restore RESTORE VERIFY ONLY Backup media mirroring
Backup and database page checksums
Fine grained online repair
Online restore
Piecemeal restore
Page-level restore
Database backup does not block Log backup
Backup/restore includes FullText data
Copy-only – via T-SQL only

31. High Availability Toolbox
Disaster Recovery Features
Failover Clustering
Database Mirroring – HA mode
Database Mirroring – H P/P mode
Transactional Replication
Log Shipping
Backup / Restore
Local limited disasters 
Local disasters
With geo-clusters
Extended disasters
Limited
Rapid failover 
Failure detection
 Can automate in application
Automatic switchover
Specialized hardware
Secondary workload on standby (reporting)
With DB snapshot
 With limitations
Meta data support
User DB only
Some
Performance impact
None
Minimal ~ low
Minimal
Low
Protect against storage failure
Locations
Unrestricted

32. Agenda What is High Availability SQL Server 2005 HA technologies
Hot Standby
Failover Clustering
Database Mirroring – High Availability mode
Warm Standby
Database Mirroring – High Protection / Performance mode
Replication
Log Shipping
Database Snapshot
Cold Standby
Backup/restore
Online operations
Solutions to common scenarios
Case study
Summary

33. Online Operations Backup/restore Indexing Memory allocations
Full online backup
Online piecemeal restore; undamaged data remains available
Indexing
Allows create, drop and alter while users continue to access data
LOB datatype indexes not supported for online
Memory allocations
CPU affinity settings
Database snapshots

34. Database Snapshot
Not originally designed as a specific HA solution but works great in some situations
Turning a Database Mirroring mirror into a reporting server
Isolated historical data for report generation
Protection in case of administrative, developer or user error; classic “Oops!” scenario
Uses copy-on-write technique to reduce disk space consumption

35. Database Snapshot How does it work?
4/25/2017 6:08 PM
Database Snapshot How does it work?
CREATE DATABASE mydbSnap AS SNAPSHOT OF mydb
USE mydb
UPDATE (pages 4, 9, 10)
mydb – Database
Page 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 2 3 4 4 5 6 7 8 9 9 10 10 11 12 13 14 15 16
mydbSnap – Read-Only Database Snapshot
USE mydbSnap
SELECT (pages 4, 6, 9, 10, 14)

36. Agenda What is High Availability SQL Server 2005 HA technologies
Solutions to common scenarios
Case study
Summary

37. Rolling Upgrades In three steps
4/25/2017 6:08 PM
Rolling Upgrades In three steps
Perform upgrades on the mirror, secondary, or subscriber
Switch roles
Database Mirroring Failover to the mirror
Log Shipping
Replication Redirect clients to subscriber
Perform upgrades on the original database server
Optional: Switch roles again
Backup principal log with no-recovery
Recover secondary
Re-direct clients to secondary

38. Site Disaster Protection
4/25/2017 6:08 PM
Site Disaster Protection
Example Scenarios
Earthquake, fire, or flood causes datacenter outage
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
Log Shipping to one or more secondary sites
Basic solution – requires additional effort for failover
Third-party geo-clustering solutions for data center storage level redundancy
Find SQL Server Always On reviewed solutions at the Microsoft Always On website:

39. Database Mirroring Configuration In three steps
4/25/2017 6:08 PM
Database Mirroring Configuration In three steps
Step 1: Restore database copy to mirror site with no-recovery option
Step 2: Configure communication endpoints
Step 3: Set the data protection level and Start Mirroring

40. Database Query Workload Scale Out With Redundancy
4/25/2017 6:08 PM
Database Query Workload Scale Out With Redundancy
Scenario
Need for near real time reporting on a second server that can also be used for disaster recovery
Need for a tier of identical databases for scaling out application queries with ability to use any one of the database copies for disaster recovery
Solutions
Transactional Replication
Peer-to-Peer Replication

41. Putting It All Together
4/25/2017 6:08 PM
Putting It All Together
Failover Clustering
Local server redundancy
Full server/instance protection
Database Mirroring
Primary disaster site for databases
Reporting with Snapshot
Log Shipping
Additional disaster sites for databases
Logical recovery (with delay)
Replication
Database reporting and read scale out with redundancy
Database
Scale Out
For Queries
Replication
Hot
Standby
Database Mirroring
Production
Database
Failover Clustering
Log Shipping
Warm
Standby
Log Shipping
With Restore Delay
Logical
Recovery
Standby

42. Agenda What is High Availability SQL Server 2005 HA technologies
Solutions to common scenarios
Summary

43. Summary
<<WiP>>

44. Resources www.microsoft.com/sql/ msdn.microsoft.com/sqlserver/

45. High Availability Toolbox
Disaster Recovery Features
Failover Clustering
Database Mirroring – HA mode
Database Mirroring – H P/P mode
Transactional Replication
Log Shipping
Backup / Restore
Local limited disasters 
Local disasters
With geo-clusters
Extended disasters
Limited
Rapid failover 
Failure detection
 Can automate in application
Automatic switchover
Specialized hardware
Secondary workload on standby (reporting)
With DB snapshot
 With limitations
Meta data support
User DB only
Some
Performance impact
None
Minimal ~ low
Minimal
Low
Protect against storage failure
Locations
Unrestricted