At times when opening data form you may encounter "An error occurred" message and the Plannig_WebApp.log will have messages like below
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.util.Arrays.copyOf
java.lang.reflect.InvocationTargetException
com.hyperion.planning.db.HspFMDBImpl.getWebGrid
com.hyperion.planning.smartview.XMLAdhocGrid2.getWebGrid
com.hyperion.planning.HspSmartViewProvider.adHocValidateQuery
HspSmartViewServlet.java
HspSmartViewServlet.doPostcom.hyperion.planning.olap.HspWebGrid.setGrid
Cause:
The errors in the log are indicative of Planning JVM being unable to perform the requested action
Solution:
Take the following steps to troubleshoot and resolve the issue -
a) Set the Governor
To prevent the error message and possible crash of the JVM if you are on the 11.1.2.3.501 version of Planning or higher you can enable the system property ERROR_THRESHOLD_NUM_OF_CELLS. 250,000 is a comfortable starting point. You do not want it to be too high or it will again crash the server. You will want to shrink the size of the query instead.
The following is a KM article that explains this governor in more detail. How it calculates the number and how to set it. Doc ID 1951571.1 Error Opening Planning Web Forms : "Unable to execute this operation as it exceeded the configured threshhold"
At least with the governor in place you will prevent these crashes and users will be able to log into the system.
b) Redesign the form
Most of the time final users don't want to use a governor because they simply WANT to run large queries.
It is important to remember that Planning is used for budgeting and planning, so the initial goal would be to NOT use forms for reporting purposes or data mining.
The most common mistake is to try and use the planning and budgeting product as a way to hunt for data. It is very likely, if they think about it, the business users know more specifically where the slice of data that they are looking for is located (so they can narrow the form scope; i.e. move largest row or column dimension to the page) but it is so much easier to design one form that looks "everywhere" for them. This is sometimes referred to as a lazy form because it is very easy to create and there is no maintenance involved. However, this should be replaced by specific forms, with a specific business purpose, focused on a select slice of the overall data in the system for the given portion of the budget being worked on at the time. This has the added benefit of controlling security access to portions of the data otherwise hard to secure.
As an example, if you have idescendants of DimA and DimB in the rows and there are 1000 members in each dimension you are starting with 1 million rows. Even if there are only 4 columns, this form has a cell count of 4 million (this example is oversimplified for the sake of discussion)
To reduce the size of the form, the most common solution is to create a form where one of these dimensions (preferably the largest sparse dimension) becomes the anchor dimension for the form. So, the adjusted form is based on 1, or 10 or however many members in that DimA. Then the other dimension remains in the row. 1000 rows is much less than 1000 times 1000. If you use the page dimension to toggle between your available members in DimA and analyze and budget accordingly you won’t run a query that is 4 million cells. At the onset, there may be a need to design a few extra forms, but the benefit is never running a query that is too large for the JVM container to process.
Review the KM Document:779502.1 - Hyperion Planning Data Form Design Considerations
c) Disable ad-hoc for the user(s)
Another way to prevent the huge query from running would be to disable the ad hoc option from forms for any user who has run large queries. This is an option in the form design. If the user does not have access to the ad hoc form they cannot run a query that is too large for the JVM container to process.
d) Tune the JVM
Follow the suggestions in the KM below to tune the JVM for optimal heap size and configuration
java.lang.OutOfMemoryError: GC overhead limit exceeded
java.util.Arrays.copyOf
java.lang.reflect.InvocationTargetException
com.hyperion.planning.db.HspFMDBImpl.getWebGrid
com.hyperion.planning.smartview.XMLAdhocGrid2.getWebGrid
com.hyperion.planning.HspSmartViewProvider.adHocValidateQuery
HspSmartViewServlet.java
HspSmartViewServlet.doPostcom.hyperion.planning.olap.HspWebGrid.setGrid
Cause:
The errors in the log are indicative of Planning JVM being unable to perform the requested action
Solution:
Take the following steps to troubleshoot and resolve the issue -
a) Set the Governor
To prevent the error message and possible crash of the JVM if you are on the 11.1.2.3.501 version of Planning or higher you can enable the system property ERROR_THRESHOLD_NUM_OF_CELLS. 250,000 is a comfortable starting point. You do not want it to be too high or it will again crash the server. You will want to shrink the size of the query instead.
The following is a KM article that explains this governor in more detail. How it calculates the number and how to set it. Doc ID 1951571.1 Error Opening Planning Web Forms : "Unable to execute this operation as it exceeded the configured threshhold"
At least with the governor in place you will prevent these crashes and users will be able to log into the system.
b) Redesign the form
Most of the time final users don't want to use a governor because they simply WANT to run large queries.
It is important to remember that Planning is used for budgeting and planning, so the initial goal would be to NOT use forms for reporting purposes or data mining.
The most common mistake is to try and use the planning and budgeting product as a way to hunt for data. It is very likely, if they think about it, the business users know more specifically where the slice of data that they are looking for is located (so they can narrow the form scope; i.e. move largest row or column dimension to the page) but it is so much easier to design one form that looks "everywhere" for them. This is sometimes referred to as a lazy form because it is very easy to create and there is no maintenance involved. However, this should be replaced by specific forms, with a specific business purpose, focused on a select slice of the overall data in the system for the given portion of the budget being worked on at the time. This has the added benefit of controlling security access to portions of the data otherwise hard to secure.
As an example, if you have idescendants of DimA and DimB in the rows and there are 1000 members in each dimension you are starting with 1 million rows. Even if there are only 4 columns, this form has a cell count of 4 million (this example is oversimplified for the sake of discussion)
To reduce the size of the form, the most common solution is to create a form where one of these dimensions (preferably the largest sparse dimension) becomes the anchor dimension for the form. So, the adjusted form is based on 1, or 10 or however many members in that DimA. Then the other dimension remains in the row. 1000 rows is much less than 1000 times 1000. If you use the page dimension to toggle between your available members in DimA and analyze and budget accordingly you won’t run a query that is 4 million cells. At the onset, there may be a need to design a few extra forms, but the benefit is never running a query that is too large for the JVM container to process.
Review the KM Document:779502.1 - Hyperion Planning Data Form Design Considerations
c) Disable ad-hoc for the user(s)
Another way to prevent the huge query from running would be to disable the ad hoc option from forms for any user who has run large queries. This is an option in the form design. If the user does not have access to the ad hoc form they cannot run a query that is too large for the JVM container to process.
d) Tune the JVM
Follow the suggestions in the KM below to tune the JVM for optimal heap size and configuration
No comments:
Post a Comment