Maa

Switchover and failover are the two role-transition operations in Oracle Data Guard. Switchover is a planned, graceful transition (both databases remain available throughout). Failover is an emergency response to primary failure. Having a tested, documented playbook for both is a MAA operational requirement — discovering the procedure on the night of a failure is not a plan. Terminology Recap Term Trigger Data Loss? Primary State Afterward Switchover Planned maintenance None Becomes standby (online) Failover Primary failure Possible (ASYNC) or None (SYNC) Unavailable (failed) Reinstate After failover N/A Failed primary becomes new standby Always use the Data Guard Broker (DGMGRL) for role transitions. Direct SQL*Plus procedures are error-prone and lack the consistency checks the Broker provides. ...

Oracle Base Database Service (formerly DB System) is OCI’s IaaS-level Oracle Database offering — you provision a VM or Bare Metal shape, OCI installs and manages Oracle Database, and you retain full DBA control. Understanding its HA architecture is essential for designing systems that meet enterprise RPO/RTO targets. Shape Selection and Its HA Implications Base Database Service runs on two shape families: VM shapes (VM.Standard, VM.Optimized) — single or 2-node RAC. Bare Metal shapes (BM.DenseIO) — single instance with local NVMe, high IOPS. For high availability, the critical shape decision is whether to provision a 2-node RAC or a single-instance + Data Guard architecture. These are not equivalent: ...

Far Sync is an Oracle Data Guard feature that lets you achieve zero data loss (SYNC transport) to a remote standby database without paying the latency penalty on primary transactions. A Far Sync instance sits in a third location between the primary and the standby, receives redo synchronously from the primary (low-latency hop), and then ships it asynchronously to the standby (long-distance hop). 1. Reference Architecture 1.1 Environment Overview Role Hostname DB Unique Name Location OS Primary DB (RAC, 2 nodes) prim01.fra.example.com, prim02.fra.example.com ORCL_FRA Frankfurt DC (AZ-1) OL 8.9 Far Sync Instance farsync01.fra.example.com ORCL_FS Frankfurt DC (AZ-2) OL 8.9 Physical Standby (RAC, 2 nodes) stby01.ams.example.com, stby02.ams.example.com ORCL_AMS Amsterdam DC OL 8.9 DGMGRL / Observer host observer01.fra.example.com — Frankfurt DC (AZ-3) OL 8.9 Oracle version: 19c (19.23 RU) Primary ↔ Far Sync network: Dedicated 10 GbE VLAN, round-trip latency ≈ 0.4 ms Far Sync ↔ Standby network: WAN link, round-trip latency ≈ 8 ms DB_NAME: ORCL (same for all members); DB_UNIQUE_NAME differs per member 2. Live Redo Information Flow The diagram above shows the full geographical redo flow. Below is the step-by-step explanation of how zero data loss is achieved: ...

The redo transport configuration is the most consequential architectural decision in a Data Guard deployment. It determines the data loss exposure (RPO), the performance overhead on the primary, and the recovery point after a failover. Choosing SYNC or ASYNC without understanding the mechanics leads to either unacceptable data loss or unnecessary primary database degradation. Redo Transport Mechanisms ASYNC Transport (ARCN-based) In ASYNC mode, the primary database commits without waiting for the standby to acknowledge receipt of redo. The ARCn background process archives completed log groups and ships them to the standby. ...