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.

You can also get below error similar to error 53 under below details.

An error has occurred while establishing a connection to the server. When connecting to SQL Server, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server) (.Net SqlClient Data Provider)

Root Cause

Microsoft SQL Server Error 53 looks very much like the Error 40: A network-related or instance-specific error occurred while establishing a connection to SQL Server at first look. Like SQL Server error 40, here also SQL Server client cannot connect to the SQL Server Instance. This error could occur because either the client cannot resolve the name of the server or the name of the server is incorrect.

You might get this issue due to other reasons as well although main reason is the wrong server name or port name. I have given all those possible reasons behind the Microsoft SQL Server error 53 in below points.

1. Wrong SQL Server Instance name while establishing database connection.
2. Entering wrong port no can be one of the reason for SQL Server error 53.
3. SQL Server Instance is not accessible due to firewall or any reason.
4. Telnet port 1433 or port no on which SQL Server is running. These ports might be blocked.
5. TCP/IP or Named Pipes protocol is disabled in SQL Server Configuration Manager.
6. Remote Connection is disabled for this SQL Server Instance.
7. SQL Server Browser service is stopped.

Solution

We need to check and validate multiple factors to rectify Microsoft SQL Server error 53. Check all factors given in below step by step points to fix all possibilities for this error.

1. Sometimes, we enter wrong server details by mistake. Make sure to enter correct SQL Server instance name while making database connection otherwise you will face sql error 53.
2. Try to connect using ip address and port number instead of putting server name in connection string.
3. Make sure SQL Server services are running fine and its accessible.
4. Check firewall details. Firewall should open between your client machine and database server. Port 1433 and 1434 should be enabled. Telnet both ports to make sure ports are open.
5. Make sure to enable TCP/IP and Named Pipes. Launch SQL Server Configuration Manager. Expand SQL Server Network Configuration from left side pane and click on Protocols for MSSQLSERVER. MSSQLSERVER is SQL Server Instance name. Now you will see all protocols in to right side pane. Right click on given protocols and select Enable button to enable both protocols.
6. Check TCP/IP name resolution, you can use the ping command in the Windows operating system. You can also right-click on TCP/IP and select Properties in SQL Server Configuration Manager. Verify that, under IP2, the IP Address is set to the computer’s IP address on the local subnet. Scroll down to IPAll. Make sure that TCP Dynamic Ports is blank. Make sure that TCP Port is set to 1433 or your identified port no.
7. Remote connection must be enabled to connect to databases remotely. Connect to SQL Server Instance in SSMS. Right click on SQL Server instance name in SSMS and choose Properties. You will get Server properties window. Click on Connections from left side pane and tick the check box on Allow remote connections to this server option from right side pane.
8. SQL browser service should not be stopped if your security policy allows it. If you have disabled this service to apply hardening then make sure to pass port no along with SQL Server instance name/IP while making database connection.

You can fix SQL error 53 by applying above solutions on your SQL Server instance. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

Related Articles:

• Fix Error 28 – Server doesn’t support requested protocol
• Error 40: A network-related or instance-specific error occurred while establishing a connection to SQL Server
• Error 4064: Cannot open user default database. Login failed.
• Fix Login Drop issue Error 15138 and Error 3729

The post Fix SQL Server Error 53: Could not open a connection on SQL Server appeared first on Techyaz.com.

The error details are given below.

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error:40 – Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 2)

Below is the screenshot of above Microsoft SQL Server error 40.

Sometimes, we get same error under below error text.

An error has occurred while establishing a connection to the server. When connecting to SQL Server, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server) (.Net SqlClient Data Provider)

Microsoft SQL Server Error 40 – Root Cause

We get SQL error 40 because SQL Server did not respond to the client request. This issue occurs due to multiple reasons. I have given all those possible reasons behind Microsoft SQL Server error 40 in below points.

1. Server is probably not started and shutdown.
2. SQL Server Service is down.
3. SQL Server Instance is not accessible due to firewall or any reason.
4. Telnet port 1433 or port no on which SQL Server is running. These ports might be blocked.
5. TCP/IP or Named Pipes protocol is disabled in SQL Server Configuration Manager.
6. Remote Connection is disabled for this SQL Server Instance.
7. SQL Server browser service is stopped.
8. Wrong SQL Server Instance name while establishing database connection

Solution

We need to check and validate multiple factors to rectify Microsoft SQL Server error 40. Check all factors given in below step by step points to fix all possibilities for this error.

1. Make sure that database server is up and running fine.
2. Make sure SQL Server services are running fine and its accessible.
3. Check firewall details. Firewall should open between your client machine and database server.
4. Port 1433 and 1434 should be enabled. Telnet both ports to make sure ports are open.
5. Make sure to enable TCP/IP and Named Pipes protocols. Launch SQL Server Configuration Manager. Expand SQL Server Network Configuration from left side pane and click on Protocols for MSSQLSERVER. MSSQLSERVER is SQL Server Instance name. Now you will see all protocols in to right side pane. Right click on given protocols and select Enable button to enable both protocols.
6. Remote connection must be enabled to connect to databases remotely. Connect to SQL Server Instance in SSMS. Right click on SQL Server instance name in SSMS and choose Properties. You will get Server properties window. Click on Connections from left side pane and tick the check box on Allow remote connections to this server option from right side pane.
7. SQL browser service should not be stopped if your security policy allows it. If you have disabled this service to apply hardening then make sure to pass port no along with SQL Server instance name while making database connection.
8. Sometimes, we enter wrong server details. Make sure to enter correct SQL Server instance name while making database connection.

Related Articles

• Fix Error 28 – Server doesn’t support requested protocol
• Fix Error 233: How to set user connections server configuration in SQL Server?
• Error 4064: Cannot open user default database. Login failed.

Here, I have given different solutions to fix sql error 40 in SQL Server. I hope you like this article. Please follow our Facebook and Twitter handle to get latest updates.

The post SQL Server Error 40: A network-related or instance-specific error occurred while establishing a connection to SQL Server. appeared first on Techyaz.com.

Cannot Connect to ‘SERVERNAME’.
Login failed for user ‘username’. (Microsoft SQL Server, Error: 18456)

SQL Server Error 18456 – Login failed 

Initially, I thought login failed SQL error 18456 was reported because user might have entered wrong password, but when I tried it with correct password, it displayed same error again. Read this article to fix this error.

When I received same MSSQL error 18456 even after entering correct login id and password then we have decided to check the server authentication mode configured for this instance. Here we got the answer because this SQL Server instance was configured to run in only Windows Authentication mode, that is why SQL Server database engine was not allowing us to login using SQL Server login that comes in to Mixed authentication mode.

As we know there are two types of authentication mode in SQL Server.

1. Windows Authentication Mode
2. SQL Server and Windows Authentication Mode (Mixed Authentication Mode)

Only windows login accounts can connect to SQL Server if your instance is configured in Windows Authentication mode but when Mixed Authentication mode is configured you can connect using windows and SQL Server logins both way.

Solution

So, to fix this SQL Server error 18456 ( Login failed error 18456 ), we have two options:

1. Either Change Server Authentication mode of this SQL Server Instance to Mixed mode (SQL Server and Windows Authentication Mode)
2. Or, always use windows login or Domain login account to connect to SQL Server Instance.

You can also read the below articles which is a comprehensive guide to fix this error 18456:

• How to Fix SQL Server Error 18456: A Comprehensive Guide
• Fix SQL Error 18456: failed to open the explicitly specified database

Now, let’s come back to this specific issue. Here, we have decided to change the Server Authentication mode from Windows Authentication to Mixed mode authentication. Below are the steps:

1. Right click on SQL Server Instance name in SSMS and choose properties.
2. Select Security from left side pane.
3. You can see Server Authentication mode is set to Windows Authentication mode in below screenshot.
   
4. Change this to SQL Server and Windows Authentication mode that is second option in above screenshot and click on OK button.
5. Restart SQL Server and SQL Server Agent services to apply the changes to database engine.
6. Now you would be able to login to your SQL Server Instance using SQL logins as well.

Here, i have shown you how to fix a SQL Server error 18456 by changing its authentication mode. Read more articles in related section given below.

Related Articles

• Fix Error 15170: Login owns one or more Agent Jobs
• Fix Login failed Error 4064: Cannot open user default database
• How to fix error 28 – Server doesn’t support requested protocol
• Fix Error 18452: Login Failed

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

The post Fix SQL Server Error 18456: Login failed for user ‘User_Name’. appeared first on Techyaz.com.

Microsoft SQL Server Error 28

This is very common error that most of the people have gone through. Microsoft SQL Server Error 28 details are given below:

Sometime you might get same error as below description.

Root Cause

Generally, we get SQL Network Interfaces Error 28 while connecting to SQL Server instance either using SQL Server Management studio or using any other way. There might be several reasons behind generating Microsoft SQL Server Error 28. I have tried to capture all such reasons in below points..

• A specified SQL Server instance name is not valid. Wrong SQL Server Instance Name can lead to generate Microsoft SQL Server Error 28.
• Remote access is not enabled for your SQL Server instance.
• The firewall on the server has refused the connection because ports used by SQLBROWSER.EXE and SQLSERVR.EXE is still blocked.
• The SQL Server Browser service (sqlbrowser) is not started.

Solution

We need to check and validate multiple factors to fix Microsoft SQL Server error 28. Check all factors given in below step by step points to fix all possibilities for this SQL error 28.

• Validate whether server on which SQL Server is hosted is reachable from your client machine or not. Run ping and telnet to make sure server connectivity.
• Make sure SQL Server is running fine on your server. Check SQL Server services.
• Firewall ports 1433 for SQL Server and 1434 for SQL Server Browser services should be opened.
• Verify correct SQL Server Instance name. Check the spelling of the SQL Server instance name that is specified in the connection string.
• Make sure to enter full SQL Server Instance name in case you have named instance like SERVERNAME\SQL2017.
• Make sure that the SQL Server Browser service is started on the server.
• Enable Remote connection for your SQL Server Instance. Most of the people face Microsoft SQL Server error 28 because remote connection was disabled on the SQL Server Instance. Use the SQL Server Configuration Manager tool to enable SQL Server to accept remote connections over the TCP or named pipes protocols. Below steps you can follow to enable remote connections.

1. Launch SQL Server Configuration Manager. Expand SQL Server Network Configuration from left side pane and then click Protocols for InstanceName. If your server has default instance then it will look like “Protocols for MSSQLSERVER”
2. You can see all three protocols in right side pane. Shared Memory, Named Pipes and TCP/IP.
3. Make sure to enable Named Pipes and TCP/IP. Right-click at the protocol name and then click Enable. The icon for the protocol will change to show that the protocol is enabled.
4. You need to restart the SQL Server services to bring the changes into effect so restart your SQL Server services.

Related Articles

• Fix SQL Server Error 40: A Network related or Instance specific Error Occurred while establishing a connection to SQL Server
• How to Fix SQL Server Error 53: Could Not Open a Connection on SQL Server?
• Fix Error 4064: Cannot open user default database
• SAP Connectivity Issue After AlwaysON Automatic failover
• Fix Error 976: Cannot connect to Secondary Replica of AOAG

Here, i have shown you how to fix sql error 28. I hope you like this article. Please follow our Facebook page and Twitter handle to get latest updates.

The post Fix: SQL Network Interfaces Error 28 – Server doesn’t support requested protocol 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.

Automatic Failover Worked Well but Application failed to connect

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

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

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

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

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

Resync the SID from Primary Replica

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

SELECT replica_server_name, availability_mode_desc, failover_mode_desc
FROM sys.availability_replicas

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fix Orphaned Users

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

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

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

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

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

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

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