owp data sizing guidelines for epm pb

7/31/2019 OWP Data Sizing Guidelines for EPM PB

1/14


2/14


3/14


4/14

Table of Contents

Table of Contents........................................................................................................................................................4

Chapter 1 - Introduction .............................................................................................................................................5

Structure of this Red Paper 5

Related Materials 5

Chapter 2 - Sizing and Scaling Guidelines..............................................................................................................6

Purpose of this Document 6

Description of Issues 6Memory Limit ............................................................................................................................................................................ 6ACE Index Limit........................................................................................................................................................................7Impacts to EPM Planning and Budgeting Processes and Data Views ....................................................................................... 7

Data Volumes............................................................................................................................................................................. 8Data Volume-Drivers................................................................................................................................................................. 8Estimating Data Volume ............................................................................................................................................................ 8Data Volume and FLEX Formulas........................................................................................................................................... 10Implementation Design Options for Reducing Data Volumes.................................................................................................10Operating System Considerations ............................................................................................................................................ 11

Appendix A Validation and Feedback..................................................................................................................12

Customer Validation 12

Field Validation 12

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

Revision History ......................................................................................................................................................................13

Copyright 2008 Oracle, Inc. All rights reserved. 4


5/14

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 whoimplement, maintain, or develop applications for your PeopleSoft system. In this Red Paper, we discuss guidelineson how to diagnose a PeopleSoft Online Transaction environment, including PeopleSoft Internet Architecture andPortal 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 thereforebased on "real-life" problems encountered in the field. Although every conceivable problem that one couldencounter in this document, the issues that appear are the problems that prove to be the most common ortroublesome.

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 varywith each posted version. To see if the document has been updated since you last downloaded it, compare thedate 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 InternetArchitecture. To take full advantage of the information covered in this document, we recommend that you have abasic understanding of system administration, basic Internet architecture, relational database concepts/SQL, andhow 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 PeopleToolsPeopleBooks to ensure that you have a well-rounded understanding of our PIA technology. Note: Much of theinformation 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 InternetArchitecture Administration)

Application Designer (Development Tools|Application Designer)

Application Messaging (Integration Tools|Application Messaging)

PeopleCode (Development Tools|PeopleCode Reference)



6/14


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 determiningappropriate designs for EPM Planning and Budgeting releases 8.9, 9.0 and beyond. This document can helpmitigate 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-reportedcases as well as technical discussions between development and operating system vendors. Therecommendations 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 includeposition budgeting or asset detail activity types if there is a need to do so.

This is nota 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 informationbecomes available.

DESCRIPTION OF ISSUES

Memory Limit

EPM Planning and Budgeting uses the PeopleTools integrated Analytic Calculation Engine (ACE) included inPeopleTools 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 entryviews 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 whenPeopleTools runs as a 32-bit process where certain Planning and Budgeting processes and/or data views failed tocomplete or successfully load into pages that contain line item data. This is due to the use of ACE to createPlanning and Budgeting models.

Note: Position budgeting and asset detail activities were rewritten using PeopleCode and are much lessdependent 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. Usersecurity is respected and the system loads only the appropriate data based on a users access. For instance, adata 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 addressablememory. PeopleTools releases support multiple operating systems and operating system versions (IBM AIX 32-bitand 64-bit). Depending on the PeopleTools release, PeopleTools will run as a 32-bit process or as a 64-bitprocess. Even if an operating system version is 64-bit, PeopleTools may run only as a 32-bit process on thatversion. Please refer to the table at the end of this document for a summary of such support.



7/14


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

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 storethe cube cell data values in memory. This index is defined as a PSI64 type (the largest integer currently supportedby PeopleTools). Since ACE will also need to use one bit of this PSI64 type as the mask for the modify/non-modifyflag, the maximum integer number for this index will be 2^63 (~9.2e18). Thus the unique mapping algorithmrequires the cross product of the number of the dimension members in the cube to be less than 2^63, otherwise theindex 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 inACE internal in memory cube storage. There could be different unexpected behaviors depending on whether/howan overflowed index was created and how the system responds/accesses the memory pointed by that index. Thisdepends on which cube cell needs to be indexed (it is possible that all the cube cells that have values and need tobe indexed have the index value less than 2^63 even though the total cross product of the number of the dimensionmembers 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 beinteger index for cube cells that need to be indexed larger than 2^63 if the total cross product of the number of thedimension 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' nolonger 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 particularactivity-scenario is too large, the addressable memory for the operating system is exceeded and the activity-scenario (ACE model) does not get staged.

Recalculation.

A full model recalculation, in application terms, includes ACE model loading, the GetRowCount function andcalls, and the ACE cube collection. During recalculation, the internal ACE model routine named GetRowCounthas to build many internal structures in memory. If the data volumes in the model are too great, addressablememory 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, theamount 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, theamount of data loaded may exceed the addressable memory for the operating system if the volume is too high.



8/14


Data Volumes

The primary driver is the number of rows stored for a given activity-scenario (the ACE model). The number of rowsis 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 asingle activity-scenario/ACE model. These tests were run on PeopleTools 8.46 using a customer-providedbudgeting model. PeopleTools runs as a 32-bit process on these operating systems in releases 8.46 and 8.47:

Operating System Maximum # of Rows

Windows 800,000

HP-UX 700,000

AIX 380,000

The wide variation by operating system is determined by the algorithms and number of segments used formanaging 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 titledOperating 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 ofdimension members, and the sparsity factor of the data. Sparsity refers to the density of the dimensionintersections.

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



9/14


Planning Center (Departs) 520

Accounts 8

Currencies 1

Versions 3

Comparison Scenario 1

Base Budget Periods per scenario 12

Number of additional dimensions: 1

Products 58

Possible Detail Row Combinations 86,860,800

Sparsity Assumption 99.0000%

Physical Rows 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):

se l ec t COUNT( DI STI NCT ACCOUNT) f r om PS_BP_MDL_ACCT_VW WHERE BUSI NESS_UNI T = ' US001' ANDBP_PLANNI NG_I D = ' 2003_BUDGET' AND BP_ACTI VI TY = ' LI NEI TEM' AND BP_SCENARI O = ' 2003PROP'

2. Run the following SQL (repeat for each of your chartfield dimensions):

sel ec t COUNT( DI STI NCT B. OPERATI NG_UNI T) f r om PS_BP_LI _TBL A, PS_BP_DI M_DTL_TBL B WHEREA. BP_LI NE_SEQ=B. BP_LI NE_SEQ AND BUSI NESS_UNI T = ' US001' AND BP_PLANNI NG_I D = ' 2003_BUDGET'AND BP_ACTI VI TY = ' LI NEI TEM' AND BP_SCENARI O = ' 2003PROP' AND BP_BUDGET_VERSI ON = ' 1'

3. Multiply all the results together, then multiply that by the number of periods, number of currencies (add 1 forblank member), then multiply again by the number of budget centers. For example, if department is the budgetcenter, 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 isdetermining 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 anull value and they are not used. Only the physical rows of data are loaded into the ACE model. ACE has a featurecalled explicit tuples which handles the sparsity issue in terms of the size of the database. Having a very sparsemodel isnt an issue for ACE, unless the cross product of the number of dimension members exceeds the indexlimit 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 morestraightforward 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 includingnumber of time periods, and so on. For instance, if the actuals are stated as annual amount and the budget modelcalls for 12 months, the number of rows in the actuals would need to be multiplied by a factor of 12, since datawould presumably be stored in all 12 budget time periods. Similarly, you would multiply the number of rows in theactuals by the number of comparison scenarios, assuming each comparison scenario has the same combination ofdimension 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 productdimension, not all data will be budgeted to all 58 products. You would not multiply the actual data rows by a factorof 58 to estimate the number of budget rows. Unlike time periods, the product dimension is sparse in relation to allthe other dimensions. A sparsity assumption would need to be applied (for example, 58 x (1-95%)).



10/14


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

Data Volume and FLEX Formulas

Data volume and addressable memory are notdirectly related to flexible formulas. Data volume is the number ofrow 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 ACEdoes not encounter out-of-memory conditions.

When the ALL member is selected, the application converts the flexible formula into ACE calculation rules, and itneeds to refer to all the members in that dimension in the rule instead of only intended members. As a result, morerecalculations than necessary are performed. Again, this impacts performancerather 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 PeopleToolsrunning as a 64-bit process. However, the following design considerations should be taken into account as such anenvironment may not be available for every customer. In addition, an efficiently designed model will generally havebetter performance than a larger, less efficient model design. This is the only solution for the index limit issue. Thefollowing 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



11/14


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 indexlimit issue. As stated previously, this may not help improve performance, but will keep the application from failingdue 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 certainlevels of data and complexity, we have seen the process requests memory, but no more addressable memory isavailable. The process dies.

When running the same process on the same database as a PeopleTools 8.46 64 bit process, the process runs tocompletion.

The following table documents the versions of PeopleTools that are certified with EPM 8.9 and 9.0.

PeopleToolsVersion

Tru 64HP-UX (IPF)

Itanium

HP-UX(PA)

Solaris AIX Linux/x86LinuxZseries(mainframe)

Windows/x86 zOS

PeopleTools

8.46/8.47 runs

as:

64 bit

process64 bit process

32 bit

process

32 bit

process

32 bit

process

32 bit

process

Not

Supported32 bit process

32 bit

process

PeopleTools

8.48 runs as:

64 bit


64 bit

process

64 bit

process

64 bit

process

32 bit

process

64 bit


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.



12/14


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. Lessonslearned from these customer experiences will be posted here.

FIELD VALIDATION

PeopleSoft Consulting has provided feedback and validation on this document. Additional lessons learned fromfield experience will be posted here.



13/14


Appendix B Revision History

Revision History

1. October 30, 2008: Created document.

2.



14/14


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 wi thout notice. Thisdocument is not warranted to be error-free, nor is it subject to any other warranties or conditions, w hether expressed orally orimplied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. Wespecifically disclaim any liability with respect to this document, and no contractual obligations are formed either di rectly orindirectly by this document. This document may not be reproduced or transmitted in any form or by any means, electronic ormechanical, for any purpose, without our prior written permission.

Oracle, JD Edwards, and PeopleSoft are registered trademarks of Oracle Corporation and/or i ts affiliates. Other names may be trademarks of their respective owners.

owp data sizing guidelines for epm pb

Documents