码迷,mamicode.com
首页 > 其他好文 > 详细

使用Rman Duplicate执行DataGuard主备重新同步

时间:2014-05-28 00:35:57      阅读:395      评论:0      收藏:0      [点我收藏+]

标签:des   c   class   blog   code   tar   

DataGuard物理主备,当遭遇各种故障导致备库的数据没有与主库同步时,就需要尽快将主备的数据同步起来。

一般的方法是主库全备份,备库nomount还原控制文件,mount还原主库全备数据。

这里Oracle有一个Rman Duplicate功能,可以用于主库与备库数据的快速同步

具体理论就不多说,网上可查,下面实战一遍,看操作步骤和对应的日志,也就自然理解了

1、在主库执行备份,备份脚本如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[oracle@sdk31 backup]$ cat rman_backup.sh
/oracle/product/10.2.0/db_1/bin/rman << EOF
connect target /
run {
allocate channel c1 type disk;
allocate channel c2 type disk;
backup current controlfile for standby format=‘/backup/control_%u‘;
backup format ‘/backup/orcl_%u_%t‘ skip inaccessible filesperset 5 database ;
sql ‘alter system archive log current‘;
backup format ‘/backup/arch_%u_%t‘ skip inaccessible filesperset 5 archivelog all delete input;
release channel c2;
release channel c1;
}
exit;
EOF

2、执行备份:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
[oracle@sdk31 backup]$ sh rman_backup.sh
 
恢复管理器: Release 10.2.0.4.0 - Production on 星期一 5月 26 20:46:54 2014
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
RMAN>
连接到目标数据库: DBCC (DBID=2552941500)
 
RMAN> 2> 3> 4> 5> 6> 7> 8> 9> 10>
使用目标数据库控制文件替代恢复目录
分配的通道: c1
通道 c1: sid=133 devtype=DISK
 
分配的通道: c2
通道 c2: sid=120 devtype=DISK
 
启动 backup 于 26-5月 -14
通道 c1: 启动全部数据文件备份集
通道 c1: 正在指定备份集中的数据文件
备份集中包括备用控制文件
通道 c1: 正在启动段 1 于 26-5月 -14
通道 c1: 已完成段 1 于 26-5月 -14
段句柄=/backup/control_0op99fu1 标记=TAG20140526T204657 注释=NONE
通道 c1: 备份集已完成, 经过时间:00:00:02
完成 backup 于 26-5月 -14
 
启动 backup 于 26-5月 -14
通道 c1: 启动全部数据文件备份集
通道 c1: 正在指定备份集中的数据文件
输入数据文件 fno=00002 name=/oracle/oradata/dbcc/undotbs01.dbf
输入数据文件 fno=00004 name=/oracle/oradata/dbcc/users01.dbf
输入数据文件 fno=00007 name=/oracle/oradata/dbcc/dgcrm03.dbf
输入数据文件 fno=00008 name=/oracle/oradata/dbcc/dgcrm04.dbf
通道 c1: 正在启动段 1 于 26-5月 -14
通道 c2: 启动全部数据文件备份集
通道 c2: 正在指定备份集中的数据文件
输入数据文件 fno=00014 name=/oracle/oradata/dbcc/soeindex.dbf
输入数据文件 fno=00013 name=/oracle/oradata/dbcc/soe.dbf
输入数据文件 fno=00010 name=/oracle/oradata/dbcc/dgcrm06.dbf
输入数据文件 fno=00005 name=/oracle/oradata/dbcc/dgcrm01.dbf
输入数据文件 fno=00006 name=/oracle/oradata/dbcc/dgcrm02.dbf
通道 c2: 正在启动段 1 于 26-5月 -14
通道 c1: 已完成段 1 于 26-5月 -14
段句柄=/backup/orcl_0pp99fu3_848609219 标记=TAG20140526T204659 注释=NONE
通道 c1: 备份集已完成, 经过时间:00:00:45
通道 c1: 启动全部数据文件备份集
通道 c1: 正在指定备份集中的数据文件
输入数据文件 fno=00001 name=/oracle/oradata/dbcc/system01.dbf
输入数据文件 fno=00003 name=/oracle/oradata/dbcc/sysaux01.dbf
输入数据文件 fno=00009 name=/oracle/oradata/dbcc/dgcrm05.dbf
输入数据文件 fno=00011 name=/oracle/oradata/dbcc/dgcrm07.dbf
输入数据文件 fno=00012 name=/oracle/oradata/dbcc/dgcrm08.dbf
通道 c1: 正在启动段 1 于 26-5月 -14
通道 c2: 已完成段 1 于 26-5月 -14
段句柄=/backup/orcl_0qp99fu3_848609219 标记=TAG20140526T204659 注释=NONE
通道 c2: 备份集已完成, 经过时间:00:03:11
通道 c2: 启动全部数据文件备份集
通道 c2: 正在指定备份集中的数据文件
备份集中包括当前控制文件
通道 c2: 正在启动段 1 于 26-5月 -14
通道 c2: 已完成段 1 于 26-5月 -14
段句柄=/backup/orcl_0sp99g42_848609410 标记=TAG20140526T204659 注释=NONE
通道 c2: 备份集已完成, 经过时间:00:00:02
通道 c2: 启动全部数据文件备份集
通道 c2: 正在指定备份集中的数据文件
在备份集中包含当前的 SPFILE
通道 c2: 正在启动段 1 于 26-5月 -14
通道 c2: 已完成段 1 于 26-5月 -14
段句柄=/backup/orcl_0tp99g44_848609412 标记=TAG20140526T204659 注释=NONE
通道 c2: 备份集已完成, 经过时间:00:00:04
通道 c1: 已完成段 1 于 26-5月 -14
段句柄=/backup/orcl_0rp99fvh_848609265 标记=TAG20140526T204659 注释=NONE
通道 c1: 备份集已完成, 经过时间:00:02:46
完成 backup 于 26-5月 -14
 
sql 语句: alter system archive log current
 
启动 backup 于 26-5月 -14
当前日志已存档
通道 c1: 正在启动存档日志备份集
通道 c1: 正在指定备份集中的存档日志
输入存档日志线程 =1 序列 =1134 记录 ID=2059 时间戳=848609433
通道 c1: 正在启动段 1 于 26-5月 -14
通道 c2: 正在启动存档日志备份集
通道 c2: 正在指定备份集中的存档日志
输入存档日志线程 =1 序列 =1135 记录 ID=2060 时间戳=848609433
通道 c2: 正在启动段 1 于 26-5月 -14
通道 c1: 已完成段 1 于 26-5月 -14
段句柄=/backup/arch_0up99g4r_848609435 标记=TAG20140526T205033 注释=NONE
通道 c1: 备份集已完成, 经过时间:00:00:02
RMAN-08137: 警告: 因为仍需要归档日志, 所以未删除
存档日志文件名 =/archive/1_1134_847917566.dbf 线程 =1 序列 =1134
通道 c2: 已完成段 1 于 26-5月 -14
段句柄=/backup/arch_0vp99g4r_848609435 标记=TAG20140526T205033 注释=NONE
通道 c2: 备份集已完成, 经过时间:00:00:02
RMAN-08137: 警告: 因为仍需要归档日志, 所以未删除
存档日志文件名 =/archive/1_1135_847917566.dbf 线程 =1 序列 =1135
完成 backup 于 26-5月 -14
 
释放的通道: c2
 
释放的通道: c1
 
RMAN>
 
恢复管理器完成。

3、以上备份操作,主库对应的日志信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Mon May 26 20:46:57 2014
Clearing standby activation ID 2552989628 (0x982b87bc)
The primary database controlfile was created using the
‘MAXLOGFILES 16‘ clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE ‘srl1.f‘ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl2.f‘ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl3.f‘ SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE ‘srl4.f‘ SIZE 52428800;
Mon May 26 20:50:32 2014
ALTER SYSTEM ARCHIVE LOG
Mon May 26 20:50:33 2014
Thread 1 advanced to log sequence 1135 (LGWR switch)
  Current log# 1 seq# 1135 mem# 0: /oracle/oradata/dbcc/redo01.log
Mon May 26 20:50:33 2014
ALTER SYSTEM ARCHIVE LOG
Mon May 26 20:50:33 2014
Thread 1 advanced to log sequence 1136 (LGWR switch)
  Current log# 2 seq# 1136 mem# 0: /oracle/oradata/dbcc/redo02.log

4、将主库的备份文件传输到备库的/backup目录

这里我是通过NFS挂载的主库的/backup目录,省去了传输的过程

1
192.168.0.31:/backup  /backup

5、备库启动到nomount状态

1
2
3
4
5
6
7
8
9
10
11
12
SQL> shutdown immediate;
ORA-01109: 数据库未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup nomount;
ORACLE 例程已经启动。
 
Total System Global Area  285212672 bytes
Fixed Size                  1267068 bytes
Variable Size              92277380 bytes
Database Buffers          188743680 bytes
Redo Buffers                2924544 bytes

6、备库执行

1
rman target sys/asp@dbcc_primary auxiliary /
1
duplicate target database for standby nofilenamecheck dorecover;<br>注意看下面的操作信息,他帮我们做了很多事情,例如还原standby控制文件,还原数据文件等;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
[oracle@sdk32 ~]$ rman target sys/asp@dbcc_primary auxiliary /
 
恢复管理器: Release 10.2.0.4.0 - Production on 星期一 5月 26 20:54:17 2014
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
连接到目标数据库: DBCC (DBID=2552941500)
已连接到辅助数据库: DBCC (未装载)
 
RMAN> duplicate target database for standby nofilenamecheck dorecover;
 
启动 Duplicate Db 于 26-5月 -14
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_AUX_DISK_1
通道 ORA_AUX_DISK_1: sid=156 devtype=DISK
 
内存脚本的内容:
{
   set until scn  26736753;
   restore clone standby controlfile;
   sql clone ‘alter database mount standby database‘;
}
正在执行内存脚本
 
正在执行命令: SET until clause
 
启动 restore 于 26-5月 -14
使用通道 ORA_AUX_DISK_1
 
通道 ORA_AUX_DISK_1: 正在开始恢复数据文件备份集
通道 ORA_AUX_DISK_1: 正在还原控制文件
通道 ORA_AUX_DISK_1: 正在读取备份片段 /backup/control_0op99fu1
通道 ORA_AUX_DISK_1: 已还原备份片段 1
段句柄 = /backup/control_0op99fu1 标记 = TAG20140526T204657
通道 ORA_AUX_DISK_1: 还原完成, 用时: 00:00:02
输出文件名=/oracle/oradata/dbcc/control01.ctl
输出文件名=/oracle/oradata/dbcc/control02.ctl
输出文件名=/oracle/oradata/dbcc/control03.ctl
完成 restore 于 26-5月 -14
 
sql 语句: alter database mount standby database
释放的通道: ORA_AUX_DISK_1
 
内存脚本的内容:
{
   set until scn  26736753;
   set newname for tempfile  1 to
 "/oracle/oradata/dbcc/temp01.dbf";
   switch clone tempfile all;
   set newname for datafile  1 to
 "/oracle/oradata/dbcc/system01.dbf";
   set newname for datafile  2 to
 "/oracle/oradata/dbcc/undotbs01.dbf";
   set newname for datafile  3 to
 "/oracle/oradata/dbcc/sysaux01.dbf";
   set newname for datafile  4 to
 "/oracle/oradata/dbcc/users01.dbf";
   set newname for datafile  5 to
 "/oracle/oradata/dbcc/dgcrm01.dbf";
   set newname for datafile  6 to
 "/oracle/oradata/dbcc/dgcrm02.dbf";
   set newname for datafile  7 to
 "/oracle/oradata/dbcc/dgcrm03.dbf";
   set newname for datafile  8 to
 "/oracle/oradata/dbcc/dgcrm04.dbf";
   set newname for datafile  9 to
 "/oracle/oradata/dbcc/dgcrm05.dbf";
   set newname for datafile  10 to
 "/oracle/oradata/dbcc/dgcrm06.dbf";
   set newname for datafile  11 to
 "/oracle/oradata/dbcc/dgcrm07.dbf";
   set newname for datafile  12 to
 "/oracle/oradata/dbcc/dgcrm08.dbf";
   set newname for datafile  13 to
 "/oracle/oradata/dbcc/soe.dbf";
   set newname for datafile  14 to
 "/oracle/oradata/dbcc/soeindex.dbf";
   restore
   check readonly
   clone database
   ;
}
正在执行内存脚本
正在执行命令: SET until clause
正在执行命令: SET NEWNAME
临时文件 1 在控制文件中已重命名为 /oracle/oradata/dbcc/temp01.dbf
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
正在执行命令: SET NEWNAME
 
启动 restore 于 26-5月 -14
分配的通道: ORA_AUX_DISK_1
通道 ORA_AUX_DISK_1: sid=156 devtype=DISK
 
通道 ORA_AUX_DISK_1: 正在开始恢复数据文件备份集
通道 ORA_AUX_DISK_1: 正在指定从备份集还原的数据文件
正将数据文件00002还原到/oracle/oradata/dbcc/undotbs01.dbf
正将数据文件00004还原到/oracle/oradata/dbcc/users01.dbf
正将数据文件00007还原到/oracle/oradata/dbcc/dgcrm03.dbf
正将数据文件00008还原到/oracle/oradata/dbcc/dgcrm04.dbf
通道 ORA_AUX_DISK_1: 正在读取备份片段 /backup/orcl_0pp99fu3_848609219
通道 ORA_AUX_DISK_1: 已还原备份片段 1
段句柄 = /backup/orcl_0pp99fu3_848609219 标记 = TAG20140526T204659
通道 ORA_AUX_DISK_1: 还原完成, 用时: 00:00:45
通道 ORA_AUX_DISK_1: 正在开始恢复数据文件备份集
通道 ORA_AUX_DISK_1: 正在指定从备份集还原的数据文件
正将数据文件00005还原到/oracle/oradata/dbcc/dgcrm01.dbf
正将数据文件00006还原到/oracle/oradata/dbcc/dgcrm02.dbf
正将数据文件00010还原到/oracle/oradata/dbcc/dgcrm06.dbf
正将数据文件00013还原到/oracle/oradata/dbcc/soe.dbf
正将数据文件00014还原到/oracle/oradata/dbcc/soeindex.dbf
通道 ORA_AUX_DISK_1: 正在读取备份片段 /backup/orcl_0qp99fu3_848609219
通道 ORA_AUX_DISK_1: 已还原备份片段 1
段句柄 = /backup/orcl_0qp99fu3_848609219 标记 = TAG20140526T204659
通道 ORA_AUX_DISK_1: 还原完成, 用时: 00:01:06
通道 ORA_AUX_DISK_1: 正在开始恢复数据文件备份集
通道 ORA_AUX_DISK_1: 正在指定从备份集还原的数据文件
正将数据文件00001还原到/oracle/oradata/dbcc/system01.dbf
正将数据文件00003还原到/oracle/oradata/dbcc/sysaux01.dbf
正将数据文件00009还原到/oracle/oradata/dbcc/dgcrm05.dbf
正将数据文件00011还原到/oracle/oradata/dbcc/dgcrm07.dbf
正将数据文件00012还原到/oracle/oradata/dbcc/dgcrm08.dbf
通道 ORA_AUX_DISK_1: 正在读取备份片段 /backup/orcl_0rp99fvh_848609265
通道 ORA_AUX_DISK_1: 已还原备份片段 1
段句柄 = /backup/orcl_0rp99fvh_848609265 标记 = TAG20140526T204659
通道 ORA_AUX_DISK_1: 还原完成, 用时: 00:00:55
完成 restore 于 26-5月 -14
 
内存脚本的内容:
{
   switch clone datafile all;
}
正在执行内存脚本
 
数据文件 1 已转换成数据文件副本
输入数据文件副本 recid=16 stamp=848609852 文件名=/oracle/oradata/dbcc/system01.dbf
数据文件 2 已转换成数据文件副本
输入数据文件副本 recid=17 stamp=848609852 文件名=/oracle/oradata/dbcc/undotbs01.dbf
数据文件 3 已转换成数据文件副本
输入数据文件副本 recid=18 stamp=848609852 文件名=/oracle/oradata/dbcc/sysaux01.dbf
数据文件 4 已转换成数据文件副本
输入数据文件副本 recid=19 stamp=848609852 文件名=/oracle/oradata/dbcc/users01.dbf
数据文件 5 已转换成数据文件副本
输入数据文件副本 recid=20 stamp=848609852 文件名=/oracle/oradata/dbcc/dgcrm01.dbf
数据文件 6 已转换成数据文件副本
输入数据文件副本 recid=21 stamp=848609852 文件名=/oracle/oradata/dbcc/dgcrm02.dbf
数据文件 7 已转换成数据文件副本
输入数据文件副本 recid=22 stamp=848609852 文件名=/oracle/oradata/dbcc/dgcrm03.dbf
数据文件 8 已转换成数据文件副本
输入数据文件副本 recid=23 stamp=848609852 文件名=/oracle/oradata/dbcc/dgcrm04.dbf
数据文件 9 已转换成数据文件副本
输入数据文件副本 recid=24 stamp=848609852 文件名=/oracle/oradata/dbcc/dgcrm05.dbf
数据文件 10 已转换成数据文件副本
输入数据文件副本 recid=25 stamp=848609852 文件名=/oracle/oradata/dbcc/dgcrm06.dbf
数据文件 11 已转换成数据文件副本
输入数据文件副本 recid=26 stamp=848609852 文件名=/oracle/oradata/dbcc/dgcrm07.dbf
数据文件 12 已转换成数据文件副本
输入数据文件副本 recid=27 stamp=848609852 文件名=/oracle/oradata/dbcc/dgcrm08.dbf
数据文件 13 已转换成数据文件副本
输入数据文件副本 recid=28 stamp=848609852 文件名=/oracle/oradata/dbcc/soe.dbf
数据文件 14 已转换成数据文件副本
输入数据文件副本 recid=29 stamp=848609852 文件名=/oracle/oradata/dbcc/soeindex.dbf
 
内存脚本的内容:
{
   set until scn  26736753;
   recover
   standby
   clone database
    delete archivelog
   ;
}
正在执行内存脚本
 
正在执行命令: SET until clause
启动 recover 于 26-5月 -14
使用通道 ORA_AUX_DISK_1
 
正在开始介质的恢复
 
存档日志线程 1 序列 1134 已作为文件 /archive/1_1134_847917566.dbf 存在于磁盘上
存档日志线程 1 序列 1135 已作为文件 /archive/1_1135_847917566.dbf 存在于磁盘上
存档日志文件名 =/archive/1_1134_847917566.dbf 线程 =1 序列 =1134
存档日志文件名 =/archive/1_1135_847917566.dbf 线程 =1 序列 =1135
介质恢复完成, 用时: 00:00:03
完成 recover 于 26-5月 -14
完成 Duplicate Db 于 26-5月 -14
RMAN> exit
 
恢复管理器完成。

7、以上操作备库对应的alert日志

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
alter database mount standby database
Mon May 26 20:54:41 2014
Setting recovery target incarnation to 2
ARCH: STARTING ARCH PROCESSES
ARC0 started with pid=18, OS id=5740
Mon May 26 20:54:42 2014
ARC0: Archival started
ARC1: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
Mon May 26 20:54:42 2014
ARC0: Becoming the ‘no FAL‘ ARCH
ARC0: Becoming the ‘no SRL‘ ARCH
ARC0: Thread not mounted
ARC1 started with pid=19, OS id=5742
ARC1: Becoming the heartbeat ARCH
ARC1: Thread not mounted
Mon May 26 20:54:42 2014
Successful mount of redo thread 1, with mount id 2553587789
Mon May 26 20:54:42 2014
Physical Standby Database mounted.
Completed: alter database mount standby database
Mon May 26 20:54:45 2014
Full restore complete of datafile 4 /oracle/oradata/dbcc/users01.dbf.  Elapsed time: 0:00:00
  checkpoint is 26736665
Mon May 26 20:55:26 2014
Full restore complete of datafile 2 /oracle/oradata/dbcc/undotbs01.dbf.  Elapsed time: 0:00:41
  checkpoint is 26736665
  last deallocation scn is 26667674
Full restore complete of datafile 7 /oracle/oradata/dbcc/dgcrm03.dbf.  Elapsed time: 0:00:42
  checkpoint is 26736665
Full restore complete of datafile 8 /oracle/oradata/dbcc/dgcrm04.dbf.  Elapsed time: 0:00:42
  checkpoint is 26736665
Mon May 26 20:56:07 2014
Full restore complete of datafile 5 /oracle/oradata/dbcc/dgcrm01.dbf.  Elapsed time: 0:00:35
  checkpoint is 26736666
Full restore complete of datafile 6 /oracle/oradata/dbcc/dgcrm02.dbf.  Elapsed time: 0:00:36
  checkpoint is 26736666
Full restore complete of datafile 10 /oracle/oradata/dbcc/dgcrm06.dbf.  Elapsed time: 0:00:40
  checkpoint is 26736666
Full restore complete of datafile 13 /oracle/oradata/dbcc/soe.dbf.  Elapsed time: 0:00:45
  checkpoint is 26736666
Mon May 26 20:56:30 2014
Full restore complete of datafile 14 /oracle/oradata/dbcc/soeindex.dbf.  Elapsed time: 0:00:57
  checkpoint is 26736666
  last deallocation scn is 15730407
Mon May 26 20:57:09 2014
Full restore complete of datafile 12 /oracle/oradata/dbcc/dgcrm08.dbf.  Elapsed time: 0:00:33
  checkpoint is 26736682
Full restore complete of datafile 11 /oracle/oradata/dbcc/dgcrm07.dbf.  Elapsed time: 0:00:37
  checkpoint is 26736682
Full restore complete of datafile 9 /oracle/oradata/dbcc/dgcrm05.dbf.  Elapsed time: 0:00:40
  checkpoint is 26736682
Mon May 26 20:57:22 2014
Full restore complete of datafile 3 /oracle/oradata/dbcc/sysaux01.dbf.  Elapsed time: 0:00:45
  checkpoint is 26736682
  last deallocation scn is 14903523
Full restore complete of datafile 1 /oracle/oradata/dbcc/system01.dbf.  Elapsed time: 0:00:47
  checkpoint is 26736682
  last deallocation scn is 15809539
Mon May 26 20:57:32 2014
Switch of datafile 1 complete to datafile copy
  checkpoint is 26736682
Switch of datafile 2 complete to datafile copy
  checkpoint is 26736665
Switch of datafile 3 complete to datafile copy
  checkpoint is 26736682
Switch of datafile 4 complete to datafile copy
  checkpoint is 26736665
Switch of datafile 5 complete to datafile copy
  checkpoint is 26736666
Switch of datafile 6 complete to datafile copy
  checkpoint is 26736666
Switch of datafile 7 complete to datafile copy
  checkpoint is 26736665
Switch of datafile 8 complete to datafile copy
  checkpoint is 26736665
Switch of datafile 9 complete to datafile copy
  checkpoint is 26736682
Switch of datafile 10 complete to datafile copy
  checkpoint is 26736666
Switch of datafile 11 complete to datafile copy
  checkpoint is 26736682
Switch of datafile 12 complete to datafile copy
  checkpoint is 26736682
Switch of datafile 13 complete to datafile copy
  checkpoint is 26736666
Switch of datafile 14 complete to datafile copy
  checkpoint is 26736666
Mon May 26 20:57:33 2014
alter database recover datafile list clear
Completed: alter database recover datafile list clear
Mon May 26 20:57:33 2014
alter database recover datafile list
 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14
Completed: alter database recover datafile list
 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 , 13 , 14
Mon May 26 20:57:33 2014
alter database recover if needed
 standby start until change 26736753
Media Recovery Start
Managed Standby Recovery not using Real Time Apply
ORA-279 signalled during: alter database recover if needed
 standby start until change 26736753
...
Mon May 26 20:57:34 2014
alter database recover logfile ‘/archive/1_1134_847917566.dbf‘
Mon May 26 20:57:34 2014
Media Recovery Log /archive/1_1134_847917566.dbf
ORA-279 signalled during: alter database recover logfile ‘/archive/1_1134_847917566.dbf‘...
Mon May 26 20:57:34 2014
alter database recover logfile ‘/archive/1_1135_847917566.dbf‘
Mon May 26 20:57:34 2014
Media Recovery Log /archive/1_1135_847917566.dbf
Mon May 26 20:57:34 2014
Incomplete Recovery applied until change 26736753
Mon May 26 20:57:34 2014
Media Recovery Complete (dbcc)
Completed: alter database recover logfile ‘/archive/1_1135_847917566.dbf‘
Mon May 26 20:58:06 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 5753
RFS[1]: Identified database type as ‘physical standby‘
Mon May 26 20:58:06 2014
RFS LogMiner: Client disabled from further notification

8、备库开始应用日志,和主库是同步的

1
2
3
4
5
6
7
8
9
10
11
12
SQL> alter database recover managed standby database disconnect from session;
 
数据库已更改。
 
SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby order by 1,4;
 
PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
MRP0      WAIT_FOR_LOG          1       1136          0          0
RFS       IDLE                  0          0          0          0

9、备库启动应用 对应的alert日志信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
Mon May 26 20:59:15 2014
alter database recover managed standby database disconnect from session
Mon May 26 20:59:15 2014
Attempt to start background Managed Standby Recovery process (dbcc)
MRP0 started with pid=17, OS id=5755
Mon May 26 20:59:15 2014
MRP0: Background Managed Standby Recovery process started (dbcc)
Managed Standby Recovery not using Real Time Apply
 parallel recovery started with 2 processes
Mon May 26 20:59:20 2014
Waiting for all non-current ORLs to be archived...
Mon May 26 20:59:20 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 1 of thread 1
Mon May 26 20:59:20 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 1 of thread 1
Clearing online redo logfile 1 /oracle/flash_recovery_area/DBCC_STANDBY/onlinelog/o1_mf_1_3213706932_.log
Clearing online log 1 of thread 1 sequence number 1132
Mon May 26 20:59:20 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 1 of thread 1
db_recovery_file_dest_size of 2048 MB is 2.44% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Clearing online redo logfile 1 complete
Mon May 26 20:59:21 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 2 of thread 1
Mon May 26 20:59:21 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 2 of thread 1
Clearing online redo logfile 2 /oracle/flash_recovery_area/DBCC_STANDBY/onlinelog/o1_mf_2_3213719840_.log
Clearing online log 2 of thread 1 sequence number 1136
Mon May 26 20:59:21 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 2 of thread 1
Mon May 26 20:59:21 2014
Completed: alter database recover managed standby database disconnect from session
Mon May 26 20:59:22 2014
Clearing online redo logfile 2 complete
Mon May 26 20:59:22 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 3 of thread 1
Mon May 26 20:59:22 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 3 of thread 1
Clearing online redo logfile 3 /oracle/flash_recovery_area/DBCC_STANDBY/onlinelog/o1_mf_3_3213719840_.log
Clearing online log 3 of thread 1 sequence number 1134
Mon May 26 20:59:22 2014
Errors in file /oracle/admin/dbcc/bdump/dbcc_mrp0_5755.trc:
ORA-00313: open failed for members of log group 3 of thread 1
Clearing online redo logfile 3 complete
Media Recovery Waiting for thread 1 sequence 1136

10、主库切换一下日志,确认主库与备库是否正常运作:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
主库
 
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       1135 INACTIVE         26-5月 -14     26736748
         2       1136 CURRENT          26-5月 -14     26736753
         3       1134 INACTIVE         26-5月 -14     26692835
 
SQL> alter system switch logfile;
 
系统已更改。
 
SQL> alter system switch logfile;
 
系统已更改。
 
Mon May 26 21:00:46 2014
Thread 1 advanced to log sequence 1137 (LGWR switch)
  Current log# 3 seq# 1137 mem# 0: /oracle/oradata/dbcc/redo03.log
Mon May 26 21:00:47 2014
Thread 1 advanced to log sequence 1138 (LGWR switch)
  Current log# 1 seq# 1138 mem# 0: /oracle/oradata/dbcc/redo01.log
   
备库
 
SQL> select process,status,thread#,sequence#,block#,blocks from V$managed_standby order by 1,4;
 
PROCESS   STATUS          THREAD#  SEQUENCE#     BLOCK#     BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH      CONNECTED             0          0          0          0
ARCH      CONNECTED             0          0          0          0
MRP0      WAIT_FOR_LOG          1       1138          0          0
RFS       IDLE                  0          0          0          0
 
RFS[1]: Archived Log: ‘/archive/1_1136_847917566.dbf‘
RFS[1]: Archived Log: ‘/archive/1_1137_847917566.dbf‘
Mon May 26 21:00:47 2014
Media Recovery Log /archive/1_1136_847917566.dbf
Media Recovery Log /archive/1_1137_847917566.dbf
Media Recovery Waiting for thread 1 sequence 1138

OK~相对来说比较快捷

使用Rman Duplicate执行DataGuard主备重新同步,布布扣,bubuko.com

使用Rman Duplicate执行DataGuard主备重新同步

标签:des   c   class   blog   code   tar   

原文地址:http://www.cnblogs.com/dbtodaysoftware/p/3753932.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!