Always on availability groups way too deep

1,251 views
1,044 views

Published on

Deep Dive into AlwaysOn Availability Groups.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,251
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
36
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Always on availability groups way too deep

  1. 1. AlwaysOn Availability Groups Way Too Deep Joey D’Antoni SQL Saturday #164 Cleveland 18 August 2012
  2. 2. About Me Principal Architect SQL Server, Comcast Cable @jdanton Joedantoni.wordpress.com (Slides will be here and on SQL Sat site) jdanton1@yahoo.com
  3. 3. 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
  4. 4. 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
  5. 5. Availability Groups
  6. 6. Extended Events Eventual Replacement for SQL Profiler Tracing 612 Events in SQL 2012 A significant portion of these deal with AlwaysOn (HADR)
  7. 7. What Happens When… We enable AlwaysOn
  8. 8. Enable AlwaysOn Demo
  9. 9. HADR_WSFC_CHANGE_NOTIFIER_STATUS
  10. 10. 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
  11. 11. Building Availability Groups Demo
  12. 12. 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.
  13. 13. Moving Data
  14. 14. Moving Data Demo
  15. 15. 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
  16. 16. Secondary Log Backup Demo
  17. 17. 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
  18. 18. Stats on Secondary
  19. 19. Stats on Secondaries Demo
  20. 20. 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
  21. 21. Questions
  22. 22. Contact @jdanton jdanton1@yahoo.com Joedantoni.wordpress.com

×