Results for “refresh_mode”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

IBE_ECR_MVLOG is a table owned by the IBE (iStore) schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It functions as the materialized view refresh history log for the iStore e-commerce application. Each row records the outcome of a materialized view refresh operation, capturing whether the refresh succeeded or failed, how long it took, what refresh mode was used, and which concurrent request drove the operation. Because iStore relies on a set of aggregate materialized views to serve catalog, pricing, and order-capture queries efficiently, IBE_ECR_MVLOG provides the operational audit trail that administrators use to diagnose refresh failures and monitor warehouse-style data freshness.

From a data-modeling perspective, the heuristic Data Vault classification for this object is standalone, meaning it does not participate as a classic hub, link, or satellite. It behaves most like an operational log or audit trail table: it is keyed by a surrogate identifier and references a security group, but it is not part of a normalized business-entity hub-and-spoke structure.

Key Information Stored

The table contains 27 documented columns. The most significant are grouped below:

• MVLOG_ID — surrogate primary key, enforced by IBE_ECR_MVLOG_PK and also uniquely indexed by IBE_ECR_MVLOG_U1. This is the single business-key candidate in the documented schema; there is no natural composite key.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the Oracle Applications framework to detect concurrent updates.
• MVIEW_NAME — the name of the materialized view that was refreshed, the principal business identifier for reading the log.
• REFRESH_MODE and REFRESH_STATUS — the refresh strategy (for example complete versus fast) and the terminal state of the run.
• BEGIN_DATE, END_DATE, and REFRESH_DURATION — start, completion, and elapsed timing data used for performance analysis.
• ERROR_CODE and ERROR_MESSAGE — diagnostic detail when a refresh fails.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, and PROGRAM_UPDATE_DATE — the concurrent program context that generated the entry.
• SECURITY_GROUP_ID — the foreign key to FND_SECURITY_GROUPS, scoping the log record to a security group.
• CURRENCY_CODE, CONVERSION_TYPE, FACT_SOURCE, DAY_BIN_OFFSET, FORCE_REFRESH_FLAG, QUARTER_BEGIN_FLAG, and PERIOD_SET_NAME — parameters that describe the refresh window and the sourcing of the underlying fact data.
• Standard WHO audit columns (CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN) record row provenance.

Common Use Cases and Queries

The primary use case is operational monitoring of the iStore materialized view refresh cycle. A typical query retrieves the most recent refresh for a given view, including its status and duration:

• SELECT MVIEW_NAME, REFRESH_MODE, REFRESH_STATUS, BEGIN_DATE, END_DATE, REFRESH_DURATION FROM IBE.IBE_ECR_MVLOG WHERE MVIEW_NAME = :p_mview ORDER BY BEGIN_DATE DESC;
• Failure triage: SELECT MVLOG_ID, MVIEW_NAME, ERROR_CODE, ERROR_MESSAGE, BEGIN_DATE FROM IBE.IBE_ECR_MVLOG WHERE REFRESH_STATUS = 'FAILED' AND BEGIN_DATE > SYSDATE - 7;
• Trend reporting on refresh performance by joining REFRESH_DURATION against BEGIN_DATE to identify views whose refresh times are degrading.
• Correlating a refresh to its concurrent request using REQUEST_ID against FND_CONCURRENT_REQUESTS.

Related Objects

The documented foreign key identifies FND_SECURITY_GROUPS via SECURITY_GROUP_ID, so any query that scopes results to a security group can join on that column. The following objects are most significant in practice:

• FND_SECURITY_GROUPS — referenced by SECURITY_GROUP_ID.
• FND_CONCURRENT_REQUESTS — joined on REQUEST_ID to trace the driving concurrent request.
• FND_CONCURRENT_PROGRAMS — joined on PROGRAM_ID and PROGRAM_APPLICATION_ID to identify the refresh program.
• FND_USER — joined on CREATED_BY and LAST_UPDATED_BY for accountability.
• The iStore materialized views named in MVIEW_NAME, together with their underlying base tables, which constitute the subjects of the logged refreshes.

As a standalone log object, IBE_ECR_MVLOG is referenced by no child tables; it depends on, rather than is depended upon by, the framework tables listed above.