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

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

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

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

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

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

?





1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

[[email protected] 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

[[email protected] 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/[email protected]_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

[[email protected] ~]$ rman target sys/[email protected]_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~相对来说比较快捷

时间: 2024-10-12 13:23:55

使用Rman Duplicate执行DataGuard主备重新同步的相关文章

DataGuard主备归档存在gap的处理办法

DataGuard主备之间可能由于网络等原因,造成备库和主库之间的归档日志不一致,这样就产生了gap. 解决gap的步骤: 1.在备库获得gap的详细信息 2.将需要的归档日志从主库拷贝到备库 3.备库将归档日志注册,然后应用.   --备库alert日志提示gap详情   Media Recovery Waiting for thread 1 sequence 7057 Fetching gap sequence in thread 1, gap sequence 7057-7080 FAL[

oracle dataguard主备库参数文件配置详解

主库参数详解: 保持同一个Data Guard中所有的DB_NAME相同 DB_NAME=ora11g 为一个数据库指定一个唯一的名称,该参数一经指定就不会发生改动除非DBA主动改动 DB_UNIQUE_NAME=ora11g_primary 初始化参数LOG_ARCHIVE_CONFIG用于控制发送归档日志到远程位置.接收远程归档日志,并指定Data  Guard配置的惟一数据库名,默认值为SEND,RECEIVE,NODG_CONFIG. 当设置该参数为SEND时,会激活发送归档日志到远程位

ORACLE DataGuard主备切换

主库磁盘问题,导致主库宕机,因为归档还没有应用,导致备库无法转为主库 先查看一下备库当前的信息: SQL> select * from v$version; BANNER ---------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production PL/SQL Release 11.

oracle 11g dataguard主备切换

1.检查主备的环境 dg1节点: SQL> archive log list; Database log mode            Archive Mode Automatic archival            Enabled Archive destination           /u01/oradata/tong/archive Oldest online log sequence      59 Next log sequence to archive     61 Cur

Oracle Dataguard HA (主备,灾备)方案部署调试

包括: centos6.5 oracle11gR2 DataGuard安装 dataGuard 主备switchover角色切换 数据同步测试 <一,>DG数据库数据同步测试1,正常启动主库$sqlplus / as sysdbasql>startup 2,启动备库$sqlplus / as sysdbasql>startup mountsql>alter database recover managed standby database disconnect from se

Oracle 11.2.0.4.0 Dataguard部署和日常维护(5)-Datauard 主备切换和故障转移篇

1. dataguard主备切换 1.1. 查看当前主备库是否具备切换条件 on slave select sequence#,first_time,next_time,archived,applied from v$archived_log where SEQUENCE#=(select max(SEQUENCE#) from v$archived_log); SEQUENCE# FIRST_TIME NEXT_TIME ARCHIVED APPLIED ---------- --------

关于rman duplicate 一些比较重要的知识点--系列三

FYI: http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta020.htm#RCMRF126 rman duplicate database 必须是相同的平台,但是支持32bit\64bit 间复制,在复制完成后需要运行¥ORACLE_HOME/rdbms/admin/utlirp.sql 脚本来转换pl/sql 代码 The DUPLICATE command requires one or more auxiliary

关于rman duplicate 一些比較重要的知识点--系列三

FYI: http://docs.oracle.com/cd/E11882_01/backup.112/e10643/rcmsynta020.htm#RCMRF126 rman duplicate database 必须是同样的平台,可是支持32bit\64bit 间复制,在复制完毕后须要执行¥ORACLE_HOME/rdbms/admin/utlirp.sql 脚本来转换pl/sql 代码 The DUPLICATE command requires one or more auxiliary

文件系统:drbd主备服务器文件同步

一. DRBD介绍 DRBD是一种块设备,可以被用于高可用(HA)之中.它类似于一个网络RAID-1功能.当你将数据写入本地 文件系统时,数据还将会被发送到网络中另一台主机上.以相同的形式记录在一个文件系统中. 本地(主节点)与远程主机(备节点)的数据可以保证实时同步.当本地系统出现故障时,远程主机上还会 保留有一份相同的数据,可以继续使用. 在高可用(HA)中使用DRBD功能,可以代替使用一个共享盘阵.因为数据同时存在于本地主机和远程主机上,切换时,远程主机只要使用它上面的那份备份数据,就可以