Error executing a query with large result set

[Former Member]

Dear all,

after executing a query which uses key figures with exception aggregation the BIA-server log (TrexIndexServerAlert_....trc) displays the following messages:

2009-09-29 10:59:00.433 e QMediator    QueryMediator.cpp(00324) : 6952; Error executing physical plan: AttributeEngine: not enough memory.;in executor::Executor in cube: bwp_v_tl_c02

2009-09-29 10:59:00.434 e SERVER_TRACE TRexApiSearch.cpp(05162) : IndexID: bwp_v_tl_c02, QueryMediator failed executing query, reason: Error executing physical plan: AttributeEngine: not enough memory.;in executor::Executor in cube: bwp_v_tl_c02

--> Does anyone know what this message exactly means? - I fear that the BIA-Installation is running out of physical memory, but I appreciate any other opinion.

- Package Wise Read (SAP Note 1157582) does not solve the problem as the error message is not: "AggregateCalculator returning out of memory with hash table size..."

- To get an impression of the data amount I had a look at table RSDDSTAT_OLAP of a query with less amount of data:

Selected rows : 50.000.000 (Event 9011)

Transferred rows : 4.800.000 (Event 9010)

It is possible to calculate the number of cells retreived from one index by multiplying the number of records from table RSDDSTAT_OLAP by the number of key figures from the query. In my example it is only one key figure so 4.800.000 are passed to the analytical engine.

--> Is there a possibility to find this figure in some kind of statistic table? This would be helpful for complex queries.

I am looking forward to your replies,

Best regards

Bjoern

[jgleichmann · Accepted solution]

Hi Björn,

you are right not enough memory means not enough memory

But have you analyzed if this information is true and not combined with another error? Please have a look at the standalone, python tool trexadmin -> services -> load and select the time for your error (I think maximum is 3 days).

Have also a look at the traces if you are really run out of memory you must have got an alert in your system ( you can check this with the python tool or in TA RSDDBIAMON2 ).

Which revision do you currently running?

Regards,

Jens

[Former Member]

Dear Jens,

nether the trex admin tool nor the BIA monitor shows anything strage. The memory usage was 26 of 32GB.

Currently we are running revision 7.00.49.00.

Rgds

Bjoern

[jgleichmann]

Hi Björn,

I recommend you to upgrade to rev 52 or 53. Rev. 49 is really stable but there are some bugs in it and if you use BW SP >= 17 you can use some features.

Please refer to this thread , you shouldn't´t use more than 50% (the other 50% are for reporting) of your memory, therefor I have stolen this quote from Vitaliy:

The idea is that data all together for all of your BIA Indexes does not consume more then 50% of total RAM of active blades (page memory cannot be counted!).
The simpliest test is during a period when no one is using the accelerator, remove all indexes (including temporary) from main memory of the BWA, and then load all indexes for all InfoCubes into ain memory. Then check your RAM utilization.
Regards,
-Vitaliy

Regards,

Jens

[Former Member]

Hello there

This is a Known problem . From TREX REV48 onwards,there are couple of changes made and one of them is the way that BIA stores the results. This can be resolved by increasing the parameter values

Parameter

max_column_number_merge

max_column_number_one_index

max_cells_one_index

Also note TREX REV 52 is not fully recommended by SAP. Either think of REV 51 or stay at the current level.

Regards

Karthi

[Former Member]

Hi Karthi,

you said that the BIA stores the results. Is it possible to monitor this behavior?

In case I change the parameter values it would enable the BIA to send more records to the analytical engine. But in my opinion the error occures due to a lack of memory on the BIA installation.

Best regards

Bjoern

[jgleichmann]

Hi Björn,

if you decide to change this parameter please follow note 1002839.

Regards,

Jens

[Former Member]

Karthi - you mention in this thread that:

Also note TREX REV 52 is not fully recommended by SAP. Either think of REV 51 or stay at the current level.

Where did you get this information?