TemSe is basically a data store that is used for storing temporary sequential data/objects.
Such data/objects are not required to be held permanently in the system. A few TemSe objects/data among others are stated below:
Spool Data
Job Logs
Objects from HR, Fin, etc. applications
Storage Location for TemSe:
Each TemSe object has a header entry in table TST01 and the actual object, which can be stored on the file system (OS Level-performance advantage) or table TST03 (DB Level- backup by default for being a part of DB).
Let’s look how the different objects are preferred to be stored generally.
Spool Data: By default stored in TST03, along with entries in TSP01 (for Spool Requests) and TSP02 (for Output Requests). However, we do have an option of selecting the storage of these objects that can be defined through the profile parameter: rspo/store_location (db value: stored in table TST03, G value: stored in global dictionary in OS)
Job Logs: Stored in File system on OS Level.
HR Objects, etc.: Stored in TST03
Managing TemSe Objects:
TemSe is not an archiving system.
And so we need to always make sure that the number of objects and memory allocation do not increase in the system. We need to delete objects that are no longer required. Deletion can be done as follows:
i. Deleting spool requests either by SPAD (if less in number) or else running report RSPO0041
ii. Deleting job logs through report RSBTCDEL. (Deleting job logs directly might lead to inconsistencies. Instead, it is better to delete the batch jobs responsible for the same)
iii. If we are very sure about the TemSe objects that need to be deleted, we can run the report RSTS0022. However, this can lead to inconsistencies while deleting spool objects as this report clears entries only in table TST01 and not the corresponding entries in TSP01/TSP02. Hence, after using this report, best practice is to perform consistency checks on Spooler and TemSe.
In case of spool requests, print list archiving is possible though.
Also, TemSe objects have a retention period. We need to check if any objects have unlimited retention period. This Expiry Time can be checked as below:
SP12 t-code, then from the menu bar selects Gotoà TemSe Contents.
This screen will get us to all the matching objects. Thereafter, double clicking any row i.e. particular object name gives us all the details about the object (e.g. Object Name, Creator, Creation Date, Last Changed on, Expiry Date, Where the object is stored, its record type, size, client, etc.)
TemSe cannot manage objects that require more than 2 GB storage space: This is irrespective of the storage location used i.e. DB or OS. Also, the total number of objects in TemSe varies from 30k to 40k generally.
We can check the memory allocation for TemSe through SP12 T-Code.
From the menu bar, we need to select TemSe Data StorageàMemory allocation.
This gives us an overview of Storage space available in Database and file system for each client. It has further sections, detailing the TemSe object name and the amount of space used across DB/ file.
TemSe Overview
