VBDATA: Update Request Data

Table VBDATA is one of the tables that is updated when update requests are created. It contains the data that is transferred to the modules (variables, structures, internal tables). Other update request tables are VBHDR (update headers), VBMOD (update modules), and VBERROR (error information when update is terminated). These tables, however, are not critical in terms of data growth.

An update request describes all data changes, which are bundled into an SAP LUW (logical unit of work) after an SAP application transaction is completed, and are executed as a whole in a single database LUW.

For consistency, an update request is either executed completely or not at all (rollback request).

5.1.34.1 Avoidance

Table VBDATA generally only sees strong growth if updates are terminated in large numbers. Here the primary action should be to analyze and resolve any update errors in the system. Program RSM13005 provides a tool for analyzing and processing update requests. It can also be used for collective runs.

If you are using SAP Business Warehouse (SAP BW) and the V3 update is activated, you may see a

temporary growth of table VBDATA. This has to do with the fact that the data for the delta update to the SAP BI system is temporarily stored in VBDATA. After the data has been loaded into SAP Business Warehouse (SAP BW) by the delta extractors, this table should go down in size again. If an error occurs during the delta upgrade, for example, because of the termination of the extractors, then the delta records remain in table VBDATA. If this table is growing too fast, you should particularly check whether the delta upgrade is stuck.

For more information about the V3 updates, see SAP Note 396647 (release independent): FAQ: V3 updates, questions and answers.

In addition, table VBDATA can often have a low fill rate, despite its size. The reason for this is that although the data was removed, the space that was needed for this data has not yet been released. This can only be remedied through a table reorganization via the appropriate database function.

For more information on updates see the SAP Library underUpdates in the SAP System (BC-CST-UP). Here you can also find detailed information on how to analyze and treat update errors.

5.1.34.2 Summarization Cannot be used

5.1.34.3 Deletion

Keeping record of documents that were not updated: To meet legal requirements with respect to documenting the assignment of accounting documents, we recommend that you regularly run program RFVBER00 (daily or weekly). It enables you to keep a record of all accounting documents that were left in table VBDATA after a terminated update run if the program is executed before the deletion of the documents that were not posted. For more information, see SAP Note 175047 (release-independent).

If a terminated update in the update control (transaction SM13) cannot be repeated via Update Requests Repeat Update, then the update data has to be entered manually. After the data has been entered, the update record has to be deleted (Update Requests Delete). Make sure that you do not delete any updates that have not been processed yet (status green), because this will erase the data that was supposed to be entered in the SAP system. Terminated updates (status Error) can be deleted by setting the main system profile parameter rdisp/vbdelete accordingly.

If requests created by collective runs were not deleted automatically, even if they have been processed completely, you can use program RSM13005 (see also SAP Note 385741 release-independent) to delete them.

If an SAP transaction terminates, there may be incomplete update requests. These are not displayed in the update control and cannot be executed. The records that are created during this process are written to tables VBDATA and VBMOD and use up space unnecessarily. By activating (V1) the main system profile

parameter rdisp/vbreorg, you can trigger the update server to look for incomplete update records and delete them after the start of the update. Because there are no active users on the server during this time, there will be no system inconsistencies as a result.

For more information on the main system profile parameter, see the update documentationSystem Profile Parameters for the Update

5.1.34.4 Archiving Cannot be used See also SAP Notes:

16083 (release-independent): Standard Jobs, Reorg Jobs 385741 (release-independent): Collective runs are not deleted

706478 (release-independent): Preventing strong growth of basis tables

5.1.35 /VIRSA/ZFFTNSLOG, /VIRSA/ZFFCDHDR, /VIRSA/ZVIRFFLOG: Firefighter Logs SAP Access Conrol for SAP enables superusers to perform emergency activities outside the parameters of their normal role, but to do so within a controlled, fully auditable environment. The application assigns a temporary ID that grants the superuser broad yet regulated access, and tracks and logs every activity the superuser performs using that temporary ID.

This logging information is stored in these tables:

/VIRSA/ZFFTNSLOG - Firefighter Transaction Log /VIRSA/ZFFCDHDR - Firefighter Change Document /VIRSA/ZVIRFFLOG - Firefighter Action Log

5.1.35.1 Avoidance

Growth in these tables can be prevented by using the firefighter IDs as restrictively as possible. It is definitely not recommended to schedule background jobs that do mass updates using a firefighter ID.

5.1.35.2 Summarization Cannot be used

5.1.35.3 Deletion Cannot be used 5.1.35.4 Archiving

The following tables may be archived using transaction /VIRSA/FFARCHIVE:

/VIRSA/ZFFTNSLOG - Firefighter Transaction Log /VIRSA/ZFFCDHDR - Firefighter Change Document /VIRSA/ZVIRFFLOG - Firefighter Action Log

Please be aware that this is a different kind of archiving than you may know from other archiving objects that are developed based on the Archive Development Kit (ADK).

See also SAP Notes:

1598473 (release-independent): Substantial growth of DBTABLOG table due to /VIRSA/ZVFATBAK 1041912 (release-independent): Firefighter Best Practice Archiving Strategy

5.2 SAP ERP