dump TSV_TNEW_PAGE_ALLOC_FAILED

[Former Member]

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

[yugandhery]

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 ..

[Former Member]

Did you try increasing the abap/heaplimit ?

[Former Member]

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.

[Former Member]

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

[markus_doehr2]

Sorry, I gave you the wrong command, please use

sappfpar check pf=<profile>

Markus

[Former Member]

Thanks to all increse abap.heaplimit and OS swap space did the trick

[former_member207153]

Ganesh

Could you adv , what value that currently you adjust for abap.heaplimit and OS Swap space?

[Former Member]

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.

[sabbir_ahmed6]

Dear All,

I have faced the same problem in my 64bit Sun Solaris Server. I have tried with increasing the following parameters in profile:

Ztta/roll_area

Abap/heap_area_total

Abap/heap_area_dia

Abap/heap_area_nondia

And the problem is solved.

Thank to all.

Razib

[MPGraziano]

This is all well, but I would really like to know what you all have increase those params to..

we are in a difficult situation as we have just encountered this issue in BI 7.0 running on win 2003 sql 2005 64bit OS

please advise asap so that we can make adjustments to try it out

maria

[Former Member]

Hi,

Did you check 'How to correct the error' in ST22 output? May be you can post here.

Hope this helps,

Manoj

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

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

[Former Member]

Hi all,

We have refreshed our QAS with PRD data last week and have aproximately same data.

[Former Member]

Job is getting executed in background , we have gone through note 20527 earlier and

both abap/heap_area_total or abap/heap_area_nondia parameters are same in PRD and QAS.

In fact all parameters are same in PRD and QAS ... with same size of data.???

[markus_doehr2]

What are the values of the parameters

abap/heap_area_dia

abap/heap_area_nondia

abap/heap_area_total

And also consider, that in QA may be fewer data.

Markus

[Former Member]

abap/heap_area_dia

2000683008

abap/heap_area_nondia

2000683008

abap/heap_area_total

2000683008

[Former Member]

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

[markus_doehr2]

Is this a 32bit or 64bit system?

Markus

[Former Member]

32-bit MSSQL 2005 platform

[markus_doehr2]

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

[Former Member]

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

[markus_doehr2]

> 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