SAP Note 15184 - Error in table logging

Symptom:

1. Table changes are not logged in the log table DBTABPRT (or logged incorrectly).

2. A work process is ended with signal11 during a delete/update to a table for logging, and the records for changing are passed on to an internal table.
Table logging has been activated via profile parameter rec/client.
The error occurs in releases 2.1D-2.1G and 2.2A.

3. Runtime error with error message DBIF_RSQL_INVALID_REQUEST after every write access to tables for which change logging has been activated in the Dictionary (this is the case for most Customizing tables).
The strange thing about this situation is that the SysLog does not contain any error messages from the DB interface.
Deactivating table logging (profile parameter rec/client =OFF) eliminates the problems.
The error can occur until Releases 2.1H and 2.2B inclusive.

4. An update operation in work area mode on a table for logging (logging activated in the technical settings of the table definition in the Data Dictionary) causes return code (SY-SUBRC) 4 (=record not found), although the record in question actually exists in the database.
This occurs, however, only when logging is active only for certain clients in the profile (rec/client =,...,), but the update is performed in a client not contained in that list. Example: rec/client =999 and update in client 000.

5. A change operation on a table for logging terminates with runtime error DBIF_RSQL_DDIC_INCONSISTENT. The message BXL is found in the Syslog: "Tuple of table does not match the logging table".

6. When executing a DELETE or UPDATE statement for which a WHERE condition was specified, runtime error DBIF_RSQL_INVALID_REQUEST occurs. The entry:
"All SAP cursors (RSQL) occupied"
appears twice in sequence in the SysLog.
This problem occurs particularly when executing program RPUMKG00 (module RPUMKG40, Form INSERT_STANDARD_549D).

7. When executing a DELETE or UPDATE statement for which a WHERE condition was specified, ABAP/4 runtime error DBIF_RSQL_INTERNAL_ERROR occurs. The SysLog then contains the following entries:
"The cursor ID that was passed does not exist" (occurs twice)
"invalid return code"
This problem occurs particularly with transaction PE02 when performing a DELETE on table T52C5.

8. A client copy operation terminates not even an ABAP/4 run-time error is displayed. The system log contains many error messages B27 "Storage request (... bytes) failed".
The detailed information for these error messages shows that the
error has occurred in the module "dbprt".
Table logging is activated (profile parameter "rec/client").

9. In the syslog displays the error message:
"Data record of Table UTAB does not fit in log file DBTABPRT"
RESET N1

Additional key words
Cause and prerequisites

Re 1)
The configuration of profile parameter rec/client is probably incorrect.

Re 2)
Error in the SAP kernel.

Re 3)
An invalid value was specified for profile parameter "rec/client", e.g. rec/client =ON. z.B. rec/client =ON .

Re 4)
Error in the SAP kernel.

Re 5)
An attempt was made to log a table which cannot be logged due to length restrictions. Tables cannot be logged if:

• the total length of the key fields exceeds 86 bytes

• the total length of the data fields exceeds 500 bytes
  Unfortunately these restrictions are not checked in the Data Dictionary when logging is activated in Releases 2.x.
  

Re 6)
This problem could occur if

• table logging is switched on globally (profile parameter "rec/client", see below) and

• the affected table in the Data Dictionary is marked for logging and

• the affected table is buffered and

• the table buffer is full (if this is the case the SysLog will contain a message of the form "Loading of table into the buffer failed")
  The problem is caused by an error in the SAP kernel.
  

Re 7)
This problem could occur if

• table logging is activated (profile parameter "rec/client", see below) and

• the affected table is marked for logging in the Data Dictionary and

• the affected table is buffered and

• buffer synchronization is switched on (profile parameter "rdisp/bufrefmode" = sendon,exeauto) and

• the R/3 system is in a relatively untouched state, that is, it has just been started up or restarted or, more precisely:
  if table DDSYN, which is read during buffer synchronization, is not yet in the buffer.

The cause of the problem is an error in the SAP kernel.

Re 8)
Error in the SAP Kernel

Re 9)
Parameter rec/client for the table logging is set correctly.
In field HFLAD in Nametab (Table DDNTT), the zero bit set to 1 (log bit) for the physical pool table (here UTAB). This turns on table logging for table pool UTAB, although this feature is not maintainable for table pools. That this bit was not removed is probably caused by a non-executed past xpar which should initialize this bit.
The HFLAG field in DDNTT for UTAB can be determined with the following report:

REPORT TESTUTAB .
DATA FLAG TYPE X.
EXEC SQL.
SELECT HFLAG INTO :FLAG FROM DDNTT WHERE TABNAME = 'UTAB'
ENDEXEC.
WRITE : / FLAG.

If the last (smallest) part of the output is a 1, the Flag
for Table logging is set.

Solution

Re 1)
The option exists of logging changes to table entries; this function- ality is implemented in the database interface. The log records are written to database table DBTABPRT.
Prerequisite:

• The table has a key that is less than or equal to 86 characters long. The non-key part cannot be longer than 500 characters.

• "Logging" must be set for the table in the technical settings (SE11).

• The profile used to start up the R/3 System is in default directory /usr/sap//SYS/profile (UNIX), name _<...> (services and instance number). It must contain the following parameters:
  
  rec/client =OFF Logging inactive for the system (this is
  the default setting when the parameter is
  not contained in the profile)
  rec/client =ALL
  Logging active for the system: changes are recorded in all clients.
  
  rec/client =
  Logging is active only for the specific client(s). Several clients (3-digit!!) can be specified separated by commas.
  No blanks are allowed between the numbers!
  (correct: rec/client=001,002,099 - wrong: rec/client=001, 002, 099)
  
  Displaying the logged changes:
  Use report RSTBSERV, which is started using SE38.
  Menu path:
  Tools
  ---> CASE
  ---> Maintenance
  ---> Compare utility
  ---> Tab. evaluation
  

Re 2)
The following workaround is available:

1. Deactivate table logging for the affected table (Data Dictionary transaction SE13, technical table settings). Because the problem may still occur with other tables, however, we recommend another solution instead:

2. Deactivate table logging globally. To do this, set profile parameter rec/client =OFF and restart the R/3 System. Do this for all your application servers.
RESET N1

Error corrected from Rel. 2.2B/2.1H onwards.

Re 3)
The syntax required for profile parameter rec/client must be adhered to exactly (see item 1 above). From Rel. 2.1I/2.2C, the system reaction to an incorrect entry in the profile parameter will be less dramatic: the only affect is that table logging will not be activated.

Re 4)
This error is present "only" in Releases 2.2B and 2.1H. The error has been corrected in later releases. To avoid the problem, either deactivate logging completely (rec/client =OFF) or activate it for all clients (rec/client =ALL). You can select all tables for which logging is activated and whose variable non-key section exceeds 500 directly using sqlplus:
select tabname from dd091 where log = 'X'
and tabname in
(select tabname from ddntt where (tablength - keylength ) > 500);
(Table DD09L is the table for the technical settings from 2.2D onward).

Re 5)
A table that violates the restrictions referred to above cannot be logged.

From Release 2.2E or 2.1K it is possible to extend log table DBTABPRT, i.e. field VKEY or VDATA can be extended in order to be able to also log tables that would otherwise violate the named restrictions. To this end it is necessary to increase the size of domain PTVKEY or PTVDATA in the Data Dictionary (other fields of DBTABPRT must not be changed!). Attention: The data type should not be changed. As of Release 3,0, however, the Data Dictionary no longer permits data type VARC. In this case, pleas use

• type LRAW,

• modify report RSTBPROT as follows:
  
  Add type 'C' to line
  assign dbtabprt-vdata(dbtabprt-dataln) to <h3>
  (in about line no. 947). I.e. the line should read as follows after the correction:
  assign dbtabprt-vdata(dbtabprt-dataln) to <h3> type 'C'.
  

Then table DBTABPRT must be converted using the database utility (SE14) (if the data logged to date is no longer of interest, it is simpler, rather than converting the table, to delete it and create it again (with the Delete/Recreate function)). After converting table DBTABPRT the R/3 System must be restarted. This is necessary since the structure description of DBTABPRT is read once only for reasons of performance when a work process is started up and is then buffered locally to the process.

Caution:If you apply this procedure, problems may occur during the upgrade to Release 4* (from Releases 3* and earlier) - (see Note 424426).

Re 6)
The problem can be avoided by eliminating one of the causes described above. If the hardware situation allows it, the size of the table buffer should be increased (profile parameter "zcsa/table_buffer_area" and/or "zcsa/db_max_buftab"), since otherwise performance problems may arise as a result of tables that have not been buffered. Otherwise either logging or buffering must be cancelled in the technical settings for the table.

The error is corrected with Re. 2.1K or 2.2E.

Re 7)
The problem can be avoided by eliminated one of the causes described above. The simplest method is to read table DDSYN after the problem arises (using transaction SE16, for example). Then the table is buffered and the problem can no longer occur.
Another possibility is to cancel either logging or buffering in the technical settings for the affected table.

Re 8)
The problem can only be avoided by deactivating table logging for
the client copy operation by setting the profile parameter "rec/client"
to "off". After the client copy the parameter can be reset to its
original value.
The error is corrected from release 2.1L/2.2F onwards.

Re 9)
Via transaction SE11, the table pool UTAB can be reactivated. Afterward, the output of report TESTUTAB (see above) should deliver a zero in the last (smallest) place.
This deactivates table logging once again for UTAB, and symptom 9 (above) should no longer appear.