drop the pressure on your production server
DESCRIPTION
Presented by Pieter Vanhove.TRANSCRIPT
TECHNET LIVE MEETING
Drop the pressure on your production serverPieter Vanhove
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: [email protected]• Twitter: http://twitter.com/#!/Pieter_Vanhove• Blog: http://blogs.sqlug.be/pieter/• MEET: http://www.microsoft.com/belux/meet/#
Pieter+Vanhove
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
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
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
ALWAYSON – IN SHORT
• 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
Primary Role
1 Commit
2 Write to
Local Log
2 Transmit to Replica
4 Write to Remote
Log
7 Acknowledge
3 Committed in Log
6 Acknowledge
Log DBDB Log
5
Constantly Redoing on Replica
ALWAYSON – IN SHORT
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
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
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”
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
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
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
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
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
CONFIGURE CONNECTION ACCESS
ReadOnly Check DB and AVG
Routing URL
Redirect
Check read_only_routing_list
Routing Enforced
Primary
Secondary
WHERE WOULD YOU PREFER TO PERFORM BACKUPS?
• Preference Description
Only on the primary replica
Backups should always occur on the primary replica.
On secondary replicas
Backups should occur on a secondary replica except when the primary replica is the only replica online.
Only on secondary replicas
Backups should never be performed on the primary replica.
No preferenceBackup jobs should ignore the role of the availability replicas when choosing the replica to perform backups.
BACKUP PRIORITY
Setting Description
1..100The relative priority of a given replica relative to the backup priorities of the other replicas in the availability group. 100 is the highest priority.
0 The availability replica will never be chosen for performing backups.
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
SCRIPTING OF BACKUP JOBS
Determine whether the current replica is the preferred backup replica?
sys.fn_hadr_backup_is_preferred_replica
IF (NOT sys.fn_hadr_backup_is_preferred_replica(@DBNAME))BEGIN Select 'This is not the preferred replica, exiting with success'; RETURN 0 ENDBACKUP DATABASE @DBNAME TO DISK=<disk> WITH COPY_ONLY;
Remark: If you use the Maintenance Plan Wizard, the job will automatically include the scripting logic that calls and checks the sys.fn_hadr_backup_is_preferred_replica function
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
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
TROUBLESHOOTING REDO BLOCKING
• a lock_redo_blocked Extended Event is generated
• query the DMV sys.dm_exec_request on the secondary
• AlwaysOn Dashboard
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
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
SECONDARY NOT ENABLED FOR READ WORKLOAD
SECONDARY ENABLED FOR READ WORKLOAD
PRIMARY RCSI OR SI ENABLED, SECONDARY NOT READ ENABLED
PRIMARY RCSI OR SI ENABLED, SECONDARY READ ENABLED
DO READ WORKLOADS RUNNING ON THE SECONDARY REPLICA IMPACT THE ACKNOWLEDGEMENT (ACK) FOR THE TRANSACTION COMMIT?
1 Commit
2 Write to
Local Log
2 Transmit to Replica
4 Write to Remote
Log
7 Acknowledge
3 Committed in Log
6 Acknowledge
Log DBDB Log
5
Constantly Redoing on Replica
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.
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/
© 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.