In the ORACLE table TST03 (tablespace PSAPPROTD) the variable length field DCONTENT has a size of 9996 bytes in most cases. As the ORACLE block size is 8Kb on many installations, almosts all rows in TST03 are chained on 2 blocks and the second one is filled only 25%.
Cause and prerequisitesWhy you cannot change the structure of TST03?
As you can see from the type of the fields, this table is not handled by ABAP programs, but only by routines of the C kernal. Ant the C kernal knows the maximum length of that field.
Why that strange length?
The length had been 31 kbytes long time ago. I had to reduce this to 9996 at a moment, when the R/3 data dictionary could handle only length information with four digits. At that time we did not know about the 8 Kbyte blocks of ORACLE. Or maybe ORACLE did not use blocks of that size in those early releases. Today I think 8032 bytes would have been better.
Why not to change the length at SAP?
The price for reducing the length is:
- modify one constant definition
- recompile the C kernal
- copy and reformat the table at each customer. And typical customers have 200 to 800 MB data in that table.
- this reformatting has to be done by a stand alone C program, because
- R/3 cannot live without this table
- SQLplus cannot handle that table
- ABAP neither.
What SAP shall do?
The C kernal has to be modified in a way, that it still can handle data base rows of 10 Kbyte, but that it will insert only new records, which are smaller that 8032 Bytes net data.
Think about storing spool data in the file system. You can do so by the profile paramter
rspo/store_location = G
Disadvantage: the data backup will not cover the spool data any longer.
Additional key words
Spool, TemSe, TST03, SP12
No comments:
Post a Comment