Search Results ad_zd_seed




Overview
Explore in AI Chat

Overview

AD_ZD_SEED is an Oracle Applications (APPS) schema PL/SQL package body that forms part of the Online Patching infrastructure introduced with Oracle E-Business Suite 12.2. Its primary business function is to seed, prepare, and manage the database objects that participate in the edition-based redefinition (EBR) model used by Online Patching. In EBS 12.2, the database is upgraded and patched while users remain connected, and this is achieved through editioning views, cross-edition triggers, editioned columns, and row-level security (RLS) policies applied to the underlying tables. AD_ZD_SEED provides the programmatic logic that creates and manages these editioning artifacts for the objects owned by the APPS schema, ensuring that the correct edition is exposed to the correct runtime session during the prepare, cutover, and cleanup phases of an online patch cycle.

The package is classified as OTHER in the ETRM metadata and holds VALID status in the APPS schema. It is heavily depended upon by the broader AD_ZD family of packages and is referenced by nineteen other database objects, underscoring its central role in the Application DBA (AD) online patching toolset.

Key Procedures and Functions

The package exposes twelve documented procedures and functions, each corresponding to a stage of the online patching lifecycle or to a category of database object being managed:

  • EDS_COLUMN — manages editioned columns, the mechanism by which a column can hold different values across editions.
  • EDS_TRIGGER — manages the cross-edition triggers that keep editioning views synchronized during patching.
  • EDS_POLICY — manages row-level security policies that restrict visibility of rows to the appropriate edition.
  • EDS_FUNCTION — supports the functions used in conjunction with editioning artifacts.
  • EDS_FCET — handles the fine-grained cross-edition triggers that support the EBR model.
  • UPGRADE — seeds the online patching objects during an upgrade to a 12.2 environment.
  • DOWNGRADE — reverses the seeding operations to return objects to their pre-EBR state.
  • PATCH — prepares and applies the editioning metadata for a specific patch.
  • PREPARE — executes the prepare phase, creating the new edition and populating the editioning views and triggers.
  • CUTOVER — switches the runtime edition so that users begin using the newly patched objects.
  • CLEANUP — removes obsolete editions and their associated artifacts after cutover completes.
  • ABORT — terminates an in-progress online patching session and rolls back seeding changes.

Tables Accessed

AD_ZD_SEED reads extensively from the Oracle data dictionary through APPS synonyms. It queries DBA_CONSTRAINTS, DBA_CONS_COLUMNS, DBA_INDEXES, and DBA_IND_COLUMNS to understand the structural definition of tables being seeded; DBA_TAB_COLUMNS and DBA_TRIGGERS to enumerate columns and existing triggers; DBA_POLICIES to inspect RLS policies; DBA_SOURCE, DBA_SYNONYMS, and DBA_OBJECTS_AE to identify dependent code and synonyms; and USER_OBJECTS, USER_OBJECTS_AE, USER_SOURCE, USER_SOURCE_AE, and USER_TRIGGERS for user-level metadata. It also relies on DBMS_LOB for large object manipulation, DBMS_LOCK for serialization during patching, DBMS_METADATA for DDL extraction, DBMS_RLS for policy management, and DBMS_UTILITY for miscellaneous utilities. The V$PARAMETER view is queried to confirm database configuration, and the KU$_DDL and KU$_DDLS fixed views supply DDL text. These reads allow the package to generate the correct editioning DDL dynamically.

Usage Notes

AD_ZD_SEED is not intended for direct invocation by end users or through standard EBS forms. It is invoked internally by the AD Online Patching drivers—specifically the adzdpmgr, adzdparray, and related AD utilities—during the prepare, cutover, and cleanup phases of an online patch. It may also be called from the ADZD concurrent programs that orchestrate patching, and from custom code only where Oracle explicitly supports AD_ZD APIs. Because it manipulates editioning views, cross-edition triggers, and RLS policies, incorrect direct use can render APPS objects inaccessible. It should be treated strictly as an internal Oracle Applications tool, and any custom interaction should be limited to the documented phase procedures (PREPARE, CUTOVER, CLEANUP, ABORT) as driven by the standard patching framework.