always on availability groups way too deep

22
AlwaysOn Availability Groups Way Too Deep Joey D’Antoni SQL Saturday #164 Cleveland 18 August 2012

Upload: jdanton

Post on 14-Jun-2015

841 views

Category:

Technology


1 download

DESCRIPTION

Deep Dive into AlwaysOn Availability Groups.

TRANSCRIPT

Page 1: Always on availability groups way too deep

AlwaysOn Availability Groups

Way Too DeepJoey D’Antoni

SQL Saturday #164 Cleveland

18 August 2012

Page 2: Always on availability groups way too deep

About Me

Principal Architect SQL Server, Comcast Cable

@jdanton

Joedantoni.wordpress.com (Slides will be here and on SQL Sat site)

[email protected]

Page 3: Always on availability groups way too deep

Agenda

Overview of AlwaysOn Extended Events Briefly What Happens When?

Turn on AlwaysOn

We Build an Availability Group

We add data to a Primary DB

We backup the transaction log on the secondary

We query the secondary DB

Page 4: Always on availability groups way too deep

Warning

You are going to see a few things that aren’t fully documented

We aren’t touching anything—just looking to see what’s going on

I’m telling you what I think is happening, I’m still trying to get answers on some of it

Page 5: Always on availability groups way too deep

Availability Groups

Page 6: Always on availability groups way too deep

Extended Events

Eventual Replacement for SQL Profiler Tracing 612 Events in SQL 2012 A significant portion of these deal with AlwaysOn

(HADR)

Page 7: Always on availability groups way too deep

What Happens When…

We enable AlwaysOn

Page 8: Always on availability groups way too deep

Enable AlwaysOn

Demo

Page 9: Always on availability groups way too deep

HADR_WSFC_CHANGE_NOTIFIER_STATUS

Page 10: Always on availability groups way too deep

Creating an Availability Group

Object in AD and DNS Gets Created (Listener) Database(s) get restored onto secondary Lots of Metadata gets created to Manage the

Availability Group

Page 11: Always on availability groups way too deep

Building Availability Groups

Demo

Page 12: Always on availability groups way too deep

Moving Data

Database Mirroring used a single thread per database to move data

Always On is different—it uses a request pool that is shared between all AlwaysOn Databases

On the primary messages the active log scanner is the log pole.  

When a secondary is ready to receive log blocks a message is sent to the primary to start the log scanning.  

This message is handled by a worker in the HadrThreadPool. 

Page 13: Always on availability groups way too deep

Moving Data

Page 14: Always on availability groups way too deep

Moving Data

Demo

Page 15: Always on availability groups way too deep

Transaction Log Backup on Secondary

One of the new features of 2012

Allows us to flush the log on the primary database by backing up on the secondary

Page 16: Always on availability groups way too deep

Secondary Log Backup

Demo

Page 17: Always on availability groups way too deep

Querying Secondary Instance

Another Big Feature of AlwaysOn Replicas

Runs in Snapshot Isolation Transaction Level to Minimize Blocking Issues

Creates Secondary Stats where missing—in TempDB

Page 18: Always on availability groups way too deep

Stats on Secondary

Page 19: Always on availability groups way too deep

Stats on Secondaries

Demo

Page 20: Always on availability groups way too deep

Summary

AlwaysOn is pretty cool

It’s clear a lot of work went into this

It’s fairly complicated, but the good news is that it’s easy to work on

Page 21: Always on availability groups way too deep

Questions

Page 22: Always on availability groups way too deep

Contact

@jdanton

[email protected]

Joedantoni.wordpress.com