Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
stefan_seemann
Employee
Employee

In case you are using SAP's software provisioning manager and you are running into a problem, this blog might help you to find out the root cause of the current problem.

The Setup

Of course it all begins with starting the software provisioning manager. There are two different ways of doing this:

  1. Starting from the DVD.

    On Microsoft Windows, you can easily start the software provisioning manager by double-clicking on the executable sapinst.exe.
    In case you are working on UNIX, you can also start directly from the DVD by executing ./sapinst.
    By doing this, the so-called installation directory or rundirectory will be created as soon as you choose a procedure on the first dialog.

    In this example the installation directory is:
    /tmp/sapinst_instdir/NW740/ORA/ORA/COPY/EXP/AS-ABAP/PRETABSPLIT

    On Microsoft Windows, it would be:
    C:\Program Files\sapinst_instdir\NW740\ORA\ORA\COPY\EXP\AS-ABAP\PRETABSPLIT
  2. Start from a specified directory.
    As you might know, the generated directory structure can become quite deep.
    To avoid this, you can create your own installation directory. For this, create a directory, open a shell and call the executable from within this directory, as also shown on the following screenshot:

No matter which procedure you choose, this directory will become the installation directory. In case of a restart, software provisioning manager will not show the product catalog again, as it knows which procedure was executed before and will continue directly with it.

All logfiles are created inside of the installation directory. So, this directory is the first place to check in case of an error.

Dealing with Error Messages


Usually, you recognize that an error occured because of an error pop-up in software provisioning manager, as shown on the following screenshot:

Often, the problem can hardly be pointed out only with the help of the text on the pop-up, so you would have to consult the corresponding logfiles described in the next section.

The Different Logfiles

The following chart shows an overview of the procedure "Database Instance Export" towards SAP HANA.

As you can see, a lot of tools are involved:

The following chart shows an overview about the installation of the target system:

Every part has its own set of logfiles.

SAPinst Framework
It doesn't matter which procedure you choose from the product catalog, the software provisioning manager always calls the sapinst framework. The sapinst framework steers the execution via the so-called control files. The main logfile of the sapinst framework is the file sapinst.log. It contains major information about the execution.
Further details are written into the file sapinst_dev.log. It should be the first place to check in case of an error.

Keep in mind that all files written by the sapinst framework are so-called version files. That means, they won't be overwritten in case the execution is repeated. Instead, the current logfile is renamed before the repetition.

As you can see from the timestamp, the file sapinst_dev.log always contains the latest information.


Before you open the file sapinst_dev.log, make sure software provisioning manager has stopped, as only if it stops, it flushes out all information to the logfiles. Once you opened the logfile, navigate to the end of the file and then search upwards for ERROR.

In this example, we have navigated to the end of the file and now search updwards for ERROR:

The sapinst framework is also able to execute external tools. These tools don't have to be part of the software provisioning manager.
In case such a call is executed, the call is logged in sapinst_dev.log and, in most cases, also creates its own logfile which is also

located in the installation directory.

Migration Monitor

The migration monitor is executed by the sapinst framework. It is used for data export and import. It controls the actual execution of R3load.

The files of the migration monitor (migmon) are as follows:

  • export_monitor_cmd.properties/import_monitor_cmd.properties

    These files contain the configuration of the migration monitor.
  • export_state.properties/import_state.properties

    These files contain the current state of each R3load job. There are three different states:
    0 = To be executed.
    ? = In process.
    + = Execution was succesfull.
    -  = Execution aborted.
  • ExportMonitor.console.log/ImportMonitor.console.log

    These files contain the output of stdout and stderr of the migration monitor. They also contain an overview about the current status of the different R3load joblist:

    The content of the file is also shown in the bottom line of the software provisioning manager.
  • export_monitor.log/import_monitor.log

    These files contain detailed information about the different R3load jobs.
  • export_monitor.java.log/import_monitor.java.log

    These files are generated because of the process call by the sapinst framework and also contain the output of stdout and stderr.

Migration Monitor Extensions createorderby.jar and migmonctrl.jar

In former versions there were two different jar files for export and import: createorderby.jar for export and migmonctrl.jar for import.

In the current version of SWPM createorderby.jar has moved into migmonctrl.jar.

So there is only one add-on left which is called migmonctrl.jar, short version 'migmonctrl'. From the functional side everything stays the same except for the parameter in export_monitor_cmd.properties to enable the add-on. It is now the same for export and import: 'migmonCtrl'

More details about the functionality and all parameters of the add-on can be found in the System Copy Guide NW 7.1 for HANA.

In case a system migration is performed towards SAP HANA, an add-on called migmonctrl was developed to support the special architecture of the SAP HANA database. The incentive of migmonctrl is to keep the runtime for the export and the import as short as possible.

migmonctrl.jar

This migration monitor extension is added to the classpath of the migration monitor in case of a system copy towards the SAP HANA database.

In case of an export it creates the following files:

  • order_by.txt
    This file is read by the migration monitor before each passage. It can contain two special sort orders: "sort by size" or "sort by former runtime"
  • order_by_visual.txt
    This file contains the data as the file order_by.txt plus it also contains the size or runtime of each package. Due to this, you can retrace the sort mechanism of the tool, as shown in the following example:
  • migmonctrl.log

    The logfile in case of an export contains runtime information about the status of the R3load jobs, about job shifting between groups and so on, as shown in the following example screenshot:

In case of import it creates the following files:

  • migmonctrl_cmd.properties
    It contains the configuration for migmonctrl. The file is read during every passage of migmon. Due to this, the parameters can be change during runtime. See the following example snaphot of such a file:
  • order_by.txt
    This file is written by migmonctrl and read by the migration monitor. Depending on the load of the SAP HANA database, the jobs are shifted between groups and also the amount of jobs changes.
  • migmonctrl.log
    The logfile of migmonctrl contains lots of information about how the tool is working, as shown in the following example:
  • MigmonJobberConsole.log
    Contains stdout and stderr of migmonctrl, as shown in the following example:
  • R3LOAD_JOBS.csv
    This file can be used to create a Microsoft Excel chart about the number of R3loads involved during the execution time:
  • CPU_USAGE.csv, SAVEPOINT_STATISTIC.csv and FREE_MEMORY.csv
    The content of these files can also be used to create a Microsoft Excel chart.

R3load

The migration monitor starts several R3load jobs. The R3load jobs also have their rundirectory in the installation directory of the software provisioning manager. They write their own set of files. For example, the R3load which is processing job SAPSSEXC:

More information about these files can be found in another blog post: Migration to SAP HANA: SAP Kernel update for the migration

HdbSlLib


The HdbSlLib is used whenever a database request is executed by the sapinst framework. It is java based and consists of two jar files: com.sap.hdb.core.jar and com.sap.hdb.sl.lib.jar. For the connection to the SAP HANA database, it used by the SAP HANA JDBC driver ngdbc.jar.

The logfile of this tool is called HdbCmdOut.log.

To find out all calls from the sapinst framework into the HdbSlLib, you can search through sapinst_dev.log for: HDB_CMD_CLAZZ_NAME


The corresponding entry within HdbCmdOut.log looks like this:

General Information

So, in case of an error within software provisioning manager, the first place to check is the installation directory. It often helps, if you sort the files by timestamp using the command 'ls -ltr *.log' on UNIX or "dir /od *.log" on Microsoft Windows.

By doing this, you get a fast impression about what was done at last:


In this example, I executed the command "ls -ltr *.log".

As sapinst_dev.log is the last file which changed, it should contain the most actual information.

2 Comments