1. AlwaysOn Readable Secondary
Sunil Agarwal

2. Agenda Readable Secondary Reporting Workloads Today Value Proposition
Architecture
Impact and Performance
Demo
Application Connectivity

3. Reporting Workloads Today
Transactional Replication
Database Mirroring
Most widely used for offloading reporting scenarios today
Pros:
Large number of subscribers, Filtering of data
Reporting work load specific indexes
Cons:
Need replication expertise to manage and tune environment
Run all workloads including reporting on Primary
Impacts primary workload
Resource/Blocking
Run reporting on mirror with snapshots.
Data Latency
Additional management overhead
No application failover
Performance Impact during snapshot

4. Active Secondary – Readable Secondary
SQLservr.exe
Secondary
SQLservr.exe
Primary
Secondary
Primary
InstanceA
Database Log Synchronization
InstanceB
DB2
DB1
DB2
DB1
Reports
Reports
Explains purpose and “close to real-time” nature of queries
Readable secondary allow offloading read queries to secondary
Low data latency.
After failover, the read applications can be connected to new Secondary
Not a replacement for replication scenarios

5. Readable Secondary – Data Latency
DB1
DB1
Log Capture
Network
Log Capture
Primary
Log Recieve
Secondary
Log Pool
Commit
Redo Thread
Log Cache
Log Cache
Redo Pages
Log Flush
Log Hardened
Page Updated
DB1 Log
DB1 Data
Acknowledge Commit
DB1 Log
DB1 Data
Explain that the log cache is flushed when either it is full or a transaction has committed.
Sync implies no data loss
Explain why it is only close to real time and never real time even when the mode is synchronous
What happens
On Async Replica when network is slow (data loss)
What happens if the REDO thread is slow to apply the log
Secondary read is always behind primary during transaction activity
Log is first hardened and then applied (REDO thread)
Redo thread is asynchronous and runs in the background
Latency (typically seconds) can be larger for log intensive operations like bulk import or index create/rebuild
Sync Replica minimizes latency due to network issues

6. ReadSec: Impact of Read Workload
Impact on RTO
Reporting workload can take resources away from persisting the transaction log and REDO thread
Can impact the primary workload (Sync mode)
Can impact the recovery time(RTO)
DB1
Log Apply
Redo Thread
Log Cache
Redo Pages
Mitigation
Use AsyncReplica to eliminate impact on the primary workload
User resource-governor to control resources taken by reporting workload
Resources taken by REDO thread
IO to read the log
Fetch the page from disk to apply the log change (IO)
CPU to apply the change
Typically, you will incur lot more IO to apply the transaction log on the secondary.
DB1 Data
DB1 Log
Page Updated
Resource Intensive
CPU
Memory
Reports

7. TechReady12 Sunil Agarwal Program Manager SQL Engine
6/9/2018
Readable Secondary
Sunil Agarwal
Program Manager
SQL Engine
In this demo, show the following
Setup AG
create database Snapshot
Do the DML on the primary and now show the queries running on database snapshot and RS
Now show the challlenges
Blocking
Stats
demo
© 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.

8. RS: Impact of read workload (Cont.)
Impact on RTO (cont.)
Concurrency and Blocking
REDO can get blocked by reporting workload
REDO thread and read workload can deadlock
Solution
Internally map read workload to non blocking isolation levels (no application changes required)
Read Uncommitted  Snapshot Isolation
Read Committed  Snapshot Isolation
Repeatable Read  Snapshot Isolation
Serializable  Snapshot Isolation
Ignore all locking hints
Never choose REDO as deadlock victim
Result
Blocking and deadlock between Reporting workload (i.e. Query) and REDO thread is eliminated
No issues with DML (INSERT/DELETE/UPDATE) as it is not allowed
Will incur additional cost of row versioning.

9. SI Mapping and Row Versioning
Support Snapshot Isolation Mapping
Row versions must be created on the secondary replica
Rule:
Primary and Secondary replica (i.e. database(s) must have the same physical structure
Implications:
14 bytes must be added to data/index row on the primary replica
Not an issue if SI or RCSI is already enabled on the primary replica
Does not require enabling SI/RCSI on primary
XSN
RID
6 bytes
8 bytes
Version overhead
Data Row
Optimization
Extend the data/index row by 14 bytes on primary but no row version to be generated
REDO thread on secondary will generate the version only if secondary replica is enabled for read workload
If no secondary replica is enabled for read workload, extra 14 bytes are not added to the rows

10. Row Versioning Optimizations
Enable RS
No RCSI/SI
Row Version
Primary
Secondary
Enable RS
RCSI/SI
Optimization
Extend the data/index row by 14 bytes on primary but no row version to be generated
REDO thread on secondary will generate the version only if secondary replica is enabled for read workload
If no secondary replica is enabled for read workload, extra 14 bytes are not added to the rows
Primary
Secondary

11. DDL and Reporting Workload
On standalone SQL Server
Query under SI can block a concurrent DDL
Same can happen on Readable Secondary
REDO can block Reporting Workload
Read workload can block REDO thread
Mitigation
DDL not common in production environment
You may have flexibility in scheduling maintenance jobs with concurrent Reporting Workload
An XEvent is generated when REDO is blocked. You can choose to kill Reporting workload
Primary Replica
Secondary Replica
Start Reporting workload on table T1
Takes SCH-S lock on table T1
Execute DDL operation on table T1
REDO processes the DDL log record
Requests SCH-M lock on table T1
Reporting Workload completes
REDO is unblocked
Blocked

12. Query Performance on Secondary
Optimized Query Plans
Goal: Comparable query plan on Readable Secondary
Query Optimization and Statistics
SQL Server uses cost based optimizer that heavily relies on object statistics
If statistics are missing, SQL Server automatically creates them and persists
Auto-stat on readable secondary will require physical Changes
Example: Table T1 (C1, C2, C3)
Query on primary with predicate (C3 > 10).
SQL Server auto-create the statistics, if needed, on column C3 on primary replica
Won’t work on Readable Secondary as it will cause physical changes to the database.
Similar issue if the statistical information is stale on the secondary replica.
Solution
Auto-create statistics on the secondary replica but persist them in TempDB
Existing catalog views (e.g. sys.stats) show temporary statistics
Key points
Temp stats are only created if AUTO STAT is enabled on primary
Auto-stats are only sampled based

13. Auto Stats: Permanent vs. Temp
SQL Memory On RS
stats T1/C1
Stats blob T1/C1
Stats blob T1/C1
Stats blob T1/C1
Key points
Missing TempStats are created with a special name
If stats is stale, the name does not change (i.e. the tempstats are created using the same name)
If tempstats exist but auto stat is created on the primary, there will be two auto stats on the same column but we SQL Server will choose the latest one.
Show what happens when we create explicit statistics on the primary with a user defined name (check)
Stats blob T1/C1
Stats blob T1/C1
Stats blob T1/C1
User DB
Temp DB

14. RS: Ghost Cleanup Issue Solution Enable RS
No RCSI/SI
Reporting Query
Row Version
Ghost
Ghost
Primary
Secondary
Issue
Cannot remove the ghost row if needed on RS by active query
Solution
Expose low_water_mark_for_ghosts for each database
Ghost can only be removed when it is safe to.
If RS preventing ghost clean up, user action is required.

15. TechReady12 Sunil Agarwal Program Manager SQL Engine
6/9/2018
Readable Secondary
Sunil Agarwal
Program Manager
SQL Engine
Show the following
Show how the version store is growing on the secondary
Show different ways tempstats can be created….
demo
© 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.

16. Setting up Readable Secondary
(1) Describe that a replica can be in two roles

17. Application Connectivity
ApplicationIntent – A New Connection Property
Used to gate access to secondary
Applicable when Secondary Replica set with ALLOW_CONNECTIONS =READ_ONLY
Connection String
Connect directly to a secondary instance
Server=N2; Database=Db1; ApplicationIntent = ReadOnly
Read-Only Routing
Connection behavior optimized for automatic routing of read only applications to secondary

18. Supportability Catalog Views DMVs Xevents PerfMon
Sys.availability_replicas (used to see if secondary allows READ)
Sys.stats
New column to indicate if the statistics is temporary
DMVs
Sys.dm_hadr_database_replica_states
Xevents
REDO Blocked
REDO Unblocked
PerfMon
REDO blocking

19. Summary Better return on hardware investment
Primary workload can better use available resources
Reporting workload can use secondary replicas
Comparable query plans on secondary replica
Easy to manage and setup

20. 6/9/ :52 PM
© 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.
© 2010 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.