60 TB EBS Migration with a 4-Hour Cutover and 5-Minute Analytics

Data Pump alone cannot meet the constraint. Moving 60 TB over 1 Gbps takes about 5.5 days at theoretical line rate, before compression, indexes, and verification. Even with parallel Data Pump and transportable tablespaces, a full export/import inside a four-hour outage is not credible. Data Pump can seed the target, but it cannot keep the target current while the source remains authoritative.

Use Data Pump for the initial load and GoldenGate for change replication.

1. Take a consistent initial load with Data Pump or transportable tablespaces to Database@Azure while the source stays online.
2. Start GoldenGate integrated extract on the source before or at the consistent SCN, and Replicat on the target after the initial load is applied.
3. Let replication catch up and monitor lag until it is near zero for a sustained period.
4. Validate with row counts, checksums, and GoldenGate Veridata on critical tables; run EBS business validation scripts.

Cutover: stop the application and batch jobs, let GoldenGate drain to zero lag, disable extract, switch sequences and scheduled jobs, run final validation, then start the application on Azure. Keep a reverse GoldenGate path for 72 hours as a rollback option. The four-hour window is for draining and validation, not for moving 60 TB.

Capture once, fan out from the trail. GoldenGate integrated extract reads the source redo once. Use a second Replicat or a distribution path to send the same trail to Azure Data Lake Storage Gen2 in Parquet format through Oracle GoldenGate for Big Data. Synapse or Spark reads the Parquet files. This avoids running heavy queries against the production database and avoids a second extract.

Sizing: 200 GB/day is about 2.3 MB/s average. Even with peak bursts, this is small compared with the ExpressRoute capacity and the EBS transaction rate. The real risks are large batch updates and DDL, so filter only the schemas and tables analytics needs, and exclude high-volume transient tables that have no analytical value.

Freshness: Configure Replicat checkpointing and file rollover so Synapse sees files within minutes, not hours. Alarm on extract lag and Replicat lag separately. A sub-5-minute target is achievable with 1–2 minute checkpoints, but test the end-to-end lag during the nightly batch, not just during quiet daytime traffic.

Cost: GoldenGate for Big Data is additional software and compute; compare it with the current nightly export plus Synapse load. The incremental cost is justified if the business uses the fresher data; otherwise keep nightly loads for cold marts.

Tagging: Enforce business_unit, application, environment, and cost_center on Azure resources with Azure Policy, and mirror the same tags in OCI. Marketplace charges for Database@Azure may not carry every resource tag, so maintain a mapping table from Azure subscription/resource group and OCI tenancy/compartment to business unit.

Showback: Use Azure Cost Management for the Azure invoice and OCI Cost Analysis for OCI-native charges. Reconcile monthly, because the same database can produce an Azure Marketplace line item and an OCI cost record. Publish a showback report with actuals, budget, and forecast; do not call it chargeback until Finance agrees on allocation rules.

Budget alerts: Set 80% and 100% alerts per business unit and per environment. Alert on ExpressRoute egress, backup storage growth, and nonproduction Exadata running outside business hours.

Dashboard: One Grafana or Log Analytics view for both teams: GoldenGate extract/replicat lag, Data Guard apply lag, Exadata CPU and storage, ExpressRoute utilization, Azure and OCI spend versus budget, and open cost anomalies. Finance needs trend and forecast; SRE needs lag and capacity. Sharing the same data source prevents two versions of the truth.