Tips for improved short dump analysis in ST22

This blog will give you tips for improved analysis in the ST22 short dump list.

Questions that will be answered are:

  • What is this new button SAP correction notes doing there?
  • Detecting Z code in dump?
  • How to deal with RFC_NO_AUTHORITY dumps?
  • How to deal with CALL_FUNCTION_SINGLE_LOGIN_REJ dumps?
  • How to deal with TIME_OUT dumps?
  • How to deal with MESSAGE_TYPE_X dumps from program SAPLOLEA?
  • How to deal with TSV_TNEW_PAGE_ALLOC_FAILED dumps?
  • How to deal with CALL_FUNCTION_BACK_REJECTED dumps?
  • How to authorize ST22 details?
  • How can I find dumps specific to SAP HANA?

The tips below assume you have not yet any clue on how the dump is created.

If you know how the dump is created, but cannot analyze from the dump: please read the blog on the ANST tool: automated notes search tool.

SAP Correction Notes button

In newer SAP versions for most dumps you can find the SAP Correction Notes button:

Based on keywords in the short dump SAP will look for known solution correction notes.

The results might be surprisingly accurate:

ST22 notes correction found notes

If you have not setup the new SAP support backbone you will get a connection error:

Access denied

OSS note 2847665 – OSS RFC Connection fails, which refers to be backbone connection. To solve this issue: follow the instructions from OSS note 2781045 – ANST / ST22 note search “Connection cannot be established” .

If you get the message “Connection cannot be established”, check also fixes mentioned in OSS note 2605397 – ST22 – SAP Correction notes – error: “Unable to extablish OSS connection properly”.

Getting the overview of dumps

After starting transaction ST22 select menu item Goto / Overview. Fill out the dates and you now get the overview including the statistics on the occurrences:

Short dump overview

Dumps in HANA environments

SAP keeps a list of ST22 dumps especially for HANA environments: 2399990 – How-To: Analyzing ABAP Short Dumps in SAP HANA Environments. This is a very extensive note.

ST22 dump analysis authorizations

All the new ABAP stacks (as of 7.54) have the option for more fine grained ST22 authorizations. Please read OSS note 2792743 – Change in Authorization Check of ABAP Dump Analysis in release SAP_BASIS 7.54/7.77 – Authorization Object S_ABAPDUMP.

Detecting Z code in a dump

Detecting Z code in a dump is normally easy if it is a Z program. Some dumps you can have due to the fact that Z code is there in a user-exit, which again is calling SAP code. This dump will appear as looking 100% standard SAP, but when you scroll down in the Call Stack you will see Z code:

Before raising OSS message to SAP: make sure the call stack does not contain custom Z code.

RFC_NO_AUTHORITY dump

The RFC_NO_AUTHORITY is special kind of dump and typically looks like this:

ST22 dump RFC_NO_AUTHORITY

First thing to get from the dump is the user ID and the calling system (is it an internal call or call from different system). And if the user ID is a human user or system user.

Second thing to determine is: is this a valid call or not a valid call?

In case of valid call, look in the dump which authorization is missing and what needs to be added. If the addition is done: do keep an eye on the dumps, since a new dump might come for a different new authorization object.

In case of an invalid call, you need to determine how the call was initiated and take action to avoid the initiation. This is not always a simple job.

Why is checking this dump important? Complete business flows might be disrupted if this happens. It is hard to detect for the end users what is going on. It will take them time to raise an incident and for functional people to determine what is going on. This way a lot of valuable time can be lost.

What can also happen: people try to connect via RFC methods to read data. This will give lot of dumps which are hard to follow up.

If you get too many of these dumps and you can’t solve them, you can switch parameter rfc/signon_error_log to value -1. Then the dumps are no longer there in ST22, but in stead moved to SM21 system log with less detail. If you need to have the details again, switch the parameter again (it is dynamic). Background on the parameter rfc/signon_error_log can be found in OSS note 402639 – Meaningful error message texts (RFC/Workplace/EBP).

CALL_FUNCTION_SINGLE_LOGIN_REJ dump

A bit similar to the above dump is the CALL_FUNCTION_SINGLE_LONG_REJ dump. Here a user tries to login via RFC to the SAP system, from a different SAP system, or from a JCO based connector.

Again: first determine if the call is valid or not. If not valid, determine the calling source (can be hard!).

If it is a valid call, scroll down in the details section for this dump and look for the part below:

There are two codes: T-RC code and the L-RC code. Check both the codes. In this case above the user ID validity was no longer ok.

Depending on the codes different solution needs to be applied.

Why is checking this dump important? Complete business flows might be disrupted if this happens to system user. If it happens to single user he might get grumpy. It is hard to find for the end users what is going on. It will take them time to raise an incident and for functional people to determine what is going on. This way a lot of valuable time can be lost.

TIME_OUT dumps

If an online query takes longer than the timing set in parameter rdisp/max_wprun_time a TIME_OUT dump will happen. By default and best practice, this time out parameter is set to 10 minutes. This is also the case in most system.

This dump will look like:

ST22 TIME_OUT dump

If you scroll down (or click in the left section) to the User and Transaction section, you can see the ID of the user who caused this and the transaction.

First reaction of the average basis person is: call/mail the user and ask him to run this in batch mode. This is indeed one of the solutions.

Alternative potential solutions:

  • Analyze with the end-user if he can fill out more selection criteria (hence reducing the time needed to select the data)
  • Analyze with the end-user if he can run the report in multiple smaller sets
  • Check if there are known performance OSS notes for the transaction the user is running (the root cause might simply be an SAP bug)
  • Check if the database statistics of the tables queried is up to date
  • In some cases both the selection criteria are ok, and the output of the list in batch only give a few results: in this case the creation of special index might be the solution. This can happen in case of check reports that look for business exceptions.

Why is checking this dump important? Users tend to get very frustrated by the system if they hit this dump. They have to wait 10 minutes and have no result. Sometimes you see this dump a couple of times in a row. Imagine yourself being the user with a boss demanding report which crashes after 10 minutes…

MESSAGE_TYPE_X dumps from program SAPLOLEA

The MESSAGE_TYPE_X can be pointing to very serious issue. But the ones generated by program SAPLOLEA point towards one type: the SAP GUI server interaction.

This dump typically look like this: a main dump MESSAGE_TYPE_X and calling program SAPLOLEA.

This dump can have 3 main root causes:

  1. Issue in ABAP code (hit the SAP correction notes button to search for solutions)
  2. Issue in local SAP gui installation of the end user
  3. Issue in the SAP kernel

If you see many dumps with the same user ID: this typically points towards an old local SAP gui installation. Solution is to update the local SAP GUI for that user to the latest version that is supported in your company.

In rare cases the SAP kernel causes these kind of dumps. These are hard to find and detect. The only remedy here is to update the kernel at regular intervals.

To find which users use which SAP GUI version: go to transaction SM04 and add the field SAP GUI version:

Add SAP GUI version in SM04

From ABAP code: use function module TH_USER_LIST to get list of sessions. The GUI version is in the field GUIVERSION of output table USRLIST.

For more background on SAP GUI patching read this dedicated blog.

TSV_TNEW_PAGE_ALLOC_FAILED dumps

This type of dumps can have 2 main root causes:

  1. Way too many data is selected
  2. System is not properly tuned

For the second case read OSS note 2180736 – TSV_TNEW_PAGE_ALLOC_FAILED for and extensive description on what to check and update on basis level.

Known TSV_TNEW_PAGE_ALLOC_FAILED dumps:

CALL_FUNCTION_BACK_REJECTED dumps

These dumps are caused by missing callback positive listing. See OSS note 2981184 – What to do in case of CALL_FUNCTION_BACK_REJECTED short dump. The solution is to add the function module to the positive list in RFC. In no way reduce the RFC security by lowering the RFC callback security parameter rfc/callback_security_method. Read this blog on how to hack using callback RFC, and why not to lower the security.

Coding and table generation dumps

Dumps can happen due to coding and tables not generated properly. When it happens during transport import, it is normal. If it persists after the import, you need to act. Best practice notes:

Dump clean up

Dumps can be cleaned up with program RSSNAPDL. For more background on this program see oss note 1995777 – Dump deleted within a short period of time ST22.

Remove 28 day limit for keeping short dumps

Note 3020638 – Short dumps cannot be kept more than 28 days explains the 28 days limit. Applying note 3022767 – Remove implicite deletion of short dumps older than 28 days removed the limit.

SAP database growth control: getting insight

This blog will explain about getting insight into SAP database growth and controlling the growth.

Questions that will be answered are:

  • Do I have a database growth issue?
  • What are my largest tables?
  • How do I categorize my tables?

Why control database growth?

Controlling database growth has several reasons:

  • When converting to S/4 HANA you could end up with smaller physical HANA blade and need to buy less memory licenses from SAP
  • Less data storage leads to less costs (think also about production data copied back to acceptance, development and sandbox systems)
  • Back up / restore procedures are longer with large databases
  • Performance is better with smaller databases

Database growth

The most easy way to check if the database is growing too fast or not is using the Database Growth section in the SAP EWA (early watch alert). The EWA has both graphical and table representation for the growth:

EWA database growth picture

EWA database growth table

Or you can check online in the EWA workspace.

You now have to determine if the growth is acceptable or not. This depends a bit on the usage of the system, amount of users, business data, and if you already stretched your infrastructure or not.

General rules of thumb: 

1. Growth < 1 GB/month: do not spend time.
2. Growth > 1 GB/month and < 5 GB/month: implement technical clean up.
3. Growth > 5 GB/month: implement technical clean up and check for functional archiving opportunities.

Which are my largest tables?

To find the largest tables and indexes in your system start transaction DB02. In here select the option Space/Segments/Detailed Analysis and select all tables larger than 1 GB (or 1000 MB):

DB02 selection of tables larger than 1 GB

Then wait for the results and sort the results by size:

DB02 sorted by size

You can also download the full list.

Analysis of the large  tables

Processing of the tables is usually done by starting with the largest tables first.

You can divide the tables in following categories:

  1. Technical data: deletion and clean up can be done (logging you don’t want any more like some idoc types, application logging older than 2 years, etc): see blog on technical clean up
  2. Technical data: archiving or storing can be done (idocs you must store, but don’t need fast access to, attachments)
    1. In Oracle based systems, you might find large SYS_LOB tables. To analyze these, read this special blog.
  3. Functional data: archiving might be done here: for functional data archiving see this blog on technical execution, and this blog for business discussions.

SAP data management guide

SAP has a best practice document called “Data Management Guide for
SAP Business Suite” or “DVM guide”. This document is updated every quarter to half year. The publication location is bit hidden by SAP under their DVM (data volume management) service. In the bottom here go to SAP support and open the How-to-guides section. Or search on google with the term “Data Management Guide for SAP Business Suite” (you might end up with a bit older version). The guide is giving you options per large table to delete and/or archive data.

Common technical objects

Most common technical tables you will come across:

  • EDIDC, EDIDS, EDI40: idocs
  • DBTABLOG: table changes
  • BALHDR, BALDAT: application logging
  • SWW* (all that start with SWW): workflow tables
  • SYS_LOB…..$$: attachments (office attachments and/or DB storage of attachments and/or GOS, global object services attachments)

Detailed table analysis for functional tables: TAANA tool

For detailed analysis on functional tables the TAANA (table analysis) tool can be used. Simply start transaction TAANA.

Now create a table analysis variant by giving the table name and selection of the analysis variant:

TAANA start screen

The default variant will only do a record count. Some tables (like BKPF in this example) come with a predefined ARCHIVE variant. This is most useful option. If this option does not fit your need, you can also push the create Ad Hoc Report button and define your own variant.

Caution: with the ad hoc variant select your fields with care, since the analysis will count all combinations of fields you select. Never select table key fields

Results of TAANA are visible after the TAANA batch job is finished.

TAANA result

By running the proper TAANA analysis for a large functional table you get insight into the distribution per year, company code, plant, document type etc. This will help you also estimate the benefits of archiving a specific object.

For TAANA improvement on dynamic subfields, please check this blog.

If you run on HANA, you can also use SE16H for the table analysis.

Bug fix OSS note for TAANA:

Alternatives for TAANA

If you are running on HANA, you can also check using SE16H and SE16S.

From analysis to action

For the technical clean up read the special blog on this topic. For functional objects, you need to find the relation from the table to the functional data archiving object. This relation and how to find it is clearly explained in OSS note 2607963 – How to find the relationship between table and archive object.

SAP data volume management via SAP solution manager

SAP is offering option to report on data volume management via SAP solution manager directly or as a subsection in the EWA. Experience so far with this: too long in setup, too buggy. The methods described above are much, much faster and you get insight into a matter of hours. The DVM setup will take you hours to do and days/weeks to wait for results…. TAANA is way faster.

S4HANA upgrade sizing

This blog will explain options and tools you have for S/4HANA sizing for both new installations as well as upgrades.

Questions that will be answered are:

  • How can I execute S/4HANA sizing?
  • How do I execute the memory sizing for upgrading existing ECC system on non-HANA database to S/4HANA?
  • How do I execute CPU sizing for S/4HANA?
  • How do I execute disc storage sizing for S/4HANA?

Executing S/4HANA sizing

For both greenfield and existing ECC systems the SAP specific quicksizer for S/4HANA can be used: S4HANA quicksizer, then launch the tool from that page:

Quick sizer

For existing system you can pull data from existing system for greenfield you have to take either existing numbers from legacy system or input from project them.

The term quick sizing can be bit misleading. The tools is nowadays pretty advanced and requires quite some input.

How to fill the quicksizer is explained in OSS note 2467172 – How to size Fiori applications based on number of users.

Memory sizing for upgrading existing system

SAP has delivered a tool to help in sizing memory for S4HANA for upgrading an existing system. In your current ECC system you need to apply OSS note 1872170 – Business Suite on HANA and S/4HANA sizing report. This will deliver ABAP report /SDF/HDB_SIZING. You test this on development system and transport it to production for productive run.

S4HANA sizing program

Best to run this in background. You can then get the results in the spool of the batch job.

Sizing results

The results give an as good as possible estimation of memory sizing after the database conversion.

CPU sizing for S/4HANA

More details on CPU sizing can be found in OSS note 1793345 – Sizing for SAP Suite on HANA.

Disc space sizing for S/4HANA

Disc space storage sizing for S/4HANA can be found in extensive document on SAP site.

OSS notes

Before running the /SDF/HDB_SIZING program it is best to update it with the most recently available updates: 3104284 – HANA memory Sizing report – Advanced correction 15 or higher, 3149498 – HANA memory Sizing report – Advanced correction 16 and 3338309 – HANA memory Sizing report – Advanced correction 17.

Also apply this note: 3125526 – Report /SDF/HDB_SIZING_CLEAN cannot use dynamic variants.

S/4 HANA readiness check

SAP has released S4HANA readiness check 2.0. Please read this blog on the new tool version.

If you want to use old version, please read on.

This blog explains the new tool for SAP customers to prepare for S/4 HANA upgrade: S/4 HANA readiness check.

Questions that will be answered are:

  • What is the S/4 HANA readiness check?
  • How to execute it?
  • What results can I expect?

S/4 HANA readiness check

The S/4 HANA readiness check is a tool from SAP that can help you prepare for S/4 HANA upgrade. The tool is a web based online tool running in SAP cloud that is using 2 files with data from your system:

  1. Extract from your customer code
  2. Usage data of transactions measured in your system (based on ST03N data)

The outcome is online report with list of potential improvements in S/4 HANA that might be relevant for your business and list of potential issues when upgrading caused by custom code or by generic changes by SAP.

The end user guide of the tool can be found on the SAP site.

Execution of S/4 HANA readiness check

The main note for the readiness check is 2290622. This note describes that there 2 ways to run the check:

  1. Via solution manager
  2. Directly

The direct approach is the most easy. The exact steps are always updated in OSS note 2310438. Carefully implement all the prerequisite notes mentioned in this note.

After this is done 2 programs will be available.

Program SYCM_DOWNLOAD_REPOSITORY_INFO will download the ABAP custom developments.

Program SYCM_DOWNLOAD_REPOSITORY_INFO

The program will check if the where-used index is up to date. If not it will refer to OSS note 2234970. This note can be bit confusing. But basically what you need to do is run program SAPRSEUB in the background (and wait up to 2 days on larger system with many custom code!!).

Please note the following: As a prerequisite for SAP Note 2185390 or the program SYCM_DOWNLOAD_REPOSITORY_INFO, please start only the program SAPRSEUB! Do not start SAPRSEUC. If you use an MSSQL database, you must implement SAP Note 1554667 before starting SAPRSEUB; otherwise, database problems occur. More on ABAP where used index via SAPRSEUB see blog link.

The second program will capture analysis data: TMW_RC_DOWNLOAD_ANALYSIS_DATA.

Program TMW_RC_DOWNLOAD_ANALYSIS_DATA

You will have to start this program a few times. Every time it will launch a new batch job for each tick box you have selected.

Both of the programs will deliver you a zip file that you store on local PC or laptop.

These result files you upload in the SAP cloud part of the tool on the SAP support portal: https://launchpad.support.sap.com/#readiness.

Readiness tool import analysis

Now you have to wait until the analysis is done.

Result of the S/4 HANA readiness check tool

When the analysis is finished you first enter the dashboard:

Readiness tool result overview page

When zooming in you will reach the detailed screens with all the small details and relevant OSS note references:

Readiness tool details

Top right in the details list there is the button to create the results document. This is easier for sharing the results with management, since they typically don’t have an S user to logon to the tool.

Running S4HANA ABAP checks in your own system

With the remote ATC tool with special variant S4HANA Readiness you can run the ABAP checks in your onw system. Read this blog for more information.

New content for new S4HANA versions

With every new version of S4HANA (and its intermediate feature packs) SAP will update the simplification list and the corresponding OSS notes. This will also impact the analysis programs. OSS note 2399707 – Simplification Item Check lists down which note version you need to apply to your system to have the checks for the S4HANA version of your choice. For the newer notes you will have to use the TCI based OSS notes (see blog on notes tips & tricks).

If you have installed the latest TCI note, you also get a new program called /SDF/RC_START_CHECK. After start of this program you get this screen:

Readiness check program

You now can immediately see if you have new versions of OSS notes to apply to get most recent checks.

And after the run, you can use the button Application Log to see a more detailed result list on the simplification checks carried out in your system.

Custom ABAP code analysis

For a more detailed analysis on your custom ABAP code you can use the remote ATC tooling for a more detailed analysis. See this blog for details.