物理备库试验二：验证redo apply的过程

环境描述：

配置好物理备库以后，将备库关闭。

主库进程创建用户，创建表和插入数据；切换日志。

试验目的：观察备库启动过程与DG相关状态的关系

1、备库启动到nomount

系统进程

查看archived_log的redo applay情况

主库上（由于试验前已将备库mount过一次，所以105到109已经传递过去但是没有apply的，而110到112 备库关闭后产生的还没有传输的信息）

结论：备库nomount状态，redo信息没有传递，所以不存在redo apply

2、将备库置于mount状态下

备库日志apply情况

主库

备库系统进程（多了几个arc的后台进程，由初始化参数决定了n；以及几个service process进程，此处的service process 进程包含了FRS服务，用于redo信息传输）

主库此时的系统进程（主库的系统进程在备库的关闭，nomount，mount下一致）

Mount 过程中备库启动的arc进程，及各自分工

arc进程数量通过参数log_archive_max_processes 决定，此过程中server porcess会派生出2个FRS进程。对应的主库会启动LNS后台进程（如果没有standby redo logfile那么redo信息都是通过arch传输归档日志，主库也就没有LNS后台进程）。

Mon May 11 14:57:14 2015

ARC3 started with pid=24, OS id=33334

Completed: alter database mount

Mon May 11 14:57:14 2015

ARC4 started with pid=25, OS id=33338

Mon May 11 14:57:14 2015

ARC5 started with pid=23, OS id=33340

Mon May 11 14:57:14 2015

ARC6 started with pid=26, OS id=33342

Mon May 11 14:57:14 2015

ARC7 started with pid=27, OS id=33344

ARC1: Archival started

ARC2: Archival started

ARC3: Archival started

ARC4: Archival started

ARC5: Archival started

ARC6: Archival started

ARC3: Becoming the ‘no FAL’ ARCH

ARC2: Becoming the heartbeat ARCH

ARC2: Becoming the active heartbeat ARCH

ARC7: Archival started

ARC0: STARTING ARCH PROCESSES COMPLETE

Mon May 11 14:57:16 2015

Using STANDBY_ARCHIVE_DEST parameter default value as /opt/app/oracle/oradata/arch

Mon May 11 14:57:18 2015

Primary database is in MAXIMUM PERFORMANCE mode

Mon May 11 14:57:18 2015

RFS[1]: Assigned to RFS process 33348

RFS[1]: Selected log 9 for thread 1 sequence 155 dbid 1406814826 branch 879034090

RFS[2]: Assigned to RFS process 33350

RFS[2]: Selected log 8 for thread 1 sequence 156 dbid 1406814826 branch 879034090

Archived Log entry 58 added for thread 1 sequence 155 ID 0x53d9896a dest 1:

3、备库启用redo apply

系统进程方面多了：mrp 和 三个后台ora_pr0进程，这些进程的日志显示其也是为mrp服务的

启动redo apply过程

启动redo apply，备库会开启MRP进程，并且启用n个slave进程（ora_pr0n）如果存在standby redo logfile，系统会clear redo信息。

Mon May 11 15:00:25 2015

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION

Attempt to start background Managed Standby Recovery process (orcl)

Mon May 11 15:00:25 2015

MRP0 started with pid=31, OS id=33363

MRP0: Background Managed Standby Recovery process started (orcl)

started logmerger process

Mon May 11 15:00:30 2015

Managed Standby Recovery starting Real Time Apply

Parallel Media Recovery started with 2 slaves

Waiting for all non-current ORLs to be archived…

All non-current ORLs have been archived.

Clearing online redo logfile 1 /opt/app/oracle/oradata/orcl/redo01.log

Clearing online log 1 of thread 1 sequence number 154

Clearing online redo logfile 1 complete

Clearing online redo logfile 2 /opt/app/oracle/oradata/orcl/redo02.log

Clearing online log 2 of thread 1 sequence number 155

Clearing online redo logfile 2 complete

Clearing online redo logfile 3 /opt/app/oracle/oradata/orcl/redo03.log

Clearing online log 3 of thread 1 sequence number 156

Clearing online redo logfile 3 complete

Media Recovery Log /opt/app/oracle/oradata/arch/arc_1_155_879034090.arc

Media Recovery Waiting for thread 1 sequence 156 (in transit)

Recovery of Online Redo Log: Thread 1 Group 8 Seq 156 Reading mem 0

Mem# 0: /opt/app/oracle/oradata/orcl/slog5.rdo

Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION

未经允许不得转载：SRE空间 » 物理备库试验二：验证redo apply的过程