Search Results x_mode

Overview

APPS.AD_ZD is the core Oracle E-Business Suite package that implements and manages the Edition-Based Redefinition (EBR) infrastructure introduced with Online Patching in EBS 12.2. Where 12.1.1 relied on traditional patching downtime through adpatch and AutoPatch phases, 12.2.x uses multiple database editions to run the file system and database tiers of the patch cycle while the production application remains online. AD_ZD is the PL/SQL layer that orchestrates this machinery: it creates and retires editions, switches the runtime edition, controls the logon trigger that routes new sessions to the correct edition, disconnects existing sessions at cutover, and executes the DDL that each patch phase requires. The HEADER line (ADZDXS.pls 120.25, shipped January 2013) confirms the package is part of the 12.2 code line and is owned by APPS with definer-style privileges, declared as authid current_user.

The package is documented in ETRM 12.2.2 with an API classification of OTHER, reflecting that it is an internal, AD utilities-owned package rather than a published business API. It is referenced by 28 other packages, largely the Online Patching driver code executed through ADOP and AutoPatch.

Key Procedures and Functions

The documented interface divides into helper routines, edition lifecycle procedures, and online patching phase control.

• LOG, ERROR — Write informational and error messages to the AD_ZD log repository and raise the standard error for the calling phase.
• EXEC — Overloaded helper that executes dynamic SQL (VARCHAR2 or CLOB) with a logging module name and an optional ignore-error flag; this is the workhorse used by all phase procedures.
• LOAD_DDL — Loads DDL statements for a given patch phase (PREPARE, CUTOVER, CLEANUP, etc.) into the edition so they can be applied at the correct point in the cycle.
• APPS_SCHEMA, APPLSYS_SCHEMA — Return the current APPS and APPLSYS schema names, accounting for edition-specific object resolution.
• IS_EDITIONS_ENABLED — Reports whether the database is in an editions-enabled, online-patching capable configuration.
• GET_EDITION, GET_EDITION_TYPE, SET_EDITION — Retrieve the current edition name or type (RUN, PATCH, PREPARE, etc.) and set the session’s edition context.
• CHECK_SPACE — Validates available tablespace and free space before an edition is created.
• CREATE_EDITION, RETIRE_EDITION, DROP_EDITION, DROP_OLD_EDITIONS — Manage the full edition lifecycle: create the new patch edition, retire the previous runtime edition, drop it, and purge all obsolete editions.
• ALTER_LOGON_TRIGGER — Enable or disable the database logon trigger that directs new connections to the appropriate edition. This is the procedure directly relevant to the search term logon_trigger_status.
• LOGON_TRIGGER_STATUS — Returns the current enabled or disabled state of the EBS logon trigger, allowing ADOP and operators to confirm that session routing is in the expected state before and after a cutover.
• KILL_SESSIONS — Terminates active sessions for a specified edition type, essential for ensuring no user remains attached to the old edition at cutover.
• PREPARE, FINALIZE, COMPILE, CUTOVER, CLEANUP, ABORT — The phase control API. Each procedure performs the database-side work for the corresponding ADOP phase.

Tables Accessed

AD_ZD queries and modifies several data dictionary views (via APPS synonyms) to drive edition management. ALL_EDITIONS, DBA_EDITIONS, and DBA_OBJECTS_AE provide the edition catalog and editioned object metadata used to determine which objects are patched. DATABASE_PROPERTIES exposes the default edition and related database settings. DBA_DATA_FILES and DBA_FREE_SPACE back CHECK_SPACE. DBA_TRIGGERS and DBA_USERS support logon-trigger inspection and session/user validation, while DBA_TAB_PRIVS is used for privilege checks. V$SESSION and V$PROCESS supply the session information consumed by KILL_SESSIONS. DBMS_LOB, DBMS_SESSION, DBMS_SQL, and DBMS_STATS are invoked for CLOB handling, session control, dynamic SQL execution, and statistics gathering during the patch cycle.

Usage Notes

AD_ZD is not intended for direct application use; it is invoked by the Online Patching infrastructure and is a prerequisite for 12.2 patching operations. The logon_trigger_status function is typically queried when diagnosing session-routing problems during adoption, for example to verify that ALTER_LOGON_TRIGGER left the trigger enabled after an aborted cutover. In the 12.1.1 context there was no EBR, so AD_ZD exists only in 12.2.x; the corresponding 12.1.1-only scenarios relied on AD utilities and adpatch alone. When custom code must run during a patch cycle, developers should respect the current edition context returned by GET_EDITION rather than hard-coding edition names, and should not call AD_ZD phase procedures directly. All log output can be reviewed through the standard ADOP log locations to trace execution.