Plan External Data Access

Choose the SQL Access Path

Access Path	Definition Lifecycle	Use when	SQL Form
Persistent external table	Stored in the Oracle data dictionary.	Multiple applications or queries require a stable object, grants, views, and statistics.	orders_ext
Inline external table	Exists for one SQL statement.	A query needs a temporary definition or query-specific location.	EXTERNAL (...)
Mounted catalog table	Metadata is resolved from an authoritative source through a database-local mount.	Many source tables must remain discoverable without a local definition for each table.	sales.orders@lake_catalog

Note - Delta Sharing is not a fourth access path. It is an ORACLE_BIGDATA access protocol that can be used through an applicable persistent external table, inline external table, or mounted catalog table.

Three SQL Paths to External Data

Oracle SQL	→	Definition used by Oracle AI Database	→	External Source
SELECT ... FROM orders_ext	→	Persistent definition in the data dictionary	→	Files or a supported sharing endpoint
SELECT ... FROM EXTERNAL (...)	→	Query-scoped inline definition	→	Files or a supported sharing endpoint
SELECT ... FROM sales.orders@lake_catalog	→	Metadata resolved through a mounted catalog	→	Catalog-managed table and its data

Understand the External-Table Contract

For a persistent external table, Oracle AI Database owns the relational definition, object grants, views, and optimizer statistics. The source system owns the files, their availability, lifecycle, and provider-side authorization. Creating the external table does not copy or take ownership of the data.

External tables are read-only for ordinary SQL access. Query, join, aggregate, and materialize their results, but do not issue INSERT, UPDATE, or DELETE against the external files. ORACLE_DATAPUMP supports specific unload workflows; that exception does not turn an external table into a general DML target.

For details about external-table ownership, access drivers, restrictions, and query behavior, see External Tables Concepts.

Select an Access Driver and Source Format

The following table summarizes the access drivers and their primary roles.

Access Driver	Primary Role	Use in this guide
ORACLE_BIGDATA	Query supported lakehouse files and protocols, including Parquet, ORC, Avro, CSV or text, JSON documents, Apache Iceberg, and Delta Sharing where supported.	Primary lakehouse access driver.
ORACLE_LOADER	Read text files through SQL*Loader-style record and field parsing.	Traditional server-side text-file workflows.
ORACLE_DATAPUMP	Read or create Oracle Data Pump binary files.	Oracle-proprietary unload and reload workflows.

The following table describes Iceberg source formats.

Source	Definition
Parquet, ORC, or Avro	Use embedded schema metadata only where the selected API supports inference. Declare a stable compatible Oracle contract when consumer names or types must not drift.
CSV or text	Define columns, delimiters, quoting, headers, character set, null handling, and date or timestamp formats explicitly.
JSON documents	Use the supported JSON-document mapping for the access driver and expose the document through the intended Oracle JSON model.
Apache Iceberg	Resolve the Iceberg metadata, snapshots, manifests, and files through a supported path in Chapter 4; do not treat the table as an arbitrary folder of Parquet files.
Delta Sharing	Treat it as an access protocol whose table data is exposed through the supported ORACLE_BIGDATA configuration, not as a file or table format.

For details about supported file formats and ORACLE_BIGDATA access, see Access External Files with ORACLE_BIGDATA.