Netherlands: Software

Introductie van Micorosoft SQL Server 2016

Issue link:

Contents of this Issue


Page 47 of 212

36 C H A P T E R 3 | Higher availability Note Although including an Azure replica in your disaster-recovery architecture is fully supported for basic availability groups, the New Availability Group Wizard does not allow you the option to add it. However, you can perform this step separately by using the Add Azure Replica Wizard, which is described in "Use the Add Azure Replica Wizard (SQL Server)" at us/library/dn463980.aspx. Using group Managed Service Accounts To comply with regulatory auditing requirements, DBAs or system administrators in a large enterprise must frequently reset service account passwords across SQL Server instances. However, managing individual service account passwords involves a high degree of risk because downtime is likely to occur if anything goes wrong. To address this problem, Microsoft enhanced Windows Server 2012 so that you can more easily manage passwords for a service account in Active Directory by creating a single service account for your SQL Server instances and then delegating permissions to each of those servers. By default, Active Directory changes the password for a group Managed Service Account (gMSA) every thirty days, although you can adjust the password-change interval to satisfy your audit requirements. In SQL Server 2012 and SQL Server 2014, you can implement this feature only in standalone configurations. In SQL Server 2016, you can now use gMSAs with both availability groups and failover clusters. If you are using Windows Server 2012 R2 as your operating system, you must install KB298082 to ensure that services can seamlessly log on after a password change. However, no patches are required if you install SQL Server 2016 on Windows Server 2016. Triggering failover at the database level Beginning in SQL Server 2012, AlwaysOn Availability Groups and AlwaysOn Failover Cluster Instances (FCIs) use the sp_server_diagnostics stored procedure to periodically monitor the health of a server. The default behavior is to fail over an availability group or an FCI when the health monitoring reveals any of the following conditions: The stored procedure returns an error condition. The SQL Service service is not running. The SQL Server instance is not responding. However, in versions earlier than SQL Server 2016, this check does not account for database-level failures. Beginning in SQL Server 2016, you can enable Database Level Health Detection when you create an availability group, as shown in Figure 3-3. This way, any error that causes a database to be suspect or go offline also triggers a failover of the availability group. Note The FailureConditionLevel property determines the conditions that trigger a failover. For normal operations, the default value is suitable. However, you can reduce or increase this property's value if necessary. To learn more, see "Configure FailureConditionLevel Property Settings" at

Articles in this issue

Links on this page

Archives of this issue

view archives of Netherlands: Software - Introductie van Micorosoft SQL Server 2016