Drop the Pressure on your Production Server

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.