Skip to Content
-1

Long running job in S/4 Hana migrated system

Jun 28, 2017 at 11:32 AM

118

avatar image

Hi

There are a few data intensive jobs which ran for 30 minutes on a traditional database is now running for more than +9 hours in HANA Database 1605. The programs are both ATC check cleared. Is there any specific process that need to follow. AMDP usage is also not helping out the cause.

Is it a basis related issue, work process error something. How will I be sure?

Do we need to run a specific index generating job upon migration to HANA Database?

Regards

Diganto

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

2 Answers

Best Answer
Matthew Billingham
Jun 29, 2017 at 07:06 AM
1

Passing ATC check does not guarantee that a program is well written. That is why peer review of source code by another programmer is a good thing.

When we upgraded out BW system to HANA, we found many places with less than optimal coding (in the area of selects), where you get away with in Oracle (it's not as fast as it could be, but the overall runtime is ok), that cause huge issues in HANA.

You need to run performance traces on the jobs and find out where the database queries are taking a long time. Then fix them. Typically, numerous select singles (even keyed fully!), FOR ALL ENTRIES selects instead of INNER JOINS. There is an OSS note concerning FOR ALL ENTRIES, and a way of adding hints to the SELECT to improve performance where you have to have them.

Show 7 Share
10 |10000 characters needed characters left characters exceeded

Hi Matt

Understood your point of view, but here I have a job which ran for 14k seconds is now running for >70k seconds on a same source code, samd data and the same variant. This variation is alarming and is occurring certainly not just due to the select queries. My question is on which process/note can I refer to drill down to the cause. I traced SQLM, it's tracing long runtime database hits. How do we not know whether this is a Database hardware issue

0

"Certainly not due to select queries"? How have you established that? Your SQLM trace "tracing long runtime database hits" is exactly saying that it is due to select queries. This is not a point of view, it is direct relevant experience. These were jobs that under Oracle were taking 2 hours, and under HANA were taking 12, 15 even 20 hours. Same code, same data, same variant.

Root cause: not-optimal coding of select queries. And I've given you the two main causative fators.

Ergo. Get someone who understands ABAP performance and get your code tuned. If all is optimal and you still have performance issues, then you can investigate other causes.

0

Dear Matt

The two jobs runs that I mentioned both ran in HANA Database, generated the same spool, then still had a variance of >60 k seconds. I had already identified the pain points with the code. But this much variance for the same job running on different dates will not help measure optimization.

0

So, contrary to what you initially posted, you are now claiming that the same report, with the same variant and the same data running on HANA both times has a variance of more than 16 hours?

Your original post was quite clear: why is the same report with the same data with the same variant taking longer on HANA than it did on Oracle. Why are you now changing the criteria? What is it that you want to know? Are you just wanting to argue the theory, or are you wanting to fix your problem.

If this is another question, with different criteria, then you should open a new question.

0

I am not changing questions, in Oracle this program ran not more than 30 minutes, and in HANA, runtime is different on different dates depending on the mood of the system. The purpose of this blog is to identify the mood of the system other than just the ABAP optimizations.

0

Well it's certainly additional (important) information.

Before: HANA/ORACLE runtimes wildly different. After: ORACLE 30 minutes. Different runs in HANA different timings.

Please do try to be clear when you ask a question (and it's a question, not a blog) - otherwise you make hard for anyone to help you.

Two questions.

1. Have you carried out the optimisations? That should be your first step.

2. Are these the timings? 1800 seconds for Oracle, 14'000 seconds and 60'000 seconds for HANA?

Problem solving is often a step-by-step-process. If there's more than one issue affecting things, deal with them one at a time. Don't try to resolve all the issues at once.

You do step 1 first, since 1'800 to 14'000 is already indicative of sub-optimal programming. So do that, then if you still have wildly differing times with exactly the same data on HANA (e.g. 200 seconds / 800 seconds, come back and tell us.

0

Just AMDP push down were worked out at the data intensive parts of the code. From 72k, the program has run down to 7600 seconds.

Further push down is under way.

Thanks for helpful inputs.

Regards

Diganto

0
Shubhamoy Dey
Jun 28, 2017 at 12:16 PM
0

Hi Diganto,

The problem that you described, can have the root cause from several layers of the newly installed HANA system(1605). Implementation of AMDP does not necessarily optimizes the performance each time. It is encouraged, when you have a large retrieval:filter ratio + few database intrinsic operations , which otherwise would have to be done via iteration, imperative logic, etc etc..

At this moment of time, you can take the ABAP trace and SQLM trace and get the idea about the internal processing.

Cheers,

Shubhamoy

Show 2 Share
10 |10000 characters needed characters left characters exceeded

Hi Shubhamoy

You had partially answered my question but other than the trace and optimization activity, should it not that the program would had run faster after the migration to S/4 from traditional Oracle database. We are seeing quite many runtime variations of the same job running on different dates.

I was wondering whether the delay is occurring due to some work process lock at a particular server.

Are there any defined steps to determine the server state during a program run.

Regards

Diganto Goswami

0

Hello Diganto,

You are right, it is quite expected that jobs running in Oracle should run faster on HANA. But, After migrating to HANA and optimizing the programs to extract the benefits that HANA provides, requires some specific ABAP workout + Basis workout. Without the ABAP workout you cannot bet that it would run faster in HANA. There are several parameters that are considered for that faster running.

From the ABAP prespective, I can say that, the jobs that are talking too long to finish in S/4 , you can trace that out. If you find any glitch, you can then move ahead with ABAP on HANA - Consulting.

For your specific question on work process lock, I believe you can check with an BASIS guy/ or you might want to post your query in BASIS community, if there is any :)

Also, Please have look at the below docs :

https://www.sap.com/documents/2015/07/9c5c8fbd-5b7c-0010-82c7-eda71af511fa.html#

https://blogs.sap.com/2016/02/08/migration-to-sap-hana-best-practices/

Cheers

2