SAP Note
375566 - Extremely large number of entries in tRFC and qRFC tables
Component: BC-MID-RFC (RFC), Version: 21, Released On: 16.03.2016
Symptom
The tables ARFCSSTATE, ARFCSDATA, ARFCRSTATE, TRFCQDATA, TRFCQIN, TRFCQOUT or TRFCQSTATE
contain a large number of entries. This leads to in poor performance during tRFC and qRFC
processing.
Other Terms
Application Link Enabling, ALE, Electronic Data Interchange, EDI, workflow, Customer
Relationship Management, CRM, SAP Business Information Warehouse, BW, Advanced Planning and
Optimization, APO
Reason and Prerequisites
The system has a very high interface load and/or a large number of tRFC/qRFC entries have
the status "Error" and/or there is a large number of tRFC/qRFCs waiting to be processed.
Solution
Before you correct the problem, you must analyze the problem in more detail.
1. Outgoing t/qRFCs
Check that you are using tRFC or qRFC:
Use transaction SE16 to check how many entries are contained in the table ARFCSSTATE.
Now determine for how many entries the field ARFCRETURN is empty in the table
ARFCSSTATE. These entries represent tRFCs that have either not yet been processed or
that have the status "Error". This affects the tables ARFCSSTATE and ARFCSDATA. These
tables contain a large number of entries (see also point 5).
All of the entries of the table ARFCSSTATE, for which the field ARFCRETURN is not empty,
come from qRFCs that either have not yet been processed or that have the status "Error".
Here, the tables ARFCSSTATE, ARFCSDATA and TRFCQOUT are affected by the growth (see also
point 3).
2. Incoming t/qRFCs
a) The table ARFCRSTATE has a large number of entries. It does not matter whether
these were written by a tRFC or qRFC. Note 366869 describes some possible solutions.
b) The tables TRFCQIN, TRFCQDATA, and/or TRFCQSTATE contain a lot of entries. These
are qRFCs (see also point 4).
We will now describe known solutions. If there is no solution for the problem that you are
experiencing in your system, open a message under the component of the affected SAP product
(CRM, SRM, and so on). If you know the affected application within the SAP product, then
specify the message component more precisely.
Generally, you should not delete tRFC entries or (especially not) qRFC entries because the
applications that the databases use to communicate will become inconsistent. (Only some
cases mentioned in Note 366869 are exceptions). Apart from that, the following always
applies: After deletion, you must check and restore the consistency of the databases
involved.
3. Known solutions for outgoing (sending) qRFC:
a) APO example
When you call transaction SMQ1, there is a large number of queues on
CPICERR. The system writes this error if the data required by the liveCache was blocked
during execution. Normally, the system automatically postprocesses this error (every 15
minutes by default). If you want this postprocessing to occur immediately, you can send the
queue manually from transaction SMQ1. The sequence of the queues is irrelevant because the
qRFC automatically identifies which other queues must be processed and in which sequence
within the same LUW.
However, if it is not a lock but an actual CPIC error that causes the
CPICERR (for example, the target system is not started, the destination is not maintained in
SM59 and so on), you must correct the error before post-processing.
b) CRM Mobile Sales example
In transaction SMQ1, there is a large number of entries for queues
with the name CRM_Site_00....XX in the status NOSEND. Generally, these queues have a large
number of entries (more than 100) and the first date (oldest queue entry) is older than one
week.
These queues are the queues of the Mobile Client. The owner of the
Mobile Client has not logged on to CRM (CONTRANS not started) from transaction SMQ1 since
the "first date". The system constantly places queue entries into the outbound queue for
each individual mobile client, as a result, the queues and therefore the qRFC table grow
(this is due to the delta load from the OLTP and data replication in the middleware). This
has a negative effect on performance for all qRFC users and especially on the communication
with the OLTP system.
Above all, the growth per queue depends on the quantity of data
subscribed for the Mobile Client.
We recommend that you limit the quantity to the minimum from the
outset.
The only solution here: The Mobile Clients must log on to CRM and
start CONTRANS on a regular basis (at least once a week). IMPORTANT: If one or more clients
are no longer required or have no owner, they must be logged off from the admin station by
the administrator. This actually causes a temporary load on the system, but consistently
removes the queues.
4. Known solutions for incoming qRFC:
a) CRM: In transaction SMQ2, queues have the status STOP.
Either the CRM application writes this STOP or it is set manually. A
short STOP triggered by the application is normal.
If, however, the queues have the status STOP for a long time and were
not deliberately deregistered in SMQR, there is an application problem. This may either have
been caused by a short-term lock of the application object where a simple status reset and
subsequent processing helps.
Alternatively, a real application error may exist and you can
determine its cause using transaction SMW01: Here select the date according to the queue
STOP date, select the corresponding line and choose the "Error" pushbutton. The system
displays the application error that has to be corrected by the user department. Afterwards,
you can trigger the queue again from SMW01 by following the menu "Message -> Process ->
Retry to process".
If you have deliberately deregistered the queue, note that stopping
several queue entries for a long period of time may also affect performance. You should
register and process the queues again as soon as possible.
Known solutions for incoming and outgoing qRFC:
b) All SAP products that use qRFC: The QRFC performs poorly after you import
Supplement 11, QRFC 6.30.060.
On ORACLE, this supplement also requires database statistics for the
tables TRFCQIN and TRFCQOUT. You may experience considerable performance problems if you
forget to generate these statistics after you upgrade to Supplement 11 (see Notes 742950 and
371068).
5. Known solutions for outgoing tRFC:
For all users, use transaction SM58 to check which function module should be
processed by the TRFCs:
a) For function modules: "SWW_WI_*" and a status text that indicates an error: There
is a workflow problem. First use transaction SWU3 to check the workflow Customizing
and continue to search for possible workflow errors.
If the error has been corrected, try to postprocess the tRFC. If that
does not work technically, you must first contact your workflow application department to
clarify which steps to take to ensure the business flow before you use the "Reorganization"
in transaction SM58 to delete the entries that cannot be postprocessed.
b) For the function module: "IDOC_INBOUND_ASYNCHRONOUS" (Release 4.X and above) or
"INBOUND_IDOC_PROCESS" (Release 3.X) and a status text that indicates an error:
There is an ALE/EDI-RFC transfer problem.
Check the technical function of the interface (destination test in
transaction SM59, checking the ALE/EDI Customizing for this interface).
Correct the error and then postprocess the tRFC, otherwise this IDoc
is lost for the business process.
c) A frequent cause when using ALE/EDI in a system in releases from 4.6 is that the
error workflow is delivered for these interfaces but the general workflow
customizing is not. Since the workflow for error handling cannot be deactivated in
EDI, in this case carry out the workflow Customizing and define processors for the
work items.
In ALE, you have the choice to perform error handling either in the
workflow or in transactions BD87 and BD88. If you choose BD87/88, you can deactivate the
workflow for troubleshooting. As a result, the TRFC entries for the error workflow are
suppressed.
Proceed as follows to deactivate the error workflow for ALE and EDI:
Transaction WEDI -> Control -> System Process Code. Here you can deactivate each
standard task by selecting "Inactive".
Deactivate the event linking in transaction SWE2 by removing the cross in the "Type
Linkage active" field. Here you can deactivate the error workflow at message type
level. You may only be able to deactivate the event linking for certain message
types.
Always set the PROCESSSTATEREACHED event to "Active" for the IDoc object
if you are communicating using the file interface, otherwise no immediate processing is
possible.
If you have deactivated the error workflow and you have corrected the
IDOC errors with BD87/88, you can use transaction SM58 to delete the relevant entries in the
TRFC tables.
For further detailed questions and support, please contact SAP Consulting.
Manual Activities
Attributes
Key
Value
Transaction codes
HIER
Transaction codes
TRANSAKTIONEN
Transaction codes
IDOC
Transaction codes
SE16
Transaction codes
BD87
Transaction codes
SMQ2
Transaction codes
SMQ1
Transaction codes
SM59
Transaction codes
SMW01
Transaction codes
SM58
Transaction codes
SMQR
Transaction codes
WEDI
Transaction codes
SWE2
Transaction codes
SWU3
Transaction codes
BD88
This document refers to
SAP Note/KBA
Title
706478
Preventing Basis tables from increasing considerably
440670
435125
Poor performance of tables used by CRM (Oracle only)
407125
Poor performance of Q and TRFC on ORACLE
384077
APO: Optimizing CIF Communication
370601
Composite SAP note: APO 3.0 and 3.1 performance
1597364
FAQ: BW-BCT: Extraction performance in source system
This document is referenced by
SAP Note/KBA
Title
3356918
How to distinguish tRFC or qRFC entry in table ARFCSSTATE
2899366
Huge entries in table ARFCSDATA
2000002
FAQ: SAP HANA SQL Optimization
706478
Preventing Basis tables from increasing considerably
1597364
FAQ: BW-BCT: Extraction performance in source system
384077
APO: Optimizing CIF Communication
435125
Poor performance of tables used by CRM (Oracle only)
407125
Poor performance of Q and TRFC on ORACLE
370601
Composite SAP note: APO 3.0 and 3.1 performance