1

We are comparing performance between a classic R/3 and a S/4 system, and simple selects from standard function modules ( e.g. selecting records from an IDoc table ) look different in S/4.

The most interesting things are those:

  • The S/4 brings less performance, than R/3 ( with same amount of records stored in the db table )
  • When we see ( in this case in a FOR ALL ENTRIES A.K.A. FAE ) WHERE STATUS = 69 or FLAG ="X" inside the R/3, we see this prefixed with an N, like FLAG = N"X"....

I assume, this stands for negation, BUT the code says clearly EQUALS. And because the performance is so bad compared to S/4, I assumed, the S/4 somehow sometimes cannot deal with FAE and one of the side-effects is, to negate the where clause on the fields of the FAE-related source-table...

What does this N stand for ?

Suncatcher
  • 10,355
  • 10
  • 52
  • 90
icbytes
  • 1,831
  • 1
  • 17
  • 27
  • 1
    R/3 and S/4 have the same performance. What can be different is the system architecture (CPU, RAM, etc.) and database system (HANA, etc.) S/4 is always using HANA. Concerning HANA SQL syntax `N`, see [Data Types](https://help.sap.com/viewer/product/SAP_HANA_PLATFORM/latest/en-US?q=Data%20Types) – Sandra Rossi Mar 03 '22 at 07:11
  • HANA is indeed not that good with `FOR ALL ENTRIES` queries. In order to really play to its strengths, you need to combine them with the previous query providing the `FOR ALL ENTRIES` by turning them into a JOIN. But in a SAP standard function module, this is usually not an option. However, when the problem is serious enough, you might be able to convince SAP to do that optimization for you in form of a note by sending them a support ticket. – Philipp Mar 10 '22 at 13:01
  • What DB are you using on R3? – András Mar 15 '22 at 08:19

1 Answers1

1

FLAG=N"X"

It does not mean negation, it means the value is sent down to HANA as a Unicode hardcoded value (NCHAR).

S4 performance

This was not directly asked, but I think it is imporant to also answer. There can be several reasons why R3 is sometimes faster:

  • In R3 you have Oracle or DB2 (DB6) and the SELECT is using the perfect index and the data is in the cache
  • You are comparing SELECTs on a table that was transparent in R3, but is a compatibility view in S4, like MARC or ANLC
  • Your S4 hardware is slower than R3. It is quite common, new CPUs with very high core count run the individual cores slower than a decade ago. So the total throughput is much higher, but each individual report and transaction runs slower

In my experience these are the typical cases where S4 is slower than R3.

András
  • 1,326
  • 4
  • 16
  • 26