on 03-17-2009 10:30 AM
Dear all,
We have ECC 6.0 PRD system running on Windows/MSSQL 2005 platform with 16GB physical memory.
We have one customized report which runs on monthly basis and extracts data to a flat file.
Currentlt this job is failing due to below mentioned dump.
Runtime Error TSV_TNEW_PAGE_ALLOC_FAILED
Occurred on 03/17/2009 at 05:16:06
-
No storage space available for extending the internal table.
Below are current settings for parameter , we have QAS system with less hardware resource where this program runs with same set of parameters.
Below are PRD settings
zcsa/table_buffer_area
74336256
rtbb/buffer_length
20000
rsdb/cua/buffersize
121000
zcsa/presentation_buffer_area
16592896
abap/heap_area_dia
2000683008
abap/heap_area_nondia
2000683008
abap/heap_area_total
2000683008
abap/heaplimit
40894464
Please suggess what we need to change in order to execute this program successfully.
Regards,
RR
Hi All,
I have solved the isiue in strage way...I have deletd all the PSA and then my issue got resolved.
May be it will not work in all cases, try it ..
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Did you try increasing the abap/heaplimit ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Kalpesh,
Appreciate if you could advice whether there are any diverce affects of changing abap/heaplimit parameter. Only factor which is restricting us from changing this parameter is same value for this parameter in QA and PRD. Still if possible could you please advise effects of changing this parameter.
Markus,
Please find output below for sappfpar
Shared memory resource requirements estimated
================================================================
Total Nr of shared segments required.....: 40
Shared memory segment size required min..: 268435556 ( 256.0 MB)
Swap space requirements estimated
================================================
Shared memory....................: 823.8 MB
Processes........................: 24.0 MB
Extended Memory .................: 11009.0 MB
-
Total, minimum requirement.......: 11856.8 MB
Process local heaps, worst case..: 1907.3 MB
Total, worst case requirement....: 13764.2 MB
Errors detected..................: 0
Warnings detected................: 0
adjusting abap/heap limit solved our problem tempararily .. we went with dedicated apps server for processing memory intensive background jobs.
Note 552209 addresses the settings for the memory intensive programs for which available address space (memory) is still insufficient even after the parameter change.
Hi,
Did you check 'How to correct the error' in ST22 output? May be you can post here.
Hope this helps,
Manoj
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
hello Ganesh,
you have the actual data in prod as compared to qas.and the database size of prod will be very much as compared to qas
so when this report runs in prod,it has to extract a large amount of data as compared to qas which has less amount of data and thats why job is failing in prod.
Ask your developer to tune the report;there is no point in increasing the memory parameters for a single report
Rohit
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hai,
The Z program was not able to extend the Internal table to accommodate data into it.
This can happen when memory is not enough or less, if the program has some big select statements.
You can analyze the ABAP dump which says the amount of memory used at the time of termination and also the select statements where the termination occurred.
If this system is a test system than you can try increasing the memory parameter in concern and check.If this a Production system then ask the programmer to review the code of the Z program and correct if it has any expensive select statements.
Regards,
Yoganand.V
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yoganand,
Please find details for the termination time
The amount of storage space (in bytes) filled at termination time was:
Roll area...................... 11613680
Extended memory (EM)........... 382578336
Assigned memory (HEAP)......... 389701744
Short area..................... " "
Paging area.................... 24576
Maximum address space.......... " "
As mentioned earlier , this program runs successfully in QAS with even less hardware but not in PRD.
Please suggess what changes should we make to which parameters.
Program coding is already done and its running in QAS.
No difference in memory parameters in PRD and QAS , perhaps PRD has better hardware resource.
Regards,
RR
Hai,
You might have the better resource in PRD but the table from which you retrieve data will be larger in PRD than in QAS. This will cause this type of problems.
In your case since this is the PRD system you have be cautious in increasing the memory parameters in concern. Check SAP Note:20527.
It is always better to ask the ABAPer to review the code and break up the select statements to smaller one if you have some expensive SQL statements.
Also you can update the statistics of your DB using DB13.
Regards,
Yoganand.V
Markus,
As mentioned , we refreshed QA last week , i do not see considerable difference in PRD and QA data.
As per provided parameters which are present in PRD as well as QA , appreciate if you could provide your quick views/recommendations for change.
Regards,
RR
Edited by: ganesh rr on Mar 17, 2009 1:00 PM
Ok.
In this case you have "hit the limit". A process on a 32bit platform can allocate a max. of 2 GB memory (2^32 bytes). This memory is not only heap but also your buffers (e. g. abap/buffersize etc.). Those parameters may be different on your QA system (lower) because production is tuned for fewer swaps for programs (in ST02).
It seems to me, that all your buffers together are ~ 1.4 GB - then the program tries to allocate further than the additional available 600 MB and hence dump. This has nothing to do with the 16 GB installed, the system is unable to allocate that memory on a per process base.
You may be able to tune your system a bit - by iteratively changing buffer values - but a long term solution may be an upgrade to a 64bit platform.
You may also check if you can set the /3GB /USERVA option in boot.ini and reboot the system
see
Note 110172 - Windows: Transactions with large memory requirements
Note 990538 - WSAENOBUFS error on Windows
SAP recommends - since BASIS 6.20 - to no more use 32bit platforms:
Note 1280759 - SAP recommends only 64-Bit Windows for SAP Appl. Servers
If this is a new server (manufactured in the last 2 years) it's very likely, that it's able to run a 64bit Windows.
Markus
Markus,
Thanks for your views but we have 3GB /USERVA option already activated across our landscape.
we are considering option to upgrade to 64-bit platform , but currently we need to get this program run.
I would like to know what are the parameters this dump is affected and in relation with.
Appreciate if you could suggess some change in parameter after analysing
The amount of storage space (in bytes) filled at termination time was:
Roll area...................... 11613680
Extended memory (EM)........... 382578336
Assigned memory (HEAP)......... 389701744
Short area..................... " "
Paging area.................... 24576
Maximum address space.......... " "
Regards,
RR
> I would like to know what are the parameters this dump is affected and in relation with.
All your buffers and settings are affecting this. There is no solution as changing some parameters and you're done.
Please post the output of
sappfpar <yourprofile> check
And please:
put code tags around (means, mark your text and pres on the << >> button next to the underline button), this makes reading posts containing formatted numbers much easier. Thanx.
Markus
User | Count |
---|---|
90 | |
10 | |
10 | |
10 | |
7 | |
7 | |
6 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.