on 12-19-2007 10:48 AM
Dear Friends,
Why TST03 table size in increasing on daily basis and how come we restrict it?
Thanks,
Rd,
Sachin
Hi,
Unfortunateley there is much more than spool entries in the infamous TST03 table.
When people use the HR module, the data to interconnect the Payroll and the FI module is stored in TST03 and it can be huge.
The standard programs can only purge the data for payroll tests but not the real one.
It turns out that one should use archiving (from transaction SARA) to actually purge this data !
One other common problem is also when users change the default spool retention date and put it in year 9999.
In that case RSPO141 does not delete these spool entries.
TST03 is really often a "painful" table !
Regards,
Olivier
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I believe a database reorg (exp/import) will also help to free fragmented space for this table.
Cheers,
Nisch
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks,
But which job are relevant for that? I know ESS user (HR) is responsible i am killing this job if it take more time.
Can please suggest other job or some thing else.
Thanks,
Regards,
Sachin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sachin,
this is what I have done to reduce a bit the size of the table:
. Remove of inconsistencies displayed via SP12.
. Analyse of the memory allocation to check the memory distribution in the Temse Database
. Deletion of HR objects beyond their validity date with report RPUTSR00.
It did not make a lot but still is better than nothing.
Rgds,
Loukas
Hello,
Droping and re-creating the table not at all a reasonable approach and you should not do in production environment.
Analyze properly and increase the execution frequency of
the house keeping Job.
Best Regards,
Srinivas Darlapudi
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
thanks,
but i execute sp12 -> consistency check-.delete all on daily then also it is not decreasing. So i drop that table in SE14 and recreate then size goes to zero. But my question is why it is increases and how to restrict.
reply me.
rd,
sachin
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You delete the table using SE14? Be careful with that - maybe the data is still needed.
TST03 is the binary data of all spool work processes, almost each batch job creates a spool request, all output that is printed is in the spool request.
If you blindly delete using SE14 you may delete important printouts (e. g. invoices), that could not be printed yet because of a printer problem (no more paper) etc.
Additionally people may need the spool request to download data or to check, if batch jobs did run fine. If you delete everything once in a while they may not be able to do so.
Thus - use the program RSPO1041, it will take care of that.
Markus
Run job RSPO1041 as maintenance to delete old spool jobs that have been printed.
Markus
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Follow the indications on the note
706478 Preventing Basis tables from increasing considerably
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
23 | |
11 | |
9 | |
8 | |
5 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.