2212293 - PXA_NO_FREE_SPACE occurs when executing large ABAP programs

Prévia do material em texto

22122932020-05-04
2212293 - PXA_NO_FREE_SPACE occurs when 
executing large ABAP programs.
Version 7 Type SAP Knowledge Base Article
Language English Master Language English
Release Status Released to Customer Category Problem
Component BC-ABA-LA (Syntax, Compiler, Runtime) Released On 16.12.2019
Please find the original document at https://launchpad.support.sap.com/#/notes/2212293
Symptom
The following Function Groups (load size) are very large, PXA_NO_FREE_SPACE dump could happen on 
them frequently:
when any Function Modules of these Function Groups are called•
when any Forms / Subroutines of these function groups are called•
1. Function Group KAUP - main program SAPLKAUP:
FM CO_DOCUMENT_INFO
FM K_DOCUMENT_UPDATE
FM K_PARKED_DOCUMENT_DELETE
2. Function Group GLIU - main program SAPLGLIU:
FM G_CLEAR_TIMESTAMP
FM G_ENQ_EXCLUSIVE_FOR_BW_EXTR
FM G_ENQ_SHARED_FOR_BW_EXTR
FM G_EXIT_FOR_DELTA_EXTRACTOR
FM G_INSERT_SI_AND_ADD_TO_TT
FM G_INSERT_TABLE
FM G_RESET_TOTALS
FM G_SET_TIMESTAMP
FM G_UPDATE_TOTALS
The issue may start to happen since kernel 741 suddenly.
Example 1)
PXA_NO_FREE_SPACE dump occurs in ABAP program "SAPLKAIS". The termination occurs in form 
"CALL_USER_EXIT".
1 of© 2020 SAP SE or an SAP affiliate company. All rights reserved 5
https://launchpad.support.sap.com/#/notes/2212293
22122932020-05-04
The function module 'CO_DOCUMENT_INFO' belongs to Function group KAUP - main program 
SAPLKAUP. If you check the generation limits of program SAPLKAUP, you could see that the load size 
is larger than before.
For example, about 1MB before kernel 741, about 10MB bytes on kernel 741, about 5MB on kernel 742.
Example 2)
“Information on where terminated” section of the dump:
The termination occurred in ABAP program "SAPLKKCK", in "CO_OBJECT_UPDATE_ON_DB". The 
main program was "SAPLCOIH". 
In the source code, the termination point is in line 426 of (Include) program "LKKCKF08".
"Source Code Extract" section of the dump：
422 PERFORM get_timestamp IN PROGRAM saplkaup IF FOUND <<<<It is calling the form of program 
2 of© 2020 SAP SE or an SAP affiliate company. All rights reserved 5
22122932020-05-04
SAPLKAUP 
423 CHANGING 
424 ld_timestmp. 
425 
>>>>> IF NOT p_co_object-status-cosxa_oldkeys_valid IS INITIAL 
427 OR NOT p_co_object-status-cosxa_old_valid IS INITIAL. 
428 * Alte Key-Daten wurden schon gelesen 
429 * Aufteilung in INS-, UPD- und DEL-Tabellen vornehmen 
430 * und in entsprechende GD_UPDDATA Tabellen einstellen
[Other common dumps will be listed here]
[1]Dump could happen on MIGO, program "LBUAVC_DATABASE_ACCESSF01", calling FM 
G_UPDATE_TOTALS (Function Group GLIU).
"Information on where terminated" section of the dump: 
---------------------------------------------------------------------------------------------------- 
| The termination occurred in ABAP program "SAPLBUAVC_DATABASE_ACCESS", in 
| "UPDATE_FISL". The main program 
| was "SAPLMIGO". 
| 
| In the source code, the termination point is in line 181 of (Include) 
| program "LBUAVC_DATABASE_ACCESSF01". 
----------------------------------------------------------------------------------------------------
[2]Dump could happen on FB1D, program "LBWFIPF01", calling FM G_ENQ_SHARED_FOR_BW_EXTR 
(Function Group GLIU).
"Information on where terminated" section of the dump: 
---------------------------------------------------------------------------------------------------- 
| The termination occurred in ABAP program "SAPLBWFIP", in "INSERT_BWFI_AEDAT" 
| The main program was "RSM13000". 
| 
| In the source code, the termination point is in line 18 of (Include) 
| program "LBUAVC_DATABASE_ACCESSF01". 
| The program "SAPLBWFIP" was started in the update system. 
----------------------------------------------------------------------------------------------------
[3]Dump could happen on MB1A, program "LGIVAF50", calling FM G_UPDATE_TOTALS (Function Group 
GLIU).
"Information on where terminated" section of the dump: 
---------------------------------------------------------------------------------------------------- 
| The termination occurred in ABAP program "SAPLGIVA", in "NEW_UPDATE_GLT0" 
| The main program was "RSM13000". 
| 
| In the source code, the termination point is in line 147 of (Include) 
| program "LGIVAF50". 
| The program "SAPLGIVA" was started in the update system. 
----------------------------------------------------------------------------------------------------
[4]Dump could happen on ME21N, program "LKAINU01", calling FM K_DOCUMENT_UPDATE (Function 
Group KAUP).
3 of© 2020 SAP SE or an SAP affiliate company. All rights reserved 5
22122932020-05-04
"Information on where terminated" section of the dump: 
---------------------------------------------------------------------------------------------------- 
| The termination occurred in ABAP program "SAPLKAIN", in "K_COEP_INSERT" 
| The main program was "RSM13000". 
| 
| In the source code, the termination point is in line 34 of (Include) 
| program "LKAINU01". 
| The program "SAPLKAIN" was started in the update system. 
----------------------------------------------------------------------------------------------------
Environment
The problem mainly happens on a system that kernel release >= 7.41
Reproducing the Issue
There are no specific recreation steps. You may observe the dump in different transactions. The dump will 
occur if the ABAP loads of
programs or functions modules etc. are large and cannot be loaded successfully.
Cause
Starting with 741 kernel, the ABAP compiler may produce slightly larger ABAP loads by putting some 
information into the ABAP loads which
is then used to improve the performance of OpenSQL statements at runtime. For some programs, however, it 
is observed that the
load size increases drastically because of this optimization. When there is a high number of swaps per day 
which leads to a fragmentation
of the buffer, the large loads can’t be loaded because no free block which is large enough can be found.
Resolution
If you are using kernel 741：•
Please use the kernel 742 as downward-compatible kernel. In the kernel 742, the ABAP compiler 
has been changed again to avoid the creation of such extremely large program loads.
•
If the dump still happen after upgrading to kernel 742, please increase abap/buffersize until 
dump stops. (Based on past incidents, 1,2GB ~ 1,5GB is the suggested starting value)
•
If you are already using kernel 742 or higher：•
Please increase abap/buffersize until dump stops. (Based on past incidents, 1,2GB ~ 1,5GB is 
the suggested starting value)
•
Keywords
resource shortage, PXA storage space, Kernel, ABAP, program, swap, memory, SAPLKAIS, 
PXA_NO_FREE_SPACE, CALL_USER_EXIT, CO_DOCUMENT_INFO, SAPLKAUP, SAPLGLIU, 
GLIUG_INSERT_TABLE, G_ENQ_SHARED_FOR_BW_EXTR, G_UPDATE_TOTALS
4 of© 2020 SAP SE or an SAP affiliate company. All rights reserved 5
22122932020-05-04
Products
SAP NetWeaver 7.4
Terms of use | Copyright | Trademark | Legal Disclosure | Privacy
5 of© 2020 SAP SE or an SAP affiliate company. All rights reserved 5
https://support.sap.com/support-programs-services/about/terms-of-use.html
http://www.sap.com/corporate-en/about/legal/copyright/index.html
http://www.sap.com/corporate-en/about/legal/copyright/index.html#trademark
http://www.sap.com/corporate-en/about/legal/impressum.html
http://www.sap.com/corporate-en/about/legal/privacy.html