OracleDG主库丢失归档增量同步
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(*)
----------
4
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 CONNECTED 0 0 0 0
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
RFS IDLE 0 0 0 0
RFS IDLE 0 0 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;
ID
----------
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
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
MRP0 WAIT_FOR_GAP 1 195 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 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
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
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
MRP0 WAIT_FOR_GAP 1 195 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 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
Copyright (c) 1982, 2007, Oracle. All rights reserved.
已连接到目标数据库: 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
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
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 CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CLOSING 1 198 1 777
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
MRP0 WAIT_FOR_GAP 1 195 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 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
Copyright (c) 1982, 2007, Oracle. All rights reserved.
连接到目标数据库: 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
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
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 CONNECTED 0 0 0 0
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
ARCH CONNECTED 0 0 0 0
MRP0 WAIT_FOR_LOG 1 202 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 0 0
RFS IDLE 0 0 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;
ID
----------
111
222
删除的1 2 3 数据同步删除了 新增的222数据也新增了。
1.6 主库执行全备
最后记得将主数据库进行一次全备
转载于:https://www.cnblogs.com/aspartic/p/4166440.html
OracleDG主库丢失归档增量同步相关推荐
- 【DB笔试面试759】在Oracle中，如果主库丢失归档文件，那么物理DG如何恢复？
♣ 题目部分 在Oracle中,如果主库丢失归档文件,那么物理DG如何恢复? ♣ 答案部分 面试DBA岗位,面试官对于DG环境常常会问到,若是主库丢失了归档文件,而这些归档文件还未来得及传递到备库,则 ...
- Redis持久化机制 -全量同步与增量同步的区别
全量同步与增量同步的区别 全量同步:就是每天定时(避开高峰期)或者采用一个周期实现将数据拷贝到一个地方也就是Rdb存储. 增量同步:比如采用对行为的操作实现对数据的同步,也就是AOF. 全量与增量的比 ...
- 增量同步_使用Kettle工具进行增量数据同步
增量同步的方式有很多种,我使用的是: 快照表 + 触发器 需求: 当主库库表发生增删改时,从库库表与主库库表数据保持一致. 环境: 1.Mysql 2.kettle 7.1 思路: 1.在主库中,将需 ...
- 通过Logstash实现mysql数据定时增量同步到ES
文章目录 前言 一.系统配置 二.同步步骤整体概览 三.logstash数据同步实战 1.新建mysql表 2.ES中新建索引 3.Logstash 管道配置 4.启动Logstash 5.测试 6. ...
- DataX以及增量同步
目录 第一部分:DataX 一.DataX基本知识 二.DataX应用 三.DataX安装测试 四.DataX性能调优 五.DataX源码编译问题整理 六.datax增量同步 第二部分:增量同步 一. ...
- SpringBoot + xxl-job 多数据源异构数据增量同步
SpringBoot + xxl-job 多数据源异构数据增量同步 文章目录 SpringBoot + xxl-job 多数据源异构数据增量同步 一.概述 二.实现步骤 2.1 项目搭建 2.2 接口 ...
- 结合inotify与rsync实现openstack镜像的实时增量同步
目标 在各种高可用环境下,都会涉及到数据的共享和同步,要么通过集群本身同步数据,如MariaDB Galera Cluster,要么就构建共享存储,如分布式CEPH存储,或者NFS/NAS存储.当以上 ...
- mysql 归档日志恢复_Oracle丢失归档日志文件的数据库恢复方法
使用案例描述:ORDTAB表空间的一个数据文件ordtab03.dbf毁坏,其包含很多ORDERS表的分区,数据文件热备于July 4, 2004,July 4 丢失归档日志文件的数据库恢复方法,从一 ...
- mysql增量同步kafka_MySQL数据实时增量同步到Kafka - Flume
写在前面的话 需求,将MySQL里的数据实时增量同步到Kafka.接到活儿的时候,第一个想法就是通过读取MySQL的binlog日志,将数据写到Kafka.不过对比了一些工具,例如:Canel,Dat ...
- Kafka实现MySQL增量同步
目标 本文是对[1]的复现和整理 环境 组件 版本 Zookeeper 3.6.0 Kafka 2.5.0 Mysql 8.0.21-0ubuntu0.20.04.4 准备工作 分别新建两个数据库A和 ...
最新文章
- MySQL数据库中创建表并给某个字段添加数据
- android UI进阶之实现listview中checkbox的多选与记录
- php 时间函数详解,PHP时间函数date()详解
- 判断电离层是否存在自由电子
- adb查看某个文件是否存在_动能定理是否存在某个方向的分量方程式？
- 机器学习实战-SVM算法-27
- cfg桩设备型号_试桩、试验桩、工程桩是一回事吗？
- java.lang.ClassNotFoundException: com.sap.exception.GlobalDefaultExceptionHandler
- VS_VERSION_INFO信息的读取
- 高可用性HA及Cluster集群
- GoldenGate 之 Bounded Recovery说明
- 通过Git进行分支管理
- 二进制补码以及为什么要使用补码
- YII composer全局安装
- 三个一工程_C语言阶段第二阶段部分程序整理
- 炫酷 雨滴桌面设置工具
- 在全志平台调试博通的wifi驱动（类似ap6212）【转】
- 从零学Java（10）之方法详解，喷打野你真的没我6！
- S7-1200 PLC的常见扩展模块
- html+css实现自定义图片上传按钮