Search Results ad_zd_mview




Overview
Explore in AI Chat

Overview

AD_ZD_MVIEW is an Oracle EBS Applications (APPS) PL/SQL package body that belongs to the Online Patching (adzd) infrastructure introduced with the AD/TXK codelevel delivered in EBS 12.2. Its central business function is the creation and lifecycle management of materialized views (and their supporting materialized view logs) used during the online patching cutover process. In 12.2, Edition-Based Redefinition (EBR) allows patches to be applied while the production application remains online; a short downtime is required only for the final cutover. AD_ZD_MVIEW supports that model by generating, upgrading, and swapping the materialized views that consolidate data across editions so that the newly patched edition presents a consistent, complete data set immediately after cutover.

The package is classified as OTHER in the ETRM repository and is listed with a status of INVALID, which is expected because the package body is recompiled against the target database iteratively as the AD_Z* stack is deployed. In the ETRM 12.2.2 dependency inventory, APPS.AD_ZD_MVIEW references numerous database objects but is itself not referenced by any database object, and it is reported as being referenced by five other packages that depend on it.

Key Procedures and Functions

The documented interface exposes thirteen procedures and functions. The names of most of them map directly to the materialized view lifecycle stages operated during online patching:

  • GENERATE – Produces the definition (DDL) of the materialized views required for a patching run.
  • INSTALL_MVQ_ARCH – Installs the materialized view query architecture used to collect and stage data changes.
  • DROP_MVQ – Removes the materialized view query structures once they are no longer needed.
  • DROP_MV – Drops the materialized views created by the package.
  • PATCH / PATCH_LOG – Applies the package's patching operations and writes diagnostic log records through AD_ZD_LOG.
  • UPGRADE / UPGRADE_DB – Upgrade existing materialized view definitions and database-level artifacts so they match the current edition's requirements.
  • CUTOVER – Performs the final switch of the materialized views during the patching cutover, making the new edition's data visible.
  • FINALIZE – Completes cleanup and verification after cutover.
  • GET_MVQ_NAME / GET_MV_NAME – Return the naming conventions used for the generated materialized view queries and materialized views.

No parameter lists are documented in the ETRM metadata, so callers should not rely on undocumented signatures.

Tables Accessed

The package reads and writes both AD dictionary tables and Oracle data dictionary views. Among the AD tables, AD_OBSOLETE_OBJECTS, AD_PATCHED_TABLES, AD_ZD_CLOB, and FND_PRODUCT_INSTALLATIONS provide the patching state and product installation context, while FND_ORACLE_USERID supplies schema/credential information. The data dictionary views DBA_MVIEWS, DBA_MVIEW_LOGS, DBA_MVIEW_LOG_FILTER_COLS, DBA_TABLES, DBA_TAB_COLS, DBA_INDEXES, DBA_CONSTRAINTS, DBA_DEPENDENCIES, DBA_OBJECTS, DBA_SYNONYMS, DBA_TAB_COMMENTS, DBA_TAB_PRIVS, DBA_TRIGGERS, and DBA_VIEWS allow it to introspect and validate the objects it is generating or dropping. DBMS_METADATA, DBMS_MVIEW, DBMS_SQL, and DBMS_LOB supply DDL extraction, refresh management, dynamic SQL, and large-object handling respectively.

Usage Notes

AD_ZD_MVIEW is an internal online patching utility, not an end-user API. It is invoked by the AD patching driver and by the other five dependent packages during an online patch cycle, effectively in the phases of the ADOP (Online Patching) lifecycle: prepare, apply, and cutover. It is not exposed through EBS forms and there is normally no concurrent program that a user would submit directly. Administrators may observe its activity through the AD diagnostic log rather than calling it manually. Custom code should not invoke AD_ZD_MVIEW directly; if extension of online patching behavior is required, Oracle-supported AD utilities and documented ADOP commands should be used instead. Because the package body is frequently reported as INVALID and is recompiled as part of patching, its validity state alone is not a reliable indicator of failure.