Eight-Terabyte RAC Migration with a Four-Hour Window
A retailer runs Oracle 19c RAC on four on-premises nodes. The primary database is 8 TB, peak load is 12,000 transactions per minute, and a nightly batch runs for three hours. The maintenance window is four hours, and the business tolerates no more than 15 minutes of downtime and 1 minute of data loss. The network team provides a 1 Gbps Direct Connect with 18 ms round-trip latency to the AWS Region. The retailer is moving to Oracle Database@AWS Exadata Database Service and has Oracle GoldenGate 19c licenses, Data Pump, and Zero Downtime Migration available. It has completed two test migrations, but the third was cancelled after the batch overran by 40 minutes. The team debates a big-bang Data Pump export versus GoldenGate. You must choose the migration approach and define a cutover runbook.
1. Select the migration method and justify it against the RTO/RPO and 8 TB size.
Read the worked answer
Method. Use an initial physical load followed by GoldenGate change capture, not a big-bang Data Pump export. At 1 Gbps, an 8 TB export and import has no realistic chance inside a four-hour window once compression, network overhead, and index builds are included; the overrun is a symptom. Take an RMAN backup or use Data Pump for the initial load, then start GoldenGate extract from the on-premises source and apply to Oracle Database@AWS. Keep the source active while replicating. Data Guard is an alternative for same-version physical migration and can provide a standby, but it does not solve the cutover as flexibly if the batch must continue during transition. GoldenGate lets you drain the batch, confirm lag is zero, and cut over in minutes. Validate conflict handling and sequence values.
2. Write the cutover sequence with go/no-go gates and rollback.
Read the worked answer
Runbook. T-7 days: freeze DDL, run a full compare, and rehearse. T-0: announce, stop application writes, let the batch finish or pause at a restart point, and confirm GoldenGate lag is zero. Run final row counts and key business checks. Switch the application connection string to Oracle Database@AWS, start the batch, and monitor latency and errors. Go/no-go gates: replication lag under 5 seconds for 30 minutes, no unresolved DDL, batch checkpoint verified, backup completed on target, and rollback connection tested. Rollback: stop writes on target, point the application back to the source, and reconcile any target-only transactions if writes were allowed. Keep the source read-only for 72 hours. The 15-minute RTO is achievable only if connection strings and runbooks are pre-staged, not typed during the incident.
3. What HA and backup checks must pass before decommissioning the source?
Read the worked answer
HA checks. Validate a Data Guard standby in a second AZ with transport appropriate to the 1-minute RPO, and measure apply lag under peak batch. Test a planned switchover and an unplanned failover, including application reconnect. Confirm backups are scheduled, encrypted, and restorable to a point in time; perform an actual restore of a sample tablespace or database. Test the batch on the target at full volume; the 40-minute overrun suggests statistics, parallelism, or network throughput must be tuned. Confirm monitoring, alerting, and on-call ownership. Only then decommission the source. A backup that has never been restored is not evidence, and a standby that has never been promoted is not proof of RTO.