Search Results reset_version

Overview

SYS.DBMS_REGISTRY is the Oracle Database component registry package that maintains the registry$ repository, which records every registered database component, its version, status, and associated schema. In Oracle EBS 12.1.1 and 12.2.2 environments, this package underpins the integrity of the E-Business Suite database by tracking components such as the RDBMS kernel itself and the Applications tier products registered through the AD (AutoInstall/ADOP) toolset. Its PL/SQL interface, packaged as a PUBLIC synonym with EXECUTE granted to the standard registry roles, allows administrators and Oracle-supplied scripts to transition components through well-defined lifecycle states within the database.

The ETRM 12.2.2 metadata classifies DBMS_REGISTRY as an OTHER API owned by SYS and documents more than sixty-eight procedures and functions. Among these, comp_id appears as the primary identifier parameter used throughout the package to qualify component-level operations.

Key Procedures and Functions

The documented entry points fall into several logical groups. Registration and lifecycle procedures include LOADING, LOADED, UPGRADING, UPGRADED, DOWNGRADING, DOWNGRADED, REMOVING, and REMOVED. LOADING registers a new component by supplying its identifier, name, procedure, schema, schema list, and optional parent; LOADED signals completion with an optional version and banner. The Upgrading family marks a component as undergoing an upgrade, and the Downgrading and Removing families parallel this pattern for rollback and de-installation. Each of these procedures takes comp_id as its first identifier parameter, which is precisely the token referenced throughout the package's internal query logic.

Status-management procedures include INVALID and VALID, which toggle the registry status for a component, and SET_RDBMS_STATUS and SET_RDBMS_UPGRADED_STATUS, which specifically control the RDBMS component row. Namespace procedures, SET_SESSION_NAMESPACE and SET_COMP_NAMESPACE, control the logical namespace for the session or a given component, keyed again via comp_id. Utility functions such as STATUS_NAME, STARTUP_REQUIRED, STARTUP_COMPLETE, OPTION_OFF, RESET_VERSION, and UPDATE_SCHEMA_LIST manage status display, restart-required flags, option toggling, version resets, and schema-list maintenance. These operate against the registry$ table and its companion views (registry$version, registry$sqlpatch), which are queried using the comp_id column as the principal predicate.

Tables Accessed

The package reads and writes the core registry tables. The registry$ table stores one row per registered component with columns including comp_id, version, status, and namespace. The registry$version and registry$history tables hold historical version and patch information. The registry$sqlpatch table tracks SQL patch identifiers. The registry$schemas table links components to their schemas, and registry$upgrade and registry$progress track upgrade states. All of these are keyed on the comp_id column established by this package, which is why the term appears prominently in the user's search. The package also reads the V$DATABASE view for RDBMS status and the ALL_USERS data dictionary view to validate schema assignments.

Usage Notes

DBMS_REGISTRY is invoked internally by the Oracle-supplied scripts (e.g., catqm.sql, catupgrd.sql) during database creation and patching, and by the AutoPatch and ADOP utilities when applying EBS patches that register replaced or new products. Direct invocation by end users is uncommon outside of patching. In EBS, concurrent programs such as "Active Users" and "License Manager" queries may reference registry data. Custom code should avoid direct DML on registry$ and use the API where possible, since manual modification can invalidate component status and cause patch verification to fail with ORA-20001 or similar errors relating to an unsupported component identifier.