Skill Level: Any Skill Level

This recipe is helpful for SAP admins who is working with high availability solutions

SAP high availability failover scenarios may result in not shutting down the ERS by SAP, after ES has failed over to the ERS server. Consequently, TSA is not able to start the ERS on the alternative server. Make sure the ERS settings are correct.


SAP high availability setup is deployed, which means Enqueue Server and Enqueue Replication Server are installed and configured on two or more servers.

See picture on the title.



  1. Check correctness of the ES and ERS SAP profiles

    • Disable autostart of all SAP instances in all their profiles by commenting the line Autostart = 1.
    • To share the enqueue backup file within the Linux or AIX cluster, store the file in the NFS-mounted /sapmnt/<SID>/global directory. It can be accessed from all nodes in the cluster where the Enqueue Server can start. Add the following parameter to the (A)SCS profile for sharing the enqueue backup files between nodes:
      enque/backup_file = $(DIR_GLOBAL)/ENQBCK(A)SCS
    • It is required to disable the SAP restart capability for the Enqueue Server and the Enqueue Replication Server in the appropriate profiles. Otherwise, the automatic restart of SAP by using the command startsapsrv mismatches with System Automation for Multiplatforms start function and causes problems with the automation. Set the SAP profile parameter for EN and ERS to Start_Program_<NR> in the EN and ERS profiles in the /sapmnt/<SID>/profile directory.
      For all servers other than EN and ERS, set the SAP profile parameters Restart_Program_<NR>.
    • If Start_Program is defined, then – Initial start is started by startsapsrv framework. – Recovery start is started by System Automation for Multiplatforms. Resources can start either in place or resources can fail over.
    • If Restart_Program is defined, then – Initial start is started by startsapsrv framework – Recovery start is started by startsapsrv framework. Resources can start in place.


    SAP profile example


    # Start SAP enqueue server
    _EN = en.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME) Execute_04 = local rm -f $(_EN) Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enserver$(FT_EXE) $(_EN) Start_Program_01 = local $(_EN) pf=$(_PF)
    # Start SAP message server
    Execute_02 = local rm -f $(_MS)
    Execute_03 = local ln -s -f $(DIR_EXECUTABLE)/msg_server$(FT_EXE) $(_MS)
    Restart_Program_00 = local $(_MS) pf=$(_PF)
    SAP profile /sapmnt/<SID>/profile/<SID>_ERS02
    # Start enqueue replication server
    Execute_03 = local rm -f $(_ER)
    Execute_04 = local ln -s -f $(DIR_EXECUTABLE)/enrepserver$(FT_EXE) $(_ER)
    Start_Program_00 = local $(_ER) pf=$(_PFL) NR=$(SCSID)

  2. Check the consistency of the global and local ERS profiles

    As opposed to the standard architecture of any SAP instance, the ERS instance directory on the LINUX servers has a local profile directory. Below are the global and local profile directories location:



    specific to ERS instance:


    in particular the parameter Autostart has to be out commented:


  3. Check replication status for each ERS instance

    Check replication status for each ERS instance on the second node using ensmon utility:

    # ensmon pf=/usr/sap/<SID>/ERS<ID>/profile/<SID>_ERS<ID>_<node2>

    Select task: Get replication information. The output looks like this
    …Replication is enabled in server, replication server is connected. Replication is active…

  4. Retest the ES failover scenario

    1. Kill ES process on the ES server, or crash the ES server
    2. Make sure, ES has failed over to ERS server
    3. Make sure, ERS has been shutdown by SAP after ERS –> ES table replication is complete
    4. Make sure, ERS has been restarted by TSA on the alternative server.
  5. More info…

    For more information, how to setup and test the high availability solution for SAP with TSA, refer here:

    SAP high availability solution with TSA


Join The Discussion