Skip to end of metadata
Go to start of metadata

Symptom

Queries failed with errors like "Amount of data to be read from the BIA server is too large", "The following error 6,952 occured in BIA server" and "Error executing physical plan: AttributeEngine: not enough memory".

Problem

In order to control the overall memory usage in BWA system, there are standard configurations in BWA to control the overall resultset of a query. If intermediate result size or final result size exceeds the value configured in BWA, the queries will failed.
You can find these configurations in TREXIndexServer.ini file.

Starting from BWA 7.0 Revision 48, the parameter is max_cells_one_index with default value 40,000,000.

In trace TrexIndexServerAlert.trc, you can find entries about "AggregateCalculator returning out of memory with hash table size <number of rows>, key figures <number of columns>".

For example, in trace TrexIndexServerAlert.trc, there is entry as
AggregateCalculator returning out of memory with hash table size 3956689, key figures 15

Solution

You can raise parameter max_cells_one_index in a way that query does not abort. The value of max_cells_one_index must be larger than the product of rows multiplying columns.

For example, in trace TrexIndexServerAlert.trc, there is entry as
AggregateCalculator returning out of memory with hash table size 3956689, key figures 15

Then the value of max_cells_one_index should be larger than 3956689*15=59350335. In such case, you can modify the value of max_cells_one_index to 60,000,000.

After changing the settings in the TREXIndexServer.ini you have to restart the TREX index server to let the changes in the TREXIndexServer.ini take effect.

Note

  • Be aware that the TrexRfcServer, the RFC connection or the application server can stop working if the resultset does not fit into the memory of the service!
  • It is strongly recommended to set the parameters to the same value in the respective TREXIndexServer.ini configuration file on each TREX index server of your BIA landscape.
  • The bigger the size of the resultset, the longer the response time of the BIA will be due to longer transport times. So before you raise the limit of the resultset, consider a
    redesign of the BIA query. Normally you can split the query into several queries with smaller resultsets using more filter criterias in the queries. This also leads to more readable results for the enduser.
  • If you do not find that entry in the trace then the execution of the query really ran out of memory and the query will abort anytime independent of value of max_cells_one_index.

You can also refer to SAP Note 1002839 for more details.