OracleDG主库丢失归档增量同步-白红宇

OracleDG主库丢失归档增量同步

阅读量：5095 次

发布时间：2019-06-13

本文共 22723 字，大约阅读时间需要 75 分钟。

1.1 问题

在主库archivelog丢失后，数据无法同步到备库时，可以利用增量scn的方式，来避免全库还原备库或重建standby

以下在Oracle10g下操作

1.2 当前正常主备

确认当前主库与备库是同步的：

1.2.1 主库

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE

----------------

PRIMARY

SQL> set linesize 200 pagesize 200

SQL> select group#,sequence#,status,first_time,to_char(first_change#) as begin_scn from v$log order by group# asc;

GROUP# SEQUENCE# STATUS FIRST_TIME BEGIN_SCN

---------- ---------- ---------------- -------------- ----------------

1 192 CURRENT 03-9月 -13 1883016

2 190 INACTIVE 03-9月 -13 1882999

3 191 INACTIVE 03-9月 -13 1883014

SQL> select count(*) from t;

COUNT(*)

----------

SQL> archive log list;

数据库日志模式存档模式

自动存档启用

存档终点 /archive

最早的联机日志序列 190

下一个存档日志序列 192

当前日志序列 192

1.2.2 备库

SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

--------- ------------ ---------- ---------- ---------- ----------

ARCH CONNECTED 0 0 0 0

ARCH CLOSING 1 189 1 1

ARCH CLOSING 1 191 1 1

ARCH CLOSING 1 188 40961 1824

ARCH CLOSING 1 190 1 4

ARCH CONNECTED 0 0 0 0

MRP0 WAIT_FOR_LOG 1 192 0 0

RFS IDLE 0 0 0 0

已选择13行。

1.3 模拟主库丢失归档

1.3.1 禁用归档至备库

SQL> SELECT * FROM v$Log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME

---------- ---------- ------- ---------- --- ---------------- -------------

1 1 192 52428800 3 YES INACTIVE 1883016 03-9月 -13

2 1 193 52428800 3 YES INACTIVE 1883668 03-9月 -13

3 1 194 52428800 3 NO CURRENT 1883688 03-9月 -13

SQL> ALTER system SET log_archive_dest_state_2 = 'defer';

系统已更改

1.3.2 测试数据准备

SQL> delete from t where id<10;

已删除3行。

SQL> commit;

提交完成。

SQL> select * from t;

----------

111

SQL> ALTER system switch logfile;

系统已更改。

SQL> ALTER system switch logfile;

系统已更改。

SQL> ALTER system switch logfile;

系统已更改。

1.3.3 删除未传输到备库的某个归档

oracle@linux-7gnw:~> cd /archive/

oracle@linux-7gnw:/archive> ls -lrt

total 1935908

-rw-r----- 1 oracle oinstall 1024 2013-09-03 11:30 sdk_1_819054888_189.dbf

-rw-r----- 1 oracle oinstall 21905920 2013-09-03 11:31 sdk_1_819054888_188.dbf

-rw-r----- 1 oracle oinstall 2560 2013-09-03 11:31 sdk_1_819054888_190.dbf

-rw-r----- 1 oracle oinstall 1024 2013-09-03 11:31 sdk_1_819054888_191.dbf

-rw-r----- 1 oracle oinstall 204288 2013-09-03 11:55 sdk_1_819054888_192.dbf

-rw-r----- 1 oracle oinstall 4608 2013-09-03 11:56 sdk_1_819054888_193.dbf

-rw-r----- 1 oracle oinstall 3465728 2013-09-03 14:09 sdk_1_819054888_194.dbf

-rw-r----- 1 oracle oinstall 1024 2013-09-03 14:09 sdk_1_819054888_195.dbf

-rw-r----- 1 oracle oinstall 2560 2013-09-03 14:09 sdk_1_819054888_196.dbf

oracle@linux-7gnw:/archive> rm sdk_1_819054888_195.dbf

oracle@linux-7gnw:/archive> rm sdk_1_819054888_196.dbf

SQL> ALTER system switch logfile;

系统已更改。

SQL> ALTER system SET log_archive_dest_state_2 = 'enable';

系统已更改。

1.3.4 主库报错

Tue Sep 3 14:13:08 2013

Errors in file /oracle/admin/sdk/bdump/sdk_arc4_4339.trc:

ORA-00308: cannot open archived log '/archive/sdk_1_819054888_196.dbf'

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

Tue Sep 3 14:13:08 2013

FAL[server, ARC4]: FAL archive failed, see trace file.

Tue Sep 3 14:13:08 2013

Errors in file /oracle/admin/sdk/bdump/sdk_arc4_4339.trc:

ORA-16055: FAL request rejected

ARCH: FAL archive failed. Archiver continuing

Tue Sep 3 14:13:08 2013

ORACLE Instance sdk - Archival Error. Archiver continuing.

Tue Sep 3 14:13:08 2013

Errors in file /oracle/admin/sdk/bdump/sdk_arc3_4337.trc:

ORA-00308: cannot open archived log '/archive/sdk_1_819054888_195.dbf'

ORA-27037: unable to obtain file status

Linux-x86_64 Error: 2: No such file or directory

Additional information: 3

Tue Sep 3 14:13:08 2013

FAL[server, ARC3]: FAL archive failed, see trace file.

Tue Sep 3 14:13:08 2013

Errors in file /oracle/admin/sdk/bdump/sdk_arc3_4337.trc:

ORA-16055: FAL request rejected

ARCH: FAL archive failed. Archiver continuing

Tue Sep 3 14:13:08 2013

ORACLE Instance sdk - Archival Error. Archiver continuing.

1.3.5 备库也报错

SQL> ALTER DATABASE recover managed standby DATABASE cancel;

数据库已更改。

SQL> alter database recover managed standby database parallel 4 using current logfile disconnect from session;

数据库已更改。

SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

--------- ------------ ---------- ---------- ---------- ----------

ARCH CONNECTED 0 0 0 0

MRP0 WAIT_FOR_GAP 1 195 0 0

RFS IDLE 0 0 0 0

已选择13行。

主库丢失了两个归档日志，备库无法同步

alter database recover managed standby database parallel 4 using current logfile disconnect from session

Tue Sep 3 14:12:18 2013

Attempt to start background Managed Standby Recovery process (sdk)

MRP0 started with pid=24, OS id=5134

Tue Sep 3 14:12:18 2013

MRP0: Background Managed Standby Recovery process started (sdk)

Managed Standby Recovery starting Real Time Apply

parallel recovery started with 4 processes

Tue Sep 3 14:12:24 2013

Waiting for all non-current ORLs to be archived...

Tue Sep 3 14:12:24 2013

Completed: alter database recover managed standby database parallel 4 using current logfile disconnect from session

Tue Sep 3 14:12:25 2013

Media Recovery Waiting for thread 1 sequence 195

Fetching gap sequence in thread 1, gap sequence 195-196

Tue Sep 3 14:13:26 2013

FAL[client]: Failed to request gap sequence

GAP - thread 1 sequence 195-196

DBID 3126144103 branch 819054888

FAL[client]: All defined FAL servers have been attempted.

-------------------------------------------------------------

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that is sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

-------------------------------------------------------------

1.4 恢复同步

1.4.1 定位到SCN

根据GAP情况 GAP - thread 1 sequence 195-196

SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# FROM v$archived_log

WHERE SEQUENCE# > 194 ORDER BY 1;

SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#

---------- ------------- ------------

195 1888252 1888254

196 1888254 1888257

197 1888257 1888287

1.4.2 从丢失归档时SCN备份

195号规定对应的SCN是1888252

RMAN> backup device type disk incremental from scn 1888252 database format '/oracle/lost_archive_%u_%s_%p.bk';

启动 backup 于 03-9月 -13

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=131 devtype=DISK

通道 ORA_DISK_1: 启动全部数据文件备份集

通道 ORA_DISK_1: 正在指定备份集中的数据文件

输入数据文件 fno=00002 name=/oracle/oradata/sdk/undotbs01.dbf

输入数据文件 fno=00001 name=/oracle/oradata/sdk/system01.dbf

输入数据文件 fno=00003 name=/oracle/oradata/sdk/sysaux01.dbf

输入数据文件 fno=00004 name=/oracle/oradata/sdk/users01.dbf

通道 ORA_DISK_1: 正在启动段 1 于 03-9月 -13

通道 ORA_DISK_1: 已完成段 1 于 03-9月 -13

段句柄=/oracle/lost_archive_06oiu8cg_6_1.bk 标记=TAG20130903T143248 注释=NONE

通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:45

通道 ORA_DISK_1: 启动全部数据文件备份集

通道 ORA_DISK_1: 正在指定备份集中的数据文件

备份集中包括当前控制文件

在备份集中包含当前的 SPFILE

通道 ORA_DISK_1: 正在启动段 1 于 03-9月 -13

通道 ORA_DISK_1: 已完成段 1 于 03-9月 -13

段句柄=/oracle/lost_archive_07oiu8du_7_1.bk 标记=TAG20130903T143248 注释=NONE

通道 ORA_DISK_1: 备份集已完成, 经过时间:00:00:03

完成 backup 于 03-9月 -13

1.4.3 查看备份片

oracle@linux-7gnw:~> ls -lrt /oracle/

total 1165084

drwxr-xr-x 3 oracle oinstall 4096 2013-06-25 18:46 product

drwxr-xr-x 3 oracle oinstall 4096 2013-06-25 19:14 oradata

-rw-r----- 1 oracle oinstall 630784 2013-09-03 14:33 lost_archive_06oiu8cg_6_1.bk

-rw-r----- 1 oracle oinstall 7438336 2013-09-03 14:33 lost_archive_07oiu8du_7_1.bk

1.4.4 传输备份片到备库

oracle@linux-7gnw:~> cd /oracle/

oracle@linux-7gnw:/oracle> scp lost_archive_06oiu8cg_6_1.bk lost_archive_07oiu8du_7_1.bk oracle@192.168.142.163:/archive

Password:

lost_archive_06oiu8cg_6_1.bk 100% 616KB 616.0KB/s 00:00

lost_archive_07oiu8du_7_1.bk 100% 7264KB 3.6MB/s 00:02

然后去备库还原这2个文件：

1.4.5 备库增量还原

SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

--------- ------------ ---------- ---------- ---------- ----------

ARCH CONNECTED 0 0 0 0

MRP0 WAIT_FOR_GAP 1 195 0 0

RFS IDLE 0 0 0 0

已选择13行。

SQL> ALTER DATABASE recover managed standby DATABASE cancel;

数据库已更改。

oracle@linux-5pzu:~> rman target /

恢复管理器: Release 10.2.0.4.0 - Production on 星期二 9月 3 14:36:52 2013

已连接到目标数据库: SDK (DBID=3126144103, 未打开)

RMAN> catalog backuppiece '/archive/lost_archive_06oiu8cg_6_1.bk';

使用目标数据库控制文件替代恢复目录

已列入目录的备份段

备份段 handle=/archive/lost_archive_06oiu8cg_6_1.bk recid=1 stamp=825172729

RMAN> catalog backuppiece '/archive/lost_archive_07oiu8du_7_1.bk';

已列入目录的备份段

备份段 handle=/archive/lost_archive_07oiu8du_7_1.bk recid=2 stamp=825172787

RMAN> recover DATABASE noredo;

启动 recover 于 03-9月 -13

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=147 devtype=DISK

通道 ORA_DISK_1: 正在开始恢复增量数据文件备份集

通道 ORA_DISK_1: 正在指定从备份集还原的数据文件

数据文件 00001 的还原目标: /oracle/oradata/sdk/system01.dbf

数据文件 00002 的还原目标: /oracle/oradata/sdk/undotbs01.dbf

数据文件 00003 的还原目标: /oracle/oradata/sdk/sysaux01.dbf

数据文件 00004 的还原目标: /oracle/oradata/sdk/users01.dbf

通道 ORA_DISK_1: 正在读取备份片段 /archive/lost_archive_06oiu8cg_6_1.bk

通道 ORA_DISK_1: 已还原备份片段 1

段句柄 = /archive/lost_archive_06oiu8cg_6_1.bk 标记 = TAG20130903T143248

通道 ORA_DISK_1: 还原完成, 用时: 00:00:03

完成 recover 于 03-9月 -13

RMAN> exit

恢复管理器完成。

1.4.6 启动同步

oracle@linux-5pzu:~> sqlplus /nolog

SQL*Plus: Release 10.2.0.4.0 - Production on 星期二 9月 3 14:41:27 2013

SQL> connect / as sysdba

已连接。

SQL> alter database recover managed standby database parallel 4 using current logfile disconnect from session;

数据库已更改。

SQL> SELECT database_role,open_mode FROM v$database;

DATABASE_ROLE OPEN_MODE

---------------- ----------

PHYSICAL STANDBY MOUNTED

Tue Sep 3 14:35:38 2013

ALTER DATABASE recover managed standby DATABASE cancel

Tue Sep 3 14:35:56 2013

MRP0: Background Media Recovery cancelled with status 16037

Tue Sep 3 14:35:56 2013

Errors in file /oracle/admin/sdk/bdump/sdk_mrp0_5134.trc:

ORA-16037: user requested cancel of managed recovery operation

Managed Standby Recovery not using Real Time Apply

Recovery interrupted!

Tue Sep 3 14:35:56 2013

Errors in file /oracle/admin/sdk/bdump/sdk_mrp0_5134.trc:

ORA-16037: user requested cancel of managed recovery operation

Tue Sep 3 14:35:56 2013

MRP0: Background Media Recovery process shutdown (sdk)

Tue Sep 3 14:35:56 2013

Managed Standby Recovery Canceled (sdk)

Tue Sep 3 14:35:56 2013

Completed: ALTER DATABASE recover managed standby DATABASE cancel

Tue Sep 3 14:40:42 2013

Incremental restore complete of datafile 4 /oracle/oradata/sdk/users01.dbf

checkpoint is 1888992

Incremental restore complete of datafile 3 /oracle/oradata/sdk/sysaux01.dbf

checkpoint is 1888992

Incremental restore complete of datafile 1 /oracle/oradata/sdk/system01.dbf

checkpoint is 1888992

Incremental restore complete of datafile 2 /oracle/oradata/sdk/undotbs01.dbf

checkpoint is 1888992

Tue Sep 3 14:41:36 2013

alter database recover managed standby database parallel 4 using current logfile disconnect from session

Tue Sep 3 14:41:36 2013

Attempt to start background Managed Standby Recovery process (sdk)

MRP0 started with pid=24, OS id=5277

Tue Sep 3 14:41:37 2013

MRP0: Background Managed Standby Recovery process started (sdk)

Managed Standby Recovery starting Real Time Apply

parallel recovery started with 4 processes

Tue Sep 3 14:41:46 2013

Waiting for all non-current ORLs to be archived...

Media Recovery Waiting for thread 1 sequence 195

Fetching gap sequence in thread 1, gap sequence 195-196

Tue Sep 3 14:41:46 2013

Completed: alter database recover managed standby database parallel 4 using current logfile disconnect from session

Tue Sep 3 14:42:47 2013

FAL[client]: Failed to request gap sequence

GAP - thread 1 sequence 195-196

DBID 3126144103 branch 819054888

FAL[client]: All defined FAL servers have been attempted.

-------------------------------------------------------------

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that is sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

-------------------------------------------------------------

1.4.7 主库归档位置

SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",MAX(lh.SEQUENCE#) "Last Seq Applied"

FROM v$archived_log al, v$log_history lh;

SQL> SELECT database_role,open_mode FROM v$database;

DATABASE_ROLE OPEN_MODE

---------------- ----------

PRIMARY READ WRITE

SQL> ALTER system switch logfile;

系统已更改。

SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",MAX(lh.SEQUENCE#) "Last Seq Applied"

2 FROM v$archived_log al, v$log_history lh;

Last Seq Recieved Last Seq Applied

----------------- ----------------

198 198

1.4.8 备库归档位置

SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

--------- ------------ ---------- ---------- ---------- ----------

ARCH CONNECTED 0 0 0 0

ARCH CLOSING 1 198 1 777

ARCH CONNECTED 0 0 0 0

MRP0 WAIT_FOR_GAP 1 195 0 0

RFS IDLE 0 0 0 0

已选择14行。

SQL> SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",MAX(lh.SEQUENCE#) "Last Seq Applied"

2 FROM v$archived_log al, v$log_history lh;

Last Seq Recieved Last Seq Applied

----------------- ----------------

198 194

SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",MAX(lh.SEQUENCE#) "Last Seq Applied"

FROM v$archived_log al, v$log_history lh;

1.4.9 显示有GAP

SQL> SELECT * FROM v$archive_gap;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

---------- ------------- --------------

1 195 196

SQL> SELECT * FROM v$archive_gap;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

---------- ------------- --------------

1 195 196

SQL> ALTER DATABASE recover managed standby DATABASE cancel;

数据库已更改。

SQL> SELECT file#,checkpoint_change# FROM v$datafile ORDER BY 1;

FILE# CHECKPOINT_CHANGE#

---------- ------------------

1 1888252

2 1888252

3 1888252

4 1888252

SQL> SELECT file#,checkpoint_change# FROM v$datafile_header ORDER BY 1;

FILE# CHECKPOINT_CHANGE#

---------- ------------------

1 1888992

2 1888992

3 1888992

4 1888992

1.4.10 GAP说明

尽管在恢复两个备份片后备库日志还说有GAP：

备库归档显示也是缺少归档的：

linux-5pzu:~ # ls -lrt /archive/

total 83144

-rw-r----- 1 oracle oinstall 50181632 Sep 3 10:22 sdk_1_819054888_187.dbf

-rw-r----- 1 oracle oinstall 1024 Sep 3 11:31 sdk_1_819054888_189.dbf

-rw-r----- 1 oracle oinstall 1024 Sep 3 11:31 sdk_1_819054888_191.dbf

-rw-r----- 1 oracle oinstall 2560 Sep 3 11:31 sdk_1_819054888_190.dbf

-rw-r----- 1 oracle oinstall 21905920 Sep 3 11:32 sdk_1_819054888_188.dbf

-rw-r----- 1 oracle oinstall 204288 Sep 3 11:58 sdk_1_819054888_192.dbf

-rw-r----- 1 oracle oinstall 4608 Sep 3 11:58 sdk_1_819054888_193.dbf

-rw-r----- 1 oracle oinstall 3465728 Sep 3 14:11 sdk_1_819054888_194.dbf

缺少删除的196和 196.

-rw-r----- 1 oracle oinstall 7168 Sep 3 14:11 sdk_1_819054888_197.dbf

-rw-r----- 1 oracle oinstall 107520 Sep 3 14:59 sdk_1_819054888_199.dbf

-rw-r----- 1 oracle oinstall 1024 Sep 3 14:59 sdk_1_819054888_200.dbf

-rw-r----- 1 oracle oinstall 398336 Sep 3 14:59 sdk_1_819054888_198.dbf

-rw-r----- 1 oracle oinstall 636928 Sep 3 15:01 sdk_1_819054888_201.dbf

但是实际上已经恢复了可以同步起来

1.4.11 需要恢复控制文件

SQL> alter database open read only;

alter database open read only

第 1 行出现错误:

ORA-16004: 备份数据库需要恢复

ORA-01152: 文件 1 没有从过旧的备份中还原

ORA-01110: 数据文件 1: '/oracle/oradata/sdk/system01.dbf'

Tue Sep 3 14:44:24 2013

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[6]: Assigned to RFS process 5287

RFS[6]: Identified database type as 'physical standby'

RFS[6]: Successfully opened standby log 4: '/oracle/oradata/sdk/redo1_standby_01'

Tue Sep 3 14:47:28 2013

ALTER DATABASE recover managed standby DATABASE cancel

Tue Sep 3 14:47:47 2013

MRP0: Background Media Recovery cancelled with status 16037

Tue Sep 3 14:47:47 2013

Errors in file /oracle/admin/sdk/bdump/sdk_mrp0_5277.trc:

ORA-16037: user requested cancel of managed recovery operation

Managed Standby Recovery not using Real Time Apply

Recovery interrupted!

Tue Sep 3 14:47:48 2013

Errors in file /oracle/admin/sdk/bdump/sdk_mrp0_5277.trc:

ORA-16037: user requested cancel of managed recovery operation

Tue Sep 3 14:47:48 2013

MRP0: Background Media Recovery process shutdown (sdk)

Tue Sep 3 14:47:49 2013

Managed Standby Recovery Canceled (sdk)

Tue Sep 3 14:47:49 2013

Completed: ALTER DATABASE recover managed standby DATABASE cancel

Tue Sep 3 14:48:25 2013

alter database open read only

Tue Sep 3 14:48:25 2013

Signalling error 1152 for datafile 1!

ORA-16004 signalled during: alter database open read only...

从主库创建控制文件：

SQL> ALTER DATABASE CREATE standby controlfile AS '/oracle/standby_lostarchive.ctl';

数据库已更改。

SQL> !

oracle@linux-7gnw:~> scp /oracle/standby_lostarchive.ctl oracle@192.168.142.163:/oracle

Password:

standby_lostarchive.ctl 100% 7184KB 7.0MB/s 00:00

1.4.12 备库恢复控制文件

SQL> shutdown immediate

ORA-01109: 数据库未打开

已经卸载数据库。

ORACLE 例程已经关闭。

SQL> startup nomount

ORACLE 例程已经启动。

Total System Global Area 419430400 bytes

Fixed Size 2084456 bytes

Variable Size 184549784 bytes

Database Buffers 226492416 bytes

Redo Buffers 6303744 bytes

SQL> !

oracle@linux-5pzu:~> rman target /

恢复管理器: Release 10.2.0.4.0 - Production on 星期二 9月 3 14:53:37 2013

连接到目标数据库: sdk (未装载)

RMAN> restore controlfile from '/oracle/standby_lostarchive.ctl';

启动 restore 于 03-9月 -13

使用目标数据库控制文件替代恢复目录

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=155 devtype=DISK

通道 ORA_DISK_1: 已复制控制文件副本

输出文件名=/oracle/oradata/sdk/control01.ctl

输出文件名=/oracle/oradata/sdk/control02.ctl

输出文件名=/oracle/oradata/sdk/control03.ctl

完成 restore 于 03-9月 -13

RMAN> exit

恢复管理器完成。

1.4.13 启动备库同步

SQL> alter database mount standby database;

数据库已更改。

SQL> alter database recover managed standby database parallel 4 using current logfile disconnect from session;

数据库已更改。

SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

------------------ ------------------------ ---------- ---------- ----------

ARCH CONNECTED 0 0 0 0

MRP0 WAIT_FOR_LOG 1 198 0 0

RFS IDLE 0 0 0 0

已选择10行。

alter database recover managed standby database parallel 4 using current logfile disconnect from session

Tue Sep 3 14:56:13 2013

Attempt to start background Managed Standby Recovery process (sdk)

MRP0 started with pid=24, OS id=5400

Tue Sep 3 14:56:13 2013

MRP0: Background Managed Standby Recovery process started (sdk)

Managed Standby Recovery starting Real Time Apply

parallel recovery started with 4 processes

Tue Sep 3 14:56:21 2013

Waiting for all non-current ORLs to be archived...

Media Recovery Waiting for thread 1 sequence 198

Tue Sep 3 14:56:21 2013

Completed: alter database recover managed standby database parallel 4 using current logfile disconnect from session

Tue Sep 3 14:57:25 2013

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[1]: Assigned to RFS process 5410

RFS[1]: Identified database type as 'physical standby'

Tue Sep 3 14:57:25 2013

RFS LogMiner: Client disabled from further notification

1.5 确认主库同步

1.5.1 主库

SQL> alter system switch logfile;

系统已更改。

SQL> alter system switch logfile;

系统已更改。

SQL> insert into t values(222);

已创建 1 行。

SQL> commit;

提交完成。

SQL> alter system switch logfile;

系统已更改。

SQL> archive log list;

数据库日志模式存档模式

自动存档启用

存档终点 /archive

最早的联机日志序列 200

下一个存档日志序列 202

当前日志序列 202

Tue Sep 3 15:01:08 2013

Thread 1 cannot allocate new log, sequence 202

Checkpoint not complete

Current log# 1 seq# 201 mem# 0: /oracle/oradata/sdk/redo01.log

Current log# 1 seq# 201 mem# 1: /oracle/oradata/sdk/redo04.log

Current log# 1 seq# 201 mem# 2: /oracle/oradata/sdk/redo07.log

Tue Sep 3 15:01:09 2013

Thread 1 advanced to log sequence 202 (LGWR switch)

Current log# 2 seq# 202 mem# 0: /oracle/oradata/sdk/redo02.log

Current log# 2 seq# 202 mem# 1: /oracle/oradata/sdk/redo05.log

Current log# 2 seq# 202 mem# 2: /oracle/oradata/sdk/redo08.log

Tue Sep 3 15:01:09 2013

ARC2: Standby redo logfile selected for thread 1 sequence 201 for destination LOG_ARCHIVE_DEST_2

1.5.2 备库

Tue Sep 3 14:59:44 2013

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[2]: Assigned to RFS process 5412

RFS[2]: Identified database type as 'physical standby'

RFS[2]: Successfully opened standby log 4: '/oracle/oradata/sdk/redo1_standby_01'

Tue Sep 3 14:59:46 2013

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[3]: Assigned to RFS process 5414

RFS[3]: Identified database type as 'physical standby'

RFS[3]: Successfully opened standby log 4: '/oracle/oradata/sdk/redo1_standby_01'

Tue Sep 3 14:59:46 2013

Fetching gap sequence in thread 1, gap sequence 198-198

Tue Sep 3 14:59:46 2013

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[4]: Assigned to RFS process 5416

RFS[4]: Identified database type as 'physical standby'

RFS[4]: Archived Log: '/archive/sdk_1_819054888_198.dbf'

Tue Sep 3 15:00:16 2013

Media Recovery Log /archive/sdk_1_819054888_198.dbf

Media Recovery Log /archive/sdk_1_819054888_199.dbf

Media Recovery Log /archive/sdk_1_819054888_200.dbf

Media Recovery Waiting for thread 1 sequence 201

Tue Sep 3 15:01:10 2013

RFS[1]: Successfully opened standby log 4: '/oracle/oradata/sdk/redo1_standby_01'

Tue Sep 3 15:01:12 2013

Media Recovery Log /archive/sdk_1_819054888_201.dbf

Media Recovery Waiting for thread 1 sequence 202

SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS

------------------ ------------------------ ---------- ---------- ----------

ARCH CONNECTED 0 0 0 0

ARCH CLOSING 1 199 1 209

ARCH CLOSING 1 200 1 1

ARCH CLOSING 1 201 1 1243

ARCH CONNECTED 0 0 0 0

MRP0 WAIT_FOR_LOG 1 202 0 0

RFS IDLE 0 0 0 0

已选择13行。

1.5.3 查看同步的数据

SQL> ALTER DATABASE recover managed standby DATABASE cancel;

数据库已更改。

SQL> alter database open read only;

数据库已更改。

SQL> select * from t;

----------

111

222

删除的1 2 3 数据同步删除了新增的222数据也新增了。

1.6 主库执行全备

最后记得将主数据库进行一次全备

转载于:https://www.cnblogs.com/aspartic/p/4166440.html

你可能感兴趣的文章

Android开发中整合测试注意事项

查看>>

DevExpress ASP.NET v18.2新功能详解（三）

JavaScript数值类型保留显示小数方法

查看>>

python--以1-31的数字作为结尾的列表？论英文好的重要性!

python学习笔记—— 多进程中的孤儿进程和僵尸进程

查看>>

webapi ，前台json传入raw读取

浏览器请求页面时Etag和cache的区别

查看>>

Java 基础知识面试题

查看>>

【Visual Installer】如何注册自已的文件类型

查看>>

关于跳出循环

查看>>

文件拓展名/HTML转义字符/RGB颜色参考/网页字体参考