Result set too large:
This is not an error. This is the safety belt doing his job to avoid out of memory dumps and Portal crashes.
The safety belt parameter is documented into the note below:
1127156 - Safety belt: Result set is too large
The recommended value is 500 000 cells. You are able to increase the parameter but at your own risk. For huge queries, you can run them on transaction RSRT2.
1913710 - BI Java Memory Improvements for NW 7.30
Note 1688678 - Memory Usage Improvements for Web Applications (SP 07 Patch 20)
Long navigating users are causing increase in "navigation stack” (enabling backward navigations)
Every navigation step can take up to 20 MB / Data Provider. Some heap dumps were with 250 navigation steps and occupation of 250 MB / User Session for this reason
XML compression (can be disabled: RSWR_DISABLE_PARAM_COMPR=X)
RSADMIN parameter RSWR_MAXIMUM_BACK_STACK (>=10) to limit navigation stack. (default =50). A user message can be suppressed
(RSWR_SUPPRESS_BACK_MESSAGE = X).
Query / Query View instantiation requires DomReader object which is required for the initialization phase.
Such a DomReader is taking about 125 MB / Data Provider. (Leak) => Corrected.
Usage of "PATH" functionality for dynamic value resolving for Web Application Designer parameters in Web Items and Data Providers is expensive – memory peak => Optimization through serialization.
Note 1711936 - Limit number of member selections (SP 07 Patch 30)
For productive environments it is recommended to define a safety belt (upper limit) of the number of single selection value of a characteristic. A single selection may consume up to 10 kB of heap memory.
In case of a characteristic with many available master data entries a significant amount of memory may be allocated and causing the system to stop with OOM event.
Introducing a “Selector Safety Belt” via RSADMIN parameters:
This parameter defines the maximum number of master data entries shown in a list (e.g.selector dialog). There is no default value defined.
This parameter defines the maximum number of single selection entries of a characteristic. There is no default value defined.
Note 1710626 - Safety belts and memory availability assurance (SP 07 Patch 30)
This note introduces a lot of additional RSADMIN parameters created to control the memory consumption on the JAVA layer.
Using these options on J2EEs with small heap size is not recommended. Small heap size is below 4GB. Reason is that then the server is all the time in higher heap usage and good parameterization is not easy.
Introduction of memory checks in the application. The checks are reading actual heap value and checking the percentage of memory. When given value will be reached (3 alert levels are possible) the server can take intermediate actions - and block any new requests on this server node.
Switchable via RSADMIN parameter RSWR_MEMORY_CHECK_ACTIVE=1.
Recommended only for heap > 4GB. Detailed configuration:
RSWR_JAVA_MEMORY_RESERVED = memory that should be reserved for other tasks. Recommended: 10% heap.
RSWR_JAVA_MEMORY_CHECK_POINTS=<STRING:"1,2,3,4,5,6,7">, defines the parameters for the memory statistics calculation, which uses weighted averages.
Default is "20,60,20,1,3000,2,20000" and should be used
• Activates/deactivates check per Application processing step, see next.
RSWR_JAVA_MEMORY_ACTIONS_L<X> = <ACTIONS>;
<X> = Alert level
<ACTIONS> as 16 bit binary string, to control which further activities will be rejected
(applications, web sessions, web requests, exports, result set request, result set
creation, template deployment, true type PDF export, parsing, RFC calls etc.0
Means, active memory checks (calculations) in alert level 0 are always done on checks number 1,2,3,4 (EB8: 011110000101111)
Those active checks are sufficient on heaps >= 4GB.
Means, in level "1" no termination of existing sessions, just block of new web sessions. Action 2 is set "0", meaning that broadcasting, callbacks from tools (WAD) and Xcelsius will still work.
Note 1703966 - Limit number of user applications (SP 07 Patch 30)
It was found that it is typical end user behaviour to start further sessions within the same browser session in case of a long-running WebTemplate. Due to session stickyness this lead
to even higher memory and CPU workload on the same JAVA server node.
For heavily used productive BI Java installations it's recommended to define an upper limit of the maximum number of parallel user sessions. This increases the overall system stability e.g.
if the load balancing between the server nodes is not optimal or a single user is requesting too many BI sessions.
Configuration via RSADMIN parameters
RSWR_MAX_ALL_SESSIONS = maximum number of overall BI sessions on a single BI Java server node (EB8: not set)
RSWR_MAX_USER_SESSIONS = maximum number of BI sessions of a specific named user on a single BI Java server node
Also please check the Links:
For Heap Dump:
heap dump and have identified that the large object that is taking up most of the memory heap. Usually applying a limit as per note 1127156 solves the issue. Anyway I am giving you also other action that can help. Please follow the below items and let me know if that resolves the issue.
> In general, please apply filters to the query to avoid this kind of situation. For example, mandatory variables might help.
> Please use safety belt settings as per note 1127156 to limit the maximum amount of data.
> Please check the JVM parameters of your system. They should be set according to SAP recommendations. Kindly refer to SAP Notes 723909 and 716604 for the SAP recommended JVM parameters.
> Also refer to following SAP Notes
- Note 1025307 - Composite note for NW2004s performance: Reporting
- Note 1008619 - java.lang.OutOfMemoryError in BEx Web Applications
> Please make sure that you have followed all the recommendations for BI JAVA sizing mentioned in the note 927530.
> Apply the latest patches of the BI Java components BI-BASE-S, BI-BASE-E,BI-BASE-B, BI-BIC and BIWEBAPP compatible with the used Support Package Stack according to note 1163789.
1515139 - Frequent WEB AS JAVA out of memory crashes and/or core dumps due to large BI data access queries.