Academy of Profit Center — Your Journey
Control Tower
Hall 6 of 9 · Academy of Profit Center · EPCM Study Tour
The observation deck
A 47-minute allocation run becomes a 90-second run — not through code changes, but through observation and targeted tuning. Calculation Analysis is the dashboard that tells you exactly where your model is bleeding time. This hall teaches you how to read the statistics, identify bottlenecks, and apply the performance settings that transform production runs from overnight jobs into on-demand reports.
Understanding Calculation Analysis
Every calculation run in EPCM leaves behind a trail of statistics. Calculation Analysis is where you read that trail — and where performance tuning begins.
After you calculate a model using Calculation Control, EPM Automate, or the REST API, EPCM records detailed statistics about every rule that ran: elapsed time, updated cells, scripts generated, and the execution order. The Calculation Analysis page — accessed via Home → Modeling → Calculation Analysis — displays these records and lets you generate diagnostic reports.
For NovaPrism's M01 (Actuals Allocation Process), a typical monthly close run touches all 5 rule sets, 18 rules, and writes to roughly 4,200 cell intersections. When the model runs in 90 seconds, Finance closes the books on time. When it takes 47 minutes, the CFO starts asking questions. The difference is almost always visible in the statistics.
Automating the close pipeline. In production, NovaPrism triggers
calculateModel via EPM Automate in a nightly scheduled script — not via the Calculation Control UI. After the run, exportData archives the statistics before auto-purge removes them. Groovy adds in-product validation before the run and writes a completion status flag to the cube after. For the full automation architecture — EPM Automate vs Groovy, the hybrid pipeline, and all EPCM-relevant commands — see the EPM Automate vs Groovy reference.90s
Tuned M01 Runtime
47m
Untuned M01 Runtime
18
Rules in M01
4,200
Cells Updated
The 80/20 of EPCM performance: In almost every slow model, 80% of the runtime comes from 2-3 rules. The Calculation Statistics Summary report shows you the "Top 10 Longest Running Rules" in descending order by elapsed time. Start there. If one rule takes 40 minutes out of a 47-minute run, fixing that rule fixes the model.
The Calculation Analysis page
Each row on the Calculation Analysis page is a calculation record — a snapshot of one model run at one POV.
The Calculation Analysis page lists every calculation that has been performed on your models. Each record includes the model name, POV (Scenario, Version, Period), start/end timestamps, status (Completed, Running, Failed), and the user who initiated the run. You can select any record to generate reports or re-run the calculation.
| Column | What It Shows | NovaPrism Example |
|---|---|---|
| Model | The model name that was calculated | M01 — Actuals Allocation Process |
| POV | Point of View: Scenario × Version × Period | Actual · Working · FY24-Q1 |
| Status | Completed, Running, Failed, or Cancelled | Completed |
| Start Time | When the calculation began | 2024-03-15 09:04:12 |
| End Time | When the calculation finished | 2024-03-15 09:05:42 |
| Elapsed | Total runtime (End - Start) | 00:01:30 |
| Initiated By | User or service account that triggered the run | svc_epm_scheduler |
Auto-purge behaviour: EPCM automatically purges old calculation records when the volume exceeds certain thresholds. If you need to retain a longer history — for audit, for trend analysis, for month-over-month runtime comparisons — use the Export to Excel option on the Calculation Analysis page to archive calculation runs before they're purged.
The three statistics reports
EPCM provides three levels of diagnostic detail. Know which report to use for which question.
Report 1
Calculation Statistics Summary
Use when: Initial performance triage
The Summary report gives you a high-level overview: calculation metadata, any errors/warnings in the Job Log, the Top 10 Longest Running Rules, and detailed statistics for every rule set and rule. Available in PDF, Excel, Word, HTML, or XML. This is your first stop when diagnosing a slow model.
Key insight: The Top 10 list is sorted by elapsed time descending. The #1 rule is your primary tuning target.
Report 2
Calculation Statistics Diagnostics
Use when: Deep-dive troubleshooting
The Diagnostics report provides additional rule execution detail useful for diagnosing performance issues. It's delivered as an Excel file with two worksheets: Job Statistics (overall run metadata) and Rule Statistics (per-rule breakdown with script counts, cell updates, and timing). Use this when the Summary report shows a problem but doesn't show the cause.
Key insight: The "Scripts" column tells you how many Essbase calc scripts EPCM generated for a rule. High script counts on Custom Calc rules often indicate missing FIX scoping.
Report 3
Calculation Statistics Comparison
Use when: Before/after tuning validation
The Comparison report lets you select two calculation records and compare them side-by-side. Use this after making a tuning change — compare the pre-change run against the post-change run to confirm the improvement. Also useful for comparing the same model across different POVs (e.g., Q1 vs Q2) to detect data-volume-driven slowdowns.
Watch out: If you're comparing runs from different time periods, EPCM may have auto-purged the older record. Archive important runs before tuning.
The statistics that matter
Not all numbers in the report are equally useful. Focus on these five.
| Statistic | What It Tells You | Warning Sign |
|---|---|---|
| Elapsed Time | Wall-clock time from rule start to rule finish | Single rule >50% of total runtime |
| Updated Cells | Count of cell intersections written by the rule | Unexpectedly high count (millions) or unexpectedly zero |
| Scripts Generated | Number of Essbase calc scripts EPCM created to execute the rule | Custom Calc with 1,000+ scripts — missing FIX statement |
| Execution Order | The sequence in which rules actually ran (may differ from design-time order in Parallel sets) | Unexpected ordering causing data dependency issues |
| Job Log Errors | Any errors or warnings that occurred during calculation | Any error — indicates rule logic or data issue |
Elapsed time vs actual execution: The elapsed time shown in statistics reports includes queue time and Essbase processing overhead — not just pure calculation. If the Calculation Analysis page shows 90 seconds but the Statistics report shows 120 seconds elapsed for Rule 1, the difference is queue/overhead. This is normal, but be aware of it when benchmarking.
Execution Control — triggering calculations
Before you can analyse, you must calculate. Execution Control is where you initiate runs — and where you configure multi-POV calculations.
Execution Control lives in Home → Modeling → Models → Execution Control. From here, you can run a single-POV calculation (select one data POV, apply its own rules) or a multi-POV calculation (apply the rules from one model POV against the data from one or more different POVs). Multi-POV is useful when you have a single rule set that applies across Actual, Forecast, and Budget scenarios — you define the rules once and execute against multiple data sets.
Multi-POV calculation example
/* Run M01 rules against both Q1 and Q2 data in a single execution */ Data POVs: Actual · Working · FY24-Q1 Actual · Working · FY24-Q2 Model POV (rules source): M01 — Actuals Allocation Process /* EPCM will run M01's 5 rule sets against both Q1 and Q2 data */ /* Two calculation records will appear in Calculation Analysis */
Run Express Calculation: For quick re-runs during development, use the Run Express Calculation option on the Execution Control page. It runs the model without generating a full calculation record — faster, but no statistics are logged. Use this for iterative testing, not for production runs you need to analyse.
Calculation settings that affect performance
EPCM has several application-level settings that can dramatically change calculation behaviour. Know what they do before you touch them.
Performance
Logical Clear vs Physical Clear
Application Settings → Clear Type
Logical Clear (default) marks cells as cleared without physically deleting them — faster, but the "cleared" data still occupies storage until the next restructure. Physical Clear actually deletes the data — slower during calculation, but cleaner storage. For NovaPrism, Logical Clear is the right choice — the monthly close needs speed, and restructures happen during maintenance windows.
Exam note: Know that Logical Clear is the EPCM default and is recommended for most implementations.
Performance
Allocation Rule Non Empty Tuple
Model Settings → Calculation Options
When enabled, EPCM automatically applies NONEMPTYTUPLE logic to Allocation rules — skipping empty cell combinations during the allocation pass. This can improve performance on sparse data sets. However, if your drivers are densely populated, the overhead of checking emptiness on every cell may actually slow things down. Test before enabling.
Warning: This setting affects Allocation rules only. Custom Calc rules always require manual NONEMPTYTUPLE in the script.
Performance
Optimize for Reporting
Model Settings → Calculation Options
When enabled (default), EPCM runs Essbase aggregations on the reporting cube after a calculation completes. This significantly boosts query and report performance — data is pre-aggregated along hierarchies. If you run multiple concurrent calculation jobs, only the last job to complete performs the aggregation, avoiding redundant work.
Best practice: Keep this enabled for production models. Only disable it during rapid iterative testing when you don't need reporting performance.
Parallelism
Maximum Calculation Threads
Application Settings → Calc Threads
Controls how many rules can run in parallel within a Parallel rule set. NovaPrism uses 5 threads. Increasing threads can speed up Parallel sets — but only if the rules are truly independent. If your infrastructure is constrained, more threads may cause resource contention and actually slow things down. Monitor before and after.
Warning: Increasing threads does not help Serial rule sets. Serial rules run one at a time by design — data dependencies require it.
Common bottleneck patterns
Most slow models fall into one of these four patterns. Learn to recognize them from the statistics.
| Pattern | Symptom in Statistics | Root Cause | Fix |
|---|---|---|---|
| Unscoped Custom Calc | One Custom Calc rule takes 40+ minutes; "Scripts" count in thousands | Missing FIX statement — EPCM iterates every cell intersection | Add FIX to restrict calculation to required members only |
| Missing NONEMPTYTUPLE | Custom Calc rule slow despite FIX; Updated Cells count lower than Scripts count | Script iterates over empty dimension combinations | Add NONEMPTYTUPLE(dim) to skip empty cells |
| Overly broad allocation | Allocation rule "Updated Cells" is millions — far more than expected cost objects | Allocation destination is too broad (e.g., all Customer × Product × Region combinations) | Restrict destination POV or use driver filters |
| Serial set serializing independent rules | Multiple rules in a Serial set show stacked elapsed times; no data dependency exists | Rules that could run in parallel are forced to run sequentially | Move independent rules to a Parallel set or create separate Serial sets |
The "Updated Cells" sanity check: Before running a calculation, estimate how many cells you expect the rule to update. NovaPrism's IT pool allocation should update ~4 entities × ~60 customers × ~12 products = ~2,880 cells. If the statistics show 2.8 million, something is wrong with the rule's scoping.
NovaPrism M01 tuning walkthrough
See how targeted changes transform NovaPrism's 47-minute M01 run into a 90-second production-ready model.
M01 Performance Analysis
Select a scenario to inspect
Context: NovaPrism's M01 model runs during the monthly close. Finance needs results within 2 minutes to hit their SLA. The untuned model takes 47 minutes. The CFO has escalated.
Before Tuning
Total Runtime47:12
Seq:10 Rule 143:08
Scripts Generated14,200
SLA StatusFAILED
91% of runtime in one rule. Classic unscoped Custom Calc pattern.
After Tuning
Total Runtime1:28
Seq:10 Rule 10:04
Scripts Generated3
SLA StatusPASSED
Same result. 31× faster. FIX + NONEMPTYTUPLE + Parallel restructure.
The tuning checklist
A systematic approach to EPCM performance tuning. Work through this list before escalating to Oracle Support.
| # | Check | How to Verify | Fix if Failing |
|---|---|---|---|
| 1 | Run Calculation Statistics Summary | Generate the report; review Top 10 Longest Running Rules | Identify the #1 bottleneck rule |
| 2 | Check Custom Calc FIX statements | Open rule definition; confirm FIX is present and scoped tightly | Add FIX with minimum required members |
| 3 | Check Custom Calc NONEMPTYTUPLE | Open rule definition; confirm NET wraps iteration logic | Add NONEMPTYTUPLE for sparse dimensions |
| 4 | Verify Allocation destination scope | Check rule's destination POV; estimate expected cell count | Restrict destination or add driver filters |
| 5 | Review Serial vs Parallel assignment | Check rule set type; verify data dependencies actually exist | Move independent rules to Parallel sets |
| 6 | Check Logical Clear setting | Application Settings → Clear Type | Ensure Logical Clear is enabled (default) |
| 7 | Review Optimize for Reporting | Model Settings → Calculation Options | Enable unless rapid iterative testing |
| 8 | Compare before/after | Run Comparison report on pre-change and post-change records | Confirm improvement; iterate if needed |
Archive before you tune: Before making any changes, export the current calculation record to Excel. This gives you a baseline to compare against — and proof that your changes actually improved things. The Comparison report is only useful if you have the "before" record.
Lab: Diagnose NovaPrism's M01 bottleneck
Practice the diagnostic workflow you'll use on real EPCM implementations.
Lab 6.1 — Calculation Statistics Analysis
Scenario: NovaPrism's Finance team reports that the M01 monthly close calculation is taking 47 minutes — well above the 2-minute SLA. The CFO has asked for a root cause analysis and a tuning plan. You have access to the Calculation Analysis page and the most recent M01 calculation record.
Navigate to Home → Modeling → Calculation Analysis and locate the most recent M01 calculation record
Click the Actions dropdown and select Calculation Statistics Reports → Summary (Excel format)
Open the report and scroll to the Top 10 Longest Running Rules section
Identify the #1 rule: seq:10 Rule 1 (IT GL Account Aggregation) — 43:08 elapsed (91% of total)
Note the Scripts Generated count: 14,200 scripts for a rule that should touch ~120 GL accounts
Document the diagnosis: Unscoped Custom Calc — missing FIX statement
Progress: 0%
Lab 6.2 — Apply Tuning Fixes
Scenario: Based on your Lab 6.1 diagnosis, you need to fix seq:10 Rule 1. Open the rule definition and apply the necessary scoping.
Navigate to Home → Modeling → Models → M01 → seq:10 → Rule 1
Open the Custom Calculation Script editor
Add FIX("ES", "PCM_Input") to scope the calculation to Enterprise Support at PCM_Input only
Wrap the aggregation logic in NONEMPTYTUPLE("Account") to skip empty GL accounts
Save the rule and re-deploy the model
Re-run M01 via Execution Control and verify the new runtime: ~4 seconds for Rule 1
Progress: 0%
Exam alignment — 1Z0-1082-25
This lab covers the "Calculating models" exam topic. Expect questions on: accessing Calculation Analysis, interpreting statistics reports, identifying bottleneck causes, and knowing which settings affect performance (Logical Clear, Optimize for Reporting, NONEMPTYTUPLE).
Exam practice — Calculation Analysis
Test your knowledge on the exam topics covered in this hall.
0/5
Your Score
Hall 6 exam takeaways
Key facts for 1Z0-1082-25
- Calculation Analysis is accessed via Home → Modeling → Calculation Analysis
- The Calculation Statistics Summary report shows the Top 10 Longest Running Rules
- Updated Cells count tells you how many cell intersections a rule wrote
- Logical Clear is the EPCM default and is faster than Physical Clear
- Optimize for Reporting runs Essbase aggregations after calculation — keep it enabled for production
- Multi-POV calculations can apply rules from one POV against data from multiple POVs
- A high Scripts Generated count on a Custom Calc rule indicates missing FIX scoping
- EPCM auto-purges old calculation records — archive important runs via Export to Excel