How to release internal table`s allocate memory dynamic

[Former Member]

I was tunning a report with memory issues, so I try to release some internal table`s allocate memory but here is a problem

EX. if the free memory of an report is only 1000M free now, I have a internal table itab1 about 700M and need to copy part of the internal table in to other table so I do like this:

loop at itab1 where xx = xx.

append itab1 to itab2.

delete itab1.

endloop.

but I got a problem, if after the loop itab2 got more than 300M memory the report will get abord becourse of the allocate memory reach the limit.

I found even if itab1 have only 1 entries but the allocate memory will still be 700M.

how to make the internal table`s allocate memory reduce to actual memory.

Copy itab1 to a new table itab3 then free itab1 may work, but the report may crash when we copy itab1 to itab3 before we free itab1.

regards.

[yuri_ziryukin]

 but the report may crash when we copy itab1 to itab3 before we free itab1.
> 
> regards.

Well, I hope it will not crash at that point because of table sharing in kernel. When you say ITAB3 = ITAB1 no actual copying takes place. The reference of ITAB3 will simply point to the memory area of ITAB1.

What is interesting is the next step - FREE ITAB1. At this moment unsharing may take place.

But here is the list of all possible options (Many thanks to Hermann Gahm 😞

Optimizing internal table storage:

You cannot do this via a direct assignment to a new or intermediate internal table because of the "Copy on write" feature.

Copying the talbe line by line (e.g. append lines of) in a new table does not share it.

So this option you can use:

append lines of itab1 to itab3.
free itab1.

Another safe solution would be to export the table to shared memory, clear it, and import it again from shared memory.

Some releases have a so called u201Ccompact un-shareu201D which releases empty pages while un-sharing if the number of used rows is <= 25 % of the number of allocated rows. For that we need a u201Cpseudo changeu201D.

I am not sure of freeing the original table is considered by the kernel as "pseudo change": Maybe you would need to append/delete a line to the ITAB3 before the FREE ITAB1 statement in order that un-share takes place in a correct way.

To be on a safe side I'd suggest to use option 1 (append lines and free afterwards).

Regards,

Yuri

Edited by: Yuri Ziryukin on Feb 17, 2012 11:11 AM

[SuhaSaha]

Hello Yuri,

append lines of itab1 to itab3. free itab1.

But if we do this separate memory will be allocated to ITAB3 & this might cause the program to dump due to lack of memory. Please correct me if i'm wrong!

But then again as per the copy-on-write feature the unsharing will take place if we do this:

itab3 = itab1. FREE itab1.

By "unsharing" do we mean that ITAB3 will be allocated separate memory?

@OP:

Another safe solution would be to export the table to shared memory, clear it, and import it again from shared memory.

Before trying this you can also try to

- free the memory allocations of global variables(which are no longer required for the program execution, of course)

- check the memory consumption.

If this doesn't help use data clusters are mentioned by Yuri.

BR,

Suhas

PS: @OP; If Yuri & I sound like aliens(pun intended), please go through this: [Memory Consumption of Deep Data Objects |http://help.sap.com/abapdocu_702/en/abenmemory_consumption.htm]

[yuri_ziryukin]

Hello Yuri,
> But if we do this separate memory will be allocated to ITAB3 & this might cause the program to dump due to lack of memory. Please correct me if i'm wrong!

Of course it may dump. But... all above was assuming that the number of entries left in ITAB1 is much less than originally. In that case you just need additional few Kb/Mb.

> But then again as per the copy-on-write feature the unsharing will take place if we do this:
> 
itab3 = itab1. FREE itab1.
> By "unsharing" do we mean that ITAB3 will be allocated separate memory? 

I do not know exactly how the kernel will behave in this case. It might do un-sharing with allocating additional memory. But it may also simply delete the reference of ITAB1 to the same memory area and only leave ITAB3 pointing to the original memory of ITAB1 with the same size.

I don't know.

[Former Member]

You cannot do this via a direct assignment to a new or intermediate internal table because of the "Copy on write" feature.
Copying the talbe line by line (e.g. append lines of) in a new table does not share it.
So this option you can use:
append lines of itab1 to itab3.
free itab1.
Another safe solution would be to export the table to shared memory, clear it, and import it again from shared memory.

thx for your help, but I think the 1 option may dump the program when we append lines of itab1 to itab3.

it`s a good solution to Export the itab1 to the memory then import memory to itab1 again.

@

Before trying this you can also try to 
- free the memory allocations of global variables(which are no longer required for the program execution, of course)
- check the memory consumption.

I`ve try to free the memory allocations of global variables but still didn`t have enough memory.

so i try to make the program as a parallel job so the memory will not be in a so dangerous level.

@Abdullah Azzouni

Did you look into breaking ITAB1 before it reached 700M so that much memory will not be reserved for ITAB1? Maybe create ITAB1.1, ITAB1.2, ITAB1.3? You can store records in each based on a certain key field. 

if I separate itab1 into itab1.1 itab1.2 ... the logic will be more complex , i need to get all the entries in some table to be compared with.

really thanks every body!

[Former Member]

Did you look into breaking ITAB1 before it reached 700M so that much memory will not be reserved for ITAB1? Maybe create ITAB1.1, ITAB1.2, ITAB1.3? You can store records in each based on a certain key field.

[Former Member]

Instead of finding required records and storing them in other table why don't you try to delete unwanted records from original internal table. I think this should solve your problem.