Cutting Over an 11g Database With a Ten-Minute Window
A hospital group must move a 6 TB patient-records database from an on-premises Oracle 11.2.0.4 single instance on Linux to OCI within one quarter. The source runs on end-of-life hardware, and the business wants a fully managed target with no OS access, automatic patching and a built-in standby. Downtime is capped at 10 minutes, so a weekend Data Pump export is not acceptable. The schema uses a public database link to a 10g reporting database, a directory object written to by a nightly UTL_FILE batch, and a few Java stored procedures. The application team can make small code changes but needs six weeks of parallel-run validation before cutover. There is an 8 TB staging host on-premises and a 1 Gbps connection to the OCI region. Roughly 40 GB of redo is generated per day.
1. Choose the target service and the migration method, and justify both against the constraints.
Read the worked answer
Target: Autonomous Database is the closest match to 'fully managed, no OS access, automatic patching, built-in standby' (Autonomous Data Guard), but it fails the compatibility check on at least one hard point. UTL_FILE writing to an OS directory is impossible because ADB exposes no filesystem beyond the Data Pump directory; the nightly batch must be rewritten to write to Object Storage through DBMS_CLOUD. The public database link to a 10g database is the second risk: DB links are supported but credentials must live in a wallet, and such an old remote version needs verification before you commit. If both changes fit in the quarter, ADB is the right answer. If not, Base Database Service or Exadata Database Service preserves full compatibility but gives back some of the managed benefits.
Method: GoldenGate, or Zero Downtime Migration in logical online mode, which orchestrates GoldenGate for you. Data Pump alone cannot meet a 10-minute window. A physical Data Guard migration is not possible here at all, because Data Guard requires the standby to be on the same database release - you cannot stand up a 19c standby directly from 11.2.0.4 without an intermediate upgrade, and an intermediate upgrade sequence blows the schedule. GoldenGate also gives you the reverse path for rollback.
2. Describe the parallel-run and cutover plan, including the details teams usually forget.
Read the worked answer
Parallel run requires a second target environment or a second replicat, not just a long wait. Sequence: provision target and validation environments; start the GoldenGate extract on the source; run the initial load; start the replicat to the target and a second replicat to the validation environment; compare continuously using row counts, checksums or GoldenGate Veridata. The six weeks are for the application team to exercise real business flows, not for the database to sit idle.
Cutover: put the application into read-only or maintenance mode; wait until replicat lag reaches zero and the checkpoint is confirmed; run final validation; recompile invalid objects and gather statistics; switch the connection string or DNS; then keep a reverse extract and replicat running against the old source for the rollback window.
Details that derail cutovers: sequences are not replicated by GoldenGate, so reset them on the target above the current high-water mark; scheduler jobs and directory paths must be re-pointed; the Java stored procedures must be compiled and tested on the target release; and the UTL_FILE batch must already be writing to Object Storage before cutover, not after.
3. Sanity-check the network and staging capacity for the initial load.
Read the worked answer
Do the arithmetic before promising a weekend.
1 Gbps is 125 MB/s theoretical. Real WAN throughput is typically 60 to 70 percent of line rate once you account for latency and windowing, so call it 80 MB/s. 6 TB is roughly 6,000,000 MB, which at 80 MB/s is about 75,000 seconds, or roughly 21 hours. That fits a weekend, but only just, and it leaves no room for a retry.
The 40 GB per day of redo is about 0.5 MB/s average - negligible against the link, which is why GoldenGate replication after the initial load is comfortable.
The 8 TB staging host is fine for a compressed Data Pump dump of roughly 1 to 1.5 TB, and for GoldenGate trail files: at 40 GB per day, 45 days without purging is about 1.8 TB. Add a purge policy for the trails anyway, because a long parallel run will accumulate more than you expect.
Two scheduling cautions: the initial load saturates the link, so run it outside business hours, and use multiple parallel streams so you actually fill the pipe rather than running one serial Data Pump process.