Operate and Troubleshoot Iceberg Read Access
Understand Read-Path Limitations
The Iceberg specification defines snapshots, schema evolution, partition evolution, delete files, and time travel. Oracle support depends on the database release, deployment, and access model. In particular:
- A direct metadata URI continues to reference the supplied metadata version; it is not a query-time time-travel interface.
- A fixed Oracle external-table definition can require recreation after an incompatible Iceberg schema change.
- Catalog discovery, local external-table compatibility, and write support have different matrices. A supported read integration does not establish write support.
Check the release-specific compatibility table before accepting producer-side schema, partition, or row-level-change features.
For Autonomous AI Database compatibility details and published restrictions, see Query Apache Iceberg Tables.
Diagnose Iceberg Access
| Symptom | Likely cause | Check |
|---|---|---|
| Direct table returns an older state. | The definition points to an older metadata file. | Confirm the producer’s intended metadata.json URI. |
| Catalog table is missing. | Wrong implementation, endpoint, namespace, permissions, or stale catalog metadata. | Provider-specific mount configuration and catalog cache. |
| Table is visible but a file read fails. | Storage credential or mapping cannot read a referenced object. | The exact metadata, manifest, delete, or data object named in the error. |
| Query fails after a producer schema change. | The Oracle definition or release does not support the new schema. | Current Iceberg schema, Oracle column mapping, and compatibility matrix. |
| Query fails after row-level changes. | The table contains unsupported delete-file semantics. | Iceberg table properties, delete files, and release-specific restrictions. |
To manage create and write operations, refer to Use Oracle-Managed Create and Write Operations.
See also: