The Legacy Obituaries

Notices of desupport & departureOracle Database → AzureTuesday, 29 September 2026The Coroner’s ReportsAbout this paper

Case q19 · howto

We're moving a 19c Enterprise Edition database from IBM AIX to Oracle Database@Azure (Exadata) with a 2-hour outage window. Which migration method should we use, and in what order should we rule the options out?

Expected: Apply the gates in order: (1) the target (Exadata on Database@Azure) allows physical methods; (2) AIX is big-endian and every Azure target is little-endian Linux, so a straight RMAN restore and a Data Guard physical standby are ruled out; (3) a 2-hour window rules out a volume-bound Data Pump or offline copy for a large database, leaving incremental cross-platform transportable tablespaces (XTTS with RMAN CONVERT) or a logical-online method (GoldenGate / ZDM logical-online); (4) EE has no edition limit here. Answer must state the order of the gates and why Data Guard is excluded.

Added after the frozen run to test the Knowledge Base on how-to prose. Not counted in the frozen totals.

No tools

The model alone, answering from memory.
larger model · 1 turn · 30 s · 16.5k in / 2.9k out

✗ verdict ✗ grounded ✗ cited

Grader: No target or edition gates; unsupported MOS and licensing claims

Answer

Migrating 19c EE from AIX to Oracle Database@Azure (Exadata) in a 2-hour window

Verdict: Use Oracle Zero Downtime Migration (ZDM) in logical online mode, which does a Data Pump initial load and then keeps the target in sync with GoldenGate. Cutover takes minutes, well inside your 2 hours. If GoldenGate can't handle your schema, use cross-platform transportable tablespaces with incremental backups (XTTS). Physical methods won't work because AIX and Exadata store data in opposite byte orders.

Rule the options out in this order

1. Byte order: this removes every physical-copy method first.

  • AIX on POWER stores data big-endian. Exadata runs Oracle Linux on x86-64, which is little-endian.
  • A physical standby can't cross byte orders, so these are out:
    • Data Guard switchover
    • RMAN restore or duplicate
    • Transportable database
    • ZDM physical online and physical offline
  • Confirm it with V$TRANSPORTABLE_PLATFORM / V$DATABASE.PLATFORM_NAME. A physical standby is only supported between the platform pairs listed in MOS 413484.1.

2. Outage time: this removes a plain Data Pump export and import, unless the database is small.

  • A full expdp, transfer to Azure and impdp (including index builds and statistics) almost never fits in 2 hours beyond a few hundred GB.
  • That limit depends on your network throughput to Azure (ExpressRoute) and your CPU.
  • ZDM logical offline is this same method, so it's out too.

3. XTTS (MOS 2471245.1, the V4 scripts): keep it as the fallback.

  • You copy and roll forward incremental backups while the source stays up, and the cross-endian conversion happens during the restore.
  • The outage covers four steps:
    • Set tablespaces read-only
    • Take and apply the last incremental backup
    • Run the full transportable metadata export and import
    • Validate
  • The risk is the metadata import. Databases with many objects, PL/SQL, partitions or grants can take hours at this step. Time it in a rehearsal before you rely on this path.
  • The main advantage is that it copies data at block level, so GoldenGate's data-type limits don't apply.

4. ZDM logical online: this is the one to pick.

  • ZDM runs Data Pump for the initial load, then GoldenGate replicates changes. ZDM supports AIX as a source and Exadata on Oracle Database@Azure as a target.
  • Cutover means stopping the application, letting GoldenGate catch up, and switching connections. That usually takes minutes.
  • You can set up reverse replication so you can fall back to AIX after cutover.
  • Licensing: GoldenGate use for ZDM migrations into Oracle Cloud targets has historically been covered by a limited-term migration license. Confirm the current terms with Oracle for your contract.

Check these before you commit to logical online

  • Query DBA_GOLDENGATE_SUPPORT_MODE. Look for tables with no primary or unique key and data types that are unsupported or only supported by fetching from the source. If there are a lot of these, XTTS becomes the better choice.
  • Plan how sequences, jobs, database links, DDL during replication and character set will be handled. The target should use AL32UTF8.
  • Set up network connectivity between on-premises, the ZDM host and the delegated subnet of the Oracle Database@Azure VM cluster. Check the latency the GoldenGate extract and replicat will see.
  • Run at least one full rehearsal and measure how long the actual cutover takes.

Sources

Keyword search

BM25 over the same 446 documents: top 8 passages pasted in, one pass, references not followed.
larger model · 1 turn · 18 s · 19.4k in / 1.6k out

✗ verdict ✓ grounded ✗ cited

Grader: XTTS is right but it puts edition before downtime

8 keyword-search passages
  1. glossary_se2-vs-ee score 29.381
  2. pattern_choose-migration-method score 27.206
  3. pattern_rman-moves-to-oracle-on-azure score 24.251
  4. mapping_non-cdb-architecture--oracle-db-at-azure score 23.257
  5. glossary_xtts-cross-endian score 23.073
  6. pattern_rac-vs-data-guard-on-azure score 22.981
  7. source_oracle-glossary-licensing-editions score 22.06
  8. feature_rac score 20.699
Answer

Recommendation: use cross-platform transportable tablespaces with incremental backups (XTTS), converting the byte order with RMAN CONVERT. It is the only physical method in these passages that works from AIX to Exadata. It also fits a 2-hour window, because the source stays online until the last incremental.

The order to rule options out

The passages only partly answer the ordering question. Passage [2] says the decision uses four gates in a fixed order, but the excerpt stops after Gate 1, so I can't quote Gates 2–4. The order below uses Gate 1 as written and fills in the rest from the other passages.

  1. Gate 1: what the target allows. Oracle Database@Azure Exadata gives you SYSDBA and file-system access, so "every method is on the table," including Data Guard and Zero Downtime Migration (ZDM) [2]. Nothing is ruled out yet. Don't stop here and pick Data Guard for its near-zero downtime; [2] names that as the classic mistake of taking the gates in the wrong order.
  2. Endianness: this removes the most options. AIX is big-endian and every Azure target runs little-endian Linux x86-64. That makes this a cross-endian move, which a plain RMAN restore or a Data Guard standby cannot do [5]. Confirm it in V$TRANSPORTABLE_PLATFORM [3][5]. This rules out:
    • RMAN restore or duplicate
    • A Data Guard standby
    • The physical paths that rely on them. [3] identifies ZDM physical-offline as an offline RMAN restore. For physical-online, the passages only imply that it depends on a standby.
  3. Edition. Enterprise Edition keeps XTTS available, since XTTS is EE-only [5]. It is also the base for GoldenGate, the online logical option [1][7]. (Oracle's 19c licensing guide: https://docs.oracle.com/en/database/oracle/oracle-database/19/dblic/Licensing-Information.html)
  4. Outage window. A full Data Pump export and import is an outage method [1]. Whether it fits in 2 hours depends on data volume, which the passages don't cover. Incremental XTTS keeps the target copy rolled forward while the source runs, and the tablespaces only go read-only for the final increment [5]. That makes it the best fit. GoldenGate is the fallback if even the final increment plus the metadata import won't fit, and you would need a GoldenGate licence.

XTTS caveats to plan for [5]

  • Undo datafiles can't be converted. XTTS moves only the user tablespaces, plus a small Data Pump export of their metadata.
  • External tables, directories and BFILEs live outside the datafiles, so you have to recreate them on the target.
  • If the source is a non-CDB, plan to plug it into an Exadata CDB as a PDB. The Exadata service creates databases as CDBs by default, and it can create a non-CDB only through dbaascli for 19c and earlier. Keep that for temporary compatibility only [4].

Before committing to the window: time a full rehearsal of the final incremental, the conversion, the metadata import and validation. None of the passages give throughput figures, so only a rehearsal will show whether it fits in 2 hours.

Sanity Context · GROQ

The agent with the GROQ endpoint: schema, joins, Portable Text.
smaller model · 11 turns · 109 s · 235.4k in / 9.3k out

✓ verdict ✓ grounded ✗ cited

Grader: Correct gate order, explains Data Guard exclusion, XTTS or GoldenGate

10 tool calls
  1. ToolSearch on · 0 chars back
    select:mcp__sanity-groq__initial_context,mcp__sanity-groq__groq_query,mcp__sanity-groq__array_field_reader,mcp__sanity-groq__schema_explorer
  2. initial_context on groq · 4,126 chars back
  3. groq_query on groq · 9,349 chars back
    *[_type=="oracleFeature"]{_id, name, "slug": slug.current, category, introducedIn, deprecatedIn, desupportedIn}
  4. groq_query on groq · 12,408 chars back
    *[_type=="pattern"]{_id, title, problem, whenNotTo, "relatedMappings": relatedMappings[]->{_id, fidelity, "oracleFeature": oracleFeature->name, "azureTarget": azureTarget->name}}
  5. array_field_reader on groq · 6,959 chars back
    {
 "mode": "range",
 "documentId": "pattern_choose-migration-method",
 "field": "approach",
 "range": {
  "startIndex": 0,
  "endIndex": 50
 }
}
  6. groq_query on groq · 2,809 chars back
    *[_type=="mapping" && oracleFeature->slug.current in ["rman","data-pump","data-guard"] && azureTarget->slug.current match "oracle*"]{_id, "feature": oracleFeature->name, "target": azureTarget->name, fidelity, effort, rationale, appliesToOracleVersions, "sources": sources[]->{title,url}, "caveats": *[_type=="caveat" && references(^._id)]{severity, statement, appliesTo, "evidence": evidence->{title,url}}}
  7. groq_query on groq · 10,772 chars back
    *[_type=="dispute"]{_id, title, whatDisagrees, resolution, "claimA": claimA->{statement, "mapping": mapping->{"feature": oracleFeature->name, "target": azureTarget->name}}, "claimB": claimB->{statement, "mapping": mapping->{"feature": oracleFeature->name, "target": azureTarget->name}}, "resolvedBy": resolvedBy->{title,url}}
  8. groq_query on groq · 561 chars back
    *[_type=="caveat" && (statement match "*endian*" || statement match "*AIX*" || statement match "*XTTS*" || statement match "*transportable*")]{_id, statement, severity, appliesTo, "mapping": mapping->{"feature": oracleFeature->name, "target": azureTarget->name}, "evidence": evidence->{title,url}}
  9. array_field_reader on groq · 6,270 chars back
    {
 "mode": "range",
 "documentId": "pattern_rman-moves-to-oracle-on-azure",
 "field": "approach",
 "range": {
  "startIndex": 0,
  "endIndex": 30
 }
}
  10. groq_query on groq · 3,881 chars back
    *[_type=="pattern" && _id in ["pattern_choose-migration-method","pattern_rman-moves-to-oracle-on-azure","pattern_data-pump-for-cloud-move","pattern_data-guard-switchover-vs-failover-at-cutover"]]{_id, title, "sources": sources[]->{title, url, publisher}}
Answer

Verdict: This is a cross‑endian move (AIX → Azure Exadata), so the endianness gate — not the downtime gate — eliminates most methods first. For a firm 2‑hour window the realistic path is incremental XTTS (transportable tablespaces with RMAN CONVERT), with plain Data Pump only if your database is small enough to finish in the window, and GoldenGate as the fallback if neither can guarantee 2 hours.

Elimination order (per the dataset's four-gate method-selection framework — Migrating Oracle to the Cloud: Which Method, and When, firsthand; corroborated by Migrate Oracle workloads to Azure VMs, Microsoft):

  1. Gate 1 — target capability: nothing eliminated. Oracle Database@Azure Exadata is a full Oracle database you administer (SYSDBA, mountable, file access), unlike Autonomous or Azure SQL/PostgreSQL targets. Every physical and logical method stays on the table at this stage — confirmed by the mapping evidence: Data Pump and RMAN both map to Oracle Database@Azure with fidelity: exact (Overview: Oracle Database@Azure; Exadata services).

  2. Gate 2 — endianness: rules out RMAN restore/duplicate and Data Guard physical standby. Check V$TRANSPORTABLE_PLATFORM on both sides. AIX is big‑endian; every Azure target, including Oracle Database@Azure, is little‑endian Linux x86‑64. RMAN restore/duplicate and a physical Data Guard standby both copy datafile blocks verbatim, so neither can cross endianness — eliminated immediately regardless of downtime budget or edition. ZDM's physical‑online mode (RMAN + Data Guard + switchover) inherits the same limitation. What survives: transportable tablespaces with RMAN CONVERT (XTTS), Data Pump, or GoldenGate. (Same pattern doc as above; also Move an Oracle database with RMAN to Azure VMs or Oracle Database@Azure.)

  3. Gate 3 — the 2‑hour downtime budget decides among the survivors. The dataset's own decision key: "Cross‑endian ..., outage acceptable: XTTS with RMAN CONVERT for very large databases, Data Pump for small and medium ones" and "Cross‑endian ..., near‑zero downtime: GoldenGate after a Data Pump initial load (ZDM logical online)." Microsoft's guidance agrees from the other side: Data Pump's outage scales with data volume and "is not recommended when data volume is large and downtime must be short." So: rule out plain Data Pump if your unload‑reload‑index‑rebuild cycle can't be rehearsed to finish inside 2 hours. If it's ruled out, use incremental XTTS: seed a level‑0 backup/tablespace set ahead of time, apply incrementals while the source stays live, and let only the final incremental plus archived logs fall inside the 2‑hour window — this is explicitly how the referenced runbook keeps a large cross‑endian move inside a fixed window (Oracle RMAN Recovery Runbook).

  4. Gate 4 — edition/licensing: not a blocker here, but sets the last fallback. Your source is Enterprise Edition, so no method is eliminated on edition grounds (a Standard Edition 2 source would have forced Data Pump/offline RMAN regardless — moot since Data Guard was already out at Gate 2). If rehearsal shows even incremental XTTS can't reliably hit 2 hours, GoldenGate (after a Data Pump initial load, ZDM logical‑online mode) is the last resort — the dataset flags it as separately licensed and the most complex method, justified "only when near‑zero downtime and a boundary crossing are both mandatory."

Gap in the dataset: no mapping or caveat gives a specific GB/TB threshold distinguishing "small/medium" (Data Pump-safe) from "very large" (needs XTTS); that boundary has to be established with your own rehearsal/timing test, not from evidence in this dataset.

Disputes: none of the dataset's 5 recorded disputes touch migration-method selection, RMAN, Data Guard, XTTS, or GoldenGate — they concern type-mapping tools (SSMA/Ora2Pg) and DBMS_JOB, so nothing to present both sides of here.

GROQ + Knowledge Base

The agent with both endpoints.
smaller model · 12 turns · 99 s · 294.9k in / 8.9k out

✓ verdict ✓ grounded ✓ cited

Grader: Correct gate order and Data Guard reason; some citation labels wrong

11 tool calls
  1. ToolSearch on · 0 chars back
    select:mcp__sanity-groq__initial_context,mcp__sanity-kb__initial_context,mcp__sanity-groq__groq_query,mcp__sanity-groq__array_field_reader,mcp__sanity-kb__knowledge_base_read,mcp__sanity-groq__schema_explorer
  2. initial_context on groq · 4,126 chars back
  3. initial_context on kb · 7,679 chars back
  4. knowledge_base_read on kb · 21,084 chars back
    {
 "knowledgeBase": "kb6MdvV3ZA3Q",
 "paths": [
  "migration_method_selection",
  "physical_migration",
  "ha_and_cutover",
  "target_platforms"
 ]
}
  5. groq_query on groq · 1,420 chars back
    *[_type=="oracleFeature" && (name match "*RMAN*" || name match "*Data Pump*" || name match "*GoldenGate*" || name match "*Data Guard*" || name match "*Transportable*" || name match "*Zero Downtime*" || name match "*XTTS*" || name match "*endian*")]{_id, name, "slug": slug.current, category, introducedIn, deprecatedIn, desupportedIn, oracleReplacement}
  6. groq_query on groq · 2,869 chars back
    *[_type=="mapping" && oracleFeature->slug.current in ["rman","data-guard","data-pump"] && azureTarget->slug.current == "oracle-db-at-azure"]{
  _id,
  "feature": oracleFeature->name,
  "target": azureTarget->name,
  fidelity, effort, rationale, appliesToOracleVersions,
  "sources": sources[]->{title,url},
  "caveats": *[_type=="caveat" && references(^._id)]{
    _id, severity, statement, appliesTo, firsthand,
    "evidence": evidence->{title,url,publisher}
  }
}
  7. groq_query on groq · 3,270 chars back
    *[_type=="glossary" && (term match "*XTTS*" || term match "*endian*" || term match "*logical*" || term match "*physical*")]{term, definition, "sources": sources[]->{title,url}}
  8. groq_query on groq · 10,456 chars back
    *[_type=="dispute"]{_id, title, whatDisagrees, resolution, "claimA": claimA->{statement, "feature": mapping->oracleFeature->name, "publisher": evidence->publisher}, "claimB": claimB->{statement, "feature": mapping->oracleFeature->name, "publisher": evidence->publisher}, "resolvedBy": resolvedBy->{title,url}}
  9. groq_query on groq · 710 chars back
    *[_type=="oracleFeature" && (name match "*tablespace*" || category=="ha" )]{name, "slug": slug.current, category}
  10. groq_query on groq · 493 chars back
    *[_type=="source" && (title match "*Choose the Oracle-to-Azure migration method*" || title match "*Move an Oracle database with RMAN*" || title match "*Decide RAC versus Data Guard*" || title match "*Cut over with a Data Guard switchover*")]{title, url, publisher}
  11. groq_query on groq · 8,694 chars back
    *[_type=="pattern"]{title, "sources": sources[]->{title,url,publisher}}
Answer

Verdict

For a 19c Enterprise Edition source on IBM AIX moving to Oracle Database@Azure (Exadata) with a 2‑hour outage window, the dataset's decision framework eliminates options in a fixed gate order — and the AIX→Azure move is cross‑endian, which is the gate that does the most work here. Depending on database size, the framework points to XTTS with RMAN CONVERT (large DB) or Data Pump (small/medium DB) as the outage-acceptable candidates; plain RMAN restore and Data Guard switchover are ruled out before downtime is even considered. Choose the Oracle-to-Azure migration method by target, downtime budget, endianness and edition

Elimination order (Gates 1→4, as specified)

Gate 1 — Target capability: nothing ruled out. Oracle Database@Azure's Exadata/Base services run unmodified Oracle Database, so both physical methods (RMAN, transportable tablespaces, Data Guard) and logical methods (Data Pump, GoldenGate) are permitted targets. RMAN and Data Pump both map to ODAA at fidelity: exact, effort: S, applicable to 19c. Overview: Oracle Database@Azure; Business continuity and disaster recovery for Oracle Database@Azure — no caveats are recorded against either mapping in the dataset.

Gate 2 — Endianness: this rules out RMAN restore and Data Guard switchover. AIX is big-endian; every Azure target, including Oracle Database@Azure, runs little-endian Linux x86-64. That makes this a cross-endian move, and a plain RMAN restore or a physical Data Guard standby copies blocks verbatim — neither can cross endianness. Confirm with V$TRANSPORTABLE_PLATFORM on both sides. What survives this gate: XTTS with RMAN CONVERT, or a logical method (Data Pump / GoldenGate). glossary: XTTS / cross-endian transport; Move an Oracle database with RMAN to Azure VMs or Oracle Database@Azure

Gate 3 — Downtime budget: 2 hours is "outage acceptable," not "near-zero," and this is where size decides the branch.

  • Very large database → XTTS with RMAN CONVERT, incremental-backup variant: datafiles are copied and rolled forward with RMAN incrementals while the source stays online; only the final increment requires the tablespaces read-only, which is what keeps a cross-endian move inside a short window. Enterprise Edition only; undo-bearing datafiles can't be converted; objects outside datafiles (external tables, directories, BFILEs) must be recreated manually.
  • Small/medium database → Data Pump, since outage scales with data volume and may fit inside 2 hours.
  • If the actual data volume makes neither fit in 2 hours, the framework's fallback for a mandatory near-zero-downtime cross-endian move is GoldenGate after a Data Pump initial load (ZDM logical-online mode) — but this is separately licensed and the most operationally complex option, to be used only if forced.

Move an Oracle database with RMAN to Azure VMs or Oracle Database@Azure; glossary: XTTS / cross-endian transport

Gate 4 — Edition/licensing: not a blocker here. Source is 19c Enterprise Edition, which satisfies XTTS's EE-only requirement and would have satisfied Data Guard's EE requirement had Gate 2 not already ruled it out. GoldenGate licensing only becomes relevant if Gate 3 forces that branch. glossary: Logical vs physical migration

Gaps

  • The dataset has no recorded caveats or blockers against RMAN or Data Pump specifically for the Oracle Database@Azure target.
  • None of the 5 disputes in the dataset touch migration-method selection, endianness, or downtime budgeting — the recorded disputes concern data-type mapping (NUMBER, ROWID, VARCHAR2) and DBMS_JOB behavior, unrelated to this question.
  • Database size wasn't given, so the final choice between XTTS and Data Pump can't be pinned down from evidence alone — that's the one input the framework needs that this conversation hasn't supplied.

← q18All casesq20 →