1. SQL 2012 AlwaysOn
Get TurnedOn with AlwaysOn!
High Availability/Disaster
Recovery Solution

2. Dilip Nayak
 DBA at CUDirect Corporation
 Expertise in performance
tuning/troubleshooting and high availability.
 17 years of experience working as a .NET
developer, 6 years as SQL DBA.
 Active member of PASS, SQL Saturday and
anything SQL related.

3. Mitch Bottel
• Sr SQL Server DBA – Sutter Health
• Owner Innovative IT Consulting, Inc.
• Idera ACE Alumni
• Advisors and Community Educators
• 12+ years in IT
• Member Placer County Search and Rescue

4. Agenda
 Concepts of HA and DR
 SQL Failover Clustering
 Database Mirroring
 Log Shipping
 SQL 2012 AlwaysON
 Demo
 Q&A

5. Definitions
 High Availability
 minimize the probability of a failure
 more local in nature and generally tolerate
smaller amounts of data loss and downtime
 Disaster Recovery
 restoring operational service after a failure
 a catastrophic event occurs and an extended
outage is necessary to get back and running
--Alan Hirt - Pro SQL Server 2008 Failover Clustering Book

6. High Availability

7. Why do we need another solution?
 The current High Availability and Disaster
Recovery Solutions from Microsoft are
scattered.
 High Availability /Disaster Recovery
Solutions:
 Windows Failover Clustering
 Database Mirroring
 Log Shipping
 Database Replication

8. SQL Failover Clustering
 A failover cluster is a combination of two or more
servers(nodes) connected to a shared storage.
Node 1
client
App Server Database
Node 2
Windows Server Failover Cluster

9. SQL Failover Clustering Issues
 Protects against hardware loss and not disk loss.
 Multi site cluster across data centers is tedious
using VLAN etc.
 Passive node is not used thus not achieving
maximum utilization of resources.

10. Database Mirroring
Primary DB
Primary Server
Client
App Server
Mirrored Server Primary DB
Mirrored DB
Primary Server

11. Database Mirroring Issues
 Can have only one mirror. No multiple copies of data.
 Mirrored database is not readable, though snapshots
can be taken from the mirrored database. Maximum
utilization of resources is not met.
 Must be setup on each database individually.
 Per database failover, no automatic failover of
multiple databases.
 No sql logins/jobs are replicated to the mirrored
instance.
 Either synchronous or asynchronous mirroring is
supported but not both.

12. Log Shipping
Primary DB
Primary Server
Client
App Server
Secondary Server
Primary Server Primary DBDB
Secondary

13. Log Shipping
Primary DB
Primary Server
Client
App Server
Secondary
Primary Server Primary DBDB
Secondary
Server

14. Log Shipping Issues
 Cannot have synchronized databases.
 Must be setup on each database individually.
 In case of failover, the connection string needs to
change to point it to the failover server.
 No logins/jobs are replicated to the mirrored
instance.

15. What if we had all these features in a
single solution?
 Protects against hardware loss.
 Protects against disk loss.
 Multiple copies of replicated databases.
 Readable mirrored databases thus maximizing
resources.
 Multiple database failover at once.
 No need to change the connection string in case
of failover, you can use the same abstract name.
 Failover can occur across datacenters without
extra effort.

16. The answer is…….
SQL 2012 AlwaysOn

17. Modes of SQL2012 AlwaysOn
1. AlwaysOn Failover Clustering Instance(FCI).
2. AlwaysOn Availability Groups.
Today we will discuss AlwaysOn Availability
Groups.

18. Rules

19. Availability Groups
Requirements:
 Needs to have Windows failover cluster(WSFC).
 Supported in Enterprise Edition Only.
 Install individual SQL servers on each machines,
not cluster aware.
 All servers should be in a single windows cluster.
 Matching hardware not required.
 Database should have Full Recovery model with
at least one full successful backup.
 All nodes must be in the same AD domain.

20. New Technology, New Vocabulary

21. Availability Groups Vocabulary
 Availability Group:
 Availability Replicas:
 Availability Group Listener:

22. Demo Architecture
Local Data
Center
SANJOSE SANJOSE 2
Synchronous Commit
DR Site
NEWYORK
Asynchronous Commit

23. Availability Groups Setup
VM1 VM2 VM3 VM4
Host Name CALIFORNIA SANJOSE SANJOSE2 NEWYORK
Server Type Domain SQL Server SQL Server SQL Server
Controller
OS W2k12 Server W2k12 Server W2k12 Server W2K12 Server
IP Address 192.168.81.1 192.168.81.2 192.168.81.3 192.168.81.4
Subnet 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0
Mask
Domain: SQL2012.Demos
Cluster Name: SQL2012AlwaysOn(192.168.81.10)
Availability Group: SQLSatAG
Listener: SQLSatListener – 192.168.81.30

24. Demo
 Sync/Async Failover.
 Availability Groups Listener.
 Read-only routing.
 Readable secondary.
 Backup on secondary.

25. Availability Groups Features
 Synchronous Commit – up to 2 mirrored replicas.
 Asynchronous Commit – up to 4 mirrored replicas.
 Can have read-only secondary databases.
 SQL Logins can be failed over using contained
databases.
 Windows PowerShell is fully supported.
 Backups can occur on the replica databases.
 DBCC commands can be run on secondary.
 Flexible failover policy – sp_server_diagnostics.
 Quorum is very important.

26. Just when things were going right!

27. Some disadvantages
 Needs Enterprise Edition of SQL 2012.
 Needs Windows Cluster which in turn needs
Windows Enterprise.
 If read-only feature on replica is used, you
need to take care of extra licensing.
 System databases cannot be replicated-
users and jobs are not part of replication.
 Differential backups are not supported on
secondary.
 Deep understanding of WSFC and quorum.

28. References
 AlwaysOn Whitepaper
http://msdn.microsoft.com/en-us/library/jj191711
 Creating Virtual machines using Virtual Box
http://bifuture.blogspot.com/2012/04/creating-sql-server-2012-
playground.html
 Setting up Availability Groups
http://www.brentozar.com/archive/2011/07/how-set-up-sql-server-
denali-availability-groups/
 Creating virtual machines on Hyper-V and AlwaysOn Features
http://www.sqlfeatures.com

29.  July 27th in Sacramento!
 Looking for Speakers and Sponsors!
 Come Attend!!
 Help us spread the word!!

30. Q&A

31. Contact Information
 Dilip Nayak
 Email: d_nayak@hotmail.com
 Twitter: @d_nayak
 Mitchell Bottel
 Email: mitch@iitconsulting.com
 Twitter: @SacSQLDude