In your R/3 system, you have found an inconsistency in the spool database or in the database for temporary sequential objects (TemSe).
There can be many different causes. For example, inconsistencies can occur if you delete table entries manually from the spool and TemSe tables, delete spool and TemSe objects from the file system or do not carry out the consistency checks correctly. Terminations of the report and transactions also cause these inconsistencies. An incorrectly executed client transport can also lead to inconsistencies in the TemSe and spool.
Inconsistencies do not 'just appear'. They always have concrete causes. However, in many cases it is impossible to determine these causes after they have occurred.
A precise analysis is generally only possible if you have a reproducible example. The following sections will therefore only describe how to detect and eliminate inconsistencies.
Definition of the term TemSe:
Some objects, which are normally not retained in the system for a long time, are stored in the temporary sequential objects (TemSe) data storage.
These are:
1. Spool requests (TemSe name: Spool.......)
2. Job logs (TemSe name: JOBLG........)
3. Objects from other applications, for example Human Resources (TemSe name: HR.......), Financial Accounting - data medium exchange (TemSe name: DTA...)
4. An object beginning with KONS. This object is regularly used by report RSPO1043 and should never be deleted.
5. If the new log procedure is used for batch input, the batch input logs (TemSe Name: BDC....).
Each TemSe object consists of a header entry in table TST01 and the actual object. It can be stored in the file system (always the case for job logs) or in table TST03 (always for HR data). In the case of spool entries, you can use a parameter to decide whether the object is stored in the file system or in table TST03. Spool requests also have entries in table TSP01 (header entries for the spool request) and possibly in table TSP02 (header entries for possible output requests).
With data medium exchange objects from Financial Accounting, you can determine whether the object is stored in TST03 or in the file system for the relevant runs (in the latter case, there is no header entry in TST01 so the object is no longer a TemSe object. You can use transaction FDTA to manage the objects). For more information about DTA objects and how to manage them, refer to the section on data medium exchange in the Accounts Receivable and Accounts Payable Accounting chapters in the online documentation.
NOTE:
TemSe cannot manage any objects larger than 2 GB, indepent of whether the object is stored in the database or at file system level. Particularly with spool orders, you need to divide them into several smaller ones.
Since spool orders larger than 2 GB cannot practically be handled, this restriction will not be changed.
Solution
1. Check memory distribution in the TemSe data storage.
-> Tools -> Administration
-> Spool -> TemSe Administration (transaction SP12)
-> TemSe database -> Memory allocation
(as of Release 4.0A: -> Tools -> CCMS -> Spool -> TemSe Data Storage (transaction SP12))
-> TemSe Data Storage -> Memory allocation
Here, you can check the distribution of your TemSe objects by age, client and creator. In this context. Check whether the number of your TemSe objects is very large and whether many of your objects are stored with an unlimited retention period.
NOTE:
You cannot see the retention period of spool requests here: it is stored in table TSP01 and can be read from the header data for the spool request (transaction SP01).
NOTE THAT TEMSE IS NOT AN ARCHIVING SYSTEM
Furthermore, the maximum permitted number of spool requests is limited. Use print list archiving for spool requests.
The number of TemSe objects may vary considerably depending on the system. In some production systems, 30,000 or 40,000 objects would be quite normal (100,000 is still considered a lot). Always ensure that the number and memory allocation do not continually increase in your system.
2. Delete any objects that are no longer required.
A. Spool objects that are no longer required can be deleted using spool administration.
-> Tools -> Administration
-> Spool -> Spool administration (transaction SPAD)
-> Delete Old Spool Requests.
(as of Release 4.0A: -> Tools -> CCMS -> Spool -> Spool Administration
(transaction SPAD) -> Administration -> Delete Old Spool Requests
Only use this online option if there are not many spool requests in the system.
You can also execute report RSPO0041.
In the meantime, an improved version of this report (RSPO1041) has been created, which you can download from sapserv3.
B. Delete obsolete job logs via report RSBTCDEL.
C.If you want to delete HR objects.
D. Use transaction FDTA to delete DTA objects from Financials (a description on how to do this is available in the online documentation). Display the list and use the Delete pushbutton. Here, you can also check for possible inconsistencies (table REGUT contains a reference to TemSe object).
E. To delete batch input logs that are no longer needed, use the RSBDCREO report.
NOTE:
If retention times for jobs and spool requests differ, then spool request numbers are sometimes reused. This can lead to invalid allocations.
NOTE:
You can use the report RSTS0022 to delete old TemSe objects. Execute this report with care. Only execute it if you know precisely what you are deleting. This report does not take into account dependencies between TemSe tables and other tables, so inconsistencies may occur.
RSTS0022 SHOULD NEVER BE SCHEDULED ON A REGULAR BASIS
Only use the reports mentioned above for this. RSTS0022 can delete only the TemSe object and the header entry in TST01. It does not touch the entries in tables TSP01 and TSP02, which causes inconsistencies in the spooler. This can result in serious errors, for example, if a batch job tries to append a spool request to an existing one and no longer finds the TemSe object.
For this reason, run a consistency check on the spooler afterwards.
After you import the Support Packages mentioned in this, report RSTS0022 can no longer be carried out from transaction SP12.
3. Perform a consistency check on TemSe and the spooler.
IMPORTANT:
There are two fundamentally different consistency checks: the TemSe checks and consistency checks specific for the respective object type (spool, batch input, and so on).
Neither of the two checks contains the other check, which means you must use BOTH checks!
The TemSe consistency check checks the header entry in table TST01 and the corresponding object for ALL TemSe objects. The spool consistency check, for example, also checks the entries in tables TSP01 and TSP02, but only the spool objects are checked. For batch input logs.
Both consistency checks are client-independent.
You can execute both consistency checks online or in the background. There is no significant difference. In production systems, we recommend that you do not use the online solution since a timeout may occur. If necessary, increase the value for parameter rdisp/max_wprun_time.
Essentially, the consistency checks contain only read operations and therefore cannot cause any 'damage'. This is also true if other users are working in the system. However, in this case the system might display temporary inconsistencies, because someone is currently writing to the TemSe (this problem can also occur when you execute the check in the background).
These are not genuine inconsistencies and must not be deleted. We recommend that you run the consistency check twice before a possible delete run, with a 30 minute interval between checks (this is an approximate value only; the exact interval depends on the jobs that are currently running). Only the inconsistencies that are displayed in both checks are genuine inconsistencies.
NOTE:
The spool consistency check also includes write access to the database, because it deletes out-of-date write locks. The default is 30 minutes, which is insufficient for many background jobs. A background job that runs for longer during this time terminates with the error.
We therefore recommend that you choose a value that is sufficiently large (the new report RSPO1043 has a default value of 10,080 minutes, which corresponds to one week).
Since the value of 30 minutes for the online check cannot be changed, you should perform the consistency check in the background.
A. TemSe consistency check
1. Online:
Transaction SP12 (menu path see above)
-> TemSe Data Storage -> Consistency check
As a result, the system displays a list with the inconsistencies.
2. In the background:
Run report RSTS0020. As a result, the system displays a list of the inconsistencies found. However, you do not have the option of deleting them. Wait some time, then run the consistency check a second time and compare the results. Inconsistencies that are found in both logs are genuine inconsistencies and should be deleted. However, bear in mind that long-running jobs for the current day might also be listed as inconsistencies in both logs.
Inconsistencies in TemSe CANNOT be deleted in the background.
You have two options for deleting:
a.) Run the consistency check online, as described above.
Select the inconsistencies to be deleted and choose:
'Delete Selected Entries' or 'Delete all', to delete the entire list.
b.) If you have many TemSe objects, use report
RSTS0030. Call RSTS0030 online
for areas of TemSe in which the consistency check found inconsistent objects. Select both the TST01 and TST03 checks (you do not have to list all TemSe objects).
Once the report has generated the object list, delete either the seletced or all inconsistencies.
Note that you can only enter a generic name (that is, using wildcards), not however, as an area with upper and lower limits.
NOTE:
Since deleting inconsistencies only includes the header entry in table TST01 and the actual TemSe object, an inconsistent spool request is not fully deleted. The entries in the two spooler tables are retained. For this reason, you should always use the spool consistency check to delete inconsistent spool requests.
B. Spool consistency check
1. Online:
Transaction SPAD (menu path, see above)
-> Check consistency (as of Release 4.X: Administration ->
-> Consistency Check of Spool Database
2. In the background:
There are two reports for the spool consistency check: RSPO0043 and RSPO1043. RSPO0043 can only display inconsistencies in the background, similar to RSTS0020 in TemSe.
Deleting inconsistencies in the spooler:
Up to and including Release 3.1I, you can only delete inconsistencies online using transaction SPAD or by starting RSPO0043 online. Then, eliminate the inconsistencies using 'Delete Selected Entries' or 'Delete all'.
As of Release 4.0A, the new report RSPO1043 is delivered in the standard system. It has two essential advantages:
It can delete inconsistencies in the background and it only deletes inconsistencies if it has found them in repeated runs, that is, there is no danger of deleting temporary inconsistencies. We therefore recommend that you use this report only as of Release 4.0A and that you schedule it on a daily basis.
Report RSPO1043 might list its own spool request as inconsistent. You can ignore this entry.
C. Consistency check for batch input: Use the reports RSBDCCKA and RSBDCCKT.
Reset the profile parameter rdisp/max_wprun_time to its previous value when you have completed the online consistency check.
Which reports should be scheduled on a regular basis?
You should run the following reports daily:
RSPO0041 (or RSPO1041), RSBTCDEL: To delete outdated TemSe objects
RSPO1043, RSTS0024, and RSTS0043 for the consistency check