Drop the Pressure on your Production Server


Published on

Presented by Pieter Vanhove.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Drop the Pressure on your Production Server

  1. 1. TECHNET LIVE MEETINGDrop the pressure on your production serverPieter Vanhove
  2. 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. 3. AGENDA• AlwaysOn – In Short• Offloading reporting workload in SQL Server 2008 R2• Setting Up Readable Secondary Replicas• Configure Connection Access on an Availability Group• Backup on Secondary Replica• Impact of Workloads on a Secondary Replica • On High Availability • On Primary • On Query Plans & Statistics
  4. 4. ALWAYSON – IN SHORT• 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
  5. 5. ALWAYSON – IN SHORT• Each availability group defines a set of two or more failover partners known as availability replicas• Each replica hosts a copy of the databases in the availability group Replica
  6. 6. ALWAYSON – IN SHORT Primary Role• Every replica is assigned an initial role – primary role or the secondary role, which is inherited by the availability databases of that replica.• Primary replica is assigned the primary role and hosts read-write databases• Secondary replica hosts read-only databases. Secondary Role
  7. 7. ALWAYSON – IN SHORT1 Commit 7 Acknowledge 6 Acknowledge Constantly Redoing on Replica 2 Transmit to Replica 2 Write to Local 3 Committed 4 Write to Log in Log Remote Log 5 DB Log Log DB
  8. 8. ALWAYSON – IN SHORT - BENEFITS• Supports on 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
  9. 9. READ-ONLY ACCESS TO SECONDARY REPLICA• Take advantage of your existing investment• Offload your read-only workloads from your primary replica• Optimizes resources on your primary replica• Near real time• Read-Only access is configured at the replica level.• You can determine the read-only access behavior whenever the replica is a secondary replica
  10. 10. LIMITATIONS AND RESTRICTIONS• Change tracking and change data capture are not supported on the databases that belong to a readable secondary replica• DBCC SHRINKFILE operation might fail on the primary replica if the file contains ghost records that are still needed on the secondary replica• DBCC CHECKDB is blocked. “The database could not be exclusively locked to perform the operation”
  11. 11. OFFLOADING WORKLOAD IN SQL SERVER 2008 R2• Database Mirroring • Snapshot on the mirror • Name of the snapshot is different • Snapshot is a static view, no real-time data • Overhead
  12. 12. OFFLOADING WORKLOAD IN SQL SERVER 2008 R2• Log Shipping • Run a reporting workload on the log shipping target node • Data Latency • If the secondary database is open for reporting workload, the log backups cannot be restored
  13. 13. OFFLOADING WORKLOAD IN SQL SERVER 2008 R2• Replication • Transactional replication • You can create reporting-workload-specific indexes • Filter the dataset on the subscriber database • All tables require a primary key • Not suitable for high transaction throughput
  14. 14. SETTING UP READABLE SECONDARY REPLICAS• Yes • Clients can connect to the secondary replica explicitly to run the reporting workload• Read-intent-only • Connections that have the ApplicationIntent=ReadOnly are accepted. • Allows clients to automatically connect to readable secondary • Prevent read loads from running on the primary
  15. 15. CONFIGURE CONNECTION ACCESS• For each readable secondary replica that is to support read-only routing, you need to specify a read-only routing URL• For each availability replica that you want to support read-only routing when it is the primary replica, you need to specify a read-only routing list
  16. 16. CONFIGURE CONNECTION ACCESS ReadOnly Check DB and AVG Routing URL Primary R e d i r e c tSecondary
  17. 17. WHERE WOULD YOU PREFER TO PERFORM BACKUPS?•Preference DescriptionOnly on the primary Backups should always occur on the primary replica.replicaOn secondary Backups should occur on a secondary replica exceptreplicas when the primary replica is the only replica online.Only on secondary Backups should never be performed on the primaryreplicas replica. Backup jobs should ignore the role of the availabilityNo preference replicas when choosing the replica to perform backups.
  18. 18. BACKUP PRIORITYSetting Description The relative priority of a given replica relative to the1..100 backup priorities of the other replicas in the availability group. 100 is the highest priority. The availability replica will never be chosen for0 performing backups.
  19. 19. BACKUP – IMPORTANT POINTS• The backup on the primary replica still works• Only copy only full backup is allowed for secondaries• Differential backups are not supported on secondary replicas• BACKUP LOG supports only regular log backups, the COPY_ONLY option is not supported• Secondary replica must be able to communicate with the primary replica and must be SYNCHRONIZED or SYNCHRONIZING• Priority is not enforced by SQL Server, script your backup jobs
  20. 20. SCRIPTING OF BACKUP JOBSDetermine whether the current replica is the preferred backup replica? sys.fn_hadr_backup_is_preferred_replicaIF (NOT sys.fn_hadr_backup_is_preferred_replica(@DBNAME))BEGIN Select This is not the preferred replica, exiting with success; RETURN 0ENDBACKUP DATABASE @DBNAME TO DISK=<disk> WITH COPY_ONLY;Remark: If you use the Maintenance Plan Wizard, the job willautomatically include the scripting logic that calls and checks thesys.fn_hadr_backup_is_preferred_replica function
  21. 21. IMPACT ON HIGH AVAILABILITY• Recovery Point Objective • Asynchronous commit mode, there is no additional impact • Synchronous commit mode, no data loss• Recovery Time Objective • After a failover, the REDO thread needs to apply the transaction log records. • The longer the REDO thread, the longer it takes to bring the DB online
  22. 22. A READ-ONLY WORKLOAD CAN IMPACT THE RTO• If the reporting workload is I/O bound• The REDO thread can be blocked by the reporting workload • DML operations • DDL operations• Result = Data Latency
  23. 23. TROUBLESHOOTING REDO BLOCKING• a lock_redo_blocked Extended Event is generated• query the DMV sys.dm_exec_request on the secondary• AlwaysOn Dashboard
  24. 24. IMPACT ON PRIMARY WORKLOAD• 14-byte overhead occurs only when an existing row is updated or deleted or when a new row is added.• This is very similar to the impact of enabling RCSI/SI on the primary• No row versions need to be generated on the primary replica.• The extra 14 bytes can lead to more page splits
  25. 25. IMPACT OF A REPORTING WORKLOAD UNDER SNAPSHOT ISOLATION• Snapshot Isolation • When a row is modified, its previous version is saved in the version store backed by tempdb and a 14-byte pointer is set from the modified row to the versioned row.• 4 scenarios • SI and RCSI are not enabled on the primary - secondary not enabled for read • SI and RCSI are not enabled on the primary - secondary is enabled for read • SI and RCSI are enabled on the primary - secondary not enabled for read • SI and RCSI are enabled on the primary - secondary is enabled for read
  30. 30. DO READ WORKLOADS RUNNING ON THE SECONDARY REPLICA IMPACT THE ACKNOWLEDGEMENT (ACK) FOR THE1 Commit 7 Acknowledge TRANSACTION COMMIT? 6 Acknowledge Constantly Redoing on Replica 2 Transmit to Replica 2 Write to Local 3 Committed 4 Write to Log in Log Remote Log 5 DB Log Log DB
  31. 31. QUERY PLANS & STATISTICS• Statistics created on the primary are automatically available on the secondary• How are missing statistics created or stale statistics updated on the secondary replica?• Temporary statistics are created and stored in tempdb.• Statistics can be lost if SQL Server is restarted• Temporary statistics are removed when a primary replica fails over.
  32. 32. RESOURCES• AlwaysOn Team Blog • http://blogs.msdn.com/b/sqlalwayson/• SQL Server 2012 Whitepapers • http://msdn.microsoft.com/en-us/library/hh403491• SQL Diablo Blog • http://www.sqldiablo.com/alwayson/
  33. 33. © 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.