微软云 azure 数据迁移之oracle11g dataguard
2024-05-09 08:04:54
背景，将本地的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: TAG20160204T010104Piece Name: /pddata2/oracle/backup/data/ctl_auto/c-3391761643-20160204-00Control 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: TAG20160204T032902Piece Name: /pddata2/oracle/backup/data/ctl_auto/c-3391761643-20160204-01Control 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-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.logRMAN-07517: Reason: The file header is corrupted
File Name: /oracle/2016-02-04/rman_backup.logRMAN-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.loglast deallocation scn is 11565967595Undo 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 11923506763last 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 11923506763last 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 11923506763last 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的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-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配置，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 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 恢复特定的数据文件。
微软云 azure 数据迁移之oracle11g dataguard相关推荐
- AWS snowball、Azure DataBox、Google GTA等云平台数据迁移总结
AWS snowball.Azure DataBox.Google GTA等云平台数据迁移总结 基本上所有云厂商都支持数据的邮寄迁移服务,下面总结一下目前市场上主流云厂商的迁移服务: 云厂商名称 服务 ...
- 亚马逊云(AWS)、微软云(Azure)、阿里云性能对比之哪家好？
这三家在云计算界统称AAA,Azure就是微软云.AWS就是亚马逊云.Aliyun当然就是阿里云了,当然还有其他的云产品包括谷歌云.腾讯云.网易云.华为云.京东云等.本次咱们主要讨论的就是微软云.亚马 ...
- 阿里云服务器数据迁移
关于阿里云服务器数据迁移 本文章献给阿里云服务器体验到期而又不知道如何将数据迁移到新服务器上的初级开发人员.如有不足,请大家指正! 1. 首先登录阿里云服务器官网.进人云服务器 ,找到过期或即将过期的 ...
- 微软云Azure训练营 | 八城联动，全球盛会
Global Azure Bootcamp是由微软发起.MVP参与组织的全球化学习交流活动.每年会挑选一个特定的时间,在同一天内,全球不同地区将同时开展. 2019年全球Azure训练营(Global ...
- 微软云azure iot hub开发环境部署
微软云当前势头越来越强,此文简单写下之前的经验. 1. 注册 1)注册地址 https://portal.azure.com/ https://azure.microsoft.com/zh-cn/ ...
- 阿里云ECS数据迁移到阿里云OSS
实操背景 在运维工作中,存在数据文件迁移的场景,例如将阿里云ECS的数据迁移到OSS中去,该操作可通过 ossutil 落地实现. 首先在你要迁移的服务器运行如下代码,安装该工具 wget https ...
- 阿里云服务器数据迁移(同一个账号内)
最近免费试用的阿里云服务器到期,购买了学生优惠的服务器,为了将数据迁移到新的服务器中,大费周章了一会,终于迁移完毕. 注意:此篇文章为自己学习JavaWeb过程中使用,请勿以专业目光审视,只负责给予部 ...
- 京东云开发者｜京东云RDS数据迁移常见场景攻略
云时代已经来临,云上很多场景下都需要数据的迁移.备份和流转,各大云厂商也大都提供了自己的迁移工具.本文主要介绍京东云数据库为解决用户数据迁移的常见场景所提供的解决方案. 场景一:数据迁移上云 数据迁移 ...
- VMOS Pro云手机数据迁移教程参考
从原VMOS Pro云手机中将数据迁移到VMOS云手机,需要用到的软件有钛备.MT文件管理器份和QQ(两边云手机都需安装这三个软件,可网上搜索下载). 提示:确保两边的云手机ROOT已开启,因为钛备份 ...
最新文章
- 并发 vs 并行 （Concurrency Is Not Parallelism）
- freeRtos学习笔记 （5）事件组
- HihoCode1721删除一个字符之后是回文字符串
- eclipse提示方法已过时_提高效率，eclipse上你可能不知道的技巧
- 流媒体服务器搭建实例——可实现录音，录像功能
- PresentViewController切换界面
- 8路抢答器c语言程序,多路抢答器c程序（原创）
- c语言三位数倒序,C语言求助！一个三位数的逆序数，总是编不对
- 功能不错的Snagit截图软件
- 横河涡街流量计安装参数说明及要求
- python局域网监控系统_python 局域网监控
- python通过ip获取地理位置等ip信息
- Ubuntu下，Kdevelop的简单使用与调试
- 联想宣布推出升级版数据中心产品组合——搭载全新英特尔(R)处理器和持久性内存且安全性增强
- 南京大学计算机学硕分数线,有谁知道南京大学这几年计算机研究生的分数线呀...
- 计蒜客 幼儿园买玩具
- 编译错误：errno undeclared的解决
- python学习--＞tkinter模块学习之Scale（尺度）学习
- ansa打开catia文件_ANSA软件介绍.doc
- seresnet50训练自己的数据集_SSD框架训练自己的数据集