This blog describes a failure situation that showed up over the last 12 months in some circumstances with customers running DBMS High Availability solutions on Azure that require an Azure Load Balancer. These customers may have observed ABAP Shortdumps with the error message 10054. We meanwhile identified the problem and described a solution to resolve this problem in a new SAP Note 3083711 - Azure - ST22 shows DBSQL_SQL_ERROR
To analyze whether you encountered the problem, follow the procedure below. All the conditions below must be true for this note to apply:
The screenshot shows an example of a Secondary Service Connection. Note: the actual name of the Secondary Connection will be different for different ABAP programs. The ABAP syntax for a Secondary Service Connection is “connection (<connection name or variable)”.
The SQL operation will typically be on a very high concurrency table such as NRIV, VARINUM etc
The problem will not occur on the Basic Load Balancer as the Basic Load Balancer runs different logic. Nevertheless, we advice customers that are using Basic Load Balancer to move to the Standard Load Balancer as general guidance due to significant latency improvements, independent of the issue described in 3083711 - Azure - ST22 shows DBSQL_SQL_ERROR.
The problem is caused by a regression in the how Azure networking handles TCP reset injection. The problem will only occur with High Availability solutions that use the Azure Standard Load Balancer to present a Virtual IP Address created by either Windows Cluster or Pacemaker.
The problem can be quickly and easily resolved by applying the following the procedure below.
High availability ports overview in Azure - Azure Load Balancer | Microsoft Docs
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.