Search Results unregisterstore_log




Overview
Explore in AI Chat

Overview

SYS.DBMS_DBFS_CONTENT_ADMIN is an Oracle-supplied administrative PL/SQL package that provides the configuration and lifecycle management interface for the Database File System (DBFS) content hierarchy. In the context of Oracle E-Business Suite 12.1.1 and 12.2.2, this package is part of the underlying database infrastructure rather than an EBS application API. It is owned by SYS and holds VALID status in the data dictionary, meaning it is present and compiled on supported EBS database releases (typically 11.2.0.x and 12.1.0.x/19c depending on the EBS version). The package allows an administrator to define content stores, register them against a schema, mount and unmount those stores into the DBFS content namespace, and maintain the metadata that binds file-system-like paths to their backing store providers. It is a building block used by other DBFS components, including DBMS_DBFS_CONTENT, DBMS_DBFS_SFS_ADMIN, DBMS_ARCH_PROVIDER_INTL, and DBMS_ARCH_PROVIDER. Within EBS, its practical relevance is indirect: it is leveraged where DBFS-based storage, secure file repositories, or WebDAV/DBFS adapters are configured, such as in the EBS file system abstraction and certain content management or attachment storage scenarios.

Key Procedures and Functions

The documented package exposes eighteen procedures and functions, grouped logically as follows.

  • Store registration: REGISTERSTORE and REGISTERSTORE_LOG create a content store record against a schema, with the _LOG variant additionally capturing the operation in the administrative log. UNREGISTERSTORE and UNREGISTERSTORE_LOG remove a previously registered store and optionally record the removal.
  • Mount management: MOUNTSTORE and MOUNTSTORE_LOG attach a registered store at a named path within the DBFS content hierarchy. UNMOUNTSTORE and UNMOUNTSTORE_LOG detach a mounted store. The logged variants preserve an audit trail of mount and unmount activity.
  • Statistics and validation: UPDATESTATS refreshes usage statistics maintained for registered stores. CHECKSPI validates the service provider interface (SPI) implementation exposed by a store provider before it is used.
  • Context and metadata: UPDATECTX updates context information held in the DBFS metadata. SYSTEM_INFO_EXP, SCHEMA_INFO_EXP, and INSTANCE_INFO_EXP are export-style functions that surface system-, schema-, and instance-level DBFS information for inspection or migration.
  • Export/import utilities: EXIMREGISTERALL, EXIM_STORE, EXIM_MOUNT, and EXIM_MOUNTP support bulk export/import registration of stores and mounts, enabling DBFS metadata to be captured and re-established across databases.

Tables Accessed

The ETRM metadata excerpt lists dependencies on SYS, STANDARD, and the PUBLIC synonym DBMS_DBFS_CONTENT_ADMIN, and records that the package is referenced by DBMS_ARCH_PROVIDER_INTL, DBMS_DBFS_CONTENT, DBMS_DBFS_CONTENT_ADMIN itself, and DBMS_DBFS_SFS_ADMIN. No application-level tables accessed through APPS synonyms are documented for this object, which is expected for a SYS-owned administrative package. Operationally, DBMS_DBFS_CONTENT_ADMIN reads and writes the DBFS content metadata dictionary that underpins registered stores, mounted paths, store statistics, and SPI validation state. These are internal DBFS tables rather than EBS product tables, so no EBS transactional data is touched directly.

Usage Notes

DBMS_DBFS_CONTENT_ADMIN is an administrative, SYS-level package and is not intended for direct invocation from EBS application forms, concurrent programs, or ordinary custom code. It is normally executed by a DBA or system administrator with the required privileges to configure and manage DBFS content stores. In EBS environments it may be referenced indirectly through DBFS setup or diagnostic scripts that initialize secure file storage, WebDAV access, or file-system-like repositories used by the application tier. Because it is owned by SYS and referenced by other DBFS packages, changes should not be made to the package itself, and any invocation should be limited to documented procedures and standard DBFS configuration workflows. Custom code should prefer the higher-level DBMS_DBFS_CONTENT API rather than calling the admin package directly.