Improve Performance in FBRA

Hello Everyone,

The idea of this blog is summarize the most commun actions to improve the performance in FBRA as well as the SAP notes related with each topic suggested.

-> If change selection parameters does not solve the issue you can use FBRA_LOC transaction as described in SAP note 487347:

487347 – FBRA: Overflow of the lock table

This note suggests to use transaction FBRA_LOAC as a workaround for problematic cases.

For avioding the lock table overflow, there are these possibilities:

1. Extend the profile-parameter “enqueue/table_size”, as per note 13907

2. Reduce BKORM entries as much as possible, i.d. for all company codes
   The less entries in table BKORM exist the more faster is FBRA or
   FBRA_LOAC. Please refer to steps 2. and 3. of note 487347.

Additonally, please review the following recommendations

1.      Use Note 1320810 Z_ENQUEUE_PERF during both high and low load.

2.      Test changing the following parameters enque/server/threadcount and enque/server/use_spinning to true.

3.      Run niping during both high and low load.

4.      Use test in okcode in sm12 and set logging on for 15 seconds and run mass calls, starting with a thousand during load and check stad record for enq performance.

5.      During problem time check for rejects in sm12. If refresh shows increases of hundreds, points more to an application issue.

6.      Consider moving the standalone enqueue server to a dedicated system.

7.      Continue application analysis.

-> If you are receiving runtime error TSV_TNEW_PAGE_ALLOC_FAILED in transaction FBRA can be that table BKORM has too many entries.

This table could contains millions of old and very old correspondence requests, which never have been printed and therefore never been deleted from this table.

If you don’t print your correspondence requests, you have to reorganize table BKORM from time to time by means of report SAPF140D. This
report can be reached for each user via transaction F.63. The BKORM should contain normally only current correspondence requirements which were not printed yet and possibly already printed, which are not older than 14 days, for a possible reprint. There is no need to keep printed correspondence in BKORM for a long time.
Many of these correspondence requests were created a long time ago and you do not intend to print and to send these correspondences. Such correspondences requests can be safely deleted. Please take the following precautions:
  1. You should run SAPF140D according to note 17831 on a regular basis (every two days or at least weekly) to delete all accounting
correspondence requests out of BKORM that are finished since (e.g. one week).
  2. The same report should be used to delete all accounting correspondence requests that have no expiry date at all(‘entries
withoutprint date under ‘Further selections’).  There is also a possibility to run the report in test mode.
  3. In the future, you should use SAPF140 as follows: On the selection screen, under ‘Program Control’ there is a field called ‘Delete if
finished since’. This field has to be filled with a certain number of days (e.g. 7). You could create a variant and then always use this
variant for SAPF140 for which this field is set.
If entries in BKORM are deleted to correct size, FBRA should work fine.

I hope that I could help!

Kind Regards,

Raquel