Case q12 · fact

What replaces the original exp utility in Oracle 26ai and what does that mean for our export-based migration scripts?

Expected: Original Export (exp) is desupported in 26ai; use Data Pump (expdp); scripts must be rewritten; mention that imp of old dumps may still be relevant if recorded.

No tools

The model alone, answering from memory.

larger model · 1 turn · 23 s · 16.5k in / 2.1k out

✗ verdict ✗ grounded ✓ cited

Grader: Denies 26ai change; many unsourced parameters, licensing, ZDM claims

Answer

Verdict: Oracle Data Pump (expdp/impdp) replaces exp, and it has done so since 10g. Nothing new replaced it in 26ai. Original exp has been desupported for general use since 11g. Any migration script that still calls exp is technical debt, and you should rewrite it for Data Pump before you target 26ai or any Azure-hosted Oracle.

Key facts

Status of the old tools: Original Export (exp) is desupported. Original Import (imp) is kept only so you can load old exp-format dump files, such as legacy archives. Don't count on exp being in a 26ai client or server install. Check your own install with ls $ORACLE_HOME/bin/exp*. Even if it's there, Oracle won't support you using it for migrations. Docs: https://docs.oracle.com/en/database/oracle/oracle-database/23/sutil/oracle-original-export-utility.html
The dump formats don't mix: imp can't read expdp dumps, and impdp can't read exp dumps. You have to switch both ends of the pipeline together.
Data Pump runs on the server: expdp writes to a database DIRECTORY object on the DB host, not to the client's local disk. This is the change that breaks most scripts. You'll need CREATE DIRECTORY plus READ/WRITE grants, and a way to move the dump files afterwards.

What to change in your scripts

`exp` parameter	Data Pump equivalent
`file=` / `log=`	`directory=DP_DIR dumpfile=x_%U.dmp logfile=x.log`
`owner=`	`schemas=`
`rows=n`	`content=metadata_only`
`consistent=y`	`flashback_time=systimestamp` (or `flashback_scn=`)
`indexes=n`, `statistics=none`	`exclude=index`, `exclude=statistics`
`direct=y`, `buffer=`	Not needed (Data Pump picks the access method itself)
`fromuser/touser` (on `imp`)	`remap_schema=`

Short-term workaround: expdp/impdp have a "legacy mode". If you pass them original exp/imp parameters, they translate them and log what they mapped. That's useful for a first pass, but don't leave it in production scripts. https://docs.oracle.com/en/database/oracle/oracle-database/23/sutil/datapump-legacy-mode.html
Features worth using once you've switched: parallel= with %U dump files, compression=all (needs the Advanced Compression option license), encryption=, network_link= (pulls data over a DB link with no dump files at all), and exclude/include filters.

What it means for each Azure target

Oracle Database@Azure (Exadata or Autonomous): Stage dump files in Azure Blob Storage. On Autonomous, use DBMS_CLOUD.CREATE_CREDENTIAL and point impdp at the Blob URI with credential= and dumpfile=https://.... Oracle's Zero Downtime Migration (ZDM) does its logical migrations with Data Pump, so scripts that already use Data Pump fit straight into it. https://docs.oracle.com/en/database/oracle/zero-downtime-migration/
Oracle on Azure VMs: Use impdp network_link= from the source if the network allows it. Otherwise, move the dumps with AzCopy or an Azure Files mount.
Azure Database for PostgreSQL: Neither exp nor expdp applies here. Use ora2pg or the Azure migration tooling instead.

Action items

Search your scripts for exp , imp , file= and owner=.
Add the DIRECTORY setup to your target build.
Rewrite the parameters using the table above.
Test with content=metadata_only first, then a full parallel run.
Keep imp only for restoring old archive dumps.

Keyword search

BM25 over the same 446 documents: top 8 passages pasted in, one pass, references not followed.

larger model · 1 turn · 13 s · 19.1k in / 1.3k out

✓ verdict ✓ grounded ✓ cited

Grader: Correct 26ai desupport, expdp rewrite, imp staging for dumps

8 keyword-search passages

feature_exp-utility score 32.792
mapping_exp-utility--ssma score 26.541
glossary_data-pump-vs-original-export score 19.023
source_oracle-sutil-19-original-export score 18.227
target_azure-dms score 18.162
feature_data-pump score 15.663
feature_oracle-wallet-manager score 15.074
glossary_character-set-vs-national-character-set score 14.579

Answer

Verdict: Data Pump Export (expdp, paired with impdp) replaces the original exp utility. The 26ai Upgrade Guide lists exp as desupported (notice dated April 2023), so any script that calls exp needs to be rewritten or retired before you rely on 26ai.

Key facts

Status: Oracle has treated original Export as desupported for general use since 11g. The only supported use left was backward migration of XMLType data to 10.2. The 26ai Upgrade Guide goes further and desupports the utility itself. Oracle names Data Pump as the replacement, and Data Pump is supported, not deprecated. [1][4][6] Source: https://docs.oracle.com/en/database/oracle/oracle-database/19/sutil/oracle-original-export-utility.html
Not a drop-in swap: Data Pump runs on the database server. The expdp/impdp clients only start and monitor a job, which writes dump files to a server-side DIRECTORY object. It can run in parallel, restart after failure, remap schemas and tablespaces, or skip dump files entirely by using a database link. exp streams data through the client on a single thread. Scripts that expect a dump file to land on the client machine, or that use exp parameters, need a real rewrite, not a renamed command. [3][6]
Dump formats don't mix: Data Pump import can't read old exp dumps, and imp can't read Data Pump dumps. Your inventory should label each existing dump by format before you decide what to keep. [1][3]

What this means for migration scripts

Oracle-to-Oracle targets (Oracle Database@Azure, Oracle on Azure VMs): move the scripts to expdp/impdp, which is the main tool for these moves. Data Pump is also the only supported load path into Autonomous Database. [3][6]
Azure SQL or PostgreSQL targets: changing the export tool won't make the output usable. Neither exp dumps nor Data Pump dumps can be loaded by Azure database services, DMS, SSMA, Ora2Pg or Data Factory. SSMA needs a live Oracle connection, and for SQL targets DMS just wraps SSMA. [1][2][5]
Legacy exp dumps you need to keep: use imp to load them into a staging Oracle database (any supported release, or Oracle Database@Azure). Then point SSMA, Ora2Pg or Data Factory at that staging database. [2]
Nightly exp cron jobs and backups: replace them with Data Factory pipelines or SQL backups on the Azure side. [2] Data Pump's metadata API (DBMS_METADATA) is still useful for pulling DDL to feed conversion tools. [6]

Gaps in these passages: They don't say whether imp still runs against a 26ai database, so plan the legacy-dump staging instance on a release where imp is known to work. They also give no URL for the 26ai Upgrade Guide notice.

Sanity Context · GROQ

The agent with the GROQ endpoint: schema, joins, Portable Text.

smaller model · 7 turns · 36 s · 44.1k in / 2.6k out

✓ verdict ✓ grounded ✓ cited

Grader: 26ai desupport, expdp, rewrite, imp replay of legacy dumps

6 tool calls

initial_context on groq · 4,126 chars back

groq_query on groq · 1,265 chars back

*[_type=="oracleFeature" && (name match "*xp*" || name match "*Export*" || name match "*exp*")]{_id, name, "slug":slug.current, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement, reviewStatus}

groq_query on groq · 3,167 chars back

*[_type=="oracleFeature" && slug.current=="exp-utility"][0]{
  _id, name, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement, reviewStatus,
  "sources": sources[]->{title, url, publisher},
  "mappings": *[_type=="mapping" && oracleFeature._ref==^._id]{
    fidelity, effort, rationale, appliesToOracleVersions,
    "azureTarget": azureTarget->{name, service},
    "sources": sources[]->{title, url, publisher},
    "caveats": *[_type=="caveat" && references(^._id)]{severity, statement, appliesTo, firsthand, "evidence": evidence->{title, url, publisher}}
  }
}

array_field_reader on groq · 108 chars back

{
 "mode": "range",
 "documentId": "feature_exp-utility",
 "field": "obituary",
 "range": {
  "startIndex": 0,
  "endIndex": 20
 }
}

array_field_reader on groq · 1,777 chars back

{
 "mode": "range",
 "documentId": "feature_exp-utility",
 "field": "summary",
 "range": {
  "startIndex": 0,
  "endIndex": 20
 }
}

groq_query on groq · 324 chars back

*[_type=="pattern" && references("mapping_exp-utility--ssma")]{title, problem, whenNotTo}

Answer

Verdict

In Oracle Database 26ai, the original Export utility (exp) is desupported — its Data Pump‑era replacement is Data Pump Export (expdp). For migration scripts, this means any runbook still invoking exp/imp needs to move to expdp/impdp, and old .dmp files from exp cannot be read by Data Pump or by Azure migration tooling.

Scoped facts

Desupport status

exp was introduced pre-11.2 and is listed as desupported in Oracle 26ai (notice dated April 2023), per Oracle Database Changes, Desupports, and Deprecations (Upgrade Guide 26ai).
Oracle's own Utilities documentation states original Export was already desupported for general use since 11g, with the sole remaining supported use being backward migration of XMLType data to 10.2; Oracle recommends Data Pump instead — per Original Export (Utilities 19c). Because that 11g statement is phrased as a limited desupport rather than a deprecation tied to a specific release, the dataset records no deprecatedIn value for this feature — only the 26ai desupport.
Recorded replacement: Data Pump Export (expdp), introduced pre-11.2 as a server-side, parallel design with a different dump-file format, per Overview of Oracle Data Pump (Utilities 19c).

Why it matters for export-based migration scripts

exp dump files are a proprietary format that only imp can read — Data Pump import cannot consume them, and no Azure migration tool accepts them directly. Per the dataset's own note: "legacy runbooks and cron jobs still call exp for backups and schema copies. Its dump files cannot be read by Data Pump import, and neither format can be loaded directly into an Azure database service, so an inventory of 'exports' must distinguish old-style dumps from Data Pump dumps before deciding what to keep."

Migration path mapping (Azure side)

Target: SQL Server Migration Assistant for Oracle (SSMA) — fidelity workaround, effort M, applies to Oracle 11.2, 12.1, 12.2, 18c, 19c, 21c, 23ai (26ai not listed in appliesToOracleVersions for this mapping).
Rationale: "The original Export utility produced legacy .dmp files that only imp could read; none of the Azure migration tools accept them. SSMA needs a live connection to the Oracle database, so old exp dumps must first be imported into an Oracle instance (any supported release, or Oracle Database@Azure) before SSMA, Ora2Pg or Data Factory can extract from it." — per SQL Server Migration Assistant for Oracle (OracleToSQL) and Azure Database Migration Service: supported migration scenarios.
No caveats are recorded against this specific mapping in the dataset.

Practical implication

Since old exp dumps require a live Oracle instance to re-import (via imp) before any Azure tool (SSMA, Ora2Pg, Data Factory) can extract data, teams should: (1) inventory scripts to separate exp-based dumps from expdp-based dumps, (2) rehost/replay old dumps through imp into a supported Oracle instance if the source data only exists as legacy .dmp files, and (3) rewrite ongoing export jobs to use expdp going forward, since that is Oracle's recorded replacement path.

Gaps

The dataset has no evidence of a Data Pump–specific Azure-target mapping in this query (only the SSMA workaround mapping was linked to the exp-utility feature), and no pattern document references this mapping directly.

GROQ + Knowledge Base

The agent with both endpoints.

smaller model · 7 turns · 35 s · 63.6k in / 3.0k out

✓ verdict ✓ grounded ✓ cited

Grader: Complete verdict, sourced lifecycle, imp staging path noted

6 tool calls

initial_context on groq · 4,126 chars back
initial_context on kb · 7,679 chars back

groq_query on groq · 1,274 chars back

*[_type=="oracleFeature" && (name match "*exp*" || name match "*Export*" || slug.current match "*exp*")]{_id, name, "slug":slug.current, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement, reviewStatus}

groq_query on groq · 2,962 chars back

*[_id=="feature_exp-utility"]{_id, name, "slug":slug.current, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement, reviewStatus, "sources":sources[]->{title,url,publisher}, summary, obituary}

groq_query on groq · 1,867 chars back

*[_type=="mapping" && oracleFeature->_id=="feature_exp-utility"]{_id, fidelity, effort, rationale, appliesToOracleVersions, "azureTarget":azureTarget->{name,"slug":slug.current}, "sources":sources[]->{title,url,publisher}, "caveats":*[_type=="caveat" && references(^._id)]{severity, statement, appliesTo, firsthand, "evidence":evidence->{title,url,publisher}}}

knowledge_base_read on kb · 8,187 chars back

{
 "knowledgeBase": "kb6MdvV3ZA3Q",
 "paths": [
  "logical_migration",
  "oracle_concepts/terminology"
 ]
}

Answer

Verdict

In Oracle Database 26ai, the original Export utility (exp) is desupported; Oracle's recorded replacement is Data Pump Export (expdp). If your export-based migration scripts still shell out to exp, they need to be rewritten to use expdp/impdp (or a downstream Azure tool) before/while moving to 26ai — old exp dump files are not readable by anything in the Azure toolchain.

Scoped facts

Lifecycle status

exp was introduced pre-11.2 and is recorded as desupported in 26ai (notice dated April 2023). No separate deprecation release is recorded — Oracle's 11g-era statement was a limited desupport-for-general-use, not a formal deprecation of a named release. — Oracle Database Changes, Desupports, and Deprecations (Upgrade Guide 26ai), Original Export (Utilities 19c)
Per the desupported/deprecated distinction in this dataset: a desupported feature "receives no further bug fixes and its code may have been removed from the product entirely... it can fail or disappear after an upgrade." For an Oracle-to-Oracle path (including Oracle Database@Azure on 26ai), a desupported feature "must be replaced before or during the migration, because the target release may not contain it at all." — Migration Terminology and Fidelity Levels entry (glossary_desupported)

What exp did vs. what replaces it

exp is the client-side program that reads the database over a session and writes a proprietary dump file (imp is its counterpart). Data Pump (expdp/impdp) replaced the pair back in 10g with a server-side, parallel design and a different, incompatible dump-file format. — Original Export (Utilities 19c), Overview of Oracle Data Pump (Utilities 19c)
Data Pump's own architecture: the client only starts/monitors a job while DBMS_DATAPUMP/DBMS_METADATA on the server do the actual read/write through a server-side DIRECTORY object — single-threaded exp/imp streams through the client instead, and the two dump formats are not interchangeable. Data Pump is the only supported load path into Autonomous Database. — Logical Migration with Data Pump entry (Dataset source: "Run Data Pump for a cloud move you can prove")

What this means for your migration scripts

Legacy runbooks/cron jobs that still call exp for backups or schema copies need to be inventoried separately from Data Pump jobs: "its dump files cannot be read by Data Pump import, and neither format can be loaded directly into an Azure database service, so an inventory of 'exports' must distinguish old-style dumps from Data Pump dumps before deciding what to keep." — Original Export (Utilities 19c) / feature summary sourced from same
The only mapping on record for old exp dumps targets SQL Server Migration Assistant for Oracle (SSMA), fidelity workaround, effort M, scoped to Oracle 11.2–23ai (this mapping's appliesToOracleVersions list does not include 26ai): SSMA needs a live Oracle connection, so "old exp dumps must first be imported into an Oracle instance (any supported release, or Oracle Database@Azure) before SSMA, Ora2Pg or Data Factory can extract from it." — SQL Server Migration Assistant for Oracle (OracleToSQL), Azure Database Migration Service: supported migration scenarios
Practically, rewritten scripts should move to expdp/impdp with explicit parameters (SCHEMAS/TABLES, REMAP_SCHEMA, PARALLEL+DUMPFILE %U, FLASHBACK_SCN/FLASHBACK_TIME for consistency, explicit TABLE_EXISTS_ACTION, VERSION when targeting an older release) and route the actual Azure load through Azure Database Migration Service, Azure Data Factory, SSMA, or Ora2Pg rather than expecting Data Pump dumps to load directly. — Logical Migration with Data Pump entry (Dataset source: "Run Data Pump for a cloud move you can prove")

Gaps

No caveat documents were found attached to the exp-utility→SSMA mapping (empty caveats array) — no additional documented edge cases beyond the rationale above.
No mapping in the dataset extends exp-utility coverage into 26ai itself; if your scripts must run against a 26ai source/target, the dataset has no evidence beyond "desupported, replace with expdp."
No dispute document touches this feature.

← q11 All cases q13 →