PHYSICAL STANDBY ARCHITECTURE

On the primary database site, LGWR collects transactions from the log buffer and
writes to the redo logs.
LGWR and LNS(Log Writer Network Server) process or ARCH process transmit redo lo
gs to standby database.
DBA need to configure LOG_ARCHIVE_DEST_n init.ora parameter to specify LGWR, ARC
H and Remote TNS to transmit Redo/Archive logs to Standby Database.
On the standby database site, the remote file server process (RFS) receives arch
ived redo logs from the primary database. The redo logs information received by
the RFS process can be stored as either standby redo logs or archived redo logs.
Managed recovery process (MRP) applies redo log information to the standby datab
ase.
fetch archive log (FAL) client runs on Standby and detects the Archive Logs whic
h are not applied to Standby database.
fetch archive log (FAL) server process runs on the primary database and services
the missing archive log requests coming from the FAL client.
Using FAL_CLIENT and FAL_SERVER init.ora parameters, the managed-recovery proces
s in the physical database will automatically check and resolve the Redo Log gap
s.
When using Data Guard broker (dg_broker_start = true), the monitor agent process
named Data Guard Broker Monitor (DMON) is running on every site (primary and st
andby) and maintain a two-way communication.
Data Guard broker automates the creation, control, and monitoring of a Data Guar
d configuration.
Setting dg_broker_start = true init.ora parameter starts the Data Guard Broker M
onitor(DMON) process.
$ dgmgrl command is used by dba to manage Data Guard Broker configuration.
LOGICAL STANDBY PROCESSES ARCHITECTURE
logical standby process (LSP) reads the Redo Logs and extract the SQL statements
from it. The Apply process applies these SQL statements to Logical Standby dat
abase.
Logical Standby can be queried while Sqls are applied on it.