Migration to SAP HANA: Analyzing Problems within Software Provisioning Manager
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.
Of course it all begins with starting the software provisioning manager. There are two different ways of doing this:
- 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:
On Microsoft Windows, it would be:
- 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.
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.
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:
These files contain the configuration of the migration monitor.
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.
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.
These files contain detailed information about the different R3load jobs.
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.
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:
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”
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:
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:
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:
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.
The logfile of migmonctrl contains lots of information about how the tool is working, as shown in the following example:
Contains stdout and stderr of migmonctrl, as shown in the following example:
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.
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
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:
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.
Thanks for the details. This blog will help avoiding many hiccups for the migration tasks.