Smart View is slow, here is why
The retrieve that takes two minutes is almost never the network and almost always member design. Five causes explain nearly every slow grid, and each has a specific fix.
◆ The five causes— straight from Oracle's own troubleshooting guidance, translated into fixes a human can follow.
| Cause | What is happening, and the fix |
|---|---|
| Level-0 members set to dynamic calc, with no formula | The engine computes nothing and gains nothing, but pays the dynamic price on every retrieve that touches them. Set them to store, and the grid stops paying rent on empty math. |
| Seeded members you cannot change | Consolidation applications ship members whose storage is fixed. The documented fix is indirect and works: add a stored placeholder child under the seeded member and let data live there, so retrieves read stored values instead of recomputing the parent. |
| Solve order fights | When a custom dimension carries a solve order that forces Account to aggregate last, ratio and rate accounts compute on garbage and views crawl. Solve order is a deliberate design, set once, documented, and checked whenever a formula member misbehaves. |
| Two-pass calculation left on | An old habit from on-premises outlines. On members that do not need it, it doubles work for nothing. Audit which members carry it and why; most should not. |
| To-date views computed at retrieve time | Quarter-to-date and year-to-date can be stored when consolidation runs, or computed by rule members every time someone opens a grid. Storing views costs consolidation time and application size and pays it back on every retrieve. Heavy reporting months earn stored views; the middle path recalculates views only for the entities that changed. |
◆ The working method— where to look, what to read, and the loop that actually fixes it.
The Activity Report lives under the application overview, generated daily, and most administrators have never opened it. Its most useful table lists the thirty worst performing user actions of the day, with durations and the object behind each one. That table is the diagnosis: it tells you which grid, which form, and which retrieve is eating the day, so you fix the real offender instead of the loudest complaint.
The loop from there is short. Take the slowest grid from the report, list the members it touches, check each against the five causes above, storage type, formula, solve order, two-pass, view storage, fix what fails the check, and retrieve again. One pass through this loop usually turns minutes into seconds, and the report the next morning shows it. Consolidation runtime is a different problem with different levers, application size, dense and sparse design, and it gets its own treatment in the consolidation module. Guidance verified against Oracle's troubleshooting documentation, July 2026.
- Activity Report
- The daily report under the application overview. The thirty worst actions table is the diagnosis.
- dynamic calc
- Computed at retrieve time. Right for formulas, rent on nothing when the member is empty.
- stored placeholder child
- The documented workaround for seeded members whose storage cannot change.
- solve order
- The sequence formula members compute in. A design decision, not a default to inherit.
- two-pass
- A second calculation pass. Rarely needed, often inherited, always worth auditing.
- stored views
- To-date values written at consolidation instead of computed at retrieve. Size for speed.