Updating SAP ABAP Systems on UNIX and Linux: SAP MaxDB

Isolating the Primary Application Server Instance

This chapter deals with isolating the primary application server instance so that only the Software Update Manager can work with the system during downtime.

Context

Isolating the primary application server (PAS) Instance means that you can use it exclusively for the update. The Software Update Manager asks you to isolate the PAS instance when downtime begins.

During downtime, all users have to be logged off from the system. You can use transaction SM02 to inform the users who are logged on to the system.

Procedure

  1. Check if a saposcol process is running in the current kernel directory.

    If so, stop and delete it as user root. To do this, change to your current kernel directory and enter the following commands:

    ./saposcol –k

    ./saposcol –d

    Collector> leave (to delete the shared memory and to detach)

    Collector> exit (to exit the process)

    rm saposcol

  2. Check if the SAProuter is not active.

    The SAProuter in the run subdirectory should not be active while the new SAP kernel is being imported. You have the following options:

    • Stop the SAProuter now and restart it after the update.

    • SPS update: If you need the SAProuter during the update, stop it at the beginning of the downtime at the latest. If you need the SAProuter during the downtime, make sure that the update is not running in parallel, especially during phase KX_SWITCH.

    To display more information about the SAProuter:

    • Enter saprouter at the operating system level.

      A list of all the parameters appears.

    • See the SAP Help Portal for your target release at: http://help.sap.com, Start of the navigation pathApplication Help Next navigation step Function-Oriented View Next navigation step Application Server Next navigation step Application Server Infrastructure Next navigation step SAProuterEnd of the navigation path.

  3. Make sure that no CRON job is scheduled that affects the SAP system. Examples: Starting and stopping the SAP system, saving the database, or similar actions.

    This could impair the full control of the Software Update Manager over the SAP system.

  4. AIX-systems only: Check the restrictions for cpu, fsize and core for user <SID>adm.

    Enter the command lsuser as user root.

    The parameters should have the following values:

    cpu=-1

    fsize=-1

    core=100000

    If not, use the chuser command to change them (enter, for example, chuser cpu=-1 <SID>adm).

    These changes only take effect for user <SID>adm when you have logged on again as <SID>adm.

    Then restart the SAP system again.

  5. Make sure that no change of operation mode is defined on the primary application server instance during the update.

    If this is the case in normal operation, call transaction SM63 either to choose a single operation mode for all-time spans, or to delete all the assignments.

  6. Clean up all outstanding updates as described in Evaluating the Results of the Preparation Roadmap Steps when the message Update records still exist - Please process appears.
  7. Make sure that you can recover the database to its current state.

    Back up the update directory now. If a hardware problem occurs during downtime, you may need to reset the upgrade to the state it had when the SAP system was isolated. So that the Software Update Manager has the correct control information, the SUM directory should have the same state as at the beginning of the MODPROF_TRANS phase.

  8. You can lock the database against remote access. Contact the database administrator, if the primary application server instance and the database server are on the same host.