A regional bank is migrating a 6 TB production Oracle 19c database that backs its core lending application to a managed Google Cloud target. Business stakeholders require continuous replication during a four-week parallel-run validation window, with cutover decided after reconciliation reports approve data parity. The source schema relies on PL/SQL packages, materialised views, and partitioned tables, and the team wants minimum operational overhead while keeping the source authoritative until cutover. Which migration approach best meets these requirements?
- AExport Oracle data to CSV with Data Pump, copy the files to Cloud Storage with Transfer Appliance, and load them into BigQuery, then run reconciliation against the live Oracle source for four weeks.
- BProvision an AlloyDB for PostgreSQL cluster as the target and use Database Migration Service with a continuous Oracle-to-AlloyDB job, accepting that PL/SQL packages and materialised views must be converted manually before promotion. Correct
- CStream Oracle change data into BigQuery using Datastream and point the lending application at BigQuery once reconciliation passes, leaving PL/SQL logic to be re-implemented in scheduled queries.
- DUse BigQuery Data Transfer Service to schedule recurring loads from the Oracle source into BigQuery datasets and treat the BigQuery copy as the new system of record after parity is confirmed.
Why A is wrong: Transfer Appliance combined with a one-shot CSV export does not provide continuous replication, so any changes during the four-week validation window would be lost, and BigQuery is not the right target for an OLTP lending workload that needs transactional semantics.
Why B is correct: Database Migration Service supports continuous Oracle-to-AlloyDB jobs with minimal operational footprint and lets the team run parallel validation before promoting the replica, while the documented limitation that PL/SQL packages and materialised views need manual conversion is explicitly acknowledged.
Why C is wrong: Datastream replicates change data into BigQuery or Cloud Storage for analytics, but BigQuery is not a transactional database for a core lending application, so cutting the OLTP workload over to it would break correctness guarantees the application depends on.
Why D is wrong: BigQuery Data Transfer Service is a managed loader for analytics sources such as SaaS applications and warehouses, not a transactional replication tool for Oracle OLTP, and BigQuery cannot serve a core lending application with row-level transactional updates.