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

The standard advise that you get for a migration is to update the SAP kernel to its latest version. In this blog, I want to provide some background information about the tools provided with the SAP kernel that are involved in a migration.

The source system:

  1. R3ldctl

    R3ldctl generates two different kind of files. The so-called STR and TPL files.

    The STR files (structure files) contain DDL information about tables, indexes and views in the source system.
    Regarding their purpose (basis, application, etc.), the table information is put in different STR files, whose names all start with SAP:


    For example, the file SAPSSEXC.STR might look as follows:


    The TPL files (termplate files) contain database specific patterns for DDL and DML statements used by R3load during the migration.
    For example, the file DDLHDB.TPL might look as follows:

    STR and template files are copied onto the export DVD by software provisioning manager during the procedure "Database Instance Export".
  2. R3ta

    This tool is used for table splitting. If you are executing the software provisioning manager procedure "Table Splitting Preparation", R3ta is called to generate the so-called where files or WHR files. Using these files, a table can be exported in parallel.

    For example, T100-1.WHR might look as follows:

    R3ta only creates one WHR file that contains all the where conditions. To be able to call different R3loads for each where clause, the package splitter is used to cut the WHR files into pieces containing only one where clause.
  3. R3szchk

    The files that R3szchk generates are DBSIZE.XML and the so-called EXT files.

    DBSIZE.XML contains the estimated size of the target database system. In case you are migrating to SAP HANA, the file DBSIZE.XML is not used.
    For example,  DBSIZE.XML might look as follows:


    The EXT files are similar to the STR files, but instead of DDL information, they contain size information of the tables in the source system.

    For example, SAPSSEXC.EXT might look as follows:

    The EXT files are very important, if it comes to package splitting or the new sort option "sort by size" during the export.
    When you are performing a system copy with SAP HANA or towards SAP HANA, R3szchk is called during the software provisioning manager procedure "Database Instance Export".
  4. R3load

    The most important tool is doing the data export using files and information from the tools above. It is called in the software provisioning manager procedure "Database Instance Export".

    During the data export, R3load creates different kind of files, outlined in the following sections.

    DATA and TOC files
    On the export DVD, R3load creates the data dumpfiles and the so-called TOC files.
    For example, this might look as follows for SAPSSEXC:

    The data dumpfile contains the binary data of the tables.

    The TOC file contains information about how many rows were exported and information about the dump files.
    For example, SAPSSEXC.TOC might contain the following information:


    CMD, TSK and logfile
    In the installation directory or rundirectory of R3load, three different files are created: cmd, TSK and the logfile.

    The cmd file (command file) contains information about file locations and package sizes.
    Example of an SAPSSEXC.cmd file:

    DDLADA.TPL is used as template file. This is because the source database is SAP MaxDB.

    The TSK file (taskfile) contains a joblist for R3load.
    Example of an SAPSSEXC.TSK file:

    During runtime. R3load keeps a backup file called TSK.bck that contains the original version of the task file. When R3load finishes the export of one table (succesfully or not), it adds the tablename with the state to the TSK file. There are three different kind of states: xeq (to be executed), ok and err.

    The most important file is - of course - the logfile. It contains all information about versions, the execution and errors.
    Example of a SAPSEXC_1.log file:


    In the logfile, you can see:
    - when R3load was started,
    - which version it is,
    - what call options were used,
    - the version of the database kernel and the database client,
    - how many rows were exported,
    - if it was succesfull
    - and when it has finished.

All tools are part of the SAP kernel and need to be executed as sidadm, because they need the SAP environment settings.

To check the version, you have two options (shown on the example of R3ldctl😞


or the full output with the patchtexts

Besides single R3 tool patches, there are two main packages for the SAP kernel:

  1. SAPEXE...SAR
    Contains the database independent part. R3ta comes with this archive.
  2. SAPEXEDB.SAR
    Contains the database-specific tools like R3load, R3szchk and R3ldctl.

The target system:

During the setup of the target system there is only one kernel tool involved which is again R3load.

As we are using software provisioning manager to install the target system it is not possible to update only R3load to the latest version.

To do this, it would be necessary to stop software provisioning manager after the installation of the SAP kernel and then to update R3load by hand.

But software provisioning manager offers to update the complete SAP kernel with the latest SAR archives from the SAP Service Marketplace

right after the SAP kernel is installed from the DVD. Due to this, you have already the latest kernel version before the data import is started.

When you are executing the software provisioning manager procedure "System Copy -> Target System ...", the following dialog is shown where you can enter the latest SAR archive for the corresponding kernel:


The dialog appears in both software provisioning manager installation modes: Typical and Custom.

But which is the right kernel for your target system ?

With respect to SAP HANA these kernels are available: 7.20, 7.21, 7.38 and 7.40

  • 7.20, 7.21
    SAP kernel 7.20 is used for SAP Netweaver Business Warehouse 7.3 on SAP HANA.
    Besides kernel 7.20, there is a so-called maintenance kernel, which is 7.21
    The kernel 7.21 contains a special feature within R3load called MASSLOADER.
    This special feature accelerates the import of LOB data. Due to this, the duration for the data import goes down noticeable.
    It is possible to switch between 7.20 and 7.21 without any influence on the system.
    Due to this, we recommend to use kernel 7.21 for the import. After that you can stay on that version or you can switch back to 7.20.
    To activate the MASSLOADER option you have to set an evironment variable in the SHELL, where you start software provisioning manager.
    It is not necessary to do this as <targetsid>adm:

    Check this SAP Note for more details:  Note 1775293 - Migration/system copy to SAP HANA using latest SWPM 1.0
  • 7.40 (7.38)
    SAP kernel 7.40 is used for SAP ERP on SAP HANA. The first kernel release was 7.38, but we now recommend to only use 7.40.
    SAP kernel 7.40 already contains the MASSLOADER feature and it is activated per default. So, no manual intervention is necessary.

It is important to download always both SAR archives SAPEXE and SAPEXEDB

Another important part is the SAP HANA client software. It is not directly a part of the SAP kernel but still should be on the latest version during the data import. The current versions already have a so-called label file or LABEL.ASC. Due to this, software provisioning manager accepts the extracted archive as DVD. Also the SAP HANA client is down- and upward compatible. That means that the version of the SAP HANA client does not have to match the version of the SAP HANA database. Both should just be as new as possible.

  1. Download the latest SAP HANA client:

    In this location you also find the SAP HANA Studio
  2. Extract the archive.:
  3. Set the path to the extracted archive on the dialog:

Hopefully, this makes the purpose of the kernel update clearer.

3 Comments