oracle standby redo,standby redo log的理解

V$LOGFILE：Contains information about the online redo log files and standby redo log files

V$LOGFILE.TYPE=ONLINE OR STANDBY

V$STANDBY_LOG：Contains log file information from the standby redo log files

RFS process：remote file server (RFS) process

The standby redo logs are populated with redo information as fast as the primary redo logs, rather than waiting for the redo log to be archived and shipped to the standby database. This means that the standby redo log has more current information than the log apply mechanism because it took a "shortcut" and was written to the standby, bypassing the traditional archiving and FTP to the standby database.

The synchronous and asynchronous redo transport modes require that a redo

transport destination have a standby redo log.A standby redo log is used to store redo

received from another Oracle database. Standby redo logs are structurally identical to

redo logs, and are created and managed using the same SQL statements used to create

and manage redo logs.

Redo received from another Oracle database via redo transport is written to the

current standby redo log group by an RFS foreground process. When a log switch

occurs on the redo source database, incoming redo is then written to the next standby

redo log group, andthe previously used standby redo log group is archived by an

ARCn foreground process.

The process of sequentially filling and then archiving redo log file groups at a redo

source database is mirrored at each redo transport destination by the sequential filling

and archiving of standby redo log groups.

Each standby redo log file must be at least as large as the largest redo log file in the

redo log of the redo source database. For administrative ease, Oracle recommends that

all redo log files in the redo log at the redo source database and the standby redo log at

a redo transport destination be of the same size.

The standby redo log must have at least one more redo log group than the redo log at

the redo source database, for each redo thread at the redo source database. At the redo

source database, query the V$LOG view to determine how many redo log groups are in

the redo log at the redo source database and query the V$THREAD view to determine

how many redo threads exist at the redo source database.

Cases Where Redo Is Written Directly To an Archived Redo Log File

Redo received by a standby database is written directly to an archived redo log file if a

standby redo log group is not available or if the redo was sent to resolve a redo gap.

When this occurs, redo is written to the location specified by the LOCATION attribute of

one LOG_ARCHIVE_DEST_n parameter that is valid for archiving redo received from

another database. The LOG_ARCHIVE_DEST_n parameter that is used for this purpose is

determined when the standby database is mounted, and this choice is reevaluated

each time a LOG_ARCHIVE_DEST_n parameter is modified.

Apply Services

Apply redo data on the standby database to maintain transactional

synchronization with the primary database. Redo data can be applied either from

archived redo log files, or, if real-time apply is enabled, directly from the standby

redo log files as they are being filled, without requiring the redo data to be

archived first at the standby database.

By default, apply services waits for a standby redo log file to be archived before

applying the redo that it contains. However, you can enable real-time apply, which

allows apply services to apply the redo in the current standby redo log file as it is

being filled