14 TB Oracle RAC into a 30-Minute Switchover Window

The binding constraint is not the 14 TB or the 6-hour window - it is the 30-minute settlement switch with zero loss. That eliminates anything whose downtime scales with data volume.

A plain Data Pump export/import is out on arithmetic: 14 TB at realistic rates plus index rebuilds means many hours, and the window is 30 minutes. Full transportable export/import is better because datafiles are copied rather than re-inserted, but the final phase still requires a consistent point, a final datafile copy and a metadata import - feasible only if the bulk copy already happened and the delta is small.

Realistic candidates:

• Physical online via Data Guard, orchestrated with Oracle Zero Downtime Migration: seed the standby ahead of time, let redo apply continuously, and the switchover is a role transition measured in seconds to a couple of minutes. It also carries everything a logical migration would force you to recreate - Java stored procedures, directory objects, database links, grants - because it is a block-level copy. ZDM additionally handles the non-CDB to PDB conversion.
• Logical online via GoldenGate: initial load plus change capture, switch when replication lag is zero. Strong when the source and target must differ structurally or by character set, but it is a second product to operate and it has known limitations on LONG and some DDL.

Recommendation: ZDM physical online with Data Guard for the settlement database. It meets the 30-minute switch, eliminates the object-recreation risk, and gives a clean reverse path during the soak period. Reserve GoldenGate for the charset decision in the next task.

This is the decision that reshapes the migration. A physical copy preserves the source character set; you cannot land a block-level copy of WE8ISO8859P1 datafiles as AL32UTF8. Data Pump performs the conversion on import, which is exactly why a logical path exists.

So you must choose deliberately, not by default:

• If AL32UTF8 is genuinely required at cutover, change the method to logical: Data Pump full transportable for the initial load plus GoldenGate (or a tightly rehearsed final delta) for the ongoing changes. Accept that this is more moving parts than Data Guard and that the 30-minute switch depends on replication lag, not on a role transition.
• If AL32UTF8 can wait, take the physical path now and schedule a separate conversion later - and be honest that 'later' usually never arrives and the cost grows with data volume.

My call with a two-year SaaS consolidation: do the conversion now, because the SaaS target will not accept the legacy set and you would be migrating twice.

Handling the specifics:

• LONG columns: convert to CLOB as part of the migration, or exclude that table from replication and move it during a short freeze. LONG is a poor fit for logical replication and a source of silent truncation.
• Database links and directory objects: recreate explicitly on the target; do not assume they follow. Re-point links to the new database names during the same change.
• Timezone file version: reconcile before cutover, not after. TIMESTAMP WITH TIME ZONE data carries the file version it was written under; run the DST upgrade on the target during the soak and validate affected queries, or values shift silently.
• Also size for multibyte expansion: VARCHAR2 BYTE semantics, index key length limits and CLOB conversion can turn a clean import into a schema change.

Runbook, expressed as gates:

• T-30 days: three test refreshes completed; load test at quarter-end peak; row-count and checksum baselines captured per table; timezone upgrade decided; DDL freeze announced.
• T-7 days: DDL freeze in force; directory objects, database links and Java recompiled and validated on target; application connection strings and wallets staged; rollback rehearsal executed end to end at least once.
• T-0, gate 1: replication lag zero and stable for 30 minutes; no open long-running transactions. If not met, stop and reschedule - do not proceed into a settlement window with lag.
• T-0, gate 2: checksum and row-count comparison within agreed tolerance on all critical tables; Java objects valid; top-20 SQL execution plans compared against the source baseline.
• T-0, gate 3: application smoke tests pass in read-only against the target; settlement batch dry run in a cloned schema.
• Switch: stop application writes, drain replication to zero, reverse database links, enable the target, run the settlement switch, monitor.

Rollback point: the moment the first write is accepted on the target. Before that, rollback is 'do nothing'; after it, rollback requires a reverse data path. Define it in writing with the application owner.

Abort conditions: replication lag not zero at gate 1; checksum mismatch on a table that feeds settlement; any PL/SQL or Java object invalid after cutover; top-20 plan regressions without an accepted workaround; or the target missing the 30-minute settlement completion in the dry run. Keep the source in read-only and intact for the agreed soak period, and state its expiry date up front - particularly where the old hardware is being returned.