Performance in BBP_GET_STATUS_2 for SRM 7.02
Hello,
Some users are facing performance issues in BBP_GET_STATUS_2 after application of SP05 of SRM 7.02 or after note 1749585 is applied.
This performance issue is occurring due to the following code, that has been introduced in note 1749585:
* set the source rel indicator to space for PRALT item if basic item is
selected and vice versa.
LOOP AT it_hlp_refdata INTO ls_hlp_refdata.
CLEAR ls_sc_refupdate.
lv_exp_update = abap_false.
SELECT SINGLE expsv_item_type orig_guid FROM bbp_pdigp
INTO corresponding fields of ls_basic_alt
WHERE guid = ls_hlp_refdata-guid.
IF ls_basic_alt-expsv_item_type = ‘PRALT’.
SELECT SINGLE * FROM bbp_pdigp
INTO CORRESPONDING FIELDS OF ls_sc_refupdate
WHERE guid = ls_basic_alt-orig_guid.
IF ls_sc_refupdate IS NOT INITIAL.
ls_sc_refupdate-source_rel_ind = gc_clear_sourcing_flag.
lv_exp_update = abap_true.
ENDIF.
ELSE.
SELECT SINGLE * FROM bbp_pdigp
INTO CORRESPONDING FIELDS OF ls_sc_refupdate
WHERE orig_guid = ls_hlp_refdata-guid.
IF ls_sc_refupdate IS NOT INITIAL.
ls_sc_refupdate-source_rel_ind = gc_clear_sourcing_flag.
lv_exp_update = abap_true.
ENDIF.
ENDIF.
IF lv_exp_update = abap_true.
APPEND ls_sc_refupdate TO et_sc_refupdate.
ENDIF.
ENDLOOP.
There are many access to table BBP_PDIGP, which causes the performance issue when BBP_GET_STATUS_2 is executed.
You can check KBA 1934917 for more details on how to solve this issue.
Thanks for lot of info on status report
we get dump in this method method GET_SHARED_LOCK
GET_SHARED_LOCK is getting time out exception
BBP_BW_WRITE_SHP_TO_QUEUE.
Any advise please , Any help is appreciated
SRM 7 SP 13
Muthu
Hi Muthu,
I have never faced this kind of dump.
If this is a memory dump, you can read note 133909.
Regards,
Ricardo
Thanks Ricardo
please see the below dump every day when i run bbpget status job
Any help is appreciated
---------------------------------------------------------------------------------------------------
|Information on where terminated |
| Termination occurred in the ABAP program "CL_ODQ_TSN====================CP" - |
| in "GET_SHARED_LOCK". |
| The main program was "RSM13000 ". |
| |
| In the source code you have the termination point in line 51 |
| of the (Include) program "CL_ODQ_TSN====================CM002". |
| The program "CL_ODQ_TSN====================CP" was started in the update |
| system. |
| The termination is caused because exception "CX_ODQ_TIMEOUT" occurred in |
| procedure "GET_TID" "(METHOD)", but it was neither handled locally nor declared |
| in the RAISING clause of its signature. |
| |
| The procedure is in program "CL_ODQ_CORE_SERVICE===========CP "; its source |
| code begins in line |
| 1 of the (Include program "CL_ODQ_CORE_SERVICE===========CM00D ". |
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
|Source Code Extract |
----------------------------------------------------------------------------------------------------
|Line |SourceCde |
----------------------------------------------------------------------------------------------------
| 21| ASSIGN l_tsn TO <l_tsn>. |
| 22| WHEN OTHERS. |
| 23| RAISE EXCEPTION TYPE cx_odq_input_invalid. |
| 24| ENDCASE. |
| 25| l_retries = c_max_retries-shared. |
| 26| WHILE l_retries GT 0. |
| 27| SUBTRACT 1 FROM l_retries. |
| 28| CALL FUNCTION 'ENQUEUE_EODQ_TSN' |
| 29| EXPORTING |
| 30| mode_odq_e_tsn = c_enqmode-shared |
| 31| mode_odq_e_tsn_aspirant = c_enqmode-check_exclusive |
| 32| tsntype = i_tsntype |
| 33| tsn = <l_tsn> |
| 34|* X_TSNTYPE = ' ' |
| 35|* X_TSN = ' ' |
| 36| _scope = l_scope |
| 37|* _WAIT = ' ' |
| 38|* _COLLECT = ' ' |
| 39| EXCEPTIONS |
| 40| foreign_lock = 1 |
| 41| system_failure = 2 |
| 42| OTHERS = 3. |
| 43| IF sy-subrc EQ 0. |
| 44| <l_enqmode> = c_enqmode-shared. |
| 45| RETURN. |
| 46| ELSE. |
| 47| cl_odq_utilities=>wait( c_waittime-shared ). |
| 48| ENDIF. |
| 49| ENDWHILE. |
| 50| |
|>>>>>| RAISE EXCEPTION TYPE cx_odq_timeout. |
| 52| |
| 53| ENDMETHOD. |
----------------------------------------------------------------------------------------------------
Short text |
| An exception occurred that was not caught. |
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
|What happened? |
| The exception 'CX_ODQ_TIMEOUT' was raised, but it was not caught anywhere along |
| the call hierarchy. |
| |
| Since exceptions represent error situations and this error was not |
| adequately responded to, the running ABAP program |
| 'CL_ODQ_TSN====================CP' has to be |
| terminated. |
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
|What can you do? |
| Note down which actions and inputs caused the error. |
| |
| |
| To process the problem further, contact you SAP system |
| administrator. |
| |
| Using Transaction ST22 for ABAP Dump Analysis, you can look |
| at and manage termination messages, and you can also |
| keep them for a long time. |
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
|Error analysis |
| An exception occurred that is explained in detail below. |
| The exception, which is assigned to class 'CX_ODQ_TIMEOUT', was not caught in |
| procedure "GET_TID" "(METHOD)", nor was it propagated by a RAISING clause. |
| Since the caller of the procedure could not have anticipated that the |
| exception would occur, the current program is terminated. |
| The reason for the exception is: |
| No reply in the waiting period |
| |
----------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------
|How to correct the error |
| |
| If the error occures in a non-modified SAP program, you may be able to |
| find an interim solution in an SAP Note. |
| If you have access to SAP Notes, carry out a search with the following |
| keywords: |
| |
| "UNCAUGHT_EXCEPTION" "CX_ODQ_TIMEOUT" |
| "CL_ODQ_TSN====================CP" or "CL_ODQ_TSN====================CM002" |
| "GET_SHARED_LOCK" |
| |
| |
| If you cannot solve the problem yourself and want to send an error |
| notification to SAP, include the following information: |
| |
| 1. The description of the current problem (short dump) |
| |
| To save the description, choose "System->List->Save->Local File |
| (Unconverted)". |
| |
| 2. Corresponding system log |
| |
| Display the system log by calling transaction SM21. |
| Restrict the time interval to 10 minutes before and five minutes |
| after the short dump. Then choose "System->List->Save->Local File |
| (Unconverted)". |
| |
| 3. If the problem occurs in a problem of your own or a modified SAP |
| program: The source code of the program |
| In the editor, choose "Utilities->More |
| Utilities->Upload/Download->Download". |
| |
| 4. Details about the conditions under which the error occurred or which |
| actions and input led to the error. |
| |
| The exception must either be prevented, caught within proedure |
| "GET_TID" "(METHOD)", or its possible occurrence must be declared in the |
| RAISING clause of the procedure. |
| To prevent the exception, note the following:
Regards
Muthu
Hi Muthu,
This dump is liked to basis area. I don't use to work on it, only in SRM application itself.
It seems that there was an enqueue table overflow which occured at the affected time.
You can see transaction SM21 for further details.
Maybe increasing the size of enqueue table would help, but I really do not work on this area.
I cannot help you too much.
Regards,
Ricardo
Thanks Ricardo. i will escalate to Basis team.
Very Helpful, thanks Ricardo 🙂