The enqueue server is a critical SAP NetWeaver AS system-wide SPOF if you have not installed the standalone enqueue replication service. If the machine hosting it (that is, the CI or SCS instance) fails, all SAP locks for transactions that have not yet been committed are lost. SAP NetWeaver ASis designed so that locking information is maintained exclusively in the memory of the host machine running the enqueue server. This is mainly for performance reasons and is true for all current SAP NetWeaver AS Releases.
No user can perform a transaction on SAP NetWeaver AS when the enqueue server (that is the CI or SCS in our definition of switchable units) is not available. This rule guarantees database consistency in the event of enqueue (that is, CI or SCS) failure.
The enqueue service needs to be restarted to continue normal work with SAP NetWeaver AS.This means that, after the CI or SCS has been switched over to another host, it has to be restarted. However, external SAP NetWeaver ASapplication servers on different host machines might still be holding open uncommitted transactions. These might be holding enqueue locks that have been lost and are not visible anywhere in the entire SAP NetWeaver ASsystem.
If no precautions are taken, any user in the SAP NetWeaver AS system can then lock the same object and change it in the database. Obviously, this can lead to database inconsistency. Therefore, all open transactions in the entire SAP NetWeaver ASsystem must be aborted and rolled back before the enqueue service (the CI or SCS) is restarted.
In earlier releases, you needed to reset all open transactions either manually or using a switchover script and reset enqueue locks on a system-wide level. However, this procedure differs depending on your SAP NetWeaver release. The impact on the SAP system, user sessions, and performance differs as well.
SAP NetWeaver now includes a feature to automatically restart the cluster nodes if the node running the enqueue server fails.
Of course, CI or SCS failure also implies failure of the message service. As most system activities require this service, it has to be restarted to continue normal system operation. Apart from this, the impact of message service failure is less severe than that of enqueue service failure.
As the CI or SCS includes the enqueue server, host failure and CI or SCS switchover mean that SAP locks for transactions that have not yet been committed are lost. This means that:
? All running transactions that hold locks are aborted and users are notified by a message in the status line.
· All user input for all transactions that have not been finished with the ABAP command COMMIT WORK has to be re-entered.
For a planned CI or SCS switchover, you need to inform users and give a deadline for them to commit all their transactions. After all transactions have been committed and update tasks finished, no SAP locks are held, so no locking information is lost during shutdown. Make sure that there are no update requests in status init (SM13) before stopping the CI or SCS. You do not need to restart the other application servers. Therefore, their buffers do not have to be refilled and so there is no negative impact on performance.
The SAP system can automatically handle transaction reset and the reset of SAP locks within certain limitations.
Host failure and switchover of CI or SCS have the following impact on your system:
? SAP locks for transactions that have not yet been committed are lost at a system-wide level.
? Normally, only the CI or SCS needs to be restarted.
? All AS instances can stay up and running.
? Only those interactive users who are directly connected to the CI or SCS have their sessions disconnected. All other users stay logged on to their application servers.
? All user input for all transactions that have not been finished with the ABAP command COMMIT WORK needs to be re-entered.
For a planned CI or SCS switchover you need to inform users and give them a deadline to commit all their transactions.
There is no reduction in performance on the application servers (AS instances) due to memory buffer rebuild. The buffer contents of all the AS instances (except the CI or SCS, of course) are preserved, and the system immediately returns to its optimal buffer hit-ratio and corresponding performance level. However, as long as the CI or SCS is not available, no update transactions can be performed.
It makes most sense to use the standalone enqueue server if your system has a high-availability solution and you want to eliminate the enqueue server as the single point of failure.
This changes the role of the CI, because the system-critical services can be concentrated on a lean instance that enables a fast restart and recovery. For more information on the enqueue server, see:
help.sap.com/nw2004s ® SAP NetWeaver Library ® SAP NetWeaver by Key Capability ® Application Platform by Key Capability ® ABAP Technology ® Client/Server Technology ® The SAP Lock Concept