Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Keep your environment always on with sql server 2016 sql bits 2017
Similar to Keep your environment always on with sql server 2016 sql bits 2017 (20)
More from Bob Ward
More from Bob Ward (16)
Recently uploaded
Recently uploaded (20)
Keep your environment always on with sql server 2016 sql bits 2017
- 4. Readable secondaries load balancing DTC support GMSA support > 2 Auto- failover targets Basic HA in Standard edition
- 5. Environments have multiple domains that cannot be merged No trust relationships Installations that do not use Active Directory domains (Ex. Workgroups) All nodes in a single domain Nodes in multiple domains with full trust Nodes in multiple domains with no trust Nodes in no domain at all Read our blog docs Requires combo of Powershell scripts, T-SQL scripts, SSMS, and Windows UI blog blog
- 6. blog
- 7. Secondary AG Replica VDI Stream No need for initial full backups on primary Automatic restores on secondary Everything built-in - Network share not required Why Automatic Seeding Use T-SQL interfaces to create VDI Stream - not compressed by default (use TF 9567 but could result higher CPU) Backup/Restore process – same worker thread design as normal backup (one worker per drive) May not be the best for large dbs with slower replicas – Large network stream and log cannot be truncated on primary How it works Extended Events - dbseed category (debug channel) DMVs – sys.dm_hadr_automatic_seeding sys.dm_hadr_physical_seeding_stats Diagnostics Primary AG Replica
- 9. CREATE AVAILABILITY GROUP [ag] WITH (DB_FAILOVER=ON) FOR DATABASE [agdb] Database state health trigger (“callback”) Enabled for entire AG Database State SUSPECT | OFFLINE | RECOVERY_PENDING sqlserver.availability_replica_database_fault_reporting XEvent May not trigger immediately Independent of flexible failover policy Refresher here Ex. When we write to tlog
- 11. Great article on diagnosing cause of a AG failover Overall server problem SQL Server lease thread unresponsive 100% CPU Utilization Server “hung” The gory details
- 15. Extended Events recovery_unit_harden_log_timestamps log_block_pushed_to_logpool hadr_logblock_compression hadr_log_block_decompression hadr_transport_receive_log_block_message hadr_log_block_group_commit hadr_capture_filestream_wait hadr_lsn_send_complete hadr_receive_harden_lsn_message Perfmon counters
- 22. • Async only for read-only workloads. Not for HA Cluster-less Availability Groups support • Here are the docs for SQL and Linux setup Availability Groups for SQL Server on Linux Cross-Platform Migration
Editor's Notes
- Recommendations and fixes for WSFC: https://support.microsoft.com/en-us/kb/2920151 Pre-requisites, Recommendation and Restrictions for Always ON Availability Group: https://msdn.microsoft.com/en-us/library/ff878487.aspx Readable secondaries load balancing: https://blogs.msdn.microsoft.com/alwaysonpro/2016/05/02/sql-server-2016-alwayson-availability-group-enhancements-load-balance-read-only-routing/ Log transport performance - https://blogs.msdn.microsoft.com/bobsql/2016/09/26/sql-server-2016-it-just-runs-faster-always-on-availability-groups-turbocharged/ Multiple automatic failover targets - https://blogs.msdn.microsoft.com/alwaysonpro/2016/05/02/sql-server-2016-alwayson-availability-group-enhancements-multiple-automatic-failover-targets/ Support for encrypted databases - https://blogs.msdn.microsoft.com/alwaysonpro/2016/06/23/sql-server-2016-alwayson-availability-group-enhancements-support-for-encrypted-databases/ Basic Availability Groups - https://msdn.microsoft.com/en-us/library/mt614935.aspx DTC support: https://msdn.microsoft.com/en-us/library/ms366279.aspx#dtcsupport
- Undoc’d trace flag 9520 will report this in the ERRORLOG. Not supported and provides more tracing about AGs. Use it only for testing and observation.
- TODO: Use a debugger here instead. Amit says so
- Before SQL 2016, HADR manager could only read the log blocks from the transaction log files (so log_flush_complete should always happen before hadr_capture_log_block and consequently before hadr_log_block_send_complete). In SQL 2016, we have the logWriter Mode, where in the log blocks can be read directly from the Log Buffer, so there is a chance where the sequencing of the events may change.