The below process flow deals with the Physical Standby
database configured with Asynchronous redo transfer which is mostly preferred.
Physical Standby - Asynchronous redo transfer architecture:
A detailed process flow:
On Primary database:
1.
Transaction entry to
Primary database’s memory:
i.
As soon as the transaction starts,
exclusive locks are acquired on all the buffer cache that is required for the
transaction.
2.
Transaction written as
redo to redo buffer:
i.
In the Program Global Area (PGA) of the
processes, the redo blocks that describe the changes or the change vectors are
generated and stored.
ii.
Space is then allocated in the redo log
buffer after successfully acquiring the redo allocation latch.
iii.
The generated redo then gets copied from
processes’ PGA to the allocated space in the redo log buffer.
3.
Flush redo log buffers to
disk:
i.
Then, Oracle foreground process (Server
process) tells LGWR to flush the redo log buffers to disk.
ii.
Then, the LGWR flushes the redo buffer
contents to the Online Redo Log file(s), and also acknowledges the session
completion. Now, the transaction is persistent on the disk without a commit.
iii.
The ARCH process archives the Online Redo
log files (ORL) into archive log files.
iv.
During the checkpoint, DBWRn writes the
database buffers, that were previously changed, are written into the disk.
Note: LGWR must have already written the redo buffers in to disk before
the DBWRn flushes the database buffers to the disks. The “write-ahead logging
protocol” enforces this explicit sequence in the database.
4.
Redo transport to Standby
site:
i.
The LNS process then reads the recently
flushed redo from the online redo log files and sends the redo data to the
Standby database using the “redo transport destination”
(LOG_ARCHIVE_DEST_n parameter) that was
defined in pfile or spfile of the Primary database while configuring the Data
Guard setup.
ii.
In ASYNC transportation method, the LGWR
does not wait for any acknowledgement from LNS for transmitting the redo data
over the network and also for applying the changes successfully on the Standby
database.
On Standby database:
5.
Writes redo stream to
Standby Redo Log files:
i.
RFS process receives the redo stream on the
Standby site from the network socket and stores it in the network buffers, and
then writes this redo buffers into the Standby redo log files (SRLs).
6.
Archiving Standby Redo log
files:
i.
The ARCH process then archives the Standby
redo logs into archive log files while a log switch occurs on the primary
database.
ii.
The generated archive logs are then
registered with the Standby control file.
7.
Recovery process on
Standby database’s memory:
i.
Initiating the actual recovery process on
the Standby database starts here. The managed recovery asynchronously reads the
redo from the SRLs (in case of real-time apply) or archive log files.
ii.
The data blocks that requires redo apply
are parsed out and stored into appropriate in-memory map segments.
8.
Further recovery process
on memory:
i.
MRP process then ships the recovery slaves
using the Parallel Query (PQ) inter-process communication framework.
ii.
And then, Parallel Media Recovery (PMR)
reads the required data blocks into the buffer cache. Then, the redo will be
subsequently applied to the buffers of that buffer cache.
9.
Data flush to database
files:
i.
During the checkpoint phase, the recently
modified buffers (by the parallel recovery slaves) that are in the buffer cache
are flushed to the disk.
ii.
And, the data files’ headers are updated to
record the checkpoint completion.
Physical Standby - Synchronous redo transfer architecture:
No comments:
Post a Comment