微软云 azure 数据迁移之oracle11g dataguard
来源：互联网 发布：搜狗网络大厦邮编 编辑：程序博客网 时间：2024/05/08 06:29
背景，将本地的oracle数据迁移到微软云azure云上面的oracle服务器。
1，复制本地的rman备份集到微软云azure的oracle服务器上
scp -r -P56922 2016-02-04 142.119.218.19:/oracle/2，复制本地的控制文件到微软云azure上面的oracle服务器
查看备份文件：
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，然后去微软云的oracle服务器上面进行恢复：
去参数文件查看微软云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-16using channel ORA_DISK_1channel ORA_DISK_1: restoring control filechannel ORA_DISK_1: restore complete, elapsed time: 00:00:03Finished 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-16using channel ORA_DISK_1channel ORA_DISK_1: restoring control filechannel ORA_DISK_1: restore complete, elapsed time: 00:00:03Finished restore at 04-FEB-16RMAN> 4，将数据库状态改成mount：
RMAN> alter database mount;database mountedreleased channel: ORA_DISK_1RMAN> 5，注册备份文件：
RMAN> catalog start with '/oracle/2016-02-04';Starting implicit crosscheck backup at 04-FEB-16allocated channel: ORA_DISK_1channel ORA_DISK_1: SID=19 device type=DISKCrosschecked 35 objectsFinished implicit crosscheck backup at 04-FEB-16Starting implicit crosscheck copy at 04-FEB-16using channel ORA_DISK_1Crosschecked 2 objectsFinished implicit crosscheck copy at 04-FEB-16searching for all files in the recovery areacataloging 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.logFile Name: /oracle/2016-02-04/arch_POWERDES_20160204_5383.bakFile Name: /oracle/2016-02-04/full_POWERDES_20160204_5382.bakFile Name: /oracle/2016-02-04/arch_POWERDES_20160204_5381.bakFile Name: /oracle/2016-02-04/arch_POWERDES_20160204_5379.bkpFile Name: /oracle/2016-02-04/rman_backup.logDo you really want to catalog the above files (enter YES or NO)? YEScataloging files...cataloging doneList of Cataloged Files=======================File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5383.bakFile Name: /oracle/2016-02-04/full_POWERDES_20160204_5382.bakFile Name: /oracle/2016-02-04/arch_POWERDES_20160204_5381.bakFile 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 corruptedFile 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-16using channel ORA_DISK_1channel ORA_DISK_1: starting datafile backup set restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setchannel ORA_DISK_1: restoring datafile 00001 to /home/oradata/powerdes/system01.dbfchannel ORA_DISK_1: restoring datafile 00002 to /home/oradata/powerdes/sysaux01.dbfchannel ORA_DISK_1: restoring datafile 00003 to /home/oradata/powerdes/undotbs01.dbfchannel ORA_DISK_1: restoring datafile 00004 to /home/oradata/powerdes/users01.dbfchannel ORA_DISK_1: restoring datafile 00005 to /home/oradata/powerdes/powerdesk01.dbfchannel ORA_DISK_1: restoring datafile 00006 to /home/oradata/powerdes/plas01.dbfchannel ORA_DISK_1: restoring datafile 00007 to /home/oradata/powerdes/pl01.dbfchannel ORA_DISK_1: restoring datafile 00008 to /home/oradata/powerdes/help01.dbfchannel ORA_DISK_1: restoring datafile 00009 to /home/oradata/powerdes/adobelc01.dbfchannel ORA_DISK_1: restoring datafile 00010 to /home/oradata/powerdes/sms01.dbfchannel ORA_DISK_1: restoring datafile 00011 to /home/oradata/powerdes/plcrm01.dbfchannel ORA_DISK_1: restoring datafile 00012 to /home/oradata/powerdes/powerdesk02.dbfchannel ORA_DISK_1: restoring datafile 00013 to /home/oradata/powerdes/datagm01.dbfchannel 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 11923236783Thu Feb 04 12:45:38 2016Full restore complete of datafile 6 /home/oradata/powerdes/plas01.dbf. Elapsed time: 0:24:26 checkpoint is 11923506763 last deallocation scn is 11902810828Thu Feb 04 12:51:09 2016Full restore complete of datafile 2 /home/oradata/powerdes/sysaux01.dbf. Elapsed time: 0:29:47 checkpoint is 11923506763 last deallocation scn is 11923006656Thu Feb 04 12:54:51 2016Full 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-16using channel ORA_DISK_1channel ORA_DISK_1: starting datafile backup set restorechannel ORA_DISK_1: specifying datafile(s) to restore from backup setchannel ORA_DISK_1: restoring datafile 00001 to /home/oradata/powerdes/system01.dbfchannel ORA_DISK_1: restoring datafile 00002 to /home/oradata/powerdes/sysaux01.dbfchannel ORA_DISK_1: restoring datafile 00003 to /home/oradata/powerdes/undotbs01.dbfchannel ORA_DISK_1: restoring datafile 00004 to /home/oradata/powerdes/users01.dbfchannel ORA_DISK_1: restoring datafile 00005 to /home/oradata/powerdes/powerdesk01.dbfchannel ORA_DISK_1: restoring datafile 00006 to /home/oradata/powerdes/plas01.dbfchannel ORA_DISK_1: restoring datafile 00007 to /home/oradata/powerdes/pl01.dbfchannel ORA_DISK_1: restoring datafile 00008 to /home/oradata/powerdes/help01.dbfchannel ORA_DISK_1: restoring datafile 00009 to /home/oradata/powerdes/adobelc01.dbfchannel ORA_DISK_1: restoring datafile 00010 to /home/oradata/powerdes/sms01.dbfchannel ORA_DISK_1: restoring datafile 00011 to /home/oradata/powerdes/plcrm01.dbfchannel ORA_DISK_1: restoring datafile 00012 to /home/oradata/powerdes/powerdesk02.dbfchannel ORA_DISK_1: restoring datafile 00013 to /home/oradata/powerdes/datagm01.dbfchannel 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=TAG20160204T030013channel ORA_DISK_1: restored backup piece 1channel ORA_DISK_1: restore complete, elapsed time: 01:17:07Finished restore at 04-FEB-16RMAN> RMAN> 7，开始recover操作
RMAN> recover database;Starting recover at 04-FEB-16using channel ORA_DISK_1starting media recoverychannel ORA_DISK_1: starting archived log restore to default destinationchannel ORA_DISK_1: restoring archived logarchived log thread=1 sequence=42421channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/arch_POWERDES_20160204_5383.bakchannel ORA_DISK_1: piece handle=/oracle/2016-02-04/arch_POWERDES_20160204_5383.bak tag=TAG20160204T032901channel ORA_DISK_1: restored backup piece 1channel ORA_DISK_1: restore complete, elapsed time: 00:00:03archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_04/o1_mf_1_42421_cc6o97x5_.arc thread=1 sequence=42421channel 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=902929321unable to find archived logarchived log thread=1 sequence=42422RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of recover command at 02/04/2016 13:42:07RMAN-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的oracle服务器上
查看备份库的归档目录：
[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-16using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel 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.dbfarchived log for thread 1 with sequence 42423 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42423_821708334.dbfarchived log for thread 1 with sequence 42424 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42424_821708334.dbfarchived log for thread 1 with sequence 42425 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42425_821708334.dbfarchived log for thread 1 with sequence 42426 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42426_821708334.dbfarchived log for thread 1 with sequence 42427 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42427_821708334.dbfarchived log for thread 1 with sequence 42428 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42428_821708334.dbfarchived log for thread 1 with sequence 42429 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42429_821708334.dbfarchived log for thread 1 with sequence 42430 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42430_821708334.dbfarchived log for thread 1 with sequence 42431 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42431_821708334.dbfarchived log for thread 1 with sequence 42432 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42432_821708334.dbfarchived log for thread 1 with sequence 42433 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42433_821708334.dbfarchived log for thread 1 with sequence 42434 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42434_821708334.dbfarchived log for thread 1 with sequence 42435 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42435_821708334.dbfarchived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42422_821708334.dbf thread=1 sequence=42422archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42423_821708334.dbf thread=1 sequence=42423archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42424_821708334.dbf thread=1 sequence=42424archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42425_821708334.dbf thread=1 sequence=42425archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42426_821708334.dbf thread=1 sequence=42426archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42427_821708334.dbf thread=1 sequence=42427archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42428_821708334.dbf thread=1 sequence=42428archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42429_821708334.dbf thread=1 sequence=42429archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42430_821708334.dbf thread=1 sequence=42430archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42431_821708334.dbf thread=1 sequence=42431archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42432_821708334.dbf thread=1 sequence=42432archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42433_821708334.dbf thread=1 sequence=42433archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42434_821708334.dbf thread=1 sequence=42434archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42435_821708334.dbf thread=1 sequence=42435unable to find archived logarchived log thread=1 sequence=42436RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of recover command at 02/04/2016 14:08:43RMAN-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-16using target database control file instead of recovery catalogallocated channel: ORA_DISK_1channel 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.dbfarchived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42436_821708334.dbf thread=1 sequence=42436unable to find archived logarchived log thread=1 sequence=42437RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of recover command at 02/04/2016 14:20:29RMAN-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-16using channel ORA_DISK_1starting media recoverymedia 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 catalogRMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03002: failure of alter db command at 02/04/2016 14:27:35RMAN-06403: could not obtain a fully authorized sessionORA-01034: ORACLE not availableORA-27101: shared memory realm does not existLinux-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> startupORACLE instance started.Total System Global Area 1453092864 bytesFixed Size 2213416 bytesVariable Size 855640536 bytesDatabase Buffers 587202560 bytesRedo Buffers 8036352 bytesDatabase mounted.ORA-03113: end-of-file on communication channelProcess ID: 8917Session ID: 1 Serial number: 5SQL> 有报错信息，ORA-03113: end-of-file on communication channel提示，后台的alert日志报警信息是：
Successful mount of redo thread 1, with mount id 3472994239Allocated 4194304 bytes in shared pool for flashback generation bufferStarting background process RVWRThu Feb 04 14:34:43 2016RVWR started with pid=20, OS id=9029 Database mounted in Exclusive ModeLost write protection disabledCompleted: ALTER DATABASE MOUNTThu Feb 04 14:34:43 2016ALTER DATABASE OPENRead of datafile '/home/oradata/powerdes/temp01.dbf' (fno 201) header failed with ORA-01203Rereading datafile 201 header failed with ORA-01203Errors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_dbw0_8973.trc:ORA-01186: file 201 failed verification testsORA-01122: database file 201 failed verification checkORA-01110: data file 201: '/home/oradata/powerdes/temp01.dbf'ORA-01203: wrong incarnation of this file - wrong creation SCNFile 201 not verified due to error ORA-01122LGWR: STARTING ARCH PROCESSESThu Feb 04 14:34:43 2016ARC0 started with pid=23, OS id=9036 ARC0: Archival startedLGWR: STARTING ARCH PROCESSES COMPLETEARC0: STARTING ARCH PROCESSESThu Feb 04 14:34:44 2016ARC1 started with pid=21, OS id=9038 LGWR: Primary database is in MAXIMUM AVAILABILITY modeLGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWRLGWR: Minimum of 1 LGWR standby database requiredErrors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_8975.trc:ORA-16072: a minimum of one standby database destination is requiredErrors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_8975.trc:ORA-16072: a minimum of one standby database destination is requiredLGWR (ospid: 8975): terminating the instance due to error 16072Thu Feb 04 14:34:44 2016ARC2 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 bytesFixed Size 2213416 bytesVariable Size 855640536 bytesDatabase Buffers 587202560 bytesRedo Buffers 8036352 bytesDatabase mounted.SQL>SQL> alter database open;alter database open*ERROR at line 1:ORA-03113: end-of-file on communication channelProcess ID: 9140Session ID: 1 Serial number: 5SQL> 查看后台alert日志信息：
Thu Feb 04 14:42:50 2016ARC1 started with pid=21, OS id=9149 LGWR: Primary database is in MAXIMUM AVAILABILITY modeLGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWRLGWR: Minimum of 1 LGWR standby database requiredErrors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_9085.trc:ORA-16072: a minimum of one standby database destination is requiredErrors in file /oracle/app/oracle/diag/rdbms/powerdes/powerdes/trace/powerdes_lgwr_9085.trc:ORA-16072: a minimum of one standby database destination is requiredLGWR (ospid: 9085): terminating the instance due to error 16072Thu Feb 04 14:42:50 2016ARC2 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配置，58427端口是微软云azure上面映射的1521端口，通过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 createdSQL> insert into z values(1);1 row insertedSQL> commit;Commit completeSQL> select * from z; ID---------- 1SQL> 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 恢复特定的数据文件。
2 0
- 微软云 azure 数据迁移之oracle11g dataguard
- oracle11g 在azure云中使用rman进行实例迁移
- 数据迁移：DataGuard配置
- 微软云azure 数据迁移expdp报错ORA-01110: data file 201: '/home/oradata/powerdes/temp01.dbf'
- Oracle11G DataGuard
- oracle运维之--dataguard 主备库迁移
- azure 微软云 规范挂载附加数据磁盘
- oracle11g dataguard 备库数据同步的检查方法
- oracle11g dataguard undo恢复
- linux oracle11g dataguard配置
- oracle11g dataguard 完全手册
- oracle11g dataguard 完全手册
- oracle11g dataguard安装实施
- oracle11g dataguard 完全手册
- oracle11g dataguard 完全手册
- oracle11g dataguard 完全手册
- Oracle11g Dataguard配置
- oracle11g dataguard 完全手册
- hdu 5206 Four Inages Strategy【计算几何】【判断空间正方形】
- 关于自增的两种方式区别（java）
- HDU 5433 Xiao Ming climbing（BFS）
- 解决ScrollView和GridView嵌套时显示不全的问题
- NFS 服务器搭建
- 微软云 azure 数据迁移之oracle11g dataguard
- 【1】用户界面概述
- Codeforces Round #317 [AimFund Thanks-Round] (Div. 2) C. Lengthening Sticks（数学）
- 杭电1856
- android *** ProgressDialog
- hdoj 4505 小Q系列故事——电梯里的爱情 【水题】
- hihocoder-1032 最长回文子串（Manacher）
- windows下运行spark程序
- eclipse中如何通过maven插件执行mvn命令
