Ansicht
Dokumentation

04804 - ABAP SELECT Inner Joins + V4R5M0 - UPDATE

04804 - ABAP SELECT Inner Joins + V4R5M0 - UPDATE

General Data in Customer Master   RFUMSV00 - Advance Return for Tax on Sales/Purchases  
This documentation is copyright by SAP AG.
SAP E-Book

ABAP SELECT Inner Joins + V4R5M0 - UPDATE

Hi Brian,

What you are describing seems to be the same problem I had (still have ?) at
a customer here in Austria. Problems appeared after DB Fix Pack #9 (V4R5).
Runtime of some jobs increased from 15 minutes to several hours.
First IBM said that changing in the SQL Optimizer was the reason, but then
they pointed to the long SQL statements.
IBM made some PTF's which didn't not improve runtime very much.
After a very long time of waiting and disappointments, IBM found a
workaround in changing some SAP profile parameters.
new values:
*** rsdb/min_blocking_factor = 1
*** rsdb/max_blocking_factor = 1
Now those jobs have the same runtime (15 min) as they had before that
disaster.
What we don't know is, if the new profile values do affect other jobs (IBM
said that the real problem is not solved by now). We changed the values last
week and have no troubles at the moment.

Hope it helps
Regards
Kuni
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mag. Kunibert Redl
KREOSYS IT Solutions & Consulting
phone: +43 / 664 / 1526672
mailto:kunibert.redlZk...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



-----Ursprüngliche Nachricht-----
Von: Brian Zugel [mailto:Brian_ZugelZc...]
Gesendet: Freitag, 25. Jänner 2002 00:04
An: 'sap400Zm...'
Betreff: ABAP SELECT Inner Joins + V4R5M0 - UPDATE
Wichtigkeit: Hoch



All,

Thanks, all, who responded to my message. But my customer now has a huge
problem.

It seems there is a problem in V4R5, DB Fix Pack #11 with extremely large
SQL statements. We originally thought that the was a problem with the ABAP
SELECT...INNER JOIN statement and the SQL Optimizer, but we found out (from
IBM) that extremely large SQL statements are exceeding the size of their
internal table at the DB level. They constructed a PTF for us which broke
this SQL statement into pieces, then reconstructed before executing it in
the DB. Unfortunately, they are able to do this on a case-by-case level,
and each subsequent problem has to be addressed by IBM individually.

This, of course, is a dangerous situation, as we cannot know what statement
will halt at the DB level next.

I guess my question is: Is there another customer out there who is running
V4R5, DB Fix Pack #11, all current PTFs? We are a 3-tier productive client
(but I don't think this makes a difference). Our options are quite limited,
as it looks like we cannot backup to DB Fix Pack #10, or back to V4R4, for
that matter.

Thanks, all. I will keep you posted.

Brian Zugel
SAP America

---



All!

We have "Another Weird One" ...

We have a custom ABAP program which executes an SQL SELECT with an INNER
JOIN of the SD Delivery Header + Detail tables. This program worked fine
and ran for a little over 1 minute until our upgrade from V4R4 to V4R5 over
the weekend. Now when this program executes, this statement "hangs".

I checked to make sure we 1) deleted the SQL Packages, and 2) applied the
APAR for V4R5. I'm running an SQL Trace now. After this, I have *no* idea
what else to check for. So far, we've seen no other impact on the system
(fingers crossed).

Anyone else seen this kind of behavior before? If so, what did you do?
Please?

Thanks!

Brian Zugel
SAP America

Durban Tours - Südafrika Safari

General Data in Customer Master   BAL_S_LOG - Application Log: Log header data  
This documentation is copyright by SAP AG.

Length: 4241 Date: 20240621 Time: 070235     sap01-206 ( 3 ms )