OBI common mistakes
OBI · Understand the traps and how to avoid them.
Treating the BI Server as a single monolithic component and being unable to say which tier performs query compilation, which performs physical SQL generation, and where results are cached.
Candidates memorize marketing diagrams of the Oracle BI stack but never map each function (logical SQL parsing, federation, aggregation navigation, result caching) to a concrete process, so architecture questions that rephrase the same fact trip them up.
What to do instead
Build a one-page table listing each tier (client/presentation, BI Server, physical data sources) with the exact responsibilities performed there, and for every practice question state aloud which tier owns the behavior before answering.
Confusing logical (presentation/business model) objects with physical objects when asked where a calculation, filter, or join is defined.
The three-layer repository (Physical, Business Model and Mapping, Presentation) looks similar at each level, and candidates answer from memory of the UI tree rather than from the semantics of each layer.
What to do instead
For each repository object type, write down which layer it belongs to and what it is allowed to reference; practice tracing a single column from physical table through logical table source to presentation column.
Assuming a logical table source automatically aggregates data, or forgetting that sources must be ordered and mapped by level so the server can pick the right grain.
Aggregate navigation is the hardest repository concept; candidates see multiple sources on a logical table and assume the server always selects the most aggregated one without configuring source levels and content.
What to do instead
Study the aggregation/content tab of logical table sources: set the column aggregation rules and source levels explicitly, then predict which source a given query uses before checking the server's explanation of the physical SQL.
Building presentation layer objects directly against physical columns instead of exposing business model columns, or breaking the presentation hierarchy so drill-down fails.
The Presentation layer is the easiest place to click quickly, so candidates create columns without a parent logical column and then cannot explain why a dashboard cannot drill.
What to do instead
Always create the logical column in the business model first, then add the presentation column referencing it, and define explicit presentation hierarchies with correct levels for every dimension used in drill-down.
Mixing up column-level and measure-level aggregation, or setting a default aggregation that contradicts the physical grain, and expecting dashboard totals to reconcile.
Default aggregation is a small dropdown that is easy to ignore, and candidates do not check whether the measure is additive, semi-additive, or non-additive before using it in a pivot.
What to do instead
For each measure, decide explicitly whether it is additive over all dimensions, over some, or none; set default aggregation accordingly and verify totals against a hand-computed SQL query.
Confusing filters applied at the analysis level with selection steps, and being unable to predict how a prompted filter interacts with a dashboard prompt.
Both restrict rows but act at different stages; candidates answer from intuition about the UI order rather than from the evaluation sequence of prompts, filters, and selection steps.
What to do instead
Memorize the order in which prompts, analysis filters, and selection steps are applied, and for each practice scenario write the resulting row set by hand before checking the answer.
Assuming a dashboard prompt automatically constrains every analysis on the page, or forgetting that an analysis-level prompt overrides a dashboard prompt.
Prompt scoping is invisible in the UI; candidates build a page prompt and expect global filtering without mapping it to the presentation columns the analyses actually use.
What to do instead
Map each dashboard prompt to the exact presentation column it targets, confirm every affected analysis uses that column, and test precedence by setting conflicting analysis-level and dashboard-level values.
Testing security only as an administrator and never verifying row-level or column-level restrictions as the restricted user.
Administrators bypass filters, so candidates see all data and conclude the policy works; they also confuse application roles with database roles and with initialization-block variables.
What to do instead
Always test by impersonating the target user, verify both object privileges and data filters, and map each requirement to the correct mechanism: application role, catalog permission, row-level filter, or session variable from an initialization block.
Blaming the BI Server for slow queries without inspecting the generated physical SQL, or enabling result caching without understanding cache hit conditions and invalidation.
Candidates tune at the presentation level because that is what they can see, and they treat caching as a toggle that always helps rather than a mechanism keyed to logical SQL, user, and session variables.
What to do instead
For every slow query, first capture the physical SQL and check indexes, joins, and aggregation pushdown; then decide whether caching is appropriate by checking the cache key (logical request plus user/session context) and how event polling purges stale entries.
Treating repository deployment and integration as a file copy, forgetting that a repository must be checked in consistently and that the BI Server must be restarted or reloaded to pick up changes.
The Administration Tool and the running server are separate; candidates edit offline and expect immediate effect, or deploy a partially merged repository with unresolved conflicts.
What to do instead
Follow the full cycle: edit offline, run consistency check, merge and resolve conflicts, check in, then restart or reload the server and verify with a test analysis; document the same steps for integration objects such as initialization blocks and connection pools.