背景，将本地的oracle数据迁移到微软云azure云上面的oracleserver。

1。复制本地的rman备份集到微软云azure的oracleserver上

  1. scp -r -P56922 2016-02-04 142.119.218.19:/oracle/

2，复制本地的控制文件到微软云azure上面的oracleserver

查看备份文件：

  1. rlwrap rman target /
  2. list backup of spfile;
  3. list backup of controlfile;

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

  1. RMAN>  list backup of controlfile;                                                                                                                                                             
  3. using target database control file instead of recovery catalog                                                                                                                                 
  5. List of Backup Sets
  6. ===================
  8. .....
  10. BS Key  Type LV Size       Device Type Elapsed Time Completion Time
  11. ------- ---- -- ---------- ----------- ------------ ---------------
  12. 5038    Full    18.36M     DISK        00:00:02     04-FEB-16
  13.         BP Key: 5038   Status: AVAILABLE  Compressed: NO  Tag: TAG20160204T010104
  14.         Piece Name: /pddata2/oracle/backup/data/ctl_auto/c-3391761643-20160204-00
  15.   Control File Included: Ckp SCN: 11923211853   Ckp time: 04-FEB-16
  17. BS Key  Type LV Size       Device Type Elapsed Time Completion Time
  18. ------- ---- -- ---------- ----------- ------------ ---------------
  19. 5042    Full    18.36M     DISK        00:00:01     04-FEB-16
  20.         BP Key: 5042   Status: AVAILABLE  Compressed: NO  Tag: TAG20160204T032902
  21.         Piece Name: /pddata2/oracle/backup/data/ctl_auto/c-3391761643-20160204-01
  22.   Control File Included: Ckp SCN: 11923509959   Ckp time: 04-FEB-16
  24. RMAN>

复制备份的控制文件：

  1. 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，然后去微软云的oracleserver上面进行恢复：

去參数文件查看微软云control的路径：

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

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

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

4，将数据库状态改成mount：

  1. RMAN> alter database mount;
  3. database mounted
  4. released channel: ORA_DISK_1
  6. RMAN>

5。注冊备份文件：

  1. RMAN> catalog start with '/oracle/2016-02-04';
  3. Starting implicit crosscheck backup at 04-FEB-16
  4. allocated channel: ORA_DISK_1
  5. channel ORA_DISK_1: SID=19 device type=DISK
  6. Crosschecked 35 objects
  7. Finished implicit crosscheck backup at 04-FEB-16
  9. Starting implicit crosscheck copy at 04-FEB-16
  10. using channel ORA_DISK_1
  11. Crosschecked 2 objects
  12. Finished implicit crosscheck copy at 04-FEB-16
  14. searching for all files in the recovery area
  15. cataloging files...
  16. cataloging done
  18. List of Cataloged Files
  19. =======================
  20. File Name: /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_01/o1_mf_1_69_cbzodbgr_.arc
  22. searching for all files that match the pattern /oracle/2016-02-04
  24. List of Files Unknown to the Database
  25. =====================================
  26. File Name: /oracle/2016-02-04/rman_backup_arch.log
  27. File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak
  28. File Name: /oracle/2016-02-04/full_POWERDES_20160204_5382.bak
  29. File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5381.bak
  30. File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5379.bkp
  31. File Name: /oracle/2016-02-04/rman_backup.log
  33. Do you really want to catalog the above files (enter YES or NO)? YES
  34. cataloging files...
  35. cataloging done
  37. List of Cataloged Files
  38. =======================
  39. File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak
  40. File Name: /oracle/2016-02-04/full_POWERDES_20160204_5382.bak
  41. File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5381.bak
  42. File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5379.bkp
  44. List of Files Which Where Not Cataloged
  45. =======================================
  46. File Name: /oracle/2016-02-04/rman_backup_arch.log
  47.   RMAN-07517: Reason: The file header is corrupted
  48. File Name: /oracle/2016-02-04/rman_backup.log
  49.   RMAN-07517: Reason: The file header is corrupted
  51. RMAN>

6。開始运行restore恢复操作，将数据从备份集写入到磁盘上的数据文件中面。

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

这个过程时间有些漫长，没写入一个数据文件，后台alert日志都会记录的，例如以下所看到的：

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

最后restore database结束:

  1. RMAN> restore database;
  3. Starting restore at 04-FEB-16
  4. using channel ORA_DISK_1
  6. channel ORA_DISK_1: starting datafile backup set restore
  7. channel ORA_DISK_1: specifying datafile(s) to restore from backup set
  8. channel ORA_DISK_1: restoring datafile 00001 to /home/oradata/powerdes/system01.dbf
  9. channel ORA_DISK_1: restoring datafile 00002 to /home/oradata/powerdes/sysaux01.dbf
  10. channel ORA_DISK_1: restoring datafile 00003 to /home/oradata/powerdes/undotbs01.dbf
  11. channel ORA_DISK_1: restoring datafile 00004 to /home/oradata/powerdes/users01.dbf
  12. channel ORA_DISK_1: restoring datafile 00005 to /home/oradata/powerdes/powerdesk01.dbf
  13. channel ORA_DISK_1: restoring datafile 00006 to /home/oradata/powerdes/plas01.dbf
  14. channel ORA_DISK_1: restoring datafile 00007 to /home/oradata/powerdes/pl01.dbf
  15. channel ORA_DISK_1: restoring datafile 00008 to /home/oradata/powerdes/help01.dbf
  16. channel ORA_DISK_1: restoring datafile 00009 to /home/oradata/powerdes/adobelc01.dbf
  17. channel ORA_DISK_1: restoring datafile 00010 to /home/oradata/powerdes/sms01.dbf
  18. channel ORA_DISK_1: restoring datafile 00011 to /home/oradata/powerdes/plcrm01.dbf
  19. channel ORA_DISK_1: restoring datafile 00012 to /home/oradata/powerdes/powerdesk02.dbf
  20. channel ORA_DISK_1: restoring datafile 00013 to /home/oradata/powerdes/datagm01.dbf
  21. channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/full_POWERDES_20160204_5382.bak
  23. channel ORA_DISK_1: piece handle=/oracle/2016-02-04/full_POWERDES_20160204_5382.bak tag=TAG20160204T030013
  24. channel ORA_DISK_1: restored backup piece 1
  25. channel ORA_DISK_1: restore complete, elapsed time: 01:17:07
  26. Finished restore at 04-FEB-16
  28. RMAN>
  29. RMAN>

7，開始recover操作

  1. RMAN> recover database;
  3. Starting recover at 04-FEB-16
  4. using channel ORA_DISK_1
  6. starting media recovery
  8. channel ORA_DISK_1: starting archived log restore to default destination
  9. channel ORA_DISK_1: restoring archived log
  10. archived log thread=1 sequence=42421
  11. channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak
  12. channel ORA_DISK_1: piece handle=/oracle/2016-02-04/arch_POWERDES_20160204_5383.bak tag=TAG20160204T032901
  13. channel ORA_DISK_1: restored backup piece 1
  14. channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
  15. 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
  16. channel default: deleting archived log(s)
  17. 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
  18. unable to find archived log
  19. archived log thread=1 sequence=42422
  20. RMAN-00571: ===========================================================
  21. RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
  22. RMAN-00571: ===========================================================
  23. RMAN-03002: failure of recover command at 02/04/2016 13:42:07
  24. RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42422 and starting SCN of 11923509947
  26. RMAN>

看到RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42422 and starting SCN of 11923509947，须要将缺失的归档日志从原始备份库copy到微软云azure的oracleserver上

查看备份库的归档文件夹：

  1. [oracle@localhost archivelog]$ find /oracle -name archivelog
  2. /oracle/app/oracle/flash_recovery_area/archivelog
  3. [oracle@localhost archivelog]$ cd /oracle/app/oracle/flash_recovery_area/archivelog
  4. [oracle@localhost archivelog]$

開始copy操作：

  1. [oracle@localhost archivelog]$ scp -P56922 *.dbf 142.119.218.19:/oracle/app/oracle/flash_recovery_area/archivelog/
  2. oracle@142.119.218.19's password:
  3. scp: /oracle/app/oracle/flash_recovery_area/archivelog/: No such file or directory
  4. [oracle@localhost archivelog]$ scp -P56922 *.dbf 142.119.218.19:/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/
  5. oracle@142.119.218.19's password:
  6. 1_42422_821708334.dbf                                                                                                                                        100% 3072     3.0KB/s   00:00
  7. 1_42423_821708334.dbf                                                                                                                                        100%   38MB  12.7MB/s   00:03
  8. 1_42424_821708334.dbf                                                                                                                                        100%   32MB  10.6MB/s   00:03
  9. 1_42425_821708334.dbf                                                                                                                                        100%   35MB  11.6MB/s   00:03
  10. 1_42426_821708334.dbf                                                                                                                                        100%   42MB  14.0MB/s   00:03
  11. 1_42427_821708334.dbf                                                                                                                                        100%   40MB  13.4MB/s   00:03
  12. 1_42428_821708334.dbf                                                                                                                                        100%   42MB   8.4MB/s   00:05
  13. 1_42429_821708334.dbf                                                                                                                                        100%   32MB  10.6MB/s   00:03
  14. 1_42430_821708334.dbf                                                                                                                                        100%   32MB  10.6MB/s   00:03
  15. 1_42431_821708334.dbf                                                                                                                                        100%   32MB   5.3MB/s   00:06
  16. 1_42432_821708334.dbf                                                                                                                                        100%   32MB  10.7MB/s   00:03
  17. 1_42433_821708334.dbf                                                                                                                                        100%   32MB   5.3MB/s   00:06
  18. 1_42434_821708334.dbf                                                                                                                                        100%   35MB  11.6MB/s   00:03
  19. 1_42435_821708334.dbf                                                                                                                                        100%   36MB  12.0MB/s   00:03
  20. [oracle@localhost archivelog]$

然后在微软云azure的oracle库上，退出rman。又一次登录rman运行recover database操作。假设不退出rman又一次登录是识别不了新的copy过来的归档日志的：

  1. RMAN> exit
  3. Recovery Manager complete.
  4. [oracle@pldb1 ~]$ rlwrap rman target /
  6. Recovery Manager: Release 11.2.0.1.0 - Production on Thu Feb 4 14:05:49 2016
  8. Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
  10. connected to target database: POWERDES (DBID=3391761643, not open)
  12. RMAN> recover database;
  14. Starting recover at 04-FEB-16
  15. using target database control file instead of recovery catalog
  16. allocated channel: ORA_DISK_1
  17. channel ORA_DISK_1: SID=1 device type=DISK
  19. starting media recovery
  21. 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
  22. 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
  23. 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
  24. 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
  25. 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
  26. 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
  27. 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
  28. 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
  29. 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
  30. 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
  31. 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
  32. 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
  33. 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
  34. 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
  35. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42422_821708334.dbf thread=1 sequence=42422
  36. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42423_821708334.dbf thread=1 sequence=42423
  37. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42424_821708334.dbf thread=1 sequence=42424
  38. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42425_821708334.dbf thread=1 sequence=42425
  39. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42426_821708334.dbf thread=1 sequence=42426
  40. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42427_821708334.dbf thread=1 sequence=42427
  41. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42428_821708334.dbf thread=1 sequence=42428
  42. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42429_821708334.dbf thread=1 sequence=42429
  43. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42430_821708334.dbf thread=1 sequence=42430
  44. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42431_821708334.dbf thread=1 sequence=42431
  45. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42432_821708334.dbf thread=1 sequence=42432
  46. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42433_821708334.dbf thread=1 sequence=42433
  47. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42434_821708334.dbf thread=1 sequence=42434
  48. archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42435_821708334.dbf thread=1 sequence=42435
  49. unable to find archived log
  50. archived log thread=1 sequence=42436
  51. RMAN-00571: ===========================================================
  52. RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
  53. RMAN-00571: ===========================================================
  54. RMAN-03002: failure of recover command at 02/04/2016 14:08:43
  55. RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42436 and starting SCN of 11924694090
  57. RMAN>

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

  1. [oracle@localhost archivelog]$ pwd
  2. /oracle/app/oracle/flash_recovery_area/archivelog
  3. [oracle@localhost archivelog]$ ll
  4. total 502488
  5. -rw-r----- 1 oracle oinstall     3072 Feb  4 03:29 1_42422_821708334.dbf
  6. -rw-r----- 1 oracle oinstall 39964160 Feb  4 04:13 1_42423_821708334.dbf
  7. -rw-r----- 1 oracle oinstall 33458688 Feb  4 04:23 1_42424_821708334.dbf
  8. -rw-r----- 1 oracle oinstall 36429824 Feb  4 05:14 1_42425_821708334.dbf
  9. -rw-r----- 1 oracle oinstall 43868672 Feb  4 05:15 1_42426_821708334.dbf
  10. -rw-r----- 1 oracle oinstall 42030592 Feb  4 05:15 1_42427_821708334.dbf
  11. -rw-r----- 1 oracle oinstall 43868672 Feb  4 08:30 1_42428_821708334.dbf
  12. -rw-r----- 1 oracle oinstall 33445888 Feb  4 08:42 1_42429_821708334.dbf
  13. -rw-r----- 1 oracle oinstall 33447424 Feb  4 09:32 1_42430_821708334.dbf
  14. -rw-r----- 1 oracle oinstall 33540608 Feb  4 10:16 1_42431_821708334.dbf
  15. -rw-r----- 1 oracle oinstall 33507328 Feb  4 11:09 1_42432_821708334.dbf
  16. -rw-r----- 1 oracle oinstall 33495040 Feb  4 12:01 1_42433_821708334.dbf
  17. -rw-r----- 1 oracle oinstall 36377088 Feb  4 13:28 1_42434_821708334.dbf
  18. -rw-r----- 1 oracle oinstall 37633536 Feb  4 13:28 1_42435_821708334.dbf
  19. -rw-r----- 1 oracle oinstall 33445376 Feb  4 14:13 1_42436_821708334.dbf
  20. [oracle@localhost archivelog]$

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

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

why？会有42437的提示？我自己猜猜是：看到有新的提示了。42437归档日志没有了。这个时候，再去原来备份的库看到42437还没有正式生成。所以这里表明已经恢复到最新记录了，这里报是由于我是copy的归档日志，可是控制文件是曾经的全备份的时候的。跟如今旧的备份库的有差异，所以会提示归档日志没有恢复到。这个时候就能够採用基于SCN的方式来recover database了:

採用scn的方式来recover database：

  1. RMAN> recover database until scn 11924899775;
  3. Starting recover at 04-FEB-16
  4. using channel ORA_DISK_1
  6. starting media recovery
  7. media recovery complete, elapsed time: 00:00:00
  9. Finished recover at 04-FEB-16
  11. RMAN>

8，打开数据库报错

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

有报错信息，ORA-03113: end-of-file on communication channel提示。后台的alert日志报警信息是：

  1. Successful mount of redo thread 1, with mount id 3472994239
  2. Allocated 4194304 bytes in shared pool for flashback generation buffer
  3. Starting background process RVWR
  4. Thu Feb 04 14:34:43 2016
  5. RVWR started with pid=20, OS id=9029
  6. Database mounted in Exclusive Mode
  7. Lost write protection disabled
  8. Completed: ALTER DATABASE   MOUNT
  9. Thu Feb 04 14:34:43 2016
  10. ALTER DATABASE OPEN
  11. Read of datafile '/home/oradata/powerdes/temp01.dbf' (fno 201) header failed with ORA-01203
  12. Rereading datafile 201 header failed with ORA-01203
  13. Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_dbw0_8973.trc:
  14. ORA-01186: file 201 failed verification tests
  15. ORA-01122: database file 201 failed verification check
  16. ORA-01110: data file 201: '/home/oradata/powerdes/temp01.dbf'
  17. ORA-01203: wrong incarnation of this file - wrong creation SCN
  18. File 201 not verified due to error ORA-01122
  19. LGWR: STARTING ARCH PROCESSES
  20. Thu Feb 04 14:34:43 2016
  21. ARC0 started with pid=23, OS id=9036
  22. ARC0: Archival started
  23. LGWR: STARTING ARCH PROCESSES COMPLETE
  24. ARC0: STARTING ARCH PROCESSES
  25. Thu Feb 04 14:34:44 2016
  26. ARC1 started with pid=21, OS id=9038
  27. LGWR: Primary database is in MAXIMUM AVAILABILITY mode
  28. LGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWR
  29. LGWR: Minimum of 1 LGWR standby database required
  30. Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_8975.trc:
  31. ORA-16072: a minimum of one standby database destination is required
  32. Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_8975.trc:
  33. ORA-16072: a minimum of one standby database destination is required
  34. LGWR (ospid: 8975): terminating the instance due to error 16072
  35. Thu Feb 04 14:34:44 2016
  36. ARC2 started with pid=22, OS id=9040
  37. Instance terminated by LGWR, pid = 8975

然后再试试分开，先mount然后open：

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

查看后台alert日志信息：

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

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

  1. SQL>  select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;
  3. DATABASE_ROLE    PROTECTION_MODE      PROTECTION_LEVEL
  4. ---------------- -------------------- --------------------
  5. PRIMARY      MAXIMUM AVAILABILITY UNPROTECTED
  7. SQL> alter database set standby to maximize performance;
  9. Database altered.
  11. SQL> alter database open;
  13. Database altered.
  15. SQL>
  16. SQL> select open_mode,database_role from v$database;
  18. OPEN_MODE        DATABASE_ROLE
  19. -------------------- ----------------
  20. READ WRITE       PRIMARY
  22. SQL>

9，在本地測试连接下

然后在本地tnsnames.ora配置，58427port是微软云azure上面映射的1521port。通过58427能够訪问到1521

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

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

  1. SQL> create table z(id number);
  2. Table created
  3. SQL> insert into z values(1);
  4. 1 row inserted
  5. SQL> commit;
  6. Commit complete
  7. SQL> select * from z;
  8.         ID
  9. ----------
  10.          1
  11. SQL> drop table z purge;
  12. Table dropped
  14. 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的更多相关文章

  1. 30分钟连接树莓派到微软云 Azure IoT Hub，并将数据进行可视化

    更多内容,关注公众号: 树莓派是很多动手达人必备的小玩具,本节内容,让我们拿出树莓派,在30分钟内,将树莓派连接到微软云Azure的IoT Hub,然后将温湿度曲线可视化.(本节内容完整视频在文章末尾 ...

  2. 微软云Azure Website 远程调试

    微软云Azure Website 远程调试 是可以的 但是只有48小时,要在后台开启,所以还是很麻烦的啊! 但是安全性提高了,不得不承认哦

  3. 本号讯 | 永不消失的协作“空间站”开课；微软推出微软云Azure文档网站

    8月29日,针对企业常面临的“协同办公”困难,开展以“还有这种操作?永不消失的协作'空间站'”为主题的协同办公培训课. 课程内容包含:在Office 365环境中,如何利用Teams与Groups等功 ...

  4. 京东云开发者｜京东云RDS数据迁移常见场景攻略

    云时代已经来临,云上很多场景下都需要数据的迁移.备份和流转,各大云厂商也大都提供了自己的迁移工具.本文主要介绍京东云数据库为解决用户数据迁移的常见场景所提供的解决方案. 场景一:数据迁移上云 数据迁移 ...

  5. Docker技术：在微软云Azure上使用K8S

    周末,受微软公司的邀请,参加微软主持的云容器培训会议,为参加培训的学院提供技术辅导,引导学员体验微软云端的DevOps实践. 说是辅导,实际上自己也学到了许多的内容,包括K8S集群.负载.Azure中 ...

  6. .Net Core Web Api 上传女朋友的照片到微软云Azure Storage

    前言 实现一个Web Api,把女朋友照片保存到Azure云的storage里. Image Upload Api 在对应的Api Controller里,加上attribute: [Consumes ...

  7. windows云服务器数据迁移

    刚入职,第一个任务是完成windows腾讯云到windows华为云上的MySQL数据库迁移.之前都是在CentOS上搞,感觉没啥难度,一口答应,没想到各种坑接踵而来.次数不再叙述坑都有哪些了,说说怎么 ...

  8. 【Azure 环境】连接到微软云Azure中国区 By VS 2019, VS Code, Powershell

    问题情形 最近,在使用最新的VS Code插件连接到中国区的Azure时候,出现了依旧是global版的登录连接.这个问题是当前Azure Account插件最新版的问题,可以使用V0.8.11版本登 ...

  9. Redis数据迁移方案

    场景 Redis实例A ---> Redis实例B,整库全量迁移 方案一: mac环境 brew install npm npm install redis-dump -g 针对RedisA: ...

随机推荐

  1. Java main方法中的String[] args

    -- Java 命令行参数 -- 关于其中的args以及public static / static public Java 命令行参数 前面已经看到多个使用Java数组的示例,每一个Java应用程序 ...

  2. Jsp学习总结（1）——JSP九大内置对象和四种属性范围解读

    一.四种属性范围 1.1.在JSP中提供了四种属性保存范围 page:在一个页面内保存属性,跳转之后无效 request:在一次服务请求范围内,服务器跳转后依然有效 session:-在一次会话范围内 ...

  3. github连接报"ssh: connect to host github.com port 22: Connection timed out"错误

    1. 异常 在连接github时,执行"ssh -T git@github.com" 命令时,出现 ssh: connect to host github.com port 22: ...

  4. 研究一些复杂java开源软件代码的体会（转）

    原文地址:http://herman-liu76.iteye.com/blog/2349026     有时候看源代码是非常有趣的事情,象是思考游戏,象是思考棋局...     平时做J2EE项目中, ...

  5. Linux下经常使用的C/C++开源Socket库

    1.      Linux Socket Programming In C++ : http://tldp.org/LDP/LG/issue74/tougher.html 2.      ACE: h ...

  6. 压缩感知——SP（subspace pursuit）重构算法前言翻译

    压缩感知是一种採样方法,它和变换编码类似,后者被广泛用于涉及到大规模数据採样的现代通信系统中.变换编码将高维空间中的输入信号.转换成很低的低维空间中的信号.变换编码器的样例有著名的小波变换和普遍存在的 ...

  7. Android学习笔记(三)

    ContentProvider简单介绍 ContentProvider是不同应用程序之间进行数据交换的标准API,当一个应用程序须要把自己的数据暴露给其它程序使用时.该应用程序便可通过提供Conten ...

  8. jquery14 on() trigger() : 事件操作的相关方法

    <!DOCTYPE HTML> <html> <head> <meta http-equiv="Content-Type" content ...

  9. Gym 100952 H. Special Palindrome

    http://codeforces.com/gym/100952/problem/H H. Special Palindrome time limit per test 1 second memory ...

  10. django第三方库

    1. django_celery_beat 作用:网页端配置定时任务 注意:1,需要迁移表格 2.需要注册app python3 manage.py makemigrations python3 ma ...