Enhanced Database Failover option is not mandatory while configuring Always on Availability Group in SQL Server 2016. It’s optional and If you have enabled Enhanced Database Failover option for any Availability Group along with automatic failover configuration then this option will trigger failover to a synchronized secondary replica in case any database participating in that availability group is no longer able to write transactions.

You cannot set this option for specific databases within availability group. Enhanced database failover or database level health detection will be enabled at availability group level. Once you configure it, all databases participating in that availability group can use this feature to trigger failover if anything goes wrong with them.

Configure Enhanced Database Failover to Availability Group

We can set this option as per our choice or requirement either by using GUI Wizard or by using Transact-SQL. As of now, you cannot configure Enhanced Database Failover option using PowerShell cmdlets. Remember, by default, enhanced database failover option is disabled. If you want to use this feature, you need to enable it. Here, I will explain how to enable Enhanced Database Failover to an Availability Group while its creation and to the existing one.

If you want to check whether an availability group has enhanced database failover enabled or not then we can use dynamic management view sys.availability_groups. You will see a column named db_failover in this DMV. If the value of any availability group is showing zero then it means this feature is disabled and if value shows 1 then it means it’s enabled. You can execute below command to get the settings for all availability group.

select name, db_failover from sys.availability_groups 

Enable Enhanced Database Failover using GUI in SSMS

We can enable this option while configuring availability group or later to the existing availability groups that was already created without enabling this option. As we know there are two ways to create an availability group using GUI in SSMS. One is by using New Availability Group dialog box and another way is by using Availability Group wizard window. Enabling this option is quite same in both ways. To enable enhanced database failover, select its checkbox next to Database Level Health Detection as shown in below image.

You can get this window by following given steps. In SQL Server Management Studio, connect to your SQL Server database engine. Right click on the AlwaysOn High Availability node, and run the New Availability Group Wizard. Check the Database Level Health Detection checkbox on the Specify Name page. Then complete the rest of the pages in the wizard.

Another way to enable this option for existing availability groups are given below. Launch Properties window of existing Availability Group in SQL Server Management Studio. Here, you can see this option as shown in below image. Check the option Database Level Health Detection, then click OK to apply the changes.

Enable Enhanced Database Failover using T-SQL

We can enable enhanced database failover using T-SQL during availability group creation or after creation by running ALTER AVAILABILITY GROUP statement. To configure it during the creation of an availability group, we must set DB_FAILOVER to ON as showing in below command. I have highlighted this in green colour.

CREATE AVAILABILITY GROUP [AG_Techyaz]
WITH (DB_FAILOVER = ON)
FOR DATABASE [Techyaz]
REPLICA ON
       'SQLInstance1' WITH (ENDPOINT_URL = 'ENDPOINT ADDRESS:PORT-Number', FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
   'SQLInstance2' WITH (ENDPOINT_URL = 'ENDPOINT ADDRESS:PORT-Number', FAILOVER_MODE = AUTOMATIC, AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)

If you have already created availability group without enabling this option then we have also an option to add this behavior to existing availability groups by using ALTER AVAILABILITY GROUP command as given below.

ALTER AVAILABILITY GROUP [AG_Techyaz] SET (DB_FAILOVER = ON)

Disable Enhanced Database Failover using T-SQL

We can disable this option simply by running below command. We must set DB_FAILOVER value to OFF to disable this feature.

ALTER AVAILABILITY GROUP [Techyaz] SET (DB_FAILOVER = OFF)

You will see error message 41653 logged in SQL Server error log if an availability group has failed over due to the database level health detection checks.

Cautions

It is very important to understand how enhanced database failover or database level health detection works. This option does not monitor disk uptime or database file availability to trigger failover.

Suppose your database is idle with no active transactions, and with no physical writes occurring and some of the database files become inaccessible in between then this option will not trigger automatic failover. Later, when a database checkpoint occurs, or a physical read or write occurs for fulfilling a query, then SQL Server may then notice the file issue, and react by changing the database status, and subsequently the availability group with database level health detection set on would failover due to the database health change.

As another example, when the SQL Server database engine needs to read a data page to fulfill a query, if the data page is cached in the buffer pool memory, then no disk read with physical access may be required to fulfill the query request. Therefore, a missing or unavailable data file may not immediately trigger an automatic failover even when database health option is enabled.

I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• How to Patch SQL Server Failover Cluster Instance Running with Always on Availability Group?
• SQL Server Alwayson Interview Questions & Answers
• Understanding Backup Preferences in Alwayson Availability Group
• How to Change Failover Mode of Availability Replica in AOAG?
• Fixing Application connectivity Issue after AOAG automatic failover

The post What is Enhanced Database Failover and How to Enable it for Availability Group? appeared first on Techyaz.com.

NOTE: Always test any solution in Lower life cycle environment before deploying it to Production.

Points to Remember

1. I have described steps to upgrade or patch SQL Server failover cluster instance having always on availability group. Do not use these steps while upgrading or patching Windows clustering or standalone SQL Server instances running with Always on Availability groups. If you have AOAG configured on standalone SQL Server instances then read attached article.
2. During the upgrade process, a secondary replica will not be available for failover or for read-only operations, and after the upgrade, it may take some time for the secondary replica to catch up with the primary replica node depending upon the volume of activity on the primary replica node (so expect high network traffic).
3. A higher version of a SQL Server instance cannot be added as a new replica to an existing AOAG. For example, a SQL Server 2016 replica cannot be added to an existing SQL Server 2014 AG.
4. Always first upgrade secondary replica then primary replica because an upgraded primary replica can no longer ship logs to any secondary replica. This may cause data loss as data movement to a secondary replica is suspended.

Planning 

We should be very careful while planning upgrade or Patching for your SQL Server Failover cluster instances and if your SQL Server cluster instances are running with availability groups then you need to be more careful considering its complex configuration. Here, i have given multiple steps that you need to plan during patching any AOAG cluster instance.

1. Make sure you can directly upgrade to the latest version of SQL Server 2017. If you are running with SQL Server 2005, you cannot go directly to SQL Server 2017. You must upgrade SQL Server 2005 to SQL Server 2012, 14 or 2016 before moving to latest version SQL Server 2017.
2. Identify your databases if they are involved in Change Data Capture or Replication then we need to perform some additional activities. These additional steps are given later in this article.
3. Run DBCC CHECKDB to make sure there is no corruption on databases hosted on these cluster instances.
4. You must run Full database backups for all your databases to secure a copy in case anything goes wrong and we need it to restore databases.
5. Make sure Always on Availability Group is working fine and in Healthy state. Fix the issues and make your AOAG configuration in healthy state before going with the upgrade.
6. Disable the backup job from the system that is going to upgrade (current secondary replica) and make sure to run it from the server that is online and acting as primary replica at the time upgrade will process. You can also change the Backup Preferences of AOAG to run backups always from primary replica during this upgrade.
7. No replicas are readable or available for backups during a version upgrade whereas during a non-version upgrade you can configure automated backups to run on secondary replicas prior to upgrading the primary replica.
8. Choose Upgrade approach. As we know, there are three approaches to perform any SQL Server upgrade. In-place upgrade, Side by side upgrade and Rolling upgrade. We will be using rolling upgrade process to apply patch or upgrade SQL Server cluster instances. This approach is used if your SQL Server Instances are required to upgrade in particular sequence. We use this approach if SQL Server is configured with Always on availability group, Database Mirroring, Log Shipping, Replication, Failover Cluster Instances, SQL Server Reporting Scale-out environment.
9. Make sure that synchronization state of the failover target is SYNCHRONIZED during any failover of Availability Group.
10. Develop a rollback plan. Executing this plan will enable you to restore your original environment if you need to rollback.
11. Plan to test the upgrade on Lower life cycle first before deploying on productions.

Upgrade or Patch SQL Server Failover Cluster Instance running with Availability Group

Here, I will explain how to upgrade or patch SQL Server failover cluster Instance running with Always on Availability group. Let me describe the cluster setup first for this upgrade.

• We have four database servers that are hosted in two data centers. Two nodes in each data centers.
• All four nodes are part of same windows cluster group. two set of storage have been shared between two nodes to install SQL Server failover cluster.
• Two SQL Server Failover Cluster Instances have been installed on these nodes of each data centers. One SQL Server failover cluster instance named FCIA is installed in data center 1 and another SQL Server cluster instance named FCIB is hosted in data center 2.
• We have configured Availability Group between these two SQL Server failover cluster instances.
• Each SQL Server cluster instance has two nodes. One active and one passive node in their respective data centers. Although active node in data center 2 is not active for connections but this will work as primary in case AOAG failover.
• Databases are hosted on shared storage that is connected to their respective nodes in their data centers. You can see this configuration depicted in below image.

Now we have to upgrade or patch this AOAG cluster instance configuration. Keep reading this article to understand step by step process to patch such complex AOAG configuration.

We can see above SQL Server cluster instances have Always on Availability Group so we will follow rolling upgrade process to perform upgrade or patch on these SQL Server cluster instances. The sequence to upgrade SQL Server cluster instances having AOAG configuration is to go from passive to active. We will upgrade the inactive nodes before upgrading the active nodes. Have a look at below step by step process.

1. First upgrade or patch passive node of SQL Server cluster instance FCIB i.e. Node 4.
2. Once you will update node 4 of above image configuration then next step is to failover second SQL Server cluster instance FCIB to upgraded instance Node 4 that is hosted in data center 2.
3. Once you performed failover for cluster instance FCIB to node 4 then next step is to patch node 3 that will be in passive state of this inactive SQL Server cluster instance. You can failback SQL Server cluster instance FCIB to node 3 again post patching. This failback is an optional step and not mandatory. Now you have applied latest patch level or upgraded your SQL Server cluster instance FCIB hosted in two cluster nodes in data center 2. Next, we will follow same process to apply patches in data center 1.
4. Apply patch on SQL Server cluster node 2 or upgrade SQL Server cluster node installed on node 2 machine as it’s passive node of SQL Server cluster instance FCIA.
5. Once you have upgraded or patched node 2 in data center 1 next we will failover SQL Server cluster instance FCIA to node 2. Now node 2 will run active instance of SQL Server cluster setup. But If you have enabled change data capture feature or replication configured on your SQL Server cluster instance then you should run few additional steps as described here. Once you upgraded or patched all secondary replicas then fail over the Availability Group to an upgraded instance. Now run below command on your primary replica.

EXECUTE [master].[sys].[sp_vupgrade_replication];

6. Go ahead after execution of above command and upgrade or patch SQL Server cluster instance that was originally the primary replica i.e. Node 1

7. Now, patch SQL Server cluster instance that is hosted on node 1 and was original primary replica that is now acting as passive in this cluster setup. Once done you can failback SQL Server cluster instance FCIA to again node 1 as active node. Here, you have patched or upgraded all SQL Server cluster instances hosted on these four nodes.

Here, I have described how to upgrade or patch SQL Server failover cluster instance that is running with Always on Availability Group. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• How to Restore a Database participating in AOAG?
• SQL Server Alwayson Interview Questions & Answers
• Change Failover Mode of Availability Replica in AOAG
• Add a New Database to Availability Group

The post Upgrade or Patch SQL Server Failover Cluster Instance Running with Availability Group appeared first on Techyaz.com.

• Automatic failover
• Planned Manual failover
• Forced Manual failover (forced failover).

There is no data loss if you perform automatic or planned manual failover but there might be some data loss if you are performing forced manual failover. Whether SQL Server Always on Availability group will failover automatically or manual, it depends on the configuration of AOAG availability mode. SQL Server Always on Availability Group supports two availability modes. First one is Synchronous-commit and another one is Asynchronous-commit mode. Synchronous-commit mode supports Automatic and Manual both failover types whereas Asynchronous-commit mode supports only manual failover that is also forced failover type.

The failover type (Automatic or Manual) will be decided by the failover mode property of availability replica. Always on Availability group failover modes depends on the AOAG availability mode configuration as I described above.

If you have synchronous commit replicas then you would have two failover mode options. One is Automatic failover mode and another is Manual failover mode whereas you have only manual failover mode option available in asynchronous commit replicas.

Here, I will describe how to change failover mode of SQL Server Always On availability group using SSMS and T-SQL statements. You can change from automatic failover mode to manual failover mode or vice-versa based on their availability mode configuration. As I explained above, failover mode is a replica property that determines the failover mode for replicas that run under synchronous-commit availability mode. Read below prerequisites before going to change failover mode of availability replica in SQL Server Always On availability group.

Prerequisites

• Make sure to perform this activity on primary replicas.
• As we know SQL Server Failover Cluster Instances (FCIs) do not support automatic failover by availability groups, so any availability replica that is hosted by an FCI can only be configured for manual failover.
• Make sure that you have admin privilege or minimum you should have ALTER AVAILABILITY GROUP permission on the availability group, CONTROL AVAILABILITY GROUP permission, ALTER ANY AVAILABILITY GROUP permission, or CONTROL SERVER permission.

Steps to Change Failover Mode of an Availability Replica

Here, I will describe to change it using two ways. One is using SSMS and another is using T-SQL statements. Let’s start with SSMS method.

Using SQL Server Management Studio

Follow below step to change failover mode of an availability replica.

1. Launch SQL Server Management Studio and connect to the primary replica, and expand the server tree.
2. Expand the Always On High Availabilitynode and then Availability Groups
3. Select the availability group for which you have to change the failover mode then right-click on the identified replica, and click Properties.
4. In the Availability Replica Properties dialog box, you can select correct Failover mode as per your requirement from the dropdown list to change the failover mode of this replica.
5. Choose any value from drop down as per your requirement and close the windows post apply this new change.

Using T-SQL

We can change failover mode of an availability replica using T-SQL statement as well. Follow below steps to do this change using T-SQL.

1. Connect to the Primary Replica.
2. Open New Query window to execute your T-SQL statements.
3. Run below statement to change the failover mode from Manual to Automatic of an availability group named Techyaz.

ALTER AVAILABILITY GROUP Techyaz MODIFY REPLICA ON 'GURTY01' WITH
(FAILOVER_MODE = AUTOMATIC);

Techyaz is the name of the availability group and GURTY01 is either the computer name or the failover cluster network name. For named instances add full instance name post \ as well. Use the name that hosts the replica that you want to modify.

Here, I have shown you step by step method to change Failover Mode of Availability Replica in SQL Server Always On Availability Group. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• How to Upgrade or Apply Patches on AOAG Instances?
• Understanding Backup Preferences in Alwayson Availability Group
• How to Restore a Database participating in AOAG?
• SQL Server Alwayson Interview Questions & Answers
• Fix SQL Server Alwayson Error 35250: Joining Database on Secondary Replica resulted in an Error

The post How to Change Failover Mode of Availability Replica in Always On Availability Group? appeared first on Techyaz.com.

NOTE: First Test this solution in Lower Life Cycle environment then deploy in Production.

Points to Remember 

Below are important points you should always keep in mind while you are planning or upgrading SQL Server Instances that has Alwayson Availability Group configured.

1. All steps given in this article are limited to upgrading or patching SQL Server Instances that has AOAG configuration. It does not cover operating system upgrade.
2. Secondary replica will not be available for failover or for read-only operations during the upgrade process.
3. A higher version of a SQL Server instance cannot be added as a new replica to an existing AOAG. For example, a SQL Server 2016 replica cannot be added to an existing SQL Server 2014 AG.
4. Don’t upgrade primary replica instance before upgrading or updating any other secondary replica instance. An upgraded primary replica can no longer ship logs to any secondary replica. This may cause data loss as data movement to a secondary replica is suspended.

Upgrade or Patch SQL Server AOAG Instances – Prerequisites

Make sure to meet and follow below prerequisites during planning the upgrade or patching of SQL Server Availability Group Instances.

1. Review the Hardware and software requirements for latest SQL Server version on which you are planning to upgrade.
2. Make sure your application is supported on the latest version of SQL Server on which we are upgrading.
3. Make sure you can directly upgrade to the latest version of SQL Server 2017. If you are running with SQL Server 2005, you cannot go directly to SQL Server 2017. You must upgrade SQL Server 2005 to SQL Server 2012, 14 or 2016 before moving to latest version SQL Server 2017.
4. Choose Upgrade approach. As we know, there are three approaches to perform any SQL Server upgrade. In-place upgrade, Side by side upgrade and Rolling upgrade. As we are planning to upgrade AOAG instance so we will choose Rolling Upgrade method. Below are the details of other upgrade methods.

• In-Place Upgrade: SQL Server setup program upgrades the existing SQL Server installation by replacing the existing SQL Server bits with the new SQL Server bits and then upgrades each of the system and user databases. This method is frequently used in a development environment without a high-availability (HA) configuration or a non-mission critical production environment that can tolerate downtime and that is running on a recent hardware and software.
• Side by Side Upgrade: We build new machine and install all required software keeping source system running separately and then migrate all databases from source to this newly build machine. This method is effective in minimizing the downtime or in case if you need to roll back the upgrade.
• Rolling Upgrade: This method is used if your SQL Server Instances are required to upgrade in particular sequence. We use this approach if SQL Server is configured with Always on availability group, Database Mirroring, Log Shipping, Replication, Failover Cluster Instances, SQL Server Reporting Scale-out environment.

5. Develop a rollback plan. Executing this plan will enable you to restore your original environment if you need to rollback.
6. Plan to test the upgrade on Lower life cycle first before deploying on productions.
7. Identify your databases if they are involved in Change Data Capture or Replication then we need to perform some addition activities. Have a look into last section of this article before performing the upgrades.

Upgrade or Patch AOAG Instances – Planning

Here, I am explaining how to plan SQL Server Availability Group instance patching or upgrade to the newer version. Have a look at below points.

1. Check database integrity on every availability databases that we are going to upgrade. Run DBCC CHECKDB to make sure there is no corruption on databases.
2. Run Full database backups for all your databases to secure a copy in case anything goes wrong we need it to restore databases.
3. Make sure Always on Availability Group is working fine and in Healthy state. You can test a manual failover whether it is working fine or not. If any issue during failover or AOAG not in healthy state, you must fix it before going with the upgrade.
4. Disable the backup job from the system that is going to upgrade (current secondary replica) and make sure to run it from the server that is online and acting as primary replica at the time upgrade will process. You can also change the Backup Preferences of AOAG to run backups always from primary replica during this upgrade.
5. The sequence will be always upgrade the remote secondary replica instances first, then local secondary replica instances next, and the primary replica instance last. If you upgrade the primary replica instance without failing over the Always on availability Group to an upgraded instance with a secondary replica then client applications may suffer extended downtime during the upgrade on the primary replica instance. So better to follow the sequence to reduce downtime.
6. Always failover the AOAG to a synchronous-commit secondary replica instance. If you fail over to an asynchronous-commit secondary replica instance, you might lose some of your data.
7. Make sure that synchronization state of the failover target is SYNCHRONIZED during any failover of Availability Group.

Upgrading or Patching Always on Availability group Instances

Now you have planned and understand the rolling upgrade methodology and the upgrade process of AOAG configured SQL Server Instances. Here, i will explain upgrade or patching of availability group instances into two sections. One has multiple secondary replicas and another have only one secondary replica that also in remote location for DR purpose.

If Availability Group has Local and Remote Secondary Replicas

Here, I am giving a standard process to perform the upgrade on a configuration that has local secondary replicas as well as remote secondary replicas for DR solution. You can consider it as four replica environments where one replica is hosted on local datacenter and remaining other replicas are hosted on one or multiple remote sites for DR purpose. I have illustrated this configuration in below screenshot where we have one local replica and two remote secondary replicas.

Let’s start with upgrade process considering above scenario.

1. Verify you have full database backup for all availability databases. If you don’t have full backups, make sure to run it before this upgrade to protect your data.
2. Now, change automatic failover on synchronous-commit replicas to manual (between replica A and B) to prevent any accidently failovers during upgrade process.
3. Test a manual failover and make sure that it is working fine.
4. Now upgrade all remote secondary replica instances (Replica C and D) running with asynchronous-commit secondary replicas.
5. Upgrade the all local replica secondary instances (Replica B) that are not currently running the primary replica.
6. Once all secondary replicas have been upgraded and you left out only with primary replica to upgrade then manually fail over the AG to a local synchronous-commit secondary replica. Here, Replica B will be acting as primary replica now.
7. Upgrade or update the local replica instance that formerly hosted the primary replica (Replica A).
8. Verify SQL Server version on all replicas to make sure every instance is upgraded. Failback current primary replica from replica B to A that was primary replica initially.
9. Now, configure automatic failover partners from manual failover (between replica A and B) as we did in step 2 to prevent unwanted failover during upgrade process.
10. Perform a failover testing on upgraded instances to make sure everything is working fine.

If Availability Group has only One Secondary Replica for DR solution

If you have configured Availability group only to achieve DR solution having single remote secondary replica with asynchronous-commit mode then you need to follow little different approach for upgrade or apply patches.

You can follow below step by step method to upgrade or Patch your AOAG instances that has only one secondary replica that also on remote site for DR purpose.

1. Verify you have full database backups to secure your data.
2. Upgrade your remote secondary replica that is hosted for DR.
3. Once remote secondary replica is upgraded or Patched, make sure to change the data transfer mode from asynchronous-commit to synchronous-commit to prevent any potential data loss during failover. Do not initiate failover until synchronization state will become SYNCHRONIZED.
4. Initiate the failover once data is synchronized between both replicas. And once failover will be done again change the data transfer more to asynchronous-commit mode to avoid any data latency issue to application users.
5. Upgrade the current secondary replica (Previous Primary Replica).
6. Once both replicas will be upgraded, you can again change the data transfer mode from asynchronous-commit to synchronous-commit to prevent any potential data loss during failover. Do not initiate failover until synchronization state will become SYNCHRONIZED.
7. Failover the AOAG to remote secondary replica and change the data transfer mode to asynchronous-commit.
8. Verify details about SQL Server version.

Additional steps for CDC (change data capture) and Replication

I have described in point no 7 of Prerequisite section to identify databases that are participating in change data capture or in Replication. I have mentioned that because we need to take some additional steps for such databases post upgrade or patching activity.

1. Upgrade each secondary replica as described in above sections.
2. After all secondary replicas have been upgraded, fail over the AG to an upgraded instance.
3. Execute below T-SQL statement on the instance that hosts the primary replica:

EXECUTE [master].[sys].[sp_vupgrade_replication];

4. Upgrade SQL Server instance that was originally configured as primary replica.

I hope you like this article. Please Like, Comment, Share & Subscribe to this website to get new articles directly into your inbox. You can also follow our Facebook page and Twitter handle to get latest updates.

The post How to Upgrade or Patch Alwayson Availability Group Instances? appeared first on Techyaz.com.

Microsoft SQL Server Error 35250

We generally get this error whenever there is a communication issue between endpoints of both replicas or any replica unable to connect to the endpoints cause this error to generate. You will see below error texts if you are getting this issue.

Alwayson Error 35250
Failed to Join the database ‘DBName’ to the availability group ‘AOAG-Name’ on the availability replica ‘Availability Replica Name’

There are many reasons behind this error that we will discuss in next section. You might also get below text if you are using T-SQL.

Below is the screenshot of this error.

Solution

You should check below points based on attached article MSDN link whenever you get this error.

• Inbound Port 5022 Traffic is Blocked
• Endpoint is not created or started
• Endpoint permissions
• SQL Server is not listening on port 5022

But if everything is ok and you are still not able to diagnose this issue, then you should keep reading this article.

I checked everything and all was well on both replicas.  As we know that there should be Grant CONNECT permission on Always On endpoint. I was reassigning GRANT CONNECT on the endpoint and came to know that the SQL Server service account was not added to the SQL Server instance of secondary replica. That is why we faced this error. Let’s first get the endpoint and then we will run Grant connect on endpoint to see the issue. Run below command to get the name of endpoint that is using in this alwayson configuration.

We can see endpoint name is hadr_endpoint. Now run below command to grant connect permission on endpoint hadr_endpoint. The login name is the service account that is used to run SQL Server services.

You can see, error is saying that the account doesn’t exist on SQL Server.

Although you can directly check this step in SSMS as a prerequisite once error is reported. The SQL Server service accounts should be added to SQL Server Instances. I checked this account on both replica and found that it was very much there on primary replica but it was not created on secondary replica. That was the missing point which caused this issue.

Now create this service account on secondary replica as well or where it was missing on any of the replica then you can try to re-add the database to the AOAG configuration. This time your database will be added to the AOAG configuration. If you are facing issue during joining database to the AOAG configuration then you can remove the existing AOAG and reconfigure it.

Your issue will be fixed if you check and follow all above suggested points including the one mentioned in MSDN link. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• Fix AOAG Error 976:Cannot Connect to Secondary Replica
• How to fix AOAG Listener Issue 19471: The handle is Invalid
• Fix Listener Issue that came during AOAG Configuration
• How to fix Error 15141: The Server Principal owns one or more endpoints
• Fixing Application connectivity Issue after AOAG automatic failover

The post SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error appeared first on Techyaz.com.

AlwaysOn Listener Error 19471

When i checked the AlwaysOn High Availability folder in SSMS on any of the replica, everything was working fine. AOAG was configured successfully and working fine but listener was not configured due to below listener error 19471. You can see this in below screenshot.

I tried creating Listener name using “Add Listener…” wizard in SSMS but failed with same error. I observed root cause of this issue during following steps given in my last article that i have attached in first paragraph. Make sure to clear all entries from DNS for your listener Name and IP, if there is any.

Kerberos Status: The handle is Invalid

First we will create a Client Access Point(CAP) in FCM for this listener name to check the status of NetBIOS, DNS & Kerberos that will help us to go deeper inside the issue.

1. Launch Failover Cluster Manager and click on Roles tab from left side pane. Here you can see your availability group role in right side pane.
2. Right click on this role and select “Add Resources” then “Client Access Point“.
3. Enter the Listener name and its IP address and click on Next button to proceed.
4. Click on Finish button of final screen to create the Listener Client Access Point in FCM.
5. Once CAP will be created in FCM, it will be in Offline state. Right click on listener CAP and click on “Bring Online” to bring it online. You can see Listener IP comes online but Listener name still shows in offline state.

Now double click on listener client access point or right click on it and choose properties. You will get CAP property window as shown in below image.

You can see, this time issue is with Kerberos status that is showing as “The handle is invalid“. Earlier DNS status was not ok in last article.

Fix Kerberos Status The handle is invalid

When i look into Active Directory server, i found that listener name object was showing as disabled as shown in below image.

I decided to enable it and then to create listener. Right click on listener name object on AD that are showing in disable mode with down arrow and click on “Enable Account” button as per below image.

You can see, listener name account is enabled and down arrow that are showing during disabled mode is not showing now.

Once you enabled the listener name object in AD, bring your listener CAP online in FCM. Right click on listener client access point and click on bring online. You can see listener CAP is showing online now.

When you will launch its property window, you will see the status of NetBIOS, DNS and Kerberos are showing OK now. Close this property window to proceed.

Now we will follow same process that we have followed in my last article. We will remove this listener CAP from FCM and then add listener in AOAG in SSMS. Right click on CAP in FCM and click on Remove button to delete it.

Once CAP will be removed, launch the SSMS and connect to your Primary Replica. Expand AlwaysOn High Availability folder followed by Availability Group. Now you can right click on Availability Group Listeners and click on Add Listener option. You will get below window to configure it.

Enter the listener name, port and then add its IP. Once you entered all details, click on OK button to create the listener. This time, listener will be created on all replicas. You can see i have just created listener for my alwayson availability group that are showing in below image for both replicas.

Related Articles:

• How to fix Listener Error 19471: DNS Status is showing “The handle is invalid” for Listener CAP in FCM
• Fix Error 976: Cannot connect to Secondary Replica
• How to fix error 15141: The server principal owns one or more endpoint(s) and cannot be dropped
• Fix Error 15434: Could not drop login ‘XXX\yyyy’ as the user is currently logged in

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix AOAG Listener Error 19471: Kerberos Status is Showing The handle is Invalid appeared first on Techyaz.com.

Before going ahead, we need to understand the rules/points that are very important in order to decide the backup preferences in AOAG configuration. Below are the important points you should consider during designing backup strategy of availability databases.

• Regular Full Backups are not allowed from secondary replicas. Only COPY_ONLY full backups are allowed on secondary replicas. That means you cannot run regular Full backup from any of the secondary replica. Remember that copy-only backups do not impact the log chain or clear the differential bitmap.
• Differential backups are not supported on secondary replicas. If you must run differential backups for your availability databases, you should not choose backup preferences as secondary replicas.
• Only regular Log backups are supported on secondary replicas. COPY_ONLY log backups are not supported on secondary replicas.
• Secondary replica must be in SYNCHRONIZED or SYNCHRONIZING state to backup a secondary database.
• Log backup chain is supported across all replicas regardless of where the log backup is taken (primary or secondary replicas) or the mode of the replication (asynchronous or synchronous).
• In a distributed availability group, backups can be performed on secondary replicas in the same availability group as the active primary replica, or on the primary replica of any secondary availability groups.

How SQL Server Decides Which Replica will execute Backup – Backup Preferences ?

It’s little complex process to determine where backup jobs should run.  If you are confused about this question, then keep reading to get the answer.

To decide on which replica, you should run your backup job depends on your Backup Preferences setting. To address this, configure the availability group to specify which availability replicas where you would prefer backups to be performed.

If you choose backup preferences as secondary only then you can create jobs on only secondary replicas or if you choose to run it on primary replica, then you can configure it on primary replica only. But if you decided to go with default option that is preferred secondary then you should schedule backup jobs on all replicas.  Although, Microsoft suggests to create scripted backup-jobs for every availability database on every server instance that hosts an availability replica that is a candidate for performing backups.

Suppose you have chosen secondary only preference and you have 3 secondary replicas then question might arise how database engine will decide that on which replica backup should run. Database engine decides where should run backup based on preferred backup replica settings and backup priority settings. I have explained about these settings later in this article.

AOAG (AlwaysOn Availability group) has a function named sys.fn_hadr_backup_is_preferred_replica  to determine which replica is set as preferred backup replica.  If the out of this function returns 1 it means current instance is the preferred backup replica and backup will run on this instance. If returns 0, it means backup will not run on that replica.  We can use this function in a backup script to determine job should run on which replica, so only one of the scheduled jobs actually proceeds to the backup stage.

In the event of a failover, none of the scripts or jobs needs to be modified. Also, if you reconfigure an availability group to add an availability replica, managing the backup job requires simply copying or scheduling the backup job. If you remove an availability replica, simply delete the backup job from the server instance that hosted that replica. Microsoft has given a sample code logic for this function that can be used to develop backup script.

If sys.fn_hadr_backup_is_preferred_replica( @dbname ) <> 1
BEGIN
-- If this is not the preferred replica, exit (probably without error).
END
-- If this is the preferred replica, continue to do the backup.

If you use the Maintenance Plan Wizard to create a given backup job, the job will automatically include the scripting logic that calls and checks the sys.fn_hadr_backup_is_preferred_replica function.

If you want to check the preferred backup replica for any availability database, you can get it by running below command. If the output of this function returns 1 it means current instance is the preferred backup replica and backup will run on this instance. If returns 0, it means backup will not run on that replica.

--Get the backup preference replica for availability database TechYaz.
SELECT sys.fn_hadr_backup_is_preferred_replica ('TechYaz');
GO

I have executed same function on my secondary replica. You can see the output is showing as 1, it means this replica is set to run backups.

Configure Backup of Availability Databases to Run only from Secondary Replicas using GUI

1. Connect to the server instance that hosts the primary replica, and click the server name to expand the server tree. You would not be able to change Backup Preferences from any secondary replicas. If you open the AOAG name property, you will find all options greyed out.
2. Expand the Alwayson High Availability node and the Availability Groups
3. Click the availability group whose backup preferences you want to configure, and select the Properties.
4. In the Availability Group Properties dialog box, select Backup Preferences You can see backup preference is set to Prefer Secondary, now we need to change it to Secondary only option. The details about each type of backup preference is given in the screenshot and AOAG backup preference property window.

5. There are 4 backup preferences in AOAG that are given below with their capabilities. Choose any as per your requirements. Now I will add one more replica to this availability group as per our requirement and set backup preference to secondary only so that backups always run from either of the both secondary replicas. It is not mandatory for you to add additional replica.

6. Use the Replica backup priorities grid to change the backup priority of the availability replicas. Backup Priority (Lowest=1, Highest=100) specifies your priority for performing backups on this replica relative to the other replicas in the same availability group. In my case backup will run on the replica that has priority 60% and if this will not be available then backup will run on the replica that has priority of 50%. Backup will never run on primary replica irrespective of backup priority settings because we have chosen to run backups only on secondary replica.
   
   We have also an option Exclude Replica to exclude any replica where you don’t want to run backups. This is useful for remote availability replicas to which you never want to run backups there.
   You should click on checkbox for your respective replica name for which you want to exclude the backup as shown in above screenshot.

7. Click on OK button to apply the changes.

Configure SQL Server Backup in AOAG to Run with default backup preference using T-SQL

I have shown you how to change backup preference setting to run backups from secondary replicas using GUI. We can do the same using T-SQL commands as well. Here i will show you how to change backup preference using T-SQL. As we have changed the backup preference to secondary only option where backups will never run from primary replica. Now we can revert this change to default option using T-SQL. Prefer Secondary is default option in which backups run from secondary replica and if only primary replica is online then it will run from primary replica only.

Connect to the server instance that hosts the primary replica and run below command.

--Choose backup preference as per your choice and pass that value in AUTOMATED_BACKUP_PREFERENCE = { PRIMARY | SECONDARY_ONLY| SECONDARY | NONE }
ALTER AVAILABILITY GROUP AG_AOAGName SET (AUTOMATED_BACKUP_PREFERENCE = SECONDARY)
GO

Now your backup preference would be set to Prefer Secondary and backups will run from primary replica if only primary replica will be online.

Related Articles:

• Fix: Secondary Replica Stucked in to Resolving state
• Fix: Connectivity Issue after AOAG Automatic Failover
• Understanding SQL Server Recovery Models
• Fix: Listener Issue Error 19471

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Understanding Backup Preferences for AlwaysOn Availability Group Databases appeared first on Techyaz.com.

Cannot connect to ‘Secondary Replica Server’.
ADDITIONAL INFORMATION:
The target database, ‘SDGC’, is participating in an availability group and is currently not accessible for queries. Either data movement is suspended or the availability replica is not enabled for read access. To allow read-only access to this and other databases in the availability group, enable read access to one or more secondary availability replicas in the group.  For more information, see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online. (Microsoft SQL Server, Error: 976)

The screenshot of this error is given below.

Solution

Before going ahead let me give you a background about SQL Server configurations.

• We have two SQL Servers Server A & Server B and there is an user database SDGC is hosted on both SQL Server Instances.
• AOAG is configured between both servers in Automatic failover mode for database SDGC.
• Availability database SDGC hosted on instance B is inaccessible because it was restored in no recovery mode and not set in read only mode for AOAG configuration.
• User’s login was created on both SQL Server instances with having default database as SDGC that are participating in AOAG.

Now, the problem is whenever user tries to connect to the secondary replica whether AOAG is active from instance A or instance B, he is not able to connect to the SQL Server Instance and getting given SQL Server error 976. I analyzed this issue and found two solutions to fix this issue:

• Change Connect to database value in SSMS while establishing the connection.
• Change default database value of your Login in Login Property window.

Change Connect to database value in SSMS

Launch SQL Server Management Studio. Click on Options tab of connection details window in SSMS as shown in below image.

You can see, Connect to database value showing as default that means it is connecting to the database that is set as default database for user’s login. Remember, default database for user’s login is set as SDGC that is running in norecovery mode.

Now, we just need to change the connect to database value from default to master or some other database. As default database for user’s login was set to SDGC, so change it master to make database engine to read an accessible database.

Once you make changes, hit the connect button and establish a database connection. This time you will be able to establish database connection to secondary replica.

Change default database value of your Login

If default database of your login is not mandatory to set to availability database then you can change it to master and remove this issue permanently. Otherwise, you need to change default database every time you make a connection to secondary replica as discussed in above section.
You can connect to your secondary replica or to the server where you are facing this issue using different admin or security admin account. If you have such account and password, you don’t need to logoff and relogin. You can just right click on SSMS icon while pressing SHIFT button to logged in using different user to the SQL Server instance. You can see that option in below image.

Click on “Run as different user” option. It will display below login screen to enter your new login and password. Enter the credentials.

Once your new account will be authenticated, SSMS will be launched and show you the details as shown in below image. Click on Connect button to establish the connection.

Expand Security folder. Identify your login for which you have to change the default database setting. Right click and choose properties on this login to launch properties window. You can double click on this login as well to launch this properties window. Below window will come to your screen where you can see the default database set for this login.

You can see default database is set as SDGC in above screenshot. Now we need to change it to master or any accessible database. Do the changes, you can see i have changed it to master in our screenshot. Once you make changes, click on Ok button to proceed.

NOTE: If you need to change default database back to availability database due to some application dependencies then you need to first make your availability database accessible. You can perform failover to make secondary replica as primary then you can make changes and then you can failback. If you don’t want to perform failover/failback, then you can do this by changing the availability database from norecovery to read only mode.

Now your issue is fixed. You would be able to connect to the SQL Server Instance that are running as secondary replica in AOAG configuration.  You can see, i have connected to secondary replica using same account with whom i was facing issue.

Related Articles:

• • Fix Error 19471: Listener Issue during Configuring AOAG
  • How to Fix SAP connectivity issue after AOAG failover
  • Fix: Secondary Replica is showing in Resolving state
  • Fix SQL Server Error 15141: Server Principal owns one or more endpoints

Please comment us to give your feedback. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 976: Cannot connect to Secondary Replica of AlwaysON Availability Group appeared first on Techyaz.com.

I have also explained another aspect of this error in attached article. If your issue is not fixed using this article, you can have a look at this one where i got the same Listener Error 19471 because Kerberos Status was showing ‘The handle is invalid’.

Microsoft SQL Server Error 19471: Create failed for Availability Group Listener ‘Listener Name’.

AOAG Listener was failed to create during its configuration and displayed SQL Server error 19471. This error might have multiple reasons. Here i will fix this issue in step by step manner. The full error details are given below.

The screenshot of this error is given below.

When i checked the AlwaysOn High Availability folder on any of the replica, everything was working fine. AOAG was configured successfully and working fine but listener was not configured due to above error. You can see this in below screenshot.

You can see there is no listener showing in their respective folder of the AOAG configuration in above screenshot. I tried creating Listener name from “Add Listener…” wizard but failed with same error. Let’s move to next section where we will fix this error.

Solution

I did some research on this error code and found a solution suggested by Microsoft in attached MSDN article. I followed step by step process given in this article. High level approach to fix this solution using this method is given below.

• Create a Client Access Point (CAP) for the AOAG listener in Failover Cluster Manager.
• Bring CAP Online.
• Repair the CAP, if it is not coming ONLINE.
• Once CAP comes online, remove it from failover cluster manager.
• Add listener to AOAG in SSMS.

You might have a question why we are removing CAP after adding, repairing and bring it online. Creating CAP and bringing it online is to just verify that everything is ok or not. If CAP will not come online then there might be some issue at certain level that needs to be fixed first before creating listener. Let’s go ahead with above given steps to fix this issue.

I launched failover cluster manager and clicked on Roles tab from left side pane. Here you can see your availability group role in right side pane. Right click on this role and select “Add Resources” then click on “Client Access Point“.

You will get below screen to enter listener details. I entered listener name into name section and listener IP in to Address section. Once i clicked at Next button to proceed. I got below error which says this listener is already in use in Active Directory.

As we know, listener name and IP should be unique and unused so here we need to remove this listener details from Active Directory. Contact your domain administrator and tell him to remove the entries for this listener name and IP.

Once listener details will be cleared from Active Directory, go ahead and try to add listener name to the existing AlwaysOn Availability Group. This time you would be able to create the listener name. If you are still facing some issue, then we will follow remaining steps of the above suggested MSDN article. Read next section to follow remaining steps to fix this issue.

Failed to add Listener after clearing DNS entries and DNS Status showing The handle is invalid

If you are still facing same issue during adding listener or configuring AlwaysOn Availability Group then you can again ask your domain admin to relook into Active Directory because there is a possibility of some entries in AD for the listener name and IP during your failed attempts to create the listen name. If domain admin will not find any entry then we will proceed with the steps that Microsoft has suggested in above attached article.

We will create Client Access Point in failover cluster manager for Availability Group role as we were trying to create in above section. Right click on Availability Group role and select “Add Resources” then “Client Access Point” as shown in image no 3. You will get below screen to enter listener name and corresponding IP address in highlighted sections. Click on Next button to proceed post entering the listener details.

You will get below screen to proceed once you click on next button of above screen.

Click on Finish button to create the Client Access Point in failover cluster manager for this listener.

Once you will click on finish button, your Client Access Point for your listener will be created in the failover cluster manager as shown in below screen. Availability Group role was running fine but after adding Client Access Point it has changed into Partial Running mode.

We can see CAP is showing as offline in above image. That is the reason Availability Group role has changed into Partial Running mode. Now we will bring it online manually. Right click on Listener CAP and click on “Bring Online” option.

We can see Listener IP has come online whereas listener name is failed to come online. Now we will check the properties of the client access point (CAP).

Right click on Listener Name and choose Properties option. You will get below screen where you can see NetBIOS, DNS and Kerberos status. NetBIOS and Kerberos status is showing OK but DNS status is not ok and showing “The handle is invalid.” This is the issue that needs to be fixed to create listener.

When i checked the cluster events, i saw below error details that are also very much same.

Cluster network name resource ‘Cluster Name’ failed registration of one or more associated DNS name(s) for the following reason:
The handle is invalid.
Ensure that the network adapters associated with dependent IP address resources are configured with at least one accessible DNS server.

To fix this DNS issue ( The handle is invalid ) we will repair this CAP. Right click on Listener Name showing in failover cluster manager, click on “More Actions” and then click on Repair as per below image.

Once you will click on Repair, it will come online and then go in offline. Now right click on Listener name again and click on Bring Online button. This time Listener Name will come online if CAP has been repaired successfully. You can repeat the repair exercise if your CAP is not coming online. If you are still facing issue then you can again contact to domain admin to look into Active Directory server.

Now you can see Client Access Point for the listener is showing online now. if you go to the property of this Listener CAP, you can see NetBIOS, DNS and Kerberos status is showing OK.

Close above property window. Now DNS issue is resolved that was main culprit during listener creation so next step is to remove this Client Access Point for this Listener and create the listener in SSMS that will create Listener client access point (CAP) automatically in the failover cluster manager.

Once you click on remove button below window will come to proceed. Click on ok to proceed.

Once this CAP will be removed then connect to primary replica of the AOAG configuration. Expand the AlwaysOn High Availability folder and then Availability Group Listeners folder. You will not be able to see anything as there is no listener as of now. Right click on Availability Group Listeners folder and click on “Add Listener…” option.

You will get below image (New Availability Group Listener Wizard) to enter the listener details. Enter the Listener DNS Name then port followed by choosing Network Mode. Click on Add button to enter Listener IP Address. Once you are done with all details. Click on Ok button to apply this changes. Add Listener wizard will disappear if listener will be created successfully otherwise it will give you the error on the same wizard.

As we have created Availability Group Listener for this AOAG configuration so you can go ahead and verify this in SSMS by expanding Availability Group Listeners folder. You can see same listener name is showing under Availability Group Listeners folder on both primary as well as secondary replica in below image.

Related Articles:

• Learn what is AlwaysOn Availability Group.
• Fix Listener Error 19471 due to Kerberos Status”The handle is invalid”
• How to fix AlwaysOn Availability group Automatic Failover Issue.
• Fix: Secondary Replica is showing in Resolving state and not becoming Primary
• How to fix error 15141: The server principal owns one or more endpoint(s) and cannot be dropped

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fix SQL Server Error 19471: Listener issue that came during Configuring SQL Server AlwaysOn Availability Group appeared first on Techyaz.com.

Automatic Failover Worked Well but Application failed to connect

I have an AOAG configuration with Automatic failover between two replicas in my environment.  Last week, we had High Availability testing for all applications. Everything was working fine if we were doing failover from Management Studio. Databases were failing over and failing back successfully.

Issue occurred when application team tried to connect to database server after failover. They were failed to connect to the secondary replica after every failover but applications were working fine from primary replica. Below are the error details that are coming to application team during establishing database connection post failover to current primary replica (earlier secondary replica).

When we saw at the database level, everything was working fine. Secondary replica was successfully transitioning as primary replica after failover and databases were accessible from failover node but application was not able to connect to this replica. We checked all respective logins associated with the application and everything was there on secondary replica.

One thing we have noticed during troubleshooting that SQL login was became orphaned after each failover and we did resolved orphaned user issue manually post each failover. But there is no benefit of automatic failover if you need to establish database connection manually after each failover.

After spending some time, we fixed this issue. Application was not able to connect to database post failover because one of the SQL login which was used by application has different SID on secondary replica than its primary replica. I recreated this login on secondary replica with same SID which was in primary replica and this has fixed the issue. Here, I will explain step by step method to make you understand the issue and its solution.

Resync the SID from Primary Replica

First check the current configuration of this AOAG. Run below command to get the AOAG details. We can see the configuration is running into automatic failover mode along with replica names.

SELECT replica_server_name, availability_mode_desc, failover_mode_desc
FROM sys.availability_replicas

If you do failover between replicas then it will not throw any error in SSMS or database level. But if you will ask application team to connect to database server using Listener post failover, you will get error.

You will face error because SID of the login used by application is different on both replica servers. You can also get the error when the login used by application to establish database connection is not present on secondary replica. You need to sync the login, password and SID of this login to the secondary replica. Follow this tip to fix the issue that are coming due to any of the given reason.

The SID identifies the security context of the login and is unique within the server instance. If the login is created from a Windows user or group, it is given the Windows SID of the source principle; the Windows SID is unique within the domain. If the login is created as a legacy-style SQL Server login that requires a password, the server will generate a SID. Now check the SID of the login which is used to connect to database on primary replica.

--Replace your identified login with xyz.
select name,sid from syslogins
where name='xyz'

Now run same command on secondary replica. You can see SID is different on both replicas for same login. Ideally everything should be same and in sync with primary replica that are associated with AOAG.

Now we need to delete this login from secondary replica and recreate it using same SID which is present on primary replica. Next, drop the login either using SSMS or T-SQL. SSMS way is given below:

• Connect to target SQL Server Instance.
• Expand the security folder.
• Expand the Logins folder.
• Right click and choose delete on the identified login which needs to be deleted.
• Click on Ok button of the login deletion window.

If you want to drop this login using T-SQL command then open a query window and execute below command.

--change the name of xyz with your login name which you want to delete.
DROP Login 'xyz'

You might get multiple dependency errors during dropping this login because there is possibility, this login might own few objects, agent jobs or databases on this instance. I got Error 15170 during dropping this login which i fixed in attached tip to remove this login. You can also read below articles if you are getting different kind of DROP Login failed issues:

• How to fix Error 15174: Login owns one or more databases.
• How to fix Error 15173: Revoke the permissions before dropping the login.
• How to fix error 15138 & Error 3729: DROP login failed
• How to fix error 15141: The server principal owns one or more endpoint(s) and cannot be dropped
• How to fix error 15434: Could not drop login as the user is currently logged in

Once login will be dropped, go ahead and create same login with same password and SID which are used on primary replica. Copy the SID from image 2 when you check the SID for this login on primary replica and use that during CREATE Login statement. If you don’t have this login on secondary replica yet then also you can follow same process to create the login.

--copy the SID from primary replica.
CREATE Login xyz WITH password = 'password@123', CHECK_Policy=Off, SID = 0xC2Cabcdefghijk123hghj6C3

We can see command executed successfully. Now issue will be fixed if you don’t had this login on secondary replica and you just created it for very first time. But you might get orphaned user issue if you had this login earlier with different SID on this instance. Now we need to fix the orphaned users on the secondary replica.

Fix Orphaned Users

Now you need to run below command to check the orphaned users on your database. Make sure that your database is working as primary otherwise you would not be able to run this command. You can failover and then run this command if database will become primary.

--change the dbname
USE DBNAME
Go
sp_change_users_login 'report'

If you will get your user name which was mapped to the identified login then we need to fix this orphaned user. Run below command to fix this issue.

--change the dbname
--Map database user xyz to login xyz.  
USE DBName;  
GO  
EXEC sp_change_users_login 'Update_One', 'xyz', 'xyz';  
GO  

Now orphaned user issue is also resolved and we have fixed the application connectivity issue that was reported after automatic failover of AOAG. You can do failover testing again to make sure application connectivity is working fine after AOAG failover.

I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

The post Fixing SAP Connectivity issue after AOAG Automatic failover appeared first on Techyaz.com.

SQL Server AlwaysOn Availability Group

SQL Server AlwaysOn Availability Group is an advanced version of database mirroring and introduced in SQL Server 2012. AOAG is HA & DR solution for SQL Server databases. We can group a bunch of databases as one Availability Group and failover/failback as one entity whereas it was not possible in database mirroring. Database Mirroring can be configured only for single database at a time. You can visit the attached link to learn more about AlwaysOn Basics.

I have also an AOAG configuration in my environment which is set for Automatic failover between both replicas. Last week, we faced an issue during automatic failover. Secondary replica was not transitioning as primary replica during an automatic failover and it was stuck in “Resolving” state. It was full down time for application because primary replica was lost and availability databases were not coming online on secondary replica.

I will explain step by step method to make you understand the issue and the fix.

Automatic Failover Not Working and Secondary Replica Stuck in Resolving State

As secondary replica is not transitioning as primary replica after failover because secondary replica hung in resolving state so here, we will check the main root cause and its fix so that secondary replica comes online after every failover. Let’s check the current configuration of this AOAG. Run below command to get the AOAG details. We can see the configuration is running into automatic failover mode.

SELECT replica_server_name, availability_mode, availability_mode_desc, failover_mode, failover_mode_desc
FROM sys.availability_replicas

Now connect to secondary replica in SQL Server Management Studio. Expand the AlwaysOn High Availability folder followed by Availability Group folder. Here, you can see the current state of this availability group which is showing in Resolving state.

I checked the SQL Server error log file but i did not get enough information about this issue to proceed. I searched about this issue and got few suggestions on web that i should check the cluster log. I checked failover cluster manager for critical events. I got below event in failover cluster manager.

Clustered role 'AG_***' has exceeded its failover threshold. It has exhausted the configured number of failover attempts within the failover period of time allotted to it and will be left in a failed state.
No additional attempts will be made to bring the role online or fail it over to another node in the cluster.
Please check the events associated with the failure. After the issues causing the failure are resolved the role can be brought online manually or the cluster may attempt to bring it online again after the restart delay period.

Fix Resolving state and Make Secondary Replica Primary

Above issue clearly indicates about some cluster configuration related to role created for AOAG. As we can see, there is one role is showing under roles tab of this cluster group in below image. We can see the current owner of this role is still showing as node 1.

Now right click on this role and choose properties as per below image.

You will get a properties window as shown in below screenshot. Now click on “Failover” tab of this screen to check the failover threshold details.

We can see the failover threshold is set to only 1 in the 6 hours. It means if any failover happen more than once in the 6 hrs time period it will remain in failed state and will not try to come online. Now increase this value as per your need. I have changed it to 10. Click on apply and Ok button.

Now, secondary replica of availability databases will not come online automatically. We need to bring them online. We have multiple options to bring them online from resolving state. You can directly run the failover by right click on availability group in SSMS and then proceed with failover.

Another option is to bring them online from failover cluster manager. You can either right click on the AOAG role and click on “Bring Online…” option or you can failover it to best possible node. As primary replica is down and not accessible so it will be failed over to the secondary replica only because this node is only available this time. Let’s right click on AOAG role in failover cluster manager, choose move and then click on “Best Possible Node”

It will process and come online within few seconds and this time you can see this role is online from node 2 as current owner is showing as node 2 now.

We can also validate this change while making a database connection to the secondary replica in SSMS. Connect to secondary replica and expand the AlwaysOn Availability Group folders. You can see now availability group is showing as primary. That means your database is online from secondary replica to accept the user connections.

You can also test this exercise to make sure automatic failover is working fine or not to prevent this kind of future outages. Once your earlier primary replica comes online, you shutdown SQL Server services on secondary replica/current primary replica. Once it will go down, your current secondary replica becomes primary automatically. Before shutdown SQL Server services, make sure databases should be fully synchronized.

Hee, we have fixed Alwayson issue where secondary replica is not coming online after failover and hung in resolving state. I hope you like this article. Please follow us on our facebook page and on Twitter handle to get latest updates.

Read More:

• How to Upgrade or Apply Patches on AOAG Instances?
• Fix AOAG Listener Error 19471: The handle is Invalid
• How to Restore a Database participating in AOAG?
• Fix Application Connectivity Issue after AOAG Failover

The post Why is Secondary Replica Showing in Resolving state after AOAG Automatic failover? appeared first on Techyaz.com.