PBCS Best Practices - **DRAFT**

CEAL Team – Oracle Development

April, 2016

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
Overview

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 3
Overview
• PBCS is a standardized environment. Therefore, it is imperative that all general
Planning and Essbase best practices are adhered to and implemented for optimal
performance on PBCS.

• This PowerPoint is intended for experienced consultants that have a full understanding
of Planning and Essbase best practices.

• PBCS design best practices are a compilation of source documentation found in the
PBCS Documentation, Essbase Database Administration Guide, various blogs and
whitepapers created by partners and Oracle Consulting Services, as well as years of
field experience and methodical testing.

4
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
Agenda

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 5
Agenda 1 Design options in PBCS

2 Relevance of Dimensions to Processes

3 BSO Optimization Best Practices

4 ASO Optimization Best Practices

5 Smart Push Best Practices

6 Data Push Best Practices

7 Web Forms Best Practices

8 Business Rules Best Practices

9 BSO Defragmentation to Optimize Plan Types
10 Migrating on premises to PBCS Considerations
11 Customer Back-up Considerations
12 Customer Service Request (SR) Best Practices

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 6
1. Design Options in PBCS

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 7
Design Options in PBCS

There are three design tracks for consideration on PBCS:

1. Classic Planning Design

2. Zero Based Budgeting (ZBB) Design
3. Custom BSO-ASO Hybrid Design

8
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
Design Options in PBCS
Classic Planning Design

1. All budgeting and forecast processes are within BSO plan types

2. Design considerations:

 Use out of the box currency where there are multiple reporting currencies.

 For one or two reporting currencies, use a custom currency conversion design in order to minimize
the number of dimensions within the plan type.

3. At the end of all budgeting and forecast processes, data is transferred to ASO for
reporting

9
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
Design Options in PBCS
Zero Based Budgeting (ZBB) Design
1. ZBB starts with a fresh budget every year without reference to the past. Every line item
of the budget, rather than only the changes, must be approved.
2. Design considerations:
 Additional Line Item dimension is needed
 Separate Driver and Account dimensions are needed. Account sparse and Driver dense and tagged
with the Accounts member property
 All Driver calculations should be self-contained within an Account sub-package and have no
dependencies on other Account sub-packages
 Although ZBB applications contain many smart lists, the number of smart lists mapped to ASO
should be limited.
3. At the end of all budgeting and forecast processes, data is transferred to ASO for
reporting

10
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
Design Options in PBCS
Custom BSO-ASO Hybrid Design

1. All budgeting and forecast processes are done at level 0 only in BSO plan types
2. Design considerations:
 Smart Push is frequently used to push level 0 data from BSO to ASO to see aggregations. Smart
Push is data transferred by end user web forms and should be small amounts of data.
 Data Push is frequently used to push level 0 data from BSO to ASO to see aggregations. Data Push
is a batch process to transfer larger amounts of data.
 Thoroughly understand all Smart Push and Data Push processes to avoid contention
3. ASO plan types are used during the entire planning approval and reporting processes for
all aggregated parent data

11
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
2. Relevance of Dimensions to Process

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 12
Relevance of Dimensions to Processes

1. Each plan type should be well defined for a specific business purpose
 Define relevant process to dimensions/hierarchies/members and data
 Reporting requirements should be in separate plan type
 Avoid inter-dimensional irrelevance
2. Assess why NoMember members are needed for a given process in each dimension. If
it’s to skip the dimension, that process should be in a separate plan type. NoMember
members should only be used to store allocation rates, drivers and/or lump sums to
allocate.
3. Review the Account dimension to ensure only the GL accounts needed for the main
business purpose of each plan type are added.

Essbase Dbag: http://docs.oracle.com/cd/E66975_01/doc.1221/essbase_db/frameset.htm?dindesin.html#dindesin24268

13
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
3. BSO Optimization Best Practice

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 14
BSO Optimization Best Practices

1. Account and Period dimensions should be the only dense dimensions

2. Dense block should be within 8 KB to 200 KB
3. Dimension order should follow either hour-glass or modified hour-glass order
 Hour-glass order is best used in cases where most calculations are performed in batch and
contain full sparse dimension aggregations.
 Modified hour-glass order (non-aggregating sparse dimensions are placed after the aggregating
dimensions) is best used in cases where most calculations are performed on save in web forms
with only partial aggregations.

Continued 
15
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
BSO Optimization Best Practices
4. Member properties should follow these general rules:
 Parent levels and member formulas in the dense block should be set to Dynamic Calc or Label Only
to avoid the necessity of dense aggregations.
 Use Label Only in sparse dimensions where reasonable to eliminate unnecessary data blocks.
 Use Dynamic Calc in sparse dimensions where the impact on query performance and data exports
is minimal to eliminate unnecessary data blocks.
o It is now possible to tag sparse dynamic calc members with two pass so the calculation occurs before the
attribute calculations. However, it is recommended to avoid formula designs that require two pass on
sparse dynamic calc members for better performance.
 Do not use Dynamic Calc and Store in PBCS i.e. where multiple users are running write operations
 Use Unary Operator ~ or ^ where reasonable to eliminate unnecessary aggregated data blocks
 Utilize implied shares where possible

Continued 
16
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
BSO Optimization Best Practices

5. Minimally use Dynamic Calc @Xref formulas. Use HSP_NOLINK UDA to stop the @Xref
generation across plan types
6. Only create plan types that are needed. PBCS allows new plan types to be added but
not deleted.
7. Only create years that are needed for the budget/planning process. All historical year’s
data should be pushed to the ASO plan types.
8. Move archived versions into ASO to keep the size of the BSO plan types down as much
as possible.
9. Alternate hierarchies needed for reporting should be in ASO plan types. If BSO plan
types require alternate hierarchies during the Planning process, consider Dynamic Calc
on parents.

17
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
4. ASO Optimization Best Practices

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 18
ASO Optimization Best Practices
1. Select the proper compression dimension for performance
2. Balance stored vs. dynamic dimensions and hierarchies for best query performance
3. Same best practices for member properties and unary operators apply to ASO as BSO
4. Compact outlines regularly
5. If multiple data slices exist, merge slices to improve query performance and reduce
database size.
 Multiple data slices are generated via data loads and/or Smart Push. Merge Data -> All ->
Remove cells with zero value merges all incremental slices into the main database slice and
removes zero value cells (logically clearing data from region results in a cell with a value of zero).
Performing this operation will significantly reduce database size.
6. Recommend query tracker for aggregate view method for best results
7. Optimize all MDX member formulas, use non-empty directives i.e. NONEMPTYMEMBER
or NONEMPTYTUPLE
Essbase Dbag Part X: http://docs.oracle.com/cd/E66975_01/doc.1221/essbase_db/frameset.htm?part_aso.html
19
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
5. Smart Push Best Practices

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 20
Smart Push Best Practices

1. Only push level 0 cells that can potentially be changed by an end user
2. Automatic push should be limited because users tend to save data in a web form before
finishing their data entry. Don’t over use Smart Push.
3. Create summary level 0 forms in the BSO plan type so that users carry out one single
Smart Push operation on all data, after all in-progress edit/save operations are
completed
4. Smart Push is intended for moving small amounts of data from the BSO to the ASO plan
types. It is not intended as a method of moving all or large amounts of data.

PBCS Documentation: https://docs.oracle.com/cloud/latest/pbcs_common/CSPAM/ch07s04s02s03.html

21
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
6. Data Push Best Practices

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 22
Data Push Best Practices

1. Only push level 0 cells that can potentially be changed by an end user.

2. If Smart Push is used, Data Push should only be done in batch to avoid contention issues
with Smart Push processes.

3. Data Push utilizes DATAEXPORT calc command. Avoid exporting dynamic calc data.

PBCS Documentation: https://docs.oracle.com/cloud/latest/pbcs_common/CSPAM/push_dat.html

23
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
7. Web Forms Best Practices

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 24
Web Forms Best Practices
1. Run Diagnostics Tools -> Diagnostics -> Grids to ensure web forms initial performance is
acceptable
2. The Diagnostics Tool uses the last used Run-Time-Prompt (RTP) and user variables so
recommend the implementer run on the customer’s pod with the full set of data
3. Design forms with dense dimensions on rows and columns, with sparse dimensions on
page and POV, which allows all the data to be retrieved from one block
4. Recommend using the Suppress Missing Blocks setting to improve performance.
Consider either reducing the number of accounts or adding a form accessed by a right
click menu option to add new sparse dimension row members. If Suppress Missing
Blocks is used, an additional process will be needed to add sparse dimension row
members that currently have no data.

PBCS Documentation: https://docs.oracle.com/cloud/latest/pbcs_common/CSPAG/ch06s02s01s01.html

25
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
8. Business Rules Best Practices

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 26
Business Rules Best Practices
1. Business Rule Environment Optimizations - See blog section:
 Environment Setting

2. Business Rule Calculation Performance Optimizations - See blog sections:

 Optimization/Performance  Level of Calculations  Aggregations
 FIX Statements  Syntax  Calc/Fix Parallel
 IF Statements  Block vs. Cell Mode
 Only Calculate blocks  BottomUp vs. TopDown
required  Create Blocks
3. Debug during development - See blog. Section:
 Debug Methodology for Developing Business Rules
4. Currency Conversion calculations –
 Consider calculating currency conversions when saving form data, restricting the calculation on the
POV and selected page members. Running currency conversions in batch can be a time consuming
process.
CEAL Blog: EPM 11.1.2.x – Planning/PBCS Best Practices for BSO Business Rule Optimization https://blogs.oracle.com/pa/entry/epm_11_1_2_x3

27
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
9. BSO Defragmentation to Optimize Plan Types

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 28
BSO Defragmentation to Optimize Plan Types
Step1 – Replace Zero Blocks with #Missing

1. Create a business rule to replace zero blocks with #missing blocks

 Set business rule environment to optimize for this type of business rule:
SET UPDATECALC OFF;
SET CREATENONMISSINGBLK OFF;
SET CREATEBLOCKONEQ OFF;
FIXPARALLEL(NumberThreads, @RELATIVE("SparseDim",0))
FIX on all level 0 sparse dimension @RELATIVE("SparseDim",0)

Note:
• The above calc commands are normally disabled by default but recommend having in case another business rule
enabled.
• Use FIXPARALLEL to help improve performance i.e. FIXPARALLEL(6, @RELATIVE(“Scenario”,0))
• Be sure to ENDFIXPARALLEL

Continued 
29
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
BSO Defragmentation to Optimize Plan Types
Step1 – Replace Zero Blocks with #Missing
 There are two calculation designs that can be written to change zero blocks to
#missing blocks. Use one of the following for best performance, depending on
dimension design, data patterns and processes:

Method 1: Method 2:
Dense or Sparse Calculation: IF on dense member in block mode

“DenseMbr” = “DenseMbr” * “DenseMbr” / DenseMbr”; "DenseBlockHeader" (

"SparseMbr” = "SparseMbr" * " SparseMbr " / " SparseMbr "; @CALCMODE(BLOCK);
IF ("DenseMbr" == 0)
Note: "DenseMbr" = #Missing;
The above formulas will result in the original value, or if zero, ENDIF
will change to #missing.

Continued 
30
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
BSO Defragmentation to Optimize Plan Types
Step2 – Remove #Missing Blocks to Reduce BSO Database Size

2. Remove #missing blocks to reduce BSO database size. There are two methods available
to clear #missing blocks:
 Force explicit dense restructure. The force restructure process can only be run manually in PBCS
through the Database Properties section of Calc Manager: Calc Manager -> Actions -> Database
Properties -> Right Click on Db -> Restructure database
 Clear all data and reload export files

31
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
10. Migration On Premises Planning to PBCS - Considerations

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 32
Migration On Premises Planning to PBCS
Considerations

1. Lift and shift migration from On Premises Planning to PBCS is not advised. It is expected
that implementation partners will design an application which follows PBCS best
practices, and not be solely influenced by an On Premises design.

2. PBCS is a standardized environment, which is optimized for all customers.

Customization of infrastructure is not possible on PBCS, therefore it is not possible to
compare environments.

PBCS Documentation: http://docs.oracle.com/cloud/latest/pbcs_common/CSPGS/migrate_app_onpremise_to_pbcs.html

33
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
11. Customer Backup Considerations

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 34
Customer Backup Considerations
1. Oracle runs a mandatory Automatic Maintenance Window (AMW) for PBCS, which is run
at a time specified by the customer.
2. Maintenance snapshots are created primarily to restore the customer’s service instance
in the case of a catastrophic failure.
 Oracle’s AMW snapshot is kept for 24 hours, and then overwritten by the next snapshot using the
same file name.
 Oracle recommends the customer should download the maintenance snapshots regularly to a local
machine, taking care to rename so as not to over write previous copies.
 If required, customers should take their own snapshots/backups to be used in the event of
recovery and/or to keep a record of the end of a budget/forecast process.
 The customer’s AMW snapshot, if kept on the pod vs. local drive, will count towards the size quota
for that pod.
 If snapshots are kept on the pod, the snapshot will be deleted after 60 days as a cleanup process.

PBCS Documentation: http://docs.oracle.com/cloud/latest/pbcs_common/CSPGS/maintenance_backup.html

35
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
12. Customer Service Request (SR) Best Practices

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 36
Customer Service Request (SR) Best Practices
1. Always create an SR for each issue:
 Create an SR for each separate issue, when an issue occurs.
 Identify functionality and describe issue with as much detail as possible e.g. issue is with web
forms, SmartView queries, business rule creation, business rule execution, security, etc.
 Provide exact steps to reproduce. What exactly happened? Etc
 Provide a job status screenshot if appropriate as this includes timestamps and job id numbers that
may help with analysis.
 Identify which pod the issue exists i.e. test, prod, etc. so that we know which version and pod being
worked on; also, which pod to collect logs from (in the event the UDR does not provide sufficient
logs).
 Run “Provide Feedback” and provide UDR# (see below how to “Provide Feedback”). If the logs
required are not in the UDR then Support or Development can access other logs on the customer’s
pod to help with SR investigation but these logs are only kept for 7 days.

Continued 
37
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
Customer Service Request (SR) Best Practices
2. “Provide Feedback” should be run for all issues at the exact time stamp of the issue:
 Select Help -> Provide Feedback from the menu when the error occurs.
 This creates a User Diagnostic Report (UDR) with a unique # and identifier plus, importantly for
diagnostics, an exact time stamp of the issue.
 Behind the scenes, this process zips up recent logs.
 This does NOT automatically create an SR. Take a screenshot of this # or write it down in order that
you can provide the reference number to Support.
3. Monitor progress of each SR and respond to any questions Support requests in a timely
manner.

PBCS Documentation https://docs.oracle.com/cloud/latest/pbcs_common/CSPGS/prov_feedback.htm

38
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
13. References

Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 39
References
PBCS Documentation

1. Smart Push Best Practices

2. Data Push Best Practices
3. Web Forms Best Practices
4. Business Rules Best Practices
5. Migrating On Premises Planning to PBCS Considerations
6. Customer Back-up Considerations

PBCS Documentation
40
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
References
Essbase Database Administration Guide and/or Tech Ref Documentation

1. Relevance of Dimensions to Processes Chapter 4

2. BSO Optimization Best Practices
3. ASO Optimization Best Practices Part X
4. Business Rules Best Practices
 Calc Command DATAEXPORT
5. BSO Defragmentation to Optimize Plan Types Chapters 53 & 55

Essbase Database Administration Guide and/or Technical Reference Guide

41
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
References
Other Links

1. CEAL Blog Links:

– EPM 11.1.2.x – Planning/PBCS Best Practices for BSO Business Rule Optimization
https://blogs.oracle.com/pa/entry/epm_11_1_2_x3

42
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 43