Important Entries for the Checks Roadmap Step

This chapter deals with the roadmap step Checks. The Software Update Manager checks if the operating system and database version of your source release match the requirements of the target release. Furthermore, it checks some application-specific requirements.

In the following, we go into detail of some important checks:

Starting the Application-Specific Upgrade Toolbox

You can start the application-specific upgrade toolbox (ASU toolbox) using transaction /ASU/UPGRADE. The system loads the XML file (ASU.XML) contained in the SUM directory, generates a task list, and branches to the task list maintenance.

For more information, see SAP Note 1000009 Information published on SAP site .

Checking the Results of the System Check

At the end of the Checks roadmap step, the Software Update Manager displays the results of the system check. The entries can be error messages, information, or prompts for user actions.

Carry out the user actions before you can start with the Preprocessing roadmap step.

Checking for Database Triggers (SLT) on Switch Tables and Tables to Be Converted (Phases RUN_CHECK_SLT_TRIGGER_*)

The SAP Landscape Transformation (SLT) software allows SAP customers to effectively manage the impact that new business or IT-driven transformation requirements have on their existing SAP landscape. The SLT Replication Server is the standard real-time replication tool for Big Data for SAP ABAP-based source systems (Unicode and non-Unicode). Targets are:

SAP HANA database
all databases by SAP
SAP Business Suite
SAP applications

It also supports non-SAP sources covered by the SAP Product Availability Matrix.

Database triggers of the SLT can update a database automatically in response to a certain event. However, database triggers that are based on switch tables and tables to be converted can cause issues during the update procedure. The reason is that during the update procedure, switch tables and tables to be converted are replaced in the database with a new version, and the replaced tables are renamed or dropped. If such database triggers exist, the behavior of the Rename or Drop statement for these tables can vary depending on the database.

To avoid later issues, the Software Update Manager checks if relevant database triggers exist and displays, if applicable, an error message. The check is performed in phase RUN_CHECK_SLT_TRIGGER_PRE during the preparations of the update. You can ignore errors in this phase, but communicate them to the responsible SLT Operations Team. Not all problematic tables can be identified at this early stage of an update. This means that the list can be incomplete.

The Software Update Manager checks again in phase RUN_CHECK_SLT_TRIGGER_DTTRANS shortly before the downtime. In this phase, the list is complete. However, you still can ignore errors in this phase.

A further check is performed in phase RUN_CHECK_SLT_TRIGGER_DOWNTIME. In this phase at the latest, you must resolve the errors.

The lines in the error log file are similar to the following:

2EETG010 "Found trigger" "/1LT/REPOSRC" "on switch table" "REPOSRC".

In this case, follow the instructions of SAP Note 1620618 Information published on SAP site to delete the relevant database triggers. Create the deleted triggers again after the downtime, and an initial load of the affected tables is required.

Update Procedure with nZDM

When you include the nZDM feature in the update procedure, you can activate settings to minimize the Business Downtime in the Downtime-optimized scenario strategy. See Using the near-Zero Downtime Maintenance (nZDM) Feature for more information.

During an update with nZDM, the checks do not list those tables as errors that have triggers for nZDM and database triggers for SLT. When these tables receive new TABUs or indexes, the Software Update Manager excludes them from the uptime and moves them into the downtime. Here you have to handle them, rather than before the downtime, as described earlier for the standard update. Excluded from the move to the downtime are tables with SLT triggers that are intended for a conversion and thus for a structural change. They remain in the uptime. However, if these tables exceed the size of 50 GB, they are moved into the downtime, too.

In the following you get a rough overview about the checks and actions to be taken in a standard procedure including the relevant actions for the update with nZDM:

Preparing SAP Profiles

At the end of the preparation roadmap steps, you have the option to review the new SAP profiles for the SUM procedure and for the target release. These new profiles are available as template in different subfolders of the folder Start of the navigation path DIR_PUT Next navigation step sapnames End of the navigation path as follows:

backup	SAP profiles of the source system. They are used if there is a reset of the Software Update Manager.
dttrans	SAP profiles of the downtime system (single instance) that run with the source kernel.
newbas	SAP profiles of the downtime system (single instance) that run with the target kernel.
prod	SAP profiles of the productive system

During the downtime, the profiles are copied to the system profile directory.

If needed, you can modify the SAP profiles with regard to your customer-specific settings, SAP Memory Management, or deprecated parameters. The modification must be finished before entering the downtime.

You can also review and modify the SAP profiles as follow-up activity. For more information, see Performing Follow-Up Activities for SAP Profiles.