我是靠谱客的博主 冷静小熊猫,这篇文章主要介绍微软云 azure 数据迁移之oracle11g dataguard,现在分享给大家,希望可以做个参考。

背景,将本地的oracle数据迁移到微软云azure云上面的oracle服务器。

1,复制本地的rman备份集到微软云azure的oracle服务器上

复制代码
1
2
scp -r -P56922 2016-02-04 142.119.218.19:/oracle/

2,复制本地的控制文件到微软云azure上面的oracle服务器

查看备份文件:

复制代码
1
2
3
4
rlwrap rman target / list backup of spfile; list backup of controlfile;

两者的最后一个文件都是一样的:

复制代码
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
RMAN> list backup of controlfile; using target database control file instead of recovery catalog List of Backup Sets =================== ..... BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 5038 Full 18.36M DISK 00:00:02 04-FEB-16 BP Key: 5038 Status: AVAILABLE Compressed: NO Tag: TAG20160204T010104 Piece Name: /pddata2/oracle/backup/data/ctl_auto/c-3391761643-20160204-00 Control File Included: Ckp SCN: 11923211853 Ckp time: 04-FEB-16 BS Key Type LV Size Device Type Elapsed Time Completion Time ------- ---- -- ---------- ----------- ------------ --------------- 5042 Full 18.36M DISK 00:00:01 04-FEB-16 BP Key: 5042 Status: AVAILABLE Compressed: NO Tag: TAG20160204T032902 Piece Name: /pddata2/oracle/backup/data/ctl_auto/c-3391761643-20160204-01 Control File Included: Ckp SCN: 11923509959 Ckp time: 04-FEB-16 RMAN>

复制备份的控制文件:

复制代码
1
2
scp -r -P56922 /pddata2/oracle/backup/data/ctl_auto/c-3391761643-20160204-01 142.119.218.19:/oracle/

博客文章原地址:http://blog.csdn.net/mchdba/article/details/50636021,未经过本人mchdba(黄杉)同意,谢绝转载。

3,然后去微软云的oracle服务器上面进行恢复:

去参数文件查看微软云control的路径:

复制代码
1
2
3
4
5
[oracle@pldb1 powerdes]$ more /oracle/initpowerdes.ora |grep control_files *.control_files='/home/oradata/powerdes/control01.ctl','/oracle/app/oracle/flash_recovery_area/powerdes/control02.ctl' [oracle@pldb1 powerdes]$

看到有2个文件,所以rman需要恢复2个控制文件:

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
RMAN> restore controlfile to '/home/oradata/powerdes/control01.ctl' from '/oracle/c-3391761643-20160204-01'; Starting restore at 04-FEB-16 using channel ORA_DISK_1 channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 Finished restore at 04-FEB-16 RMAN> RMAN> restore controlfile to '/oracle/app/oracle/flash_recovery_area/powerdes/control02.ctl' from '/oracle/c-3391761643-20160204-01'; Starting restore at 04-FEB-16 using channel ORA_DISK_1 channel ORA_DISK_1: restoring control file channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 Finished restore at 04-FEB-16 RMAN>

4,将数据库状态改成mount:

复制代码
1
2
3
4
5
RMAN> alter database mount; database mounted released channel: ORA_DISK_1 RMAN>

5,注册备份文件:

复制代码
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
RMAN> catalog start with '/oracle/2016-02-04'; Starting implicit crosscheck backup at 04-FEB-16 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=19 device type=DISK Crosschecked 35 objects Finished implicit crosscheck backup at 04-FEB-16 Starting implicit crosscheck copy at 04-FEB-16 using channel ORA_DISK_1 Crosschecked 2 objects Finished implicit crosscheck copy at 04-FEB-16 searching for all files in the recovery area cataloging files... cataloging done List of Cataloged Files ======================= File Name: /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_01/o1_mf_1_69_cbzodbgr_.arc searching for all files that match the pattern /oracle/2016-02-04 List of Files Unknown to the Database ===================================== File Name: /oracle/2016-02-04/rman_backup_arch.log File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak File Name: /oracle/2016-02-04/full_POWERDES_20160204_5382.bak File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5381.bak File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5379.bkp File Name: /oracle/2016-02-04/rman_backup.log Do you really want to catalog the above files (enter YES or NO)? YES cataloging files... cataloging done List of Cataloged Files ======================= File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak File Name: /oracle/2016-02-04/full_POWERDES_20160204_5382.bak File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5381.bak File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5379.bkp List of Files Which Where Not Cataloged ======================================= File Name: /oracle/2016-02-04/rman_backup_arch.log RMAN-07517: Reason: The file header is corrupted File Name: /oracle/2016-02-04/rman_backup.log RMAN-07517: Reason: The file header is corrupted RMAN>

6,开始执行restore恢复操作,将数据从备份集写入到磁盘上的数据文件里面。

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
RMAN> restore database; Starting restore at 04-FEB-16 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /home/oradata/powerdes/system01.dbf channel ORA_DISK_1: restoring datafile 00002 to /home/oradata/powerdes/sysaux01.dbf channel ORA_DISK_1: restoring datafile 00003 to /home/oradata/powerdes/undotbs01.dbf channel ORA_DISK_1: restoring datafile 00004 to /home/oradata/powerdes/users01.dbf channel ORA_DISK_1: restoring datafile 00005 to /home/oradata/powerdes/powerdesk01.dbf channel ORA_DISK_1: restoring datafile 00006 to /home/oradata/powerdes/plas01.dbf channel ORA_DISK_1: restoring datafile 00007 to /home/oradata/powerdes/pl01.dbf channel ORA_DISK_1: restoring datafile 00008 to /home/oradata/powerdes/help01.dbf channel ORA_DISK_1: restoring datafile 00009 to /home/oradata/powerdes/adobelc01.dbf channel ORA_DISK_1: restoring datafile 00010 to /home/oradata/powerdes/sms01.dbf channel ORA_DISK_1: restoring datafile 00011 to /home/oradata/powerdes/plcrm01.dbf channel ORA_DISK_1: restoring datafile 00012 to /home/oradata/powerdes/powerdesk02.dbf channel ORA_DISK_1: restoring datafile 00013 to /home/oradata/powerdes/datagm01.dbf channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/full_POWERDES_20160204_5382.bak

这个过程时间有些漫长,没写入一个数据文件,后台alert日志都会记录的,如下所示:

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[oracle@pldb1 powerdes]$ tail -f /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/alert_powerdes.log last deallocation scn is 11565967595 Undo Optimization current scn is 11923236783 Thu Feb 04 12:45:38 2016 Full restore complete of datafile 6 /home/oradata/powerdes/plas01.dbf. Elapsed time: 0:24:26 checkpoint is 11923506763 last deallocation scn is 11902810828 Thu Feb 04 12:51:09 2016 Full restore complete of datafile 2 /home/oradata/powerdes/sysaux01.dbf. Elapsed time: 0:29:47 checkpoint is 11923506763 last deallocation scn is 11923006656 Thu Feb 04 12:54:51 2016 Full restore complete of datafile 12 /home/oradata/powerdes/powerdesk02.dbf. Elapsed time: 0:33:52 checkpoint is 11923506763 last deallocation scn is 11902950834

最后restore database结束:

复制代码
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
RMAN> restore database; Starting restore at 04-FEB-16 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /home/oradata/powerdes/system01.dbf channel ORA_DISK_1: restoring datafile 00002 to /home/oradata/powerdes/sysaux01.dbf channel ORA_DISK_1: restoring datafile 00003 to /home/oradata/powerdes/undotbs01.dbf channel ORA_DISK_1: restoring datafile 00004 to /home/oradata/powerdes/users01.dbf channel ORA_DISK_1: restoring datafile 00005 to /home/oradata/powerdes/powerdesk01.dbf channel ORA_DISK_1: restoring datafile 00006 to /home/oradata/powerdes/plas01.dbf channel ORA_DISK_1: restoring datafile 00007 to /home/oradata/powerdes/pl01.dbf channel ORA_DISK_1: restoring datafile 00008 to /home/oradata/powerdes/help01.dbf channel ORA_DISK_1: restoring datafile 00009 to /home/oradata/powerdes/adobelc01.dbf channel ORA_DISK_1: restoring datafile 00010 to /home/oradata/powerdes/sms01.dbf channel ORA_DISK_1: restoring datafile 00011 to /home/oradata/powerdes/plcrm01.dbf channel ORA_DISK_1: restoring datafile 00012 to /home/oradata/powerdes/powerdesk02.dbf channel ORA_DISK_1: restoring datafile 00013 to /home/oradata/powerdes/datagm01.dbf channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/full_POWERDES_20160204_5382.bak channel ORA_DISK_1: piece handle=/oracle/2016-02-04/full_POWERDES_20160204_5382.bak tag=TAG20160204T030013 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 01:17:07 Finished restore at 04-FEB-16 RMAN> RMAN>

7,开始recover操作

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
RMAN> recover database; Starting recover at 04-FEB-16 using channel ORA_DISK_1 starting media recovery channel ORA_DISK_1: starting archived log restore to default destination channel ORA_DISK_1: restoring archived log archived log thread=1 sequence=42421 channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak channel ORA_DISK_1: piece handle=/oracle/2016-02-04/arch_POWERDES_20160204_5383.bak tag=TAG20160204T032901 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_04/o1_mf_1_42421_cc6o97x5_.arc thread=1 sequence=42421 channel default: deleting archived log(s) archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_04/o1_mf_1_42421_cc6o97x5_.arc RECID=83680 STAMP=902929321 unable to find archived log archived log thread=1 sequence=42422 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 02/04/2016 13:42:07 RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42422 and starting SCN of 11923509947 RMAN>

看到RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42422 and starting SCN of 11923509947,需要将缺失的归档日志从原始备份库copy到微软云azure的oracle服务器上
查看备份库的归档目录:

复制代码
1
2
3
4
5
[oracle@localhost archivelog]$ find /oracle -name archivelog /oracle/app/oracle/flash_recovery_area/archivelog [oracle@localhost archivelog]$ cd /oracle/app/oracle/flash_recovery_area/archivelog [oracle@localhost archivelog]$

开始copy操作:

复制代码
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
[oracle@localhost archivelog]$ scp -P56922 *.dbf 142.119.218.19:/oracle/app/oracle/flash_recovery_area/archivelog/ oracle@142.119.218.19's password: scp: /oracle/app/oracle/flash_recovery_area/archivelog/: No such file or directory [oracle@localhost archivelog]$ scp -P56922 *.dbf 142.119.218.19:/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/ oracle@142.119.218.19's password: 1_42422_821708334.dbf 100% 3072 3.0KB/s 00:00 1_42423_821708334.dbf 100% 38MB 12.7MB/s 00:03 1_42424_821708334.dbf 100% 32MB 10.6MB/s 00:03 1_42425_821708334.dbf 100% 35MB 11.6MB/s 00:03 1_42426_821708334.dbf 100% 42MB 14.0MB/s 00:03 1_42427_821708334.dbf 100% 40MB 13.4MB/s 00:03 1_42428_821708334.dbf 100% 42MB 8.4MB/s 00:05 1_42429_821708334.dbf 100% 32MB 10.6MB/s 00:03 1_42430_821708334.dbf 100% 32MB 10.6MB/s 00:03 1_42431_821708334.dbf 100% 32MB 5.3MB/s 00:06 1_42432_821708334.dbf 100% 32MB 10.7MB/s 00:03 1_42433_821708334.dbf 100% 32MB 5.3MB/s 00:06 1_42434_821708334.dbf 100% 35MB 11.6MB/s 00:03 1_42435_821708334.dbf 100% 36MB 12.0MB/s 00:03 [oracle@localhost archivelog]$

然后在微软云azure的oracle库上,退出rman,重新登录rman执行recover database操作,如果不退出rman重新登录是识别不了新的copy过来的归档日志的:

复制代码
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
RMAN> exit Recovery Manager complete. [oracle@pldb1 ~]$ rlwrap rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Thu Feb 4 14:05:49 2016 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: POWERDES (DBID=3391761643, not open) RMAN> recover database; Starting recover at 04-FEB-16 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=1 device type=DISK starting media recovery archived log for thread 1 with sequence 42422 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42422_821708334.dbf archived log for thread 1 with sequence 42423 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42423_821708334.dbf archived log for thread 1 with sequence 42424 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42424_821708334.dbf archived log for thread 1 with sequence 42425 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42425_821708334.dbf archived log for thread 1 with sequence 42426 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42426_821708334.dbf archived log for thread 1 with sequence 42427 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42427_821708334.dbf archived log for thread 1 with sequence 42428 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42428_821708334.dbf archived log for thread 1 with sequence 42429 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42429_821708334.dbf archived log for thread 1 with sequence 42430 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42430_821708334.dbf archived log for thread 1 with sequence 42431 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42431_821708334.dbf archived log for thread 1 with sequence 42432 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42432_821708334.dbf archived log for thread 1 with sequence 42433 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42433_821708334.dbf archived log for thread 1 with sequence 42434 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42434_821708334.dbf archived log for thread 1 with sequence 42435 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42435_821708334.dbf archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42422_821708334.dbf thread=1 sequence=42422 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42423_821708334.dbf thread=1 sequence=42423 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42424_821708334.dbf thread=1 sequence=42424 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42425_821708334.dbf thread=1 sequence=42425 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42426_821708334.dbf thread=1 sequence=42426 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42427_821708334.dbf thread=1 sequence=42427 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42428_821708334.dbf thread=1 sequence=42428 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42429_821708334.dbf thread=1 sequence=42429 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42430_821708334.dbf thread=1 sequence=42430 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42431_821708334.dbf thread=1 sequence=42431 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42432_821708334.dbf thread=1 sequence=42432 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42433_821708334.dbf thread=1 sequence=42433 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42434_821708334.dbf thread=1 sequence=42434 archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42435_821708334.dbf thread=1 sequence=42435 unable to find archived log archived log thread=1 sequence=42436 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 02/04/2016 14:08:43 RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42436 and starting SCN of 11924694090 RMAN>

发现还是在报错,42436这个归档日志没有,再去原来的备份库上看,42436是最新的归档日志,应该是刚刚生成的新的归档日志了:

复制代码
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
[oracle@localhost archivelog]$ pwd /oracle/app/oracle/flash_recovery_area/archivelog [oracle@localhost archivelog]$ ll total 502488 -rw-r----- 1 oracle oinstall 3072 Feb 4 03:29 1_42422_821708334.dbf -rw-r----- 1 oracle oinstall 39964160 Feb 4 04:13 1_42423_821708334.dbf -rw-r----- 1 oracle oinstall 33458688 Feb 4 04:23 1_42424_821708334.dbf -rw-r----- 1 oracle oinstall 36429824 Feb 4 05:14 1_42425_821708334.dbf -rw-r----- 1 oracle oinstall 43868672 Feb 4 05:15 1_42426_821708334.dbf -rw-r----- 1 oracle oinstall 42030592 Feb 4 05:15 1_42427_821708334.dbf -rw-r----- 1 oracle oinstall 43868672 Feb 4 08:30 1_42428_821708334.dbf -rw-r----- 1 oracle oinstall 33445888 Feb 4 08:42 1_42429_821708334.dbf -rw-r----- 1 oracle oinstall 33447424 Feb 4 09:32 1_42430_821708334.dbf -rw-r----- 1 oracle oinstall 33540608 Feb 4 10:16 1_42431_821708334.dbf -rw-r----- 1 oracle oinstall 33507328 Feb 4 11:09 1_42432_821708334.dbf -rw-r----- 1 oracle oinstall 33495040 Feb 4 12:01 1_42433_821708334.dbf -rw-r----- 1 oracle oinstall 36377088 Feb 4 13:28 1_42434_821708334.dbf -rw-r----- 1 oracle oinstall 37633536 Feb 4 13:28 1_42435_821708334.dbf -rw-r----- 1 oracle oinstall 33445376 Feb 4 14:13 1_42436_821708334.dbf [oracle@localhost archivelog]$

然后copy这个归的归档日志到微软云azure的oracle库,然后退出rman后再进行recover恢复操作:

复制代码
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
[oracle@localhost archivelog]$ scp -P56922 1_42436_821708334.dbf 142.119.218.19:/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/ oracle@142.119.218.19's password: 1_42436_821708334.dbf 100% 32MB 10.6MB/s 00:03 [oracle@localhost archivelog]$ RMAN> exit Recovery Manager complete. [oracle@pldb1 ~]$ rlwrap rman target / Recovery Manager: Release 11.2.0.1.0 - Production on Thu Feb 4 14:20:04 2016 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. connected to target database: POWERDES (DBID=3391761643, not open) RMAN> recover database; Starting recover at 04-FEB-16 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=19 device type=DISK starting media recovery archived log for thread 1 with sequence 42436 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42436_821708334.dbf archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42436_821708334.dbf thread=1 sequence=42436 unable to find archived log archived log thread=1 sequence=42437 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 02/04/2016 14:20:29 RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42437 and starting SCN of 11924899775 RMAN>

why?会有42437的提示?我自己猜猜是:看到有新的提示了,42437归档日志没有了,这个时候,再去原来备份的库看到42437还没有正式生成,所以这里表明已经恢复到最新记录了,这里报是因为我是copy的归档日志,但是控制文件是以前的全备份的时候的,跟现在旧的备份库的有差异,所以会提示归档日志没有恢复到。这个时候就可以采用基于SCN的方式来recover database了:

采用scn的方式来recover database:

复制代码
1
2
3
4
5
6
7
8
RMAN> recover database until scn 11924899775; Starting recover at 04-FEB-16 using channel ORA_DISK_1 starting media recovery media recovery complete, elapsed time: 00:00:00 Finished recover at 04-FEB-16 RMAN>

8,打开数据库报错

复制代码
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
RMAN> alter database open resetlogs; using target database control file instead of recovery catalog RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of alter db command at 02/04/2016 14:27:35 RMAN-06403: could not obtain a fully authorized session ORA-01034: ORACLE not available ORA-27101: shared memory realm does not exist Linux-x86_64 Error: 2: No such file or directory RMAN> exit Recovery Manager complete. [oracle@pldb1 ~]$ rlwrap sqlplus / as sysdba SQL*Plus: Release 11.2.0.1.0 Production on Thu Feb 4 14:27:50 2016 Copyright (c) 1982, 2009, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 1453092864 bytes Fixed Size 2213416 bytes Variable Size 855640536 bytes Database Buffers 587202560 bytes Redo Buffers 8036352 bytes Database mounted. ORA-03113: end-of-file on communication channel Process ID: 8917 Session ID: 1 Serial number: 5 SQL>

有报错信息,ORA-03113: end-of-file on communication channel提示,后台的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
Successful mount of redo thread 1, with mount id 3472994239 Allocated 4194304 bytes in shared pool for flashback generation buffer Starting background process RVWR Thu Feb 04 14:34:43 2016 RVWR started with pid=20, OS id=9029 Database mounted in Exclusive Mode Lost write protection disabled Completed: ALTER DATABASE MOUNT Thu Feb 04 14:34:43 2016 ALTER DATABASE OPEN Read of datafile '/home/oradata/powerdes/temp01.dbf' (fno 201) header failed with ORA-01203 Rereading datafile 201 header failed with ORA-01203 Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_dbw0_8973.trc: ORA-01186: file 201 failed verification tests ORA-01122: database file 201 failed verification check ORA-01110: data file 201: '/home/oradata/powerdes/temp01.dbf' ORA-01203: wrong incarnation of this file - wrong creation SCN File 201 not verified due to error ORA-01122 LGWR: STARTING ARCH PROCESSES Thu Feb 04 14:34:43 2016 ARC0 started with pid=23, OS id=9036 ARC0: Archival started LGWR: STARTING ARCH PROCESSES COMPLETE ARC0: STARTING ARCH PROCESSES Thu Feb 04 14:34:44 2016 ARC1 started with pid=21, OS id=9038 LGWR: Primary database is in MAXIMUM AVAILABILITY mode LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR LGWR: Minimum of 1 LGWR standby database required Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_8975.trc: ORA-16072: a minimum of one standby database destination is required Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_8975.trc: ORA-16072: a minimum of one standby database destination is required LGWR (ospid: 8975): terminating the instance due to error 16072 Thu Feb 04 14:34:44 2016 ARC2 started with pid=22, OS id=9040 Instance terminated by LGWR, pid = 8975

然后再试试分开,先mount然后open:

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
SQL> startup mount; ORACLE instance started. Total System Global Area 1453092864 bytes Fixed Size 2213416 bytes Variable Size 855640536 bytes Database Buffers 587202560 bytes Redo Buffers 8036352 bytes Database mounted. SQL> SQL> alter database open; alter database open * ERROR at line 1: ORA-03113: end-of-file on communication channel Process ID: 9140 Session ID: 1 Serial number: 5 SQL>

查看后台alert日志信息:

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Thu Feb 04 14:42:50 2016 ARC1 started with pid=21, OS id=9149 LGWR: Primary database is in MAXIMUM AVAILABILITY mode LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR LGWR: Minimum of 1 LGWR standby database required Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_9085.trc: ORA-16072: a minimum of one standby database destination is required Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_9085.trc: ORA-16072: a minimum of one standby database destination is required LGWR (ospid: 9085): terminating the instance due to error 16072 Thu Feb 04 14:42:50 2016 ARC2 started with pid=22, OS id=9151 Instance terminated by LGWR, pid = 9085

看到是因为原来的本地环境是dg模式,而这里azure只有一个单机,所以将dg变成单机最大性能模式,然后再打开试试。

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database; DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL ---------------- -------------------- -------------------- PRIMARY MAXIMUM AVAILABILITY UNPROTECTED SQL> alter database set standby to maximize performance; Database altered. SQL> alter database open; Database altered. SQL> SQL> select open_mode,database_role from v$database; OPEN_MODE DATABASE_ROLE -------------------- ---------------- READ WRITE PRIMARY SQL>

9,在本地测试连接下

然后在本地tnsnames.ora配置,58427端口是微软云azure上面映射的1521端口,通过58427可以访问到1521

复制代码
1
2
3
4
5
6
7
8
9
10
AZURE.PD = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 142.119.218.19)(PORT = 58427)) ) (CONNECT_DATA = (SID = powerdes) ) )

通过plsql连接微软云azure的oracle数据库,做个简单的测试,OK成功了。

复制代码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
SQL> create table z(id number); Table created SQL> insert into z values(1); 1 row inserted SQL> commit; Commit complete SQL> select * from z; ID ---------- 1 SQL> drop table z purge; Table dropped SQL>

10,PS:Oracle rman中recover和restore的区别:

restore just copy the physical file, recover will consistent the database.

restore 是还原,文件级的恢复。就是物理文件还原。
recover 是恢复,数据级的恢复。逻辑上恢复,比如应用归档日志、重做日志,全部同步,保持一致。

用我自己的土话讲就是,用restore先把备份文件拷贝到数据库目录下进行替换,再用recover经过一些处理,数据库就恢复正常了。

10.1、restore 命令:用于还原已经备份的数据文件。

(1)、restore database 还原所有的数据文件。
(2)、restore tablespace 还原特定表空间的数据文件。
(3)、restore datafile 还原特定的数据文件。
(4)、restore controlfile 还原控制文件。
(5)、restore archivelog 还原归档日志文件。

10.2、recover 命令:当数据库需要应用归档日志文件恢复数据文件时,使用recover命令。使用该命令数据库系统会自动应用归档的日志文件。

(1)、recover database 恢复所有的数据文件。
(2)、recover tablespace 恢复特定表空间的数据文件。
(3)、recover datafile 恢复特定的数据文件。

最后

以上就是冷静小熊猫最近收集整理的关于微软云 azure 数据迁移之oracle11g dataguard的全部内容,更多相关微软云内容请搜索靠谱客的其他文章。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(51)

评论列表共有 0 条评论

立即
投稿
返回
顶部