A connection timeout has occurred on a previously established connection to availability replica ‘manvendradbggp03’ with id [availability group id]. Either a networking or a firewall issue exists or the availability replica has transitioned to the resolving role.

You may also receive similar issue under different alwayson error 35201. Below error will generate while attempting to establish the connection to availability group but failed because of connection timeout error 35206. The error text of this SQL error 35201 is given below.

A connection timeout has occurred while attempting to establish a connection to availability replica ‘manvendradbggp03’ with id [availability group id]. Either a networking or firewall issue exists, or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

If you are always getting above issues and unable to establish any connection to its respective availability replica then you should immediately look in to network side whether there is poor network latency, any network packet drop issue or firewall is blocking some connections or not as suggested in error code. But if you are getting this issue on intermittent basis then you should keep reading this article to understand more about alwayson error 35206.

SQL Server Error 35206 and Error 35201 in Always on

Both errors come because of connection timeout error between their respective replicas. Microsoft has categorized these errors as product issue and released cumulative updates to fix them. You should also consider these cumulative updates as per your SQL Server version. These issues will be very problematic if you will not address them on time because of below reasons:

• Availability databases will stop synchronizing. This could be a risk of potential data loss.
• Log file will start growing on your primary replica. This could be a potential risk for an outage if we will not address this issue on time.
• Frequent repetitive alerts for your critical systems

You must fix this issue by applying the cumulative update to avoid above problematic scenarios. But if you already have applied these updates and are still facing these issues then i would recommend you to read below section to try out other options.

Fix Always on Connection Timeout SQL Error 35206

Generally, this problem encounters only on high end systems where you have more than 24 cores CPU and SQL Server is highly transactional. One very simple workaround to overcome this issue is to restart SQL Server service on your secondary replica where you are getting this issue. Don’t restart SQL Server on primary replica. Restarting SQL Server on impacted availability replica will surely fix the issue for the time being.

Additionally, you should consider below checks to review and make changes accordingly as per your system design if you are still getting this issue on frequent basis.

Use Default Network Packet Size

Review network packet size configuration in SQL Server. Microsoft suggested to keep network packet size configuration with default value but sometime we make changes as per our need and forgot to revert these changes to their original values so i would recommend to revert this change to its default value. Read below article if you want to learn how to change network packet size configuration in SQL Server.

• How to Change Network Packet Size in SQL Server?

You should also consider evaluating your network bandwidth and firewall settings to make sure and isolate the issue. I would suggest you to work with network engineer on this front to review network or firewall related configurations.

Review Connection Timeout Setting

Another option i would recommend you to evaluate and review the session or connection time out settings. Make sure that session timeout setting for your always on configuration must be more than or equal to 10 seconds. You can consider increasing session time out if you have slow network between your replicas. Although if you are running highly transactional databases on high end box i assume you already have good network bandwidth but nothing wrong in reviewing the settings. Read below article if you want to reconfigure or change session time out in always on availability group.

• How to Change Session Timeout in Always on Availability Group Configuration?

If you are running your always on availability group configuration between multi subnet environment then i would recommend you to read attached Microsoft article to fix connection timeout errors in multi subnet availability groups.

Read More:

• Fix SQL Server Error 976: Cannot connect to Secondary Replica of AlwaysON Availability Group
• SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error
• Fix SQL Server Error 19471: Listener issue that came during Configuring SQL Server AlwaysOn Availability Group
• SQL Server Alwayson Interview Questions & Answers

The post Fix Always ON Connection Timeout Error 35206 in SQL Server appeared first on Techyaz.com.

The connection timeout setting in AOAG applies only to identified secondary replica and its respective primary replica. Each secondary replica has its different session timeout value which works between the given replica and its primary replica. The default value for session timeout configuration is 10 seconds. Microsoft recommends to keep this setting value to 10 seconds or more to prevent system missing pings and false failure alerts.

Change Session Timeout for Availability Replica

This section will explain how to change or modify connection or session timeout value for an AOAG availability replica. This is needed sometimes if you are frequently getting connection timeout errors for your availability replicas. I will show two ways to modify session timeout in always on availability group. One is by using SQL Server Management Studio and another one by using T-SQL statement.

Modify Alwayson Connection Timeout using SQL Server Management Studio

Make sure you have connected to your SQL Server Instance which is hosting primary replica of always on availability group configuration. Follow below steps to change session timeout or connection timeout for identified availability replica where you are facing connection timeout errors 35206 or 35201.

• Launch SQL Server Management Studio and connect to the primary replica
• Expand folders once you connected to the primary replica instance. Click at plus sign to expand Always on High Availability node followed by Availability Groups node.
• Identify and click the availability group for which you have to configure connection timeout for one of its availability replica
• Identify the availability replica for which you have to change this value. Right click at this replica and click at Properties option to launch its properties page
• You can see Session timeout (seconds) option In the Availability Replica Properties dialog box. Use Session timeout (seconds) option to change the number of seconds for the session timeout period on this replica. Always keep it 10 or more as per your specific need.

We have successfully changed alwayson connection timeout for an availability replica using SQL Server management studio in above steps. Now, i will show you T-SQL approach to get this done in below section.

Change Alwayson Connection Timeout using T-SQL Statement

Here, i will show you how to change session timeout for an availability replica using T-SQL statement.

• Launch SQL Server Management Studio and connect to the primary replica.
• Open New Query window and run below ALTER AVAILABILITY GROUP statement.

ALTER AVAILABILITY GROUP group_name

MODIFY REPLICA ON ‘instance_name‘ WITH ( SESSION_TIMEOUT =seconds )

Make sure to replace group_name with your availability group name, instance_name with your secondary replica name for which you want to change session timeout value and seconds with appropriate time in seconds.

Once you will execute above statement, connection timeout value will change as per your specified value for your availability replica. Now, you can go ahead and monitor the connection timeout errors to see whether your issue has been fixed or not.

Here, i have explained how to modify or change session timeout for an always on availability group replica.

Read More:

• SQL Server Alwayson Interview Questions & Answers
• SQL Server Alwayson Error 35250: Joining database on Secondary Replica resulted in an error
• Understanding Backup Preferences for AlwaysOn Availability Group Databases

The post How to Change Session Timeout for Availability Group Replica appeared first on Techyaz.com.

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.

• 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.

Error: 18452, Severity: 14, State: 1.
Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

You can see the screenshot of the error 18452 in below image.

Error 18452 – Root Cause

Reason behind error 18452 is because of wrong security authentication mode configuration. SQL Server is set to accept only windows logins to connect to database instance.

As we know SQL Server uses two authentication modes to accept database connections. One is Windows Authentication mode and another one is SQL Server and Windows Authentication mode. We also call it Mixed Authentication mode.

Sometimes, SQL Server authentication mode is set to SQL Server and Windows Authentication mode to accept SQL as well as windows connections but still you will face this issue. That might be because you try to connect to a server that has Always on Availability Group configuration or database mirroring configuration.

Suppose you have AOAG configuration and you are connecting to database using primary replica name not listener name using a login for which default database is set as availability database. If failover got happen during your activity or you are connecting to secondary replica using a login for which default database is set as availability database then also you will get this error 18452 along with some SSPI context error that I have given below.

Error: 17806, Severity: 20, State: 14.
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed 

SSPI handshake errors comes because of Kerberos failure, which would most likely be related to non-existent SPN or bad SPN for SQL Server.

Solution

To fix this issue first we need to check the authentication mode set for your SQL Server Instance. If your SQL Server instance is running with windows authentication mode then you must change it to Mixed mode so that windows and SQL both type of logins can be authenticated.

To check the configured authentication mode for your SQL Server Instance, we need to launch SQL Server Instance property window. Right click at the instance node and click at the properties option as shown in below screenshot.

Once you will click at Properties option, you will be getting below SQL Server instance property window. Click at Security option from left side pane. You can see current Server Authentication configuration is set to Windows Authentication mode in below screenshot.

Now we will change it to SQL Server and Windows Authentication mode. Select the radio button for SQL Server and Windows Authentication mode option and click ok button to proceed. You can see that I have selected above mode to apply the changes.

Restart SQL Server services to apply the changes.

If your SQL Server Instance is already set with SQL Server and Windows Authentication mode then you should fix this issue in separate way. As I described above that one of the probable reason to get this error 18452 is because you might use AOAG replica server name to connect to the database with the login for which default database is set as the AOAG availability database.

If failover will happen then you would not be able to access the database because it will become secondary. Error 18452 will be generated along with SSPI handshake errors because same database is set as default database for your login that has become inaccessible now because of acting secondary database in AOAG. Failover will not happen for you because you are using replica server name to make database connection.

Possible solution to fix this issue is failback the AOAG to your earlier primary replica or you should use AOAG Listener name to make database connection. Also, to avoid this error during failover you should set default database for your login to master rather than availability database.

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

Read More:

• Fix Error 18456: Login failed for user “User_Name”
• Fix Error 4064: Cannot open user default database. Login failed
• Error 53: Could not open a connection on SQL Server
• AOAG Listener Error 19471: The handle is Invalid

The post Fix Error 18452: Login failed. The login is from an untrusted domain appeared first on Techyaz.com.

SQL Server Interview Questions and Answers on Alwayson

Question- How Always ON Availability Group is different from Database Mirroring?

Answer- Always On Availability Group is advanced version of Database Mirroring. We cannot configure database mirroring for more than one database per configuration whereas we can group multiple databases as one availability group and do the failover as one unit in AOAG.

Question- How many Replicas we can create in an AOAG Configuration?

Answer- We can create single primary replica and one to eight secondary replicas in AOAG Configuration.

Question-How many Availability groups we can create in an AOAG configuration?

Answer- The actual number of availability groups you can create on a Server depends on the hardware and workload, but there is no enforced limit.

Question-How many databases can be added in an AOAG configuration?

Answer- The actual number of databases you add to the AOAG depends on the available worker threads on the server, as such there is no enforced limit for databases as well.

Question- I have an AOAG configuration between an FCI and standalone server. Why AOAG is not able to perform automatic failover?

Answer- Automatic Failover is not supported for Availability groups that are configured on Failover Cluster Instances. That is why AOAG is not able to perform automatic failover on such configurations.

Question-What are basic prerequisites for a database to be a part of AOAG?

Answer-Below are the list of prerequisites for a database that needs to be added in Availability Group.

1. Database should be Online for Read-Write Operation.
2. Database must be in Full Recovery Model.
3. Database should be a user database because you cannot configure AOAG for system database.

Question-Can we configure database mirroring on a database that is part of Availability group?

Answer- No, we cannot configure database mirroring for an availability database.

Question- Can we configure Log shipping for a database that is part of Availability Group?

Answer-Yes, we can configure Log shipping for an availability database.

Question- Can we configure Replication for a database that is part of availability group?

Answer- Yes, we can configure replication of a AOAG database.

Question- Can we configure AOAG for master database or any system databases?

Answer- No, we cannot create AOAG for system database.

Question- What is difference between Synchronous-commit mode and Asynchronous-commit mode?

Answer- Under synchronous-commit mode, primary replica waits for a synchronous-commit secondary replica to acknowledge that it has finished hardening the log before committing transactions on primary replica.

Under asynchronous-commit mode, the primary replica commits transactions without waiting for acknowledgement that an asynchronous-commit secondary replica has hardened the log.

Question- What are the benefits of Readable Secondary Replicas?

Answer- Readable Secondary Replicas can be used for reporting purpose. We can divide some workload from primary replica and route all SELECT statements to run on readable secondary replicas. Even we can run database backups as well from these secondary replicas.

Question- How can we run backups from secondary replicas?

Answer- Performing backups on a secondary replica to offload the backup workload from the primary production server is a great benefit.  We can perform log backups and copy_only full backups from secondary replicas. We need to change Backup Preferences setting of AOAG configuration to run these backups from secondary replica. Read below attached article to understand AOAG Backup Preferences and how it works.

Question-If one of your availability database got corrupted or showing in suspect mode, will AOAG initiate failover to secondary replica?

Answer- No, failover will not be initiated due to any issue at database level.

Question- Can we configure AOAG of a database that is running in bulk logged recovery model?

Answer- No, database must be in full recovery model to configure AOAG.

Question- Can we redirect the read only transactions to secondary replica instead of primary replica?

Answer- Yes, we can specify the read_only intent in the connection string and add only secondary replicas to the read_only_routing list.

Question- What is read intent option?

Answer- If Read Intent option is set that means read-only connections are allowed to secondary databases on secondary replica.

Question- What is default settings for read intent or read access transactions?

Answer- By default both read-write and read-intent access are allowed to the primary replica and no connections are allowed to secondary replicas of an Always On availability group.

Question- Why is asynchronous commit mode is faster than synchronous commit mode?

Answer- Asynchronous-commit is faster because primary replica does not wait for any acknowledgement received from secondary replica to harden the logs there. Read More about these in attached article Always On Availability Group.

Question- Is it necessary to have shared storage for AOAG?

Answer- No, it is not necessary to have shared storage of AOAG.

Question- Can we configure AOAG without windows cluster?

Answer- We can create clusterless AOAG in SQL Server 2017 but rest of all previous version you must have windows cluster to create AOAG.

Question- Can we restore a database participating in Always on Availability Group?

Answer- No, we cannot restore a database that is participated in AOAG. Neither we can delete or drop these databases.

Question- How can we Restore a database that is participated in AOAG?

Answer- To Restore a database that is part of Availability Group, first we need to remove it from availability group. Once database will be removed from availability group, you can restore it and later you can add it to the same availability group. Read attached article to learn how to restore a database that is part of AOAG.

Question- What will be the difference between configuring AOAG in multi-subnet network and same subnet network?

Answer- When we need to configure AOAG between multi-subnet cluster, we need to have one IP from each subnet to configure Listener whereas we need only one IP for listener in same subnet.

I hope you like this set of SQL Server Interview Questions & Answers on Alwayson Availability Group. Please follow our Facebook page and Twitter handle to get latest updates.

Read More Interview Questions:

• SQL Server Interview Q&A on Architecture
• SQL Server Interview Q&A on Indexes
• MSSQL Backup and Recovery Interview Q&A
• SQL Server General DBA Interview Q&A

The post SQL Server Alwayson Interview Questions & Answers 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.

The operation cannot be performed on database “DBNAME” because it is involved in a database mirroring session or an availability group. Some operations are not allowed on a database that is participating in a database mirroring session or in an availability group.

As per above error details, we cannot restore a database that is part of always on availability group directly. Here, I will explain step by step process to restore such databases.

Restore Databases in Availability Group

If you need to restore an availability group database, you need to first evict that database from availability group and then restore that database and finally you can re-add it to the always on availability group. So, there are three steps involved in restoring an AOAG database.

1. Remove identified database from Availability Group.
2. Restore that database.
3. Add database to Availability Group post restore operation.

Let’s explain each steps in detail in order to restore an alwayson database.

Remove Database from Availability Group

First step is to remove the identified database from AOAG configuration to restore AOAG database. If you have to restore primary database in AOAG configuration then you should remove it from the primary replica that will automatically remove this database from AOAG configuration on secondary replica as well. You don’t need to separately remove secondary database from AOAG configuration. We can use below T-SQL statement to remove your primary database from AOAG configuration.

--Change name of AG_Techyaz to your Availability group.
--Change database name from Techyaz to your primary database.
ALTER AVAILABILITY GROUP AG_Techyaz REMOVE DATABASE Techyaz

You can use GUI method as well to remove primary database from AOAG configuration. Read attached article to understand step by step process to remove a database from Availability group using GUI method.

Restore Database

Once primary database will be removed from availability group, It will disappear from Availability Database folder showing under your Availability group name on both replicas. Now, next step will be database restore. Go ahead to restore your database.
Here, we have to restore our database till 25 Jan 8 AM to recover point in time data. You can use your backup files as per your requirement. You can use either GUI method  in SSMS or T-SQL method to restore your database. Run below command to restore this database.

--Restore primary database with the help of your backup file.
RESTORE DATABASE Techyaz
FROM Disk= ‘F:\Backups\Techyaz_Full.bak’
WITH NORECOVERY, REPLACE;

--Restore log backup till the time you want to recover the database.
RESTORE LOG Techyaz
FROM Disk= ‘F:\Backups\Techyaz_TLog.trn’
WITH NORECOVERY, REPLACE, STOPAT = 'Jan 25, 2018 8:00 AM';

--Bring database Online.
RESTORE DATABASE Techyaz WITH RECOVERY;

Once your database will be restored and comes online, we will go ahead to add this database to availability group again.

Add database to Availability Group

If you want to re-add this database to availability group then you must perform this step otherwise your database will not have any HA or DR capability. I would recommend to first prepare your corresponding secondary database before starting to add it to availability group. If you have a plan to prepare secondary database during adding it to availability group then the processing will take lot of time for huge databases.

To prepare the secondary database, you first need to take a full backup and immediate transaction log backup of your newly restored primary database. Copy these files to secondary replica and restore corresponding secondary database in norecovery mode. Below are high level steps you need to perform to add this database to AOAG configuration.

1. Run full backup and immediate transaction log backup of primary database on primary replica.
2. Copy both full backup and log backup files to secondary replica.
3. Restore corresponding secondary database with the help of above copied files in norecovery mode with REPLACE option.
4. Now, run below T-SQL command to add this database to existing availability group. If you want to add this database to existing AOAG configuration using GUI method in SSMS, visit attached link where I have described it in step by step process.

-- Connect to the server instance that hosts the primary replica.
-- Add an existing database to the availability group.
ALTER AVAILABILITY GROUP AG_Techyaz ADD DATABASE Techyaz;
GO

Make sure to configure your secondary database on secondary replica as we have done from step 1 to step 3.
If you don’t want to add this database to availability group then you can ignore this step and use your database for transactions. You can also remove its corresponding database that is in restoring state on secondary replica. If you want to use that database from secondary replica for any purpose you can bring it online by running below command on secondary replica.

--Run on secondary replica in case you don't want to configure this database in AOAG rather want to use it for transactions.
RESTORE DATABASE Techyaz WITH RECOVERY;

Now, you are done with database restore in Alwayson Availability Group. Validate it by launching dashboard report or looking in to SSMS to get AOAG health for newly added or restored database.
I hope you like this article. Please comments us and follow our facebook page and Twitter handle to get latest updates.

Read More:

• Understanding Backup Preferences in Alwayson Availability Group
• AOAG Listener Error 19471: The handle is Invalid
• Secondary Replica Showing in Resolving State after AOAG Automatic Failover
• Fix Error 976: Cannot Connect to Secondary Replica

The post Restore a Database Participating in Alwayson Availability Group appeared first on Techyaz.com.

Before starting this exercise, make sure that primary and secondary replicas are accessible to each other and existing AOAG configuration is working fine and in healthy state. You must be connected to the server instance that hosts the primary replica to add a database to availability group.

Add Database to Availability Group using GUI in SSMS

First, we need to configure the corresponding secondary database on each server instance that hosts a secondary replica to save add database wizard processing time. You just need to run the full backup and immediate transaction log backup of the database on primary replica that has been identified to add to the availability group and then restore it to corresponding secondary replica.

Although it is not mandatory step to do it before adding the database to availability group as this can be done during adding database to availability group as well. But it is recommended to prepare your secondary databases on secondary replica before adding it to availability group. Let’s start with configuring secondary replicas followed by adding them to AOAG configuration.

1. First run the full backup and immediate transaction log backup of the database that has been identified to add to the availability group on primary replica.
2. Once backups are completed on primary replica for to-be added database, copy these backups to your secondary replica and restore it with same name in no recovery mode if you want to keep your secondary database inaccessible.
3. Once database will be restored/ synced on secondary replicas, we will start adding this database to existing AOAG configuration using Add Database to Availability Group Wizard on primary replica.
4. Launch SQL Server Management Studio. Connect to the server instance that hosts the primary replica, and expand the server tree.
5. Expand the Always On High Availability folder followed by Availability Groups.
6. Right-click the availability group name, and select one of the following commands:
   • To launch the Add Database to Availability Group Wizard, select the Add Database.
   • To add one or more databases by specifying them in the Availability Group Properties dialog box, select the Properties.
7. Once you click on Add Database… option to add database to existing AOAG configuration, an Introduction wizard will appear that will very similar to the one you might have seen during creating AOAG on your SQL Server Instance.
8. Next screen will come to select databases to proceed with adding them in to AOAG configuration.
9. Third window will come to select initial data synchronization option. Here you should be careful as if you have already configured secondary databases as we did in step 1 and step 2 then you need to select second option that is “Join Only”. If you haven’t configured your secondary database you can go with either first option that will backup the primary database and restore it to secondary replica during this processing only or third option in which you can configure secondary database later. If your database is big in size it will take lot much time to complete the processing.
10. Follow rest of all windows by clicking at next button and once you will click at finish button on last window, your database will be added to existing availability group. You can see the status of this newly added database in to dashboard report or in SSMS.

Add a Database to Availability Group using T-SQL

As I have described n above section, first thing is to configure secondary database so we need to configure the corresponding secondary database on each server instance that hosts a secondary replica to save add database processing time. You just need to run the full backup and immediate transaction log backup of the database on primary replica that has been identified to add to the availability group and then restore it to corresponding secondary replica. Once restore will be completed then follow below steps to add this database to availability group.

1. 1. Connect to the server instance that hosts the server instance that hosts the primary replica.
   2. Use the ALTER AVAILABILITY GROUP statement, as follows:

--AG_name is the name of the availability group.
--database_name is the name of a database to be added to the group.
ALTER AVAILABILITY GROUP AG_name ADD DATABASE database_name

The following example adds the Techyaz database to the AG_Techyaz availability group.

-- Connect to the server instance that hosts the primary replica.
-- Add an existing database to the availability group.
ALTER AVAILABILITY GROUP AG_Techyaz ADD DATABASE Techyaz;
GO

3. If you haven’t configured your secondary database then you need to configure it on each server instance that hosts a secondary replica after adding database to an availability group. If you already added it then you are done with adding your database to existing AOAG configuration. Validate it by launching dashboard report or looking in to SSMS.

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

Read More:

• How to Remove a Database from AOAG configuration?
• Fix AOAG Listener Issue: Error 19471 The handle is Invalid
• Secondary Replica Showing in Resolving State after AOAG Automatic Failover
• Understanding Backups in Alwayson Availability Group

The post How to Add a New Database to Always On Availability Group? appeared first on Techyaz.com.

You must be connected to primary replica of AOAG configuration to perform this activity. If you connect to secondary replica to remove availability databases from AOAG configuration then only secondary database from AOAG configuration will be removed. If you remove availability database or say primary database from AOAG configuration on primary replica then it will remove availability databases from always on availability group from both replicas.

Remove Availability Database from AOAG using SSMS

1. Launch SQL Server Management Studio. Connect to the SQL Server instance that hosts the primary replica of the database or databases to be removed, and expand the server tree.
2. Expand the Always On High Availability folder followed by Availability Groups folder showing in SSMS.
3. You can see your Availability Group Name post expanding Availability Group folder. Now expand this folder as well.
4. Now you can see Availability Databases folder. Expand this folder to see your availability databases.
5. Right-click the selected database or databases, and select Remove Database from Availability Group option as shown in below screenshot.
6. You will be getting below window to proceed with the database removal from AOAG configuration. In the Remove Databases from Availability Group dialog box, to remove all the listed databases, click OK.
7. If you want to remove multiple databases from AOAG configuration, use the Object Explorer Details pane to view and select all the databases that you want to remove. You can also remove a single database either from the Object Explorer pane or the Object Explorer Details pane.

This way you will remove primary database or say availability database from AOAG configuration. Data synchronization will be stopped for this database between both replicas the moment you remove it from availability group.

Later, you can decide whether you want to remove your secondary database or you want to use it by bringing it online. Make sure to change database name of secondary database to avoid any confusion because a copy of this database is already online with same name on primary replica.

Remove Availability Database from AOAG using T-SQL

Connect to SQL Server instance that are acting as primary replica of AOAG configuration.  Open New Query window to execute T-SQL query. Run below ALTER AVAILABILITY GROUP statement. Make sure to change the availability group name and availability database name that needs to be removed from AOAG configuration.

--Availability_group_name is the name of the availability group
--Availability_db_name is the name of the database to be removed
ALTER AVAILABILITY GROUP Availibility_group_name REMOVE DATABASE Availability_db_name

I have executed below command to remove my availability database Techyaz from availability group name AG_Techyaz on primary replica.

ALTER AVAILABILITY GROUP AG_Techyaz REMOVE DATABASE Techyaz;

You can see i have successfully execute this command in below screenshot.

Now, database will be removed from always on availability group and data synchronization will be stopped for this database between both replicas. Primary database will come online for read write and secondary database on secondary replica will be in restoring state. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Fix AOAG Listener Error 19471
• Understanding Backup Preferences for Availability Databases
• Fixing Application Connectivity Issue after Automatic Failover
• Error 35250: Joining database on Secondary Replica resulted in an error

The post How to Remove Database from Always On Availability Group? 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.

Backup Preference	Backup Runs on	Remarks
Prefer Secondary	Secondary Replica	Default Option. You cannot run differential backup in this option. If only Primary Replica is online, backup will run on Primary Replica.
Secondary only	Only Secondary Replicas	Backup will never run on Primary Replica. If only Primary Replica is online, backup will not run. You cannot run differential backup in this option as well.
Primary	Primary Replica	Choose this option if you want to run differential backup.
Any Replica	Can run on any replica based on backup priority of each availability replica in combination with its operational state and connected state.	Set backup priority carefully between replicas.

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.