SAP Basis Tech Supports

Symptom
The response time during transactions which use the asynchronous update (update log) is poor.
Other terms
Update log, asynchronous updates, partitioning, VBDATA, VBMOD, VBHDR
Reason and Prerequisites
During R/3 installation, the system assigns update log tables (VBDATA, VBHDR, VBMOD), as all other R/3 tables, to a common buffer pool (BP2, BP32K). This may influence the performance negatively (also of the overall system).
This note describes how to improve performance when you access these tables.
Solution
SAP and IBM recommend the following three steps to improve performance:
1. Ensure the optimal access path to update tables
This step is imperative. For more information, see Note 116698.2. Assign the update log tables to a separate buffer pool.
SAP and IBM highly recommend that you carry out this step. It involves separating the tables within their own 4K tablespaces. The tablespaces are then assigned to a buffer pool with attributes that correspond to those of the access template for the table.
Procedure:a) Ensure that no other users can access the update tables during this procedure.b) Use transaction SM13 to process all outstanding updates. You can continue only when all updates have been processed.c) Execute the report RSM13001 in accordance with Note 67014. This deletes orphaned entries in VBDATA and VBMOD that do not have a related entry in the VBHDR table and that are, therefore, not displayed in transaction SM13.d) Use transaction SE14 -> Table -> Data available? ((and never transaction SM13)to check whether the tables VBHDR, VBMOD and VBDATA are empty.
You can import the following transport KDOK000668 only if these tables are empty.e) Import transport KDOK000668 into your system. It is supplied as an attachment to this note.
Ensure that the current DIC correction was imported for Releases 4.6A, 4.6B, and 4.6C (see Note 184399). The minimum requirements are SAPK46AOS4, SAPK46BOS2, or SAPK46COS1.
You can use the transport KDOK000668 to reduce the length of the VBDATA domain to 3800 characters so that the VBDATA table fits in a tablespace with a page size of 4 KByte.
Notes 13719 and 480180 describe how to download corrections and implement them into an R/3 system.f) Check whether the system has placed the VBHDR, VBMOD, and VBDATA tables into their own 4K tablespaces. If this is not the case, carry out a separation. As of Release 4.5A, you can use transaction SE14 to do this almost automatically (see “SAP BC Database Administration Guide”, chapter 2). However, for older releases, you must proceed as follows:Call transaction SE11, enter the table name and choose “Display”.Choose “Technical settings”.Choose “Change”.Set the size category to 4 and choose “Settings -> Activate”.Call transaction SE14, enter the table name and choose “Edit”.Choose “Delete database table”.Choose “Create database table”.Choose “Extras -> Database object -> Check” to verify whether the system created the table successfully.g) Stop the databases belonging to the tables VBHDR, VBMOD, and VBDATA.h) Assign a new buffer pool to the tablespaces and indexes (here BP4):
ALTER TABLESPACE database-name.tablespace-name BUFFERPOOL BP4i) Start the databases that you stopped before.j) Modify the update-specific buffer pool:
ALTER BUFFERPOOL(BP4) VPSIZE(1000) VPSEQT(10) DWQT(70) VDWQT(50)
Check the buffer pool after these changes. If one of the critical threshold values is reached, use the buffer pool tuning methods described in Note 82953. You can, for example, reduce the “critical thresholds”.
3. Partitioning VB log tables (not for Release 3.0F)
This step is particularly useful in a data sharing environment. In an environment without data sharing, partitioning is offered if the performance of the activities is not satisfactory in the update log tables, even though you executed steps one and two.a) Execute steps 2.a) and 2.b). Import the transport described in 2.c) if you have not yet done this.b) Partition the update tables VBHDR, VBMOD, and VBDATA. The actions required to do this depend on the SAP release:
Release 3.0F:
Important: Note that you cannot partition the update tables in Release 3.0F.
Releases 3.1H, 3.1I, and 4.0B
The example described here is based on the following assumptions:Tablespaces and indexes are created in the database SAPDB01 and assigned to the DB2 stogroups SAPSG01 – SAPSG04 to process the I/O accesses parallel.The tablespaces and their indexes are assigned to the buffer pool BP4.There are 4 application servers that have dialog processes. Their host names are: appsrv01…appsrv04.
For Releases 3.1H to 4.0B, the DDL statements for the partitioning are as follows (modify the example according to your local environment):
SET CURRENT SQLID = ‘SAPR3′;
RENAME TABLE VBHDR TO QCMVBHDR;
RENAME TABLE VBMOD TO QCMVBMOD;
RENAME TABLE VBDATA TO QCMVBDATA;
COMMIT;
CREATE TABLESPACE VBDATA IN SAPDB01
LOCKSIZE ROW
LOCKPART YES
LOCKMAX 0
CCSID ASCII
BUFFERPOOL BP4
NUMPARTS 4
(PART 1 USING STOGROUP SAPSG01 PRIQTY 36720 SECQTY 3672,
PART 2 USING STOGROUP SAPSG02 PRIQTY 36720 SECQTY 3672,
PART 3 USING STOGROUP SAPSG03 PRIQTY 36720 SECQTY 3672,
PART 4 USING STOGROUP SAPSG04 PRIQTY 36720 SECQTY 3672);
CREATE TABLE VBDATA LIKE QCMVBDATA
IN SAPDB01.VBDATA;
CREATE TYPE 2 UNIQUE INDEX VBDATA____0 ON VBDATA
(VBKEY ASC,
VBMODCNT ASC,
VBBLKNO ASC)
BUFFERPOOL BP4
CLUSTER
(PART 1 VALUES(’appsrv01′)
USING STOGROUP SAPSG05 PRIQTY 1440 SECQTY 720,
PART 2 VALUES(’appsrv02′)
USING STOGROUP SAPSG06 PRIQTY 1440 SECQTY 720,
PART 3 VALUES(’appsrv03′)
USING STOGROUP SAPSG07 PRIQTY 1440 SECQTY 720,
PART 4 VALUES(’zzzzzzzz’)
USING STOGROUP SAPSG08 PRIQTY 1440 SECQTY 720);
COMMIT;
CREATE TABLESPACE VBHDR IN SAPDB01
LOCKSIZE ROW
LOCKPART YES
LOCKMAX 0
CCSID ASCII
BUFFERPOOL BP4
NUMPARTS 4
(PART 1 USING STOGROUP SAPSG01 PRIQTY 1836 SECQTY 720,
PART 2 USING STOGROUP SAPSG02 PRIQTY 1836 SECQTY 720,
PART 3 USING STOGROUP SAPSG03 PRIQTY 1836 SECQTY 720,
PART 4 USING STOGROUP SAPSG04 PRIQTY 1836 SECQTY 720);
CREATE TABLE VBHDR LIKE QCMVBHDR
IN SAPDB01.VBHDR;
CREATE TYPE 2 UNIQUE INDEX VBHDR_____0 ON VBHDR
(VBKEY ASC)
BUFFERPOOL BP4
CLUSTER
(PART 1 VALUES(’appsrv01′)
USING STOGROUP SAPSG05 PRIQTY 720 SECQTY 720,
PART 2 VALUES(’appsrv02′)
USING STOGROUP SAPSG06 PRIQTY 720 SECQTY 720,
PART 3 VALUES(’appsrv03′)
USING STOGROUP SAPSG07 PRIQTY 720 SECQTY 720,
PART 4 VALUES(’zzzzzzzz’)
USING STOGROUP SAPSG08 PRIQTY 720 SECQTY 720);
COMMIT;
CREATE TABLESPACE VBMOD IN SAPDB01
LOCKSIZE ROW
LOCKPART YES
LOCKMAX 0
CCSID ASCII
BUFFERPOOL BP4
NUMPARTS 4
(PART 1 USING STOGROUP SAPSG01 PRIQTY 1470 SECQTY 1470,
PART 2 USING STOGROUP SAPSG02 PRIQTY 1470 SECQTY 1470,
PART 3 USING STOGROUP SAPSG03 PRIQTY 1470 SECQTY 1470,
PART 4 USING STOGROUP SAPSG04 PRIQTY 1470 SECQTY 1470);
CREATE TABLE VBMOD LIKE QCMVBMOD
IN SAPDB01.VBMOD;
CREATE TYPE 2 UNIQUE INDEX VBMOD_____0 ON VBMOD
(VBKEY ASC,
VBMODCNT ASC)
BUFFERPOOL BP4
CLUSTER
(PART 1 VALUES(’appsrv01′)
USING STOGROUP SAPSG05 PRIQTY 1440 SECQTY 720,
PART 2 VALUES(’appsrv02′)
USING STOGROUP SAPSG06 PRIQTY 1440 SECQTY 720,
PART 3 VALUES(’appsrv03′)
USING STOGROUP SAPSG07 PRIQTY 1440 SECQTY 720,
PART 4 VALUES(’zzzzzzzz’)
USING STOGROUP SAPSG08 PRIQTY 1440 SECQTY 720);
DROP TABLE QCMVBHDR;
DROP TABLE QCMVBMOD;
DROP TABLE QCMVBDATA;
COMMIT;
Releases 4.5A and 4.5B
As of Release 4.5A, partitioning tables in transaction SE14 is actively supported. For more information, see the manual “BC SAP Database Administration Guide: DB2 for OS/390″. Note that the VBDATA, VBMOD, and VBHDR tables are multiplex tables that cannot be converted. Therefore, for these tables, proceed as follows:Call transaction SE14.Choose “Delete database table”.Choose “Storage parameters”.Specify and save the storage parameters for partitioning the table (details are provided in the manual on “BC SAP Database Administration Guide: DB2 for OS/390″).Choose “Create database table” on the initial screen in transaction SE14.
You can also use SPUFI to create the tables directly for Release 4.5A or higher. In this case, use the current naming convention for the indexes. To do this, replace the index names VBDATA____0, VBMOD_____0, and VBHDR_____0 in the above SQL commands with “VBDATA~0″, “VBMOD~0″, and “VBHDR~0″ (you must use quotation marks).
Release 4.6A and higher
As of Release 4.6A, you can use transaction SE14 for partitioning in the same way as described for Release 4.5A/B. However, note that as of Release 4.6A, the system writes the IP address of the application server to the update key (in hex format), instead of the server name (see Note 191191).
For example:
Four application servers for the dialog processes exist. Their IP addresses are: 155.56.94.121 (hex 9B.38.5E.79), 155.56.94.121 (hex 9B.38.5E.7A), 155.56.94.123 (hex 9B.38.5E.7B), and 155.56.94.124 (hex 9B.38.5E.7C). The system number is 11.
This will result in the following mapping between application servers and update keys:
155.56.94.121 -> ‘9B385E7911…’
155.56.94.121 -> ‘9B385E7A11…’
155.56.94.123 -> ‘9B385E7B11…’
155.56.94.124 -> ‘9B385E7C11…’
Therefore, use the following attributes for partitioning:
PART 1 VALUES(’9B385E7911′)
PART 2 VALUES(’9B385E7A11′)
PART 3 VALUES(’9B385E7B11′)
PART 4 VALUES(X’FF’)

CAUTION: If you have a CLASS A IP address in the range 1 – 15,
for example, 10.17.222.91, the first decimal value with a leading zero must be
used for partitioning. In the example,
10.17.222.91 -> ‘0A11DE5B11…’
c) Execute steps 2e) – 2h).d) Change the R/3 profile:
rdisp/vb_key_comp = /HOST/SYNR/WPNR/DATE/TIME/STMP/
For Release 4.6A or higher, you must also specify the following parameters in the profile:
dynp/trans_id_format = 2
As of kernel release 6.40, this parameter was renamed and
the profile should contain the following lines:
dynp/luw_id_format = 2
As of Release 4.6A, you must also import a kernel patch (see Note 191191).e) The following recommendations apply only to an installation with data sharing:Set the memory attribute LOCKPART YES for the newly-created tablespaces as follows, for example:
ALTER TABLESPACE SAPDB01.VBHDR LOCKPART YESFor a large number of application processes that are linked to a data-sharing member, define the relevant update process on the application servers that are linked to the same data-sharing members. You can do this by defining the Update Logon Dispatch Balancing and the update process on the same application server, where the relevant dialog process is defined. To do this, set the corresponding profile parameters as follows:
rdisp/vb_dispatching = 0
rdisp/vb_included_server = no entry (for example, blank character)
rdisp/vbname = name of the local application server
(for example, substitute variable $(rdisp/myname) )
Note that this method can cause a bottleneck under the following conditions:If the update work processes defined on the application server cannot process the workload generated on this application server, orif the application server is stopped.
To address this problem, use the multiplexing method described in Note 109515.4. Restricting growth in the table VBDATA
To prevent the table VBDATA from growing too quickly, use ALTER TABLESPACE to set the parameter that contains the table in the 4K tablespace toLOCKSIZE PAGEMAXROWS 1
For more details, see Note 822248.
Remarks
We recommend that you no longer use the transport KDOK000667 provided up to now for Release 3.0F. This transport corrects transaction SM13 for Release 3.1H in a 3.0F system and, as a result, allows you to partition the update tables. However, you cannot implement corrections for transaction SM13 contained in hot packages due to the release level, which is different from 3.0F (see Note 102353). Therefore, transport KDOK000667 and, consequently, partitioning of the update tables in Release 3.0F is no longer supported.
Repairs in the Code

Important: Do not enter any source code here. You must only enter source code in the screen
‘Corrections’ -> ‘Correction instructions’.
Any lines entered here are automatically deleted when you save.