Job got hang due to Spool full

[Former Member]

Hello Experts,

Problem:

I found many long running background Jobs in SM37, then I checked in SM66 and found that all there are too many Jobs running on all Application Servers, and all WP were fully occupied.

Action column was showing "Insert" and Table "TSP01", then I checked Spool entries and I found that the Number of Spool entries have reached its Threshold value.

My Action:

Then I deleted old spools but still the Jobs was in active status. And the result was that the released jobs was getting delayed.

To overcome the situation I killed some of the processes by identifying the non critical Jobs via SM66. But even after 2 days those jobs that I have not killed were on the same status showing Action column "Insert" and Table "TSP01".

So Finally I decided to kill them also to make remaining WP's available.

My Question:

Is there any other way to recover this situation, as the System was Productio. and we are not allowed to increase spool count > 32,000 which is it's standard value.

Regards,

Amit Singh

[markus_doehr2 · Accepted solution]

There was a problem with certain kernel patches with the deletion date of spool request:

Note 1422843 - Wrong deletion date in spool request

Without a patched kernel nothing will be deleted since the date is put too far in front and hence neither RSPO0041 nor RSP01041 will delete the requests.

Check if your system is affected.

Markus

[Former Member · Accepted solution]

As per note 1422843, we should perform kernel upgrade on our systems. Kernel patch level is 315 with reference to note 1422843. You can see if its done on your system. If not please do it and then try it.

Thanks and Regards,

Kedar

[Former Member]

Thanks Experts for your replys!!

To avoid this situation we have set the Size to 99000, and we are keeping the last 7 days spool, so the issue is no longer exist in our system. As the job is already deleting the spools older then 7 days.

Regards,

Amit Singh

[Nibu]

Friend ,

> I found many long running background Jobs in SM37, then I checked in SM66 and found that all there are too many Jobs running on all Application Servers, and all WP were fully occupied.

>

It should not be the case . All workprocess fully occupied, means you need to work on to optimize distribution of work processes . Otherwise such issues will occur often, and you have to compromise on the performance.

Refer https://cw.sdn.sap.com/cw/docs/DOC-38580?treeid=DOC-8116 .

http://help.sap.com/saphelp_webas620/helpdata/EN/c4/3a5ef8505211d189550000e829fbbd/content.htm

> Is there any other way to recover this situation, as the System was Productio. and we are not allowed to increase spool count > 32,000 which is it's standard value.

>

Avoid such situation by the perfect optimization as mentioned above . Also configure Email alerts through CCMS config to get alerts on your SPool size and other critical stuffs so that you can be proactive .

Regards,

Nibu Antony

[Former Member]

You need to use standart reorganization jobs for deleting old spool requests ...

About your problem TSP01 are you doing the Temse check regulary using Sp12 t-code?

You need read more documentation about Basis administration ....

Note 48400 - Reorganization of TemSe and Spool

[Former Member]

Thanks Sergo,

Yes we are running standard reorganization jobs for deleting old spool requests, but we are keeping spools for 7 days, but because of more activity it suddenly gets full. I have read the note that you suggested.

My question was, is there any other way to recover this kind of problem instead of Killing the Process? As I have deleted the the spools and lots of space is now available in TSP01 table.

Regards,

Amit Singh