Вот хочу обсудить, зачем столько усилий прилагать для сохранения записей блокирования в кластере с ASCS и репликами?
Ведь пользователи при падении узла все равно "отвалятся" от системы. Все "переедет" на другой узел и на этом узле восстановятся записи блокирования из реплики. Каждый пользователь получит сообщение что им же сами что то блокировано. Сеансы не восстановятся. начнут бомбить админов чтобы он снял блокировку. Так в чем же прелесть спасения блокировок? Что пользователь будет знать что он не завершил свою работу на "умершем" узле и только?
В чем я заблуждаюсь?

Если упадет ASCS, чем поможет пользователям поднятие ERS на другом узле в качестве ASCS?

Enqueue Server Failure

If the standalone enqueue server fails, it is started by the HA software on the host on which the replication server is running. The replication table stored on the replication server is transferred to the standalone enqueue server and the new lock table is created from it. The HA software also ensures that while the standalone enqueue server is out of action, clients’ connection attempts go through host B instead of host A. For more information, see Replication and Failover.

DB Reconnect – AS ABAP
In the event of a database host failure, the network connection of SAP work processes to the DBMS is lost. If a work process encounters an error in the database connection, the built-in “DB Reconnect” mechanism starts, and tries to re-establish the database connection.
The DB reconnect feature makes sure that all work processes of all SAP instances are automatically reconnected to the DB as soon as the DB service is restarted and becomes available again. The work processes can transparently recover after temporary DB failure.
To the end user, the temporary DBMS failure is almost fully transparent, apart from the time taken for the DB service to be switched over and become operational again. The functionality depends on the type of access service involved – that is, dialog, batch, or update.

То что ASCS заменится на реплику понятно.
Но вот то что база подымется быстро на другой ноде, что пользователи ничего не заметят и не потеряют сессии не понятно. База может подыматься достаточно долго. Вы полагаете что все действия выполняемые пользователем, прерванные падением ноды, не потеряются и пользователь может продолжить выполнение диалоговой транзакции с прерванного места на новой ноде?
Т.е. диалоговая инстанция вне кластера на которой работал пользователь будет ждать пока подымется другая нода и не даст "отвалиться" пользователю?

Я поставлю вопрос проще.
Я конечный пользователь, создаю документ в ММ, в FI, без разницы.
На середине документа при вводе позиции "падает" узел А.
Я работаю на диалогов. инстанции вне кластера, она не "падает", но рвется связ с БД. Возможны два варианта при попытке продолжить ввод документа на моем фронтенде:
1. Зависли "часики" и будут висеть пока все не переедет на узел Б, а потом я продолжу работу, даже не зная что было.
2. Получу сообщение об обрыве соединения, вылечу из фронтенда.
При повторном заходе попав на узел Б и попытке выполнить снова ввод документа получу сообщение о блокировании мной же.

Какой вариант реализуется?

3.1.6 Failure and Switchover of the Database Server
You can use DB reconnect in all situations where the database connection fails, such as host failure, planned shutdown, or temporary interruption of the connection to the database host. This feature enables automatic reconnection to the database if the last connection was closed unexpectedly. There are two types of DB reconnect:

• Reconnect to the same database instance
The reconnect to the same database instance is only successful if the error condition has been resolved.

• Reconnect to a standby database instance
This setup uses parallel database technology, where application hosts are connected to one database instance with an additional database instance on another host available as a standby instance. The reconnect to a standby database instance is normally successful immediately after the DB failure, if an error does not occur on this instance as well.

However, if an instance is (re-)started without being able to access the database, the instance stops. There is no reconnect at startup time. The same applies to the restarted work process in usage type AS ABAP: if the initial connect fails, the work process is stopped and is not restarted.

DB Reconnect – AS ABAP
In the event of a database host failure, the network connection of SAP work processes to the DBMS is lost. If a work process encounters an error in the database connection, the built-in “DB Reconnect” mechanism starts, and tries to re-establish the database connection.

The DB reconnect feature makes sure that all work processes of all SAP instances are automatically reconnected to the DB as soon as the DB service is restarted and becomes available again. The work processes can transparently recover after temporary DB failure.

To the end user, the temporary DBMS failure is almost fully transparent, apart from the time taken for the DB service to be switched over and become operational again. The functionality depends on the type of access service involved – that is, dialog, batch, or update.

For more information about the database reconnect feature for ABAP, see help.sap.com/nw2004s􀃆 SAP NetWeaver 7.0 (2004s) 􀃆 English 􀃆 SAP Library 􀃆 SAP NetWeaver Library 􀃆 SAP NetWeaver by Key Capabilities􀃆 Solution Lifecycle Management by Key Capabilities 􀃆 SAP High Availability 􀃆 SAP NetWeaver AS ABAP: High Availability􀃆 DB Reconnect (AS-ABAP)