Migrating a 2.6 TB Database into an Eight-Hour Cutover

A single direct export/import cannot fit because the dump alone is estimated at 26 hours over a 250 Mbps link, before import and indexing. Use a phased approach. Perform the initial Data Pump export from the source to a local staging area or directly to OCI Object Storage, upload the dump files to Object Storage, and import them into the target well before cutover. Then start GoldenGate capture and apply so changes made after the initial load are replicated continuously. During the 8-hour window, stop application writes, allow GoldenGate to drain the backlog, validate, and switch over. Keep the source read-only until validation passes. If GoldenGate is not viable for a specific table, a second consistent Data Pump export of changed data plus a controlled outage is the fallback, but the initial 2.6 TB bulk load must not sit inside the 8-hour window. The judgment is to separate bulk transfer from change synchronization.

Directory objects are not usable as on-premises filesystem paths; replace them with Object Storage credentials or DBMS_CLOUD references, and remove dependencies on local directories. The three DBMS_SCHEDULER jobs can be recreated, but any job that calls a host command, external script, or local file will fail; rewrite those jobs to use database PL/SQL or an external scheduler. Public synonyms should be converted to private synonyms or fully qualified names, because the application should not depend on public namespace changes and ADB administration is more restricted. DBA-role grants will not carry over; map users to the appropriate predefined roles and least-privilege object grants. Also review the 40 GB LOB segment for SecureFiles compatibility and check for unsupported features or privileges before the export. The judgment is that migration success depends as much on removing OS and DBA dependencies as on moving the data.

Before cutover, record row counts, key aggregate checksums, invalid object counts, and a known set of application transactions on the source. During the window, confirm GoldenGate lag reaches zero, then compare the same counts and checksums on the target. Run the critical order-entry and reporting transactions against the target, verify sequence values, and check that scheduled jobs and synonyms resolve. Keep the source read-only, not open for writes, until the application smoke tests pass. Define a hard rollback point: if checksum mismatches exceed an agreed threshold, if GoldenGate cannot drain within the window, or if critical transactions fail, revert DNS and reopen the source. Capture the validation queries and results in the runbook so the decision is not made from memory at 03:00. The judgment is that an 8-hour window needs explicit go/no-go criteria, not a best-effort attempt to fix replication during the outage.