cancel
Showing results for 
Search instead for 
Did you mean: 

Do we need to delete Enqueue Locks Manually On Node2 After Failover In cluster Environment?

Former Member
0 Kudos

Hello Experts,

As per ERS concept as in below link that locks are carried to Node2 by ERS server in case of failover.

Enqueue Replication Server Part 1 - What is ERS - Netweaver Technology - SCN Wiki

If the user1 wants to resume the last activity of Node1 in Node2 then it will show the table is being locked by

the user1(same user name)

In this case do we need to delete locks on node2  manually from sm12?

For every time during failover do we need to perform this activity?

Kindly suggest on this.

Thanks,

Bharath.

Accepted Solutions (0)

Answers (2)

Answers (2)

Former Member
0 Kudos

Hi Bharath,

What's are the components running on Node1 & what's are the components failed over to Node 2. If CI or any app server running on Node1 and user's session was part of that app server then I think you need to delete lock entry manually after the user logoff from the system &  not active BTC jobs running with user's name.

If my assumption is correct then I think this is program crash situation as mentioned by Clebio.

Former Member
0 Kudos

Hi Experts,

We have SAP installed on Active-Active cluster with CI and ERS instances are configured on local disks of Node1 and DI & ERS instances are configured on Node2.

When i tested with failover by shutting down at OS level of Node1  all the users connected to CI configured on Node1 are getting disconnected and ASCS, SCS & DB instances are failing over to Node2.

While they reconnect to Node2 dialogue instance and continued to perform last activity initiated on Node1 CI application they are getting table is locked by the user(same user name).

This is due to ERS functionality locks in sm12 are replicated to Node2 DI from Node1 CI.

How to deal with these locks after failover?

Kindly assist.

Thanks,

Bharath.

0 Kudos

If I correctly understand your scenario, there is a problem because you are running a dialog instance in the node 1, and the user from this dialog instance will need to reconnect to the dialog instance in node 2 if the node 1 crash.

Basicaly your landscape seems to be:

NODE 1 = ASCS + SCS + Dialog instnace (CI) + ERS

NODE 2 = ASCS + SCS + Applicaiton server + ERS

The users connected to the DIalog instance will lost the connection due to the crash of node 1, therefore, they will need to reconnect to the system (connection to the application server in node 2).

The HA will not be able to handle the situation of the locks missed due to the "crash" of dialog instance. Usually you only run the ASCS + SCS in the cluster nodes because it is not possible to failover a dialog instance.

If I correctly understand your landscape, your problem is caused because your design. The dialog instance crash and there is no failover of dialog instance shared memory.

If you run the CI in another server (not in the cluster node) the users should not be affected by this issue.

Regards

Clebio

Former Member
0 Kudos

Clebio,

We have following instances in 2 nodes of the cluster

NODE 1 = ASCS + SCS +  Primary Application server(CI) + ERS

NODE 2 = ASCS + SCS + Dialog instnace(DI) + ERS



The users connected to the Primary Applicaion Server(CI) will lost the connection due to the crash of node 1, therefore, they will need to reconnect to the system.

Kindly suggest.

Thanks,

Bharath.

sunny_pahuja2
Active Contributor
0 Kudos

Hello,

ASCS and SCS should be on single node. How is it possible that it is present on both the nodes.

When your node1 goes down then users should not be disconnected but their session will be hanged for sometime till the time database will be available again on 2nd node. You can increase or decrease session reconnect time parameter.

Thanks,

Sunny

Former Member
0 Kudos

Sorry Sunny

We have following instances in 2 nodes of the cluster and also shared instances between 2nodes.

NODE 1 = Primary Application server(CI) + ERS

NODE 2 = Dialog instnace(DI) + ERS

Cluster virtual Hostname for SAP resource : ASCS + SCS

Primary Application Server Instance Number 05

Dialog Instance Number 06

Since the instance numbers are different user sessions are getting disconnected even after configuring logon load balancing is configured.

Kindly suggest on how to handle enqueue for this installation during failover?

Thanks,

Bharath.

Sriram2009
Active Contributor
0 Kudos

Hi Bharath

In Node 1 CI & Node 2 DI instance number should be same then user can reconnect the SAPGUI session. otherwise in user's PC you have define the Two system icon,

for this better you can uninstall the node 2  DI and install with instance number 05 as same in Node 1 CI instance number 05

Regards

Ram

sunny_pahuja2
Active Contributor
0 Kudos

Users should not be connected directly to CI/DI. User should login with message server with lgon group. In that, users will not be disconnected.

Thanks,

Sunny

Former Member
0 Kudos

Sriram,


As per installation guide it is not mandatory that both system numbers should be same.

Primary Application Installation :

--> Make sure that the primary application server instance number is different from the (A)SCS instance number.

Additional Application installation :

--> Make sure that the additional application server instance number is different from the (A)SCS instance number

My Analysis on our client system :

It is Active-Active cluster in which load sharing is configured between Primary and Dialog instances. Message server will share the load between these two instances during normal operations.

Kindly Suggest me about my analysis and my queries.

Thanks,

Bharath.

Former Member
0 Kudos

Sunny,

Users are connecting with message server but getting disconnected when Node1 goes down with the message application server shutdown connection to other application. Again they are able to connect with message server to node2 after some time but showing locks in sm12.

Kindly suggest on this.

Thanks,

Bharath.

Former Member
0 Kudos

At the current time there is no solution to this issue other than to release locks in sm12.

Former Member
0 Kudos

Roman,

If i disable ERS in both nodes then the locks will not be carried to the second node but will that effect enqueue locks during normal operation.

Kindly suggest on this.

Thanks,

Bharath.

Sriram2009
Active Contributor
0 Kudos

Hi Bharath

Kindly refer the link ERS replication & Failover on HA environment

Replication and Failover (SAP Library - The SAP Lock Concept (BC-CST-EQ))

Regards

Ram

Former Member
0 Kudos

Experts,

--> If i disable ERS in both nodes then the locks will not be carried to the second node but will that effect enqueue locks during normal operation.

Sorry my assumption will not workout for our system which is configured for load balancing. Since user connection will be shared between two instances during normal time and if Primary node goes down then enqueue server will restart on second node by losing all previous locks held by CI and DI. If it loses DI Application locks it will lead to inconsistencies.

I got two options:

1. I can only disable ERS if the system is not configured for load balancing. Users will connect to CI during normal operation and will connect to DI with another entry in logon pad.

2. I have to delete some sm12 locks manually after each failover from node1 to node2.

Kindly suggest on this.

Thanks,

Bharath.

Former Member
0 Kudos

1. Why you want to disable ERS? You can use ERS or not in any cases.

2. You need to delete some sm12 locks only if one of application server has been terminated abnormally.

Sriram2009
Active Contributor
0 Kudos

Hi Bharath


1. I can only disable ERS if the system is not configured for load balancing. Users will connect to CI during normal operation and will connect to DI with another entry in logon pad.         

If you are Disable the Enqueue replication server, In SAP system Enqueue service will not work. for that kindly refer the below screen shot


2. I have to delete some sm12 locks manually after each failover from node1 to node2.?

In this case you can raise the SAP OSS ticket, in better way they can explain & guide you

Regards

Ram

0 Kudos

you should never manually delete locks after a failover.

Indeed you should never manually delete locks in any situation. The release of a lock is a task to the program that create it,

If a program returns an error, after the failover, regarding an object already locked, the program is facing some problem. The lock operations in enqueue should be transparent to the program during and after the failover.

This kind of situation (object already locked) only can occurs if the program crash due some issue and is not able to handle already created locks.

Regards

Clebio

Sriram2009
Active Contributor
0 Kudos

Hi Bharath

Kindly refer the links about your query's

Replication and Failover (SAP Library - The SAP Lock Concept (BC-CST-EQ))

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/405f3bee-0c69-2a10-7b84-af7c1cb43...

In this PDF refer the Chapter 8 High Availability with Microsoft Cluster Service and ERS testing Chapter 8.4.1.1

Regards

Ram