Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

TSV_TNEW_BLOCKS_NO_ROLL_MEMORY or TSV_TNEW_PAGE_ALLOC_FAILED

Former Member
0 Kudos

Hi;

Our SAP servers run on Windows Server 2003 Enterprise x64 Edition and Mssql 2005 64 bit. They have 16 Gb Ram and 42 Gb virtual memory.

I have to make system measurement by using tcode USMM. Although there is no problem when i run USMM on our test and productive server, i get a short dump TSV_TNEW_BLOCKS_NO_ROLL_MEMORY or TSV_TNEW_PAGE_ALLOC_FAILED when i run USMM on our development server. I have checked profile parameters. They seem same on all servers. We get the dump only at our development server.

We have upgraded our production and test systems after that we have made system copy from production to development. Only difference is that.

The details for dump is below:

Runtime Errors TSV_TNEW_BLOCKS_NO_ROLL_MEMORY

Date and Time 27.01.2011 10:53:44

Short text

No roll storage space of length 1765392 available for internal storage.

What happened?

Each transaction requires some main memory space to process

application data. If the operating system cannot provide any more

space, the transaction is terminated.

Error analysis

The internal table "\PROGRAM=RSUVM000\FORM=INIT_SYSTEM_DATA\DATA=SYSTEM_DATA[]"

could not be enlarged further.

Memory location: "Session memory"

You attempted to extend the data structure for the management of the

memory blocks for table "\PROGRAM=RSUVM000\FORM=INIT_SYSTEM_DATA\DATA=SYSTEM_DA

TA[]". However, the 1765392 bytes required for

this were no longer available in the specified memory area.

The amount of memory requested is no longer available.

-


Runtime Errors TSV_TNEW_PAGE_ALLOC_FAILED

Date and Time 27.01.2011 10:11:11

Short text

No more storage space available for extending an internal table.

What happened?

You attempted to extend an internal table, but the required space was

not available.

We have observed that a disp+work.exe is rising to 4 Gb after that system gives the dump.

Is there any advice to solve the problem?

Best regards

Noyan

1 ACCEPTED SOLUTION

former_member195402
Active Contributor
0 Kudos

Hi Noyan,

it seems that you get extremely more data on your development system. Internal Table SYSTEM_DATA in USMM is built using FM VCM_GET_MEAS_DATA, which calls several following FMs. E.g. one is to get data of background jobs. If you don't reorganize your data on development system, they may be available from the beginning.

Please check, which fm call in VCM_GET_MEAS_DATA causes your problem!

Regards,

Klaus

6 REPLIES 6

former_member195402
Active Contributor
0 Kudos

Hi Noyan,

it seems that you get extremely more data on your development system. Internal Table SYSTEM_DATA in USMM is built using FM VCM_GET_MEAS_DATA, which calls several following FMs. E.g. one is to get data of background jobs. If you don't reorganize your data on development system, they may be available from the beginning.

Please check, which fm call in VCM_GET_MEAS_DATA causes your problem!

Regards,

Klaus

0 Kudos

Hi Klaus;

Thanks for your interest.

Yes you are right. System gives the dump for INT_VCM_GET_MEAS_RESULTS which is called by VCM_GET_MEAS_DATA.

Information on where terminated

Termination occurred in the ABAP program "SAPLSSYM" - in

"INT_VCM_GET_MEAS_RESULTS".

The main program was "RSUVM000 ".

In the source code you have the termination point in line 464

of the (Include) program "LSSYMU03".

Could you please advise us that how we can solve the problem?

Best regards

Noyan

0 Kudos

Hi Noyan,

FM INT_VCM_GET_MEAS_RESULTS retrieves data from tables

- TUCON

- TUREP (also from client '000')

- TUMSG

- TUMRES

You can compare those tables in SE16 (count entries) on development and other systems. Also you can call this FM iin test mode from SE37 with break-points on every select, that you can see, where your internal table is growing extremely. You may also do this on your Q system in parallel mode to compare it.

If you got the differences you should examine the regarding tables. Maybe there is a missing reorg job on your development system, or you need more memory (higher profile parameters) on this system for this action.

Regards,

Klaus

0 Kudos

Hi Klaus;

You are right again. TUMRES table has 35,494,963 records in development system. Can we reorganize it by se11 or shoudl we run a report?

Best regards

Noyan

0 Kudos

Hi Noyan,

I found SAP note 1525956 which describes your problem.

Look, if you can use it. otherwise you should contact SAP and send a message with your problem with a reference to this note.

Sorry, I can't give an advice how to solve your problem, because I don't know anything about the background of those table entries.

Regards,

Klaus

0 Kudos

Hi Klaus;

Thanks for your help. We have applied the note 1525956, then we run database utility for table TUMRES (Delete data - Activate and adjust database).

Everything seems ok now.

Best regards

Noyan