Data Guard Switchover vs GoldenGate Cutover for a Small Single-Schema Oracle Migration

Expected behavior for in‑flight transactions and connection pools

Data Guard physical standby switchover (confirmed):

• The switchover command waits until all redo from the primary has been applied to the standby.
• Any in‑flight transactions are allowed to commit or are rolled back consistently before the role change.
• After the standby becomes the new primary, existing client connections receive ORA‑03113/ORA‑03114 errors and must reconnect.
• Connection pools typically retry automatically and resume within a few seconds.

GoldenGate cutover point (confirmed):

• The source application is stopped, then Extract/Replicat lag is driven to zero.
• Any transaction that has not committed before the stop is not replicated and would be lost; therefore a quiescent state (no open transactions) is normally required.
• After the target is switched to active, connections to the old source see ORA‑03113 when the source is shut down and must reconnect to the target.
• Connection pools behave similarly – they error and then retry against the new connection string.

Effect of preserving vs. changing database service names

Preserving the original service name (confirmed):

• Application connection strings or TNS aliases remain unchanged after switchover or cutover.
• Rollback is a simple reverse switchover (Data Guard) or re‑establishing GoldenGate in the opposite direction – no name change needed.
• No application configuration updates are required at cutover.

Changing the service name at cutover (confirmed):

• The application must update its connection strings or TNS aliases to reflect the new name.
• Rollback requires reverting the name change and updating the application again, adding operational steps.
• The benefit is eliminating any chance of confusing the old and new environments, but it adds configuration overhead.

Steps needed for this small single‑schema migration

1. Verify Oracle release and patch level compatibility between primary and standby (or source and target for GoldenGate).
2. For Data Guard: ensure redo apply lag is zero, then issue the switchover command; monitor for ORA‑03113/03114 and let connection pools reconnect.
3. For GoldenGate: stop the application, drive Extract/Replicat lag to zero, confirm no open transactions on the source, then switch the target to active; redirect connections and monitor for errors.
4. Decide on service‑name handling: preserve name to avoid application changes, or change name if environment separation is preferred and you accept the extra configuration step.

Ask for one missing diagnostic detail only when it changes the recommendation:

Confirm that the primary and standby (or source and target) are running the same Oracle release and patch level; if they differ, Data Guard switchover may fail or cause data divergence, which would favor GoldenGate despite its overhead.