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.

If your drive letters or folder structures are identical on all replica servers then most of the time you will not face any issue while adding the database files but sometimes if you mount additional drive on all replicas to make it identical and then add data file in this new drive then you might face the issue. If all replica servers don’t have identical path then adding database file operation on primary replica will not successfully replicate to other replica servers because of different drive and folder structure. This, in turn, causes the secondary replica to enter the NOT SYNCHRONIZING state.

Note: Always try to keep drive and folder structure identical on all secondary replica servers to the corresponding primary replica.

If you have added a data file on primary database of Always on Availability group then you will see multiple errors logged in SQL Server error log on your secondary replica where secondary database is suspended from always on availability group and showing in “Not Synchronizing” state. You might see one of the below error codes in your log file.

Error:5123, Severity:16, State:1.
CREATE FILE encountered operating system error 3(The system cannot find the path specified.) while attempting to open or create the physical file ‘E:\MSSQL\Data\Techyaz_Data2.ndf’.

Or

Error:5183, Severity:16, State:1.
Cannot create the file “Techyaz_Data2”. Use WITH MOVE to specify a usable physical file name. Use WITH REPLACE to overwrite an existing file.

Or

Error: 3313, Severity: 21, State: 2.
During redoing of a logged operation in database ‘Techyaz’, an error occurred at log record ID (76:659:1).

Now i will describe how to fix such issues or how to plan and add a database file to always on availability databases.

Add Data file to Availability Database

If you have already added data file on primary database and your secondary databases are suspended from availability group then we need to fix it to reestablish always on availability group. If you have not added the data file and want to add it then you can keep reading this article as i have described it later in this article. I have described how to plan database file addition to avoid any future synchronization issue.

Let’s go ahead with the first option where you have already added the data file to primary availability database and secondary database status is showing as not synchronizing due to this change. Now we need to fix this issue to reestablish the synchronization between replicas of availability group. To resolve this problem the DBAs  must complete the following steps:

1. Remove the secondary database from the availability group that is showing as “Not Synchronizing”. To do this, either you can use GUI method in SSMS or run below T-SQL statement. You can connect to secondary replica then you can expand Always On High Availability node followed by Availability Groups Now, select the availability group and then expand the Availability Databases node. To remove a single database, select it in either the Object Explorer pane or the Object Explorer Details pane. Right-click the selected database or databases, and select Remove Secondary Database in the command menu. If you want to do it using T-SQL statement then you must connect to secondary replica and execute below Alter command.

ALTER DATABASE Techyaz SET HADR OFF;  
GO 

2. Once database will be removed from AOAG, restore a full backup of the filegroup that contains the added file to the secondary database, using WITH NORECOVERY and WITH MOVE option. This option is mandatory if you don’t have any log backups. Although sometimes you can do it by only running log backup on primary replica and restore it on secondary replica in norecovery mode as mentioned in next step.
3. Now, back up the transaction log that contains the add-file operation on the primary database, and manually restore the log backup on the secondary database using WITH NORECOVERY and WITH MOVE.
4. Prepare the secondary database for re-joining the availability group, by restoring, WITH NO RECOVERY, any other outstanding log backups from the primary database.
5. Rejoin the secondary database to the availability group. Read this article to get step by step method to add a database to availability group.

If you havenot added the data file then you can plan it with following steps.

1. Remove the database from secondary replica as described in above section. Now, secondary database will be showing in to restoring state.
2. Add the data file to your availability database on primary replica.
3. Take a log backup of this availability database on primary replica.
4. Copy this log backup to secondary replica and restore it on its corresponding secondary replica using NORECOVERY and WITH MOVE option.
5. Now add the database back to always on Availability Group.

Here, I have shown you step by step process to add data file to availability database. I have also let you know how to fix the issues that might arise due to adding the database files to availability database on primary replica. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Read More:

• Upgrade or Patch SQL Server Failover Cluster Instance Running with Availability Group
• Understanding Enhanced Database Failover in Always on Availability Group
• How to Change Failover Mode of Availability Replica in AOAG?
• Always ON Availability Group Interview Questions & Answers

The post How to Add Data File to Availability Database? 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.

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.

The server network address “TCP://ServerName.abc.local:5022″ cannot be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational. (Microsoft SQL Server, Error: 1418)

Reason behind Error 1418

Main reason behind database mirroring error 1418 is because the specified server network address cannot be reached or does not exist. The server network address cannot be reached because of multiple reasons. Some of them are given below.

• Principal, Mirror and Witness servers are not talking to each other.
• Wrong network address name, mirror server instance name or port number.
• Mirror database is not ready for mirroring.
• Principal or mirror server instance is behind a firewall.
• You are using local system account to run SQL Server services and not using certificates for authentication.
• SQL Server services are running with different domain accounts on Principal and Mirror server and service accounts don’t have enough permission on endpoints.
• Different endpoint encryption value set on Principal, Mirror and Witness server.
• Endpoints are not started on the partner servers.
• Principal server instance is not listening on the port assigned to its database mirroring endpoint.

We need to verify each option mentioned above carefully to fix this error.

Solution

The solution of this issue may vary case to case depending on the nature of issue. To fix this issue we need to find out the main root cause behind error 1418. The root cause may be anything that is given in above section. Here I will describe each probable reason given above and its solution to fix this issue. Make sure to go through with each point given in this article.

Principal, Mirror and Witness Servers Should be Accessible

Make sure that SQL Server Instances installed on Principal, Mirror & Witness servers are accessible to each other. If remote login for any SQL Server instance is not enabled then you might get this issue. You can enable remote connectivity by enabling TCP/IP and Named Pipes protocols in SQL Server Configuration Manager. Each system must access the ports of the other SQL Server instances over TCP. You can try telnet the SQL Server ports of other partners.

Verify Correct System Details 

Sometimes we entered wrong details that end up with throwing errors. Make sure to verify the network address name, mirror server instance name and its port numbers are correct. You can recheck all the details whether you have entered them correctly or not.

Mirror Database Preparation

Verify that the mirror database is ready for database mirroring. We should prepare mirror database before configuring or during configuring database mirroring. It is suggested to keep identical drive path for mirror database files. Below are the steps you should take care for preparing your mirroring database.

• Run full backup and subsequent transactional log backup of the Principal database and copy it to the Mirror server.
• Restore database with same name in norecovery state on Mirror server with the copied backup files from above step. You must ensure that restored database on mirror server should be in restoring mode before starting database mirroring configuration.

Firewall/Ports

One of the probable reason to get error 1418 is partner servers are behind firewall. Make sure that the principal server instance and destination mirror server instance is not behind a firewall and they should talk to each other. Principal server, Mirror server and witness server should be accessible to each other.

Verify that SQL Server port and endpoint ports are enabled and accessible via telnet. If not or you are not able to telnet any of the partner instance from any server participating in mirroring then you should ask your network admins to open these ports to establish the connectivity over given port.

Endpoints

Make sure that endpoint has been created on principal, mirror and witness servers. Verify that the endpoints are started on each partner server instances. You can check endpoint status by running below T-SQL query on each instance.

SELECT state_desc FROM sys.database_mirroring_endpoints

If either endpoint is not started, execute below ALTER ENDPOINT statement to start it.

#Change the name of your endpoints. Here endpoint name is Mirroring
ALTER ENDPOINT Mirroring
STATE = STARTED
AS TCP (LISTENER_PORT = <port_number>)
FOR database_mirroring (ROLE = ALL);
GO

Recheck that the principal server instance is listening on the port assigned to its database mirroring endpoint and the mirror server instance is listening on its port. If a partner is not listening on its assigned port, modify the database mirroring endpoint to listen on a different port.

Sometimes this issue got fixed by dropping the existing endpoint and recreate it again on partner servers.

Service Accounts

Do not use local system account to run SQL Server services. If you don’t have any choice and want to use local system then ensure to use certificates for authentications.

Make sure that service accounts that you are using to run SQL Server services must have CONNECT permission to mirroring endpoints. Also, if you are configuring database mirroring between two domains then the login of one account must be created in master database on the other computer, and that login must be granted CONNECT permissions on the endpoint.

It’s always advisable to use same service accounts to run SQL Server services on all three Instances on Principal, Mirror and Witness server.

You can comment us your experience about fixing this issue. We will update this article with your solution that you have used to fix this issue.

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

Read More:

• Fix Error 15141: The server principal owns one or more endpoints and cannot be dropped
• Fix AOAG Error 35250: Joining database on Secondary Replica resulted in an error
• How to Upgrade or Patch Availability Group Instances?
• SQL Server Always On Interview Questions and Answers

The post Fix Error 1418: The server network address cannot be reached or does not exist. 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.