正文
微软云 azure 数据迁移之oracle11g dataguard
小程序：扫一扫查出行【扫一扫了解最新限行尾号】
复制小程序
背景，将本地的oracle数据迁移到微软云azure云上面的oracleserver。1。复制本地的rman备份集到微软云azure的oracleserver上
scp -r -P56922 2016-02-04 142.119.218.19:/oracle/
2，复制本地的控制文件到微软云azure上面的oracleserver
查看备份文件：
rlwrap rman target /
list backup of spfile;
list backup of controlfile;
两者的最后一个文件都是一样的：
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-16BS 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-16RMAN>
复制备份的控制文件：
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的路径：
[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个控制文件:
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_1channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 04-FEB-16RMAN>
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_1channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 04-FEB-16RMAN>
4，将数据库状态改成mount：
RMAN> alter database mount;database mounted
released channel: ORA_DISK_1RMAN>
5。注冊备份文件：
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-16Starting implicit crosscheck copy at 04-FEB-16
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 04-FEB-16searching for all files in the recovery area
cataloging files...
cataloging doneList of Cataloged Files
=======================
File Name: /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_01/o1_mf_1_69_cbzodbgr_.arcsearching for all files that match the pattern /oracle/2016-02-04List 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.logDo you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging doneList 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.bkpList 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 corruptedRMAN>
6。開始运行restore恢复操作，将数据从备份集写入到磁盘上的数据文件中面。
RMAN> restore database;Starting restore at 04-FEB-16
using channel ORA_DISK_1channel 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日志都会记录的，例如以下所看到的：
[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结束:
RMAN> restore database;Starting restore at 04-FEB-16
using channel ORA_DISK_1channel 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.bakchannel 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-16RMAN>
RMAN>
7，開始recover操作
RMAN> recover database;Starting recover at 04-FEB-16
using channel ORA_DISK_1starting media recoverychannel 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 11923509947RMAN>
看到RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42422 and starting SCN of 11923509947，须要将缺失的归档日志从原始备份库copy到微软云azure的oracleserver上
查看备份库的归档文件夹：
[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操作：
[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过来的归档日志的：
RMAN> exitRecovery Manager complete.
[oracle@pldb1 ~]$ rlwrap rman target /Recovery Manager: Release 11.2.0.1.0 - Production on Thu Feb 4 14:05:49 2016Copyright (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=DISKstarting media recoveryarchived 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 11924694090RMAN>
发现还是在报错，42436这个归档日志没有，再去原来的备份库上看。42436是最新的归档日志，应该是刚刚生成的新的归档日志了：
[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恢复操作：
[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> exitRecovery Manager complete.
[oracle@pldb1 ~]$ rlwrap rman target /Recovery Manager: Release 11.2.0.1.0 - Production on Thu Feb 4 14:20:04 2016Copyright (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=DISKstarting media recoveryarchived 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 11924899775RMAN>
why？会有42437的提示？我自己猜猜是：看到有新的提示了。42437归档日志没有了。这个时候，再去原来备份的库看到42437还没有正式生成。所以这里表明已经恢复到最新记录了，这里报是由于我是copy的归档日志，可是控制文件是曾经的全备份的时候的。跟如今旧的备份库的有差异，所以会提示归档日志没有恢复到。这个时候就能够採用基于SCN的方式来recover database了:
採用scn的方式来recover database：
RMAN> recover database until scn 11924899775;Starting recover at 04-FEB-16
using channel ORA_DISK_1starting media recovery
media recovery complete, elapsed time: 00:00:00Finished recover at 04-FEB-16RMAN>
8，打开数据库报错
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 directoryRMAN> exitRecovery Manager complete.
[oracle@pldb1 ~]$ rlwrap sqlplus / as sysdbaSQL*Plus: Release 11.2.0.1.0 Production on Thu Feb 4 14:27:50 2016Copyright (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: 5SQL>
有报错信息，ORA-03113: end-of-file on communication channel提示。后台的alert日志报警信息是：
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：
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: 5SQL>
查看后台alert日志信息：
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变成单机最大性能模式，然后再打开试试。
SQL> select DATABASE_ROLE,PROTECTION_MODE,PROTECTION_LEVEL from v$database;DATABASE_ROLE PROTECTION_MODE PROTECTION_LEVEL
---------------- -------------------- --------------------
PRIMARY MAXIMUM AVAILABILITY UNPROTECTEDSQL> 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 PRIMARYSQL>
9，在本地測试连接下
然后在本地tnsnames.ora配置，58427port是微软云azure上面映射的1521port。通过58427能够訪问到1521
AZURE.PD =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 142.119.218.19)(PORT = 58427))
)
(CONNECT_DATA =
(SID = powerdes)
)
)
通过plsql连接微软云azure的oracle数据库。做个简单的測试，OK成功了。
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 droppedSQL>
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 恢复特定的数据文件。
