Oracle 视图 DBA_LOGSTDBY_HISTORY 官方解释,作用,如何使用详细说明
本站中文解释
DBA_LOGSTDBY_HISTORY视图提供了Logical Standby数据库中应用到DATABASE主要维护操作的历史日志。它通过检索应用程序日志文件中在一个或多个数据库之间同步数据的历史纪录来实现此功能。
使用此视图需要建立Logical Standby DataGuard环境,并且使用Oracle Database的Media Recovery功能以正确的方式应用到DATABASE。将dlm_consumer_name参数设置为DLM_ASM_CONSUMER,然后使用alter database start logical standby apply语句来启动一个Logical Standby Apply程序,这将使用该DBA_LOGSTDBY_HISTORY视图跟踪历史纪录。
该视图向您显示历史纪录行,包括以下信息:
APPLIED_SCN:指示SCN,应用到数据库的最后一个ANTI {网恢复}操作完成的时候的。
NAME:同步的日志文件的名称。
THREAD#:Logical Standby Apply程序的当前活动线程号码。
STATUS:指示每一个日志文件同步的状态。
START_TIME:指示什么时候Logical Standby Apply程序的该日志文件的同步开始的。
All_APPLIED_TIME:该日志文件所有更新操作被应用到DATABASE的完成时间。
官方英文解释
DBA_LOGSTDBY_HISTORY
displays the history of switchovers and failovers in a Data Guard configuration.
It does this by showing the complete sequence of redo log streams processed or created on the local system, across all role transitions. (After a role transition, a new log stream is started and the log stream sequence number is incremented by the new primary database.). This view is for logical standby databases only.
Column | Datatype | NULL | Description |
---|---|---|---|
|
|
Lists the sequence numbers for all log streams created or applied on the local system. Note: A value of 0 indicates an unknown sequence order; this is reserved for future log streams. |
|
|
|
Description of the log stream processing:
|
|
|
|
Describes how the log stream was started:
|
|
|
|
Database identifier of the primary database that created the log stream |
|
|
|
Lowest system change number (SCN) in the current log file |
|
|
|
Highest system change number (SCN) in the current log file |
|
|
|
Time of the first SCN entry ( |
|
|
|
Time of the last SCN entry ( |
|
|
|
Unique database name ( |
|
|
|
SCN that should be used to flashback a failed primary (that created the log stream) or to flashback a bystander logical standby database following a failover, in the context of the associated redo log stream. It is the SCN up to which redo for the associated log stream can be merged safely in all databases using local copies of archived logs received from the primary database. In order to apply changes beyond this following a failover, you will need to fetch and mine the redo logs from the failover target. |
|
|
|
Strict upper bound on the SCN up to which SQL Apply has applied redo records before it switched to a new log stream (either because it was activated and became the primary database, or in the case of a bystander logical standby database where it switched to a new log stream to accommodate a new primary database). |
Note:
In a CDB, this view shows data only when queried in the root.