Sizing and Scaling Guidelines for EPM Planning and Budgeting

SIZING AND SCALING GUIDELINES FOR EPM PLANNING AND BUDGETING 10/30/2008
Reference Number: EPM Product(s): EPM Release(s): Revision Number: EPM Planning and Budgeting 8.9 and beyond 1

Contains:
Memory Limitations ACE Limitations Data Volumes Implementation Design Options Operating System Considerations

Table of Contents
Table of Contents........................................................................................................................................................4 Chapter 1 - Introduction .............................................................................................................................................5 Structure of this Red Paper Related Materials 5 5

Chapter 2 - Sizing and Scaling Guidelines..............................................................................................................6 Purpose of this Document 6

Description of Issues 6 Memory Limit ............................................................................................................................................................................ 6 ACE Index Limit........................................................................................................................................................................ 7 Impacts to EPM Planning and Budgeting Processes and Data Views ....................................................................................... 7 Data Volumes............................................................................................................................................................................. 8 Data Volume-Drivers ................................................................................................................................................................. 8 Estimating Data Volume ............................................................................................................................................................ 8 Data Volume and FLEX Formulas........................................................................................................................................... 10 Implementation Design Options for Reducing Data Volumes................................................................................................. 10 Operating System Considerations ............................................................................................................................................ 11 Appendix A Validation and Feedback..................................................................................................................12 Customer Validation Field Validation 12 12

Appendix B Revision History................................................................................................................................13 Revision History ...................................................................................................................................................................... 13

Copyright 2008 Oracle, Inc. All rights reserved.

10/30/2008

PeopleSoft Enterprise EPM Red Paper

Chapter 1 - Introduction
This Red Paper is a practical guide for technical users, installers, system administrators, and programmers who implement, maintain, or develop applications for your PeopleSoft system. In this Red Paper, we discuss guidelines on how to diagnose a PeopleSoft Online Transaction environment, including PeopleSoft Internet Architecture and Portal configuration. Configuration of Batch processes is not covered in this document. Much of the information contained in this document originated within PeopleSoft Development and is therefore based on "real-life" problems encountered in the field. Although every conceivable problem that one could encounter in this document, the issues that appear are the problems that prove to be the most common or troublesome.

STRUCTURE OF THIS RED PAPER

This Red Paper provides guidance for sizing and scaling PeopleSoft Planning and Budgeting. Keep in mind that PeopleSoft updates this document as needed so that it reflects the most current feedback we receive from the field. Therefore, the structure, headings, content, and length of this document are likely to vary with each posted version. To see if the document has been updated since you last downloaded it, compare the date of your version to the date of the version posted on Customer Connection.

RELATED MATERIALS
We assume that our readers are experienced IT professionals, with a good understanding of PeopleSofts Internet Architecture. To take full advantage of the information covered in this document, we recommend that you have a basic understanding of system administration, basic Internet architecture, relational database concepts/SQL, and how to use PeopleSoft applications. This document is not intended to replace the documentation delivered with the CRM PeopleBooks. We recommend that before you read this document, you read the PIA related information in the PeopleTools PeopleBooks to ensure that you have a well-rounded understanding of our PIA technology. Note: Much of the information in this document eventually gets incorporated into subsequent versions of the PeopleBooks. Many of the fundamental concepts related to PIA are discussed in the following PeopleSoft PeopleBooks: PeopleSoft Internet Architecture Administration (PeopleTools|Administration Tools|PeopleSoft Internet Architecture Administration) Application Designer (Development Tools|Application Designer) Application Messaging (Integration Tools|Application Messaging) PeopleCode (Development Tools|PeopleCode Reference)

Copyright 2008 Oracle, Inc. All rights reserved.

10/30/2008

PeopleSoft Enterprise EPM Red Paper

Chapter 2 - Sizing and Scaling Guidelines PURPOSE OF THIS DOCUMENT

The purpose of this document is to assist Oracle consulting and customer service groups with determining appropriate designs for EPM Planning and Budgeting releases 8.9, 9.0 and beyond. This document can help mitigate potential design issues as they relate specifically to application server memory and data volumes. The data contained in this document is based on certain large customer line item data and customer-reported cases as well as technical discussions between development and operating system vendors. The recommendations and considerations are based on our empirical learning and experience. The scope of this document is focused on line item type activities. Over time, it may be expanded to include position budgeting or asset detail activity types if there is a need to do so. This is not a performance document with stated performance benchmarks. Performance issues should continue to be logged using the normal procedures for logging customer cases. Finally, this information should serve as a living document that should be expanded as new or different information becomes available.

DESCRIPTION OF ISSUES
Memory Limit
EPM Planning and Budgeting uses the PeopleTools integrated Analytic Calculation Engine (ACE) included in PeopleTools releases 8.46 and beyond. ACE functions primarily as the multi-dimensional calculation engine for line item type activities, including flexible formula methods. ACE is also used to display line item data in data entry views as well as read-only analysis views, such as variance analysis. EPM Planning and Budgeting customers with large amounts of data have encountered some hard limits when PeopleTools runs as a 32-bit process where certain Planning and Budgeting processes and/or data views failed to complete or successfully load into pages that contain line item data. This is due to the use of ACE to create Planning and Budgeting models.

Note: Position budgeting and asset detail activities were rewritten using PeopleCode and are much less dependent on ACE ACE is an in-memory model. Each activity-scenario combination in EPM Planning and Budgeting creates an underlying ACE model. ACE loads all the necessary data to complete a process or to materialize a data view. User security is respected and the system loads only the appropriate data based on a users access. For instance, a data entry view for a preparer will typically require much less in-memory data than for a coordinator role. Certain processes and data views fail to complete when the PeopleTools process runs out of available addressable memory. PeopleTools releases support multiple operating systems and operating system versions (IBM AIX 32-bit and 64-bit). Depending on the PeopleTools release, PeopleTools will run as a 32-bit process or as a 64-bit process. Even if an operating system version is 64-bit, PeopleTools may run only as a 32-bit process on that version. Please refer to the table at the end of this document for a summary of such support.

Copyright 2008 Oracle, Inc. All rights reserved.

10/30/2008

PeopleSoft Enterprise EPM Red Paper

Furthermore, each operating system has its unique methods for handling and allocating addressable memory. As a result, each operating system has significantly different limits for handling data volumes on 32-bit operating systems.

ACE Index Limit

When loading the multi dimension data in memory, ACE doesn't store the index array for the multi dimension data; instead it uses an algorithm to map the index array to a unique integer index that will be used as the index to store the cube cell data values in memory. This index is defined as a PSI64 type (the largest integer currently supported by PeopleTools). Since ACE will also need to use one bit of this PSI64 type as the mask for the modify/non-modify flag, the maximum integer number for this index will be 2^63 (~9.2e18). Thus the unique mapping algorithm requires the cross product of the number of the dimension members in the cube to be less than 2^63, otherwise the index will overflow and the in memory data storage cannot handle the overage. When the number of the cross products is over 2^63, the potential index overflow problem might cause problems in ACE internal in memory cube storage. There could be different unexpected behaviors depending on whether/how an overflowed index was created and how the system responds/accesses the memory pointed by that index. This depends on which cube cell needs to be indexed (it is possible that all the cube cells that have values and need to be indexed have the index value less than 2^63 even though the total cross product of the number of the dimension members are over 2^63. You can think of it as to assign the integer for each of the dimension tuples, and that integer can range from 1 to 2^63). If that is the case, then the results will be correct. But most likely there could be integer index for cube cells that need to be indexed larger than 2^63 if the total cross product of the number of the dimension members are over 2^63, and the result could be crashes or some incorrect results. One common error is the "memory access error", which results in the following error in the message log: BP_ACT_CALC.Calc.Calc engine abends during line item stage with the message: 'Initiated' or 'Processing' no longer running. Another common error is zero amounts in the analysis report grids.

Impacts to EPM Planning and Budgeting Processes and Data Views

The data volume limitation applies to the following areas, which are generally limited to the coordinator role: Staging. Each activity-scenario combination represents a single ACE model and is staged individually. If a particular activity-scenario is too large, the addressable memory for the operating system is exceeded and the activityscenario (ACE model) does not get staged. Recalculation. A full model recalculation, in application terms, includes ACE model loading, the GetRowCount function and calls, and the ACE cube collection. During recalculation, the internal ACE model routine named GetRowCount has to build many internal structures in memory. If the data volumes in the model are too great, addressable memory can be exceeded. Analysis Views (especially coordinators that have access to all data). When selecting all planning centers or a large group of planning centers for a particular activity-scenario, the amount of data loaded may exceed the addressable memory for the operating system if the volume is too high. Data Entry Views (especially coordinators that have access to all data). When selecting all planning centers or a large group of planning centers for a particular activity-scenario, the amount of data loaded may exceed the addressable memory for the operating system if the volume is too high.

Copyright 2008 Oracle, Inc. All rights reserved.

10/30/2008

PeopleSoft Enterprise EPM Red Paper

Data Volumes
The primary driver is the number of rows stored for a given activity-scenario (the ACE model). The number of rows is based on the number of dimensions and the number of members for each dimension, including budget periods. A separate row is created for each budget period (for example, Jan, Feb, Mar). There are no known sizing issues that are caused by the raw number of planning centers. The following table shows the maximum number of rows per operating system that we were able to process for a single activity-scenario/ACE model. These tests were run on PeopleTools 8.46 using a customer-provided budgeting model. PeopleTools runs as a 32-bit process on these operating systems in releases 8.46 and 8.47: Operating System Windows HP-UX AIX Maximum # of Rows 800,000 700,000 380,000

The wide variation by operating system is determined by the algorithms and number of segments used for managing addressable memory on that particular operating system. These limits do not apply to environments where PeopleTools runs as a 64 bit process. See the section titled Operating System Considerations for more information.

Data Volume-Drivers
The following factors determine the overall size, and therefore memory requirements, for a given activity-scenario: Number of dimensions and the number of members in a dimension. Planning time horizon, multiple years. Number of budget periods in a scenario (days, weeks, months, quarters, annual). Number of comparison scenarios. Number of FLEX formulas, especially where dimension selection is set to all members. Rows in materialize data view

The next section describes how these drivers impact data volumes.

Estimating Data Volume

The number of rows of data for a given ACE model is a function of the number of dimensions, the number of dimension members, and the sparsity factor of the data. Sparsity refers to the density of the dimension intersections. Function (total possible rows * sparsity factor) The following table shows the relationship for estimating the number of physical rows: Activity: Revenue Number of members for delivered/required dimensions Operating Units 10

Copyright 2008 Oracle, Inc. All rights reserved.

10/30/2008 Planning Center (Departs) Accounts Currencies Versions Comparison Scenario Base Budget Periods per scenario Number of additional dimensions: Products 520 8 1 3 1 12 1 58

PeopleSoft Enterprise EPM Red Paper

Possible Detail Row Combinations Sparsity Assumption Physical Rows

86,860,800 99.0000% 868,608

To calculate the approximate number of cross products (row combinations), use the following steps: 1. Run the following SQL to find the number of accounts (replace with correct values):
select COUNT(DISTINCT ACCOUNT) from PS_BP_MDL_ACCT_VW WHERE BUSINESS_UNIT = 'US001' AND BP_PLANNING_ID = '2003_BUDGET' AND BP_ACTIVITY = 'LINEITEM' AND BP_SCENARIO = '2003PROP'

2. Run the following SQL (repeat for each of your chartfield dimensions):
select COUNT(DISTINCT B.OPERATING_UNIT) from PS_BP_LI_TBL A, PS_BP_DIM_DTL_TBL B WHERE A.BP_LINE_SEQ=B.BP_LINE_SEQ AND BUSINESS_UNIT = 'US001' AND BP_PLANNING_ID = '2003_BUDGET' AND BP_ACTIVITY = 'LINEITEM' AND BP_SCENARIO = '2003PROP' AND BP_BUDGET_VERSION = '1'

3. Multiply all the results together, then multiply that by the number of periods, number of currencies (add 1 for blank member), then multiply again by the number of budget centers. For example, if department is the budget center, then you will use department twice in the formula). The total should be less than 2^63 or 9.2e18. Computing the possible row combinations is a simple mathematical equation. The wildcard in the equation is determining how sparsely populated the data will be for any given activity-scenario. In the previous table, a 99% sparsity rate is assumed. This means that of all the possible data combinations, 99% of those combinations have a null value and they are not used. Only the physical rows of data are loaded into the ACE model. ACE has a feature called explicit tuples which handles the sparsity issue in terms of the size of the database. Having a very sparse model isnt an issue for ACE, unless the cross product of the number of dimension members exceeds the index limit of 2^63 (for more information, see the section titled Ace Index Limit). Estimating data volumes using surrogate data is a practical approach when estimating size. In some cases a more straightforward approach is to look at the number of physical rows used for last years actuals or a prior budget. Estimating based on historical data assumes the same dimensionality, number of dimension members including number of time periods, and so on. For instance, if the actuals are stated as annual amount and the budget model calls for 12 months, the number of rows in the actuals would need to be multiplied by a factor of 12, since data would presumably be stored in all 12 budget time periods. Similarly, you would multiply the number of rows in the actuals by the number of comparison scenarios, assuming each comparison scenario has the same combination of dimension members as the actuals. On the other hand, if actual data did not have a product dimension and the budget has 58 products in a product dimension, not all data will be budgeted to all 58 products. You would not multiply the actual data rows by a factor of 58 to estimate the number of budget rows. Unlike time periods, the product dimension is sparse in relation to all the other dimensions. A sparsity assumption would need to be applied (for example, 58 x (1-95%)).
Copyright 2008 Oracle, Inc. All rights reserved.

10/30/2008

PeopleSoft Enterprise EPM Red Paper

Using fewer dimensions in your budget model than exist in your source system also affects this calculation. If your actual data includes a dimension for region, but the region dimension is not included in your budget model, then those rows will be aggregated away, and you end up with fewer rows in Planning and Budgeting than exist in your actuals ledger.

Data Volume and FLEX Formulas

Data volume and addressable memory are not directly related to flexible formulas. Data volume is the number of row of data that will be loaded into ACE and it is independent of the flexible formula. A fix was delivered in 8.9 bundle 7 that breaks up certain very large formulas into smaller formulas so that ACE does not encounter out-of-memory conditions. When the ALL member is selected, the application converts the flexible formula into ACE calculation rules, and it needs to refer to all the members in that dimension in the rule instead of only intended members. As a result, more recalculations than necessary are performed. Again, this impacts performance rather than addressable memory.

Implementation Design Options for Reducing Data Volumes

The best solution for the memory limit issue is to implement EPM Planning and Budgeting with PeopleTools running as a 64-bit process. However, the following design considerations should be taken into account as such an environment may not be available for every customer. In addition, an efficiently designed model will generally have better performance than a larger, less efficient model design. This is the only solution for the index limit issue. The following list outlines implementation approaches to reduce data volumes: Multiple activities. Break up a Planning and Budgeting model into multiple activities. Since each ACE model represents a scenario-activity combination, more combinations have fewer rows of data than a single large activity. The data distributed in multiple activities can be integrated into parent activities. Breaking up a model into a collection of smaller activities leverages the Planning and Budgeting data model and distributed architecture, helping the model to scale. Fewer dimensions. Consider concatenating some dimensions into valid dimension combinations (for example, operating unit with department for a planning center, or concatenate customer with channel or product or location). Remove chartfields which are actually attributes and don't generate additional combinations. If those chartfields are only needed for export to GL, they could be added later during the export process (requires some customization). Fewer dimension members. Consider fewer dimension members. For instance, if only one department has a corporate jet consider using a common travel account instead. Fewer time periods. Weekly planning will generate more rows of data than monthly planning. Multi-year planning for a single scenario will generate more data than a single or partial year. Multicurrency: single currency budgeting will be less sparse than multiple currency models. Fewer comparison scenarios. Few comparison scenarios will bring less data into memory during staging, materialized view including 10

Copyright 2008 Oracle, Inc. All rights reserved.

10/30/2008

PeopleSoft Enterprise EPM Red Paper

private views and recalculation via FLEX formula references to comparison scenarios. Minimize the number of private data entry views that reference history or other scenarios. Efficient FLEX formulas (performance consideration): Use explicit member selection or same as target rather than all members when possible.

Following these implementation design recommendations will help resolve these issues: Memory limits. Index limits. Performance problems.

Operating System Considerations

Running the application server as a 64-bit process should resolve the memory addressing issue, but not the index limit issue. As stated previously, this may not help improve performance, but will keep the application from failing due to lack of addressable memory. According to PeopleTools development, 64 bit processes have a vastly greater amount of addressable memory available compared to 32 bit processes (2^64 vs. 2^32). When running as a PeopleTools 8.46 32 bit process, in the calculation portion of the staging process at certain levels of data and complexity, we have seen the process requests memory, but no more addressable memory is available. The process dies. When running the same process on the same database as a PeopleTools 8.46 64 bit process, the process runs to completion. The following table documents the versions of PeopleTools that are certified with EPM 8.9 and 9.0. PeopleTools Version PeopleTools 8.46/8.47 runs as: PeopleTools 8.48 runs as: Tru 64 64 bit process 64 bit process HP-UX (IPF) Itanium 64 bit process HP-UX (PA) 32 bit process 64 bit process Solaris 32 bit process 64 bit process AIX 32 bit process 64 bit process Linux/x86 32 bit process 32 bit process Linux Zseries (mainframe) Not Supported 64 bit process Windows/x86 zOS 32 bit process 32 bit process

32 bit process

64 bit process

32 bit process

Note:

EPM 8.9 was released on PeopleTools 8.46. It is certified with PeopleTools versions up to 8.49. EPM 9.0 was released in August 2006 on PeopleTools 8.48. is also certified with PeopleTools 8.49.

Copyright 2008 Oracle, Inc. All rights reserved.

11

10/30/2008

PeopleSoft Enterprise EPM Red Paper

Appendix A Validation and Feedback

This section documents that real-world validation that this Red Paper has received.

CUSTOMER VALIDATION
PeopleSoft is working with PeopleSoft customers to get feedback and validation on this document. Lessons learned from these customer experiences will be posted here.

FIELD VALIDATION
PeopleSoft Consulting has provided feedback and validation on this document. Additional lessons learned from field experience will be posted here.

Copyright 2008 Oracle, Inc. All rights reserved.

12

10/30/2008

PeopleSoft Enterprise EPM Red Paper

Appendix B Revision History

Revision History
1. October 30, 2008: Created document. 2.

Copyright 2008 Oracle, Inc. All rights reserved.

13

10/30/2008

PeopleSoft Enterprise EPM Red Paper

Sizing and Scaling Guidelines for EPM Planning and Budgeting October 2008 Author: R. Yanetz Contributing Authors:] Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. Worldwide Inquiries: Phone: +1.650.506.7000 Fax: +1.650.506.7200 oracle.com Copyright 2008, Oracle. All rights reserved. This document is provided for information purposes only, and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor is it subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission. Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.

Copyright 2008 Oracle, Inc. All rights reserved.

14