Handling Spool & TemSe Inconsistencies in SAP R/3

SAP SPOOL & TEMSE

My Experience Handling Spool & TemSe Inconsistencies in SAP R/3

Understanding the Issue

In my R/3 system, I’ve occasionally run into inconsistencies in the spool database or the TemSe storage. These don’t appear randomly — they usually stem from actions like:

• Manual deletion of table entries in spool/TemSe tables

• Removing spool or TemSe objects directly from the file system

• Skipping or incorrectly performing consistency checks

• Report or transaction terminations

• Incorrectly executed client transports

Once inconsistencies occur, tracing the exact cause is often impossible unless you have a reproducible example.

What TemSe Stores

TemSe (Temporary Sequential Objects) is where SAP keeps short‑lived objects:

• Spool requests (names starting with Spool…)

• Job logs (JOBLG…)

• HR objects (HR…)

• Financial Accounting DTA objects (DTA…)

• Batch input logs (BDC…)

• Special objects like KONS… used by RSPO1043 (never delete these)

Each TemSe object has a header in TST01 and the actual object in either the file system or TST03. Spool requests also have entries in TSP01 and possibly TSP02.

Key Limitations

• TemSe cannot manage objects larger than 2 GB. Large spool orders must be split.

• TemSe is not an archiving system. For spool requests, use print list archiving instead.

Step 1: Check Memory Distribution

I use transaction SP12 to analyze TemSe memory allocation by age, client, and creator. This helps identify whether too many objects are stored indefinitely. In production, 30–40k objects is normal, but 100k+ is excessive.

Step 2: Delete Obsolete Objects

Here’s how I clean up:

• Spool requests → Transaction SPAD or reports RSPO0041/RSPO1041

• Job logs → Report RSBTCDEL

• HR objects → Notes 98995 & 385283

• Financial DTA objects → Transaction FDTA

• Batch input logs → Report RSBDCREO

⚠️ Avoid using RSTS0022 regularly — it deletes only TST01/TST03 entries and leaves TSP01/TSP02 inconsistent, which can cause serious spooler errors.

Step 3: Perform Consistency Checks

There are two types of checks, and both are required:

• TemSe consistency check → Transaction SP12 or report RSTS0020

• Spool consistency check → Transaction SPAD or reports RSPO0043/RSPO1043

Best practice: run checks twice with ~30 minutes between runs. Only inconsistencies appearing in both are genuine. RSPO1043 is especially useful since it deletes inconsistencies in the background and avoids temporary mismatches.

For batch input logs, I use RSBDCCKA and RSBDCCKT.

Scheduling Reports

To keep the system clean, I schedule these daily:

• RSPO1041 → Delete outdated spool requests

• RSBTCDEL → Delete old job logs

• RSPO1043, RSTS0024, RSTS0043 → Consistency checks

Lessons Learned from Practice

• Always validate before deleting: Temporary inconsistencies can appear if jobs are running.

• Never treat TemSe as archiving: It’s only for temporary storage.

• Network & memory tuning matters: Large spool requests or poor memory allocation can cause recurring issues.

• Consistency checks are safe: They’re read‑only, but I still run them in the background to avoid timeouts.

• Transport discipline: Incorrect client transports often trigger these problems, so I ensure transports are executed cleanly.