微软云 azure 数据迁移之oracle11g dataguard

Posted zhchoutai

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了微软云 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-16

BS Key  Type LV Size       Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
5042    Full    18.36M     DISK        00:00:01     04-FEB-16      
        BP Key: 5042   Status: AVAILABLE  Compressed: NO  Tag: TAG20160204T032902
        Piece Name: /pddata2/oracle/backup/data/ctl_auto/c-3391761643-20160204-01
  Control File Included: Ckp SCN: 11923509959   Ckp time: 04-FEB-16

RMAN> 

复制备份的控制文件:

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_1

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 04-FEB-16

RMAN> 
RMAN> restore controlfile to ‘/oracle/app/oracle/flash_recovery_area/powerdes/control02.ctl‘ from ‘/oracle/c-3391761643-20160204-01‘;

Starting restore at 04-FEB-16
using channel ORA_DISK_1

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
Finished restore at 04-FEB-16

RMAN> 

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

RMAN> alter database mount;

database mounted
released channel: ORA_DISK_1

RMAN> 

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-16

Starting implicit crosscheck copy at 04-FEB-16
using channel ORA_DISK_1
Crosschecked 2 objects
Finished implicit crosscheck copy at 04-FEB-16

searching for all files in the recovery area
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_01/o1_mf_1_69_cbzodbgr_.arc

searching for all files that match the pattern /oracle/2016-02-04

List of Files Unknown to the Database
=====================================
File Name: /oracle/2016-02-04/rman_backup_arch.log
File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak
File Name: /oracle/2016-02-04/full_POWERDES_20160204_5382.bak
File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5381.bak
File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5379.bkp
File Name: /oracle/2016-02-04/rman_backup.log

Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
cataloging done

List of Cataloged Files
=======================
File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak
File Name: /oracle/2016-02-04/full_POWERDES_20160204_5382.bak
File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5381.bak
File Name: /oracle/2016-02-04/arch_POWERDES_20160204_5379.bkp

List of Files Which Where Not Cataloged
=======================================
File Name: /oracle/2016-02-04/rman_backup_arch.log
  RMAN-07517: Reason: The file header is corrupted
File Name: /oracle/2016-02-04/rman_backup.log
  RMAN-07517: Reason: The file header is corrupted

RMAN> 

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

RMAN> restore database;

Starting restore at 04-FEB-16
using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /home/oradata/powerdes/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /home/oradata/powerdes/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /home/oradata/powerdes/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /home/oradata/powerdes/users01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /home/oradata/powerdes/powerdesk01.dbf
channel ORA_DISK_1: restoring datafile 00006 to /home/oradata/powerdes/plas01.dbf
channel ORA_DISK_1: restoring datafile 00007 to /home/oradata/powerdes/pl01.dbf
channel ORA_DISK_1: restoring datafile 00008 to /home/oradata/powerdes/help01.dbf
channel ORA_DISK_1: restoring datafile 00009 to /home/oradata/powerdes/adobelc01.dbf
channel ORA_DISK_1: restoring datafile 00010 to /home/oradata/powerdes/sms01.dbf
channel ORA_DISK_1: restoring datafile 00011 to /home/oradata/powerdes/plcrm01.dbf
channel ORA_DISK_1: restoring datafile 00012 to /home/oradata/powerdes/powerdesk02.dbf
channel ORA_DISK_1: restoring datafile 00013 to /home/oradata/powerdes/datagm01.dbf
channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/full_POWERDES_20160204_5382.bak

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

[[email protected] 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_1

channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /home/oradata/powerdes/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /home/oradata/powerdes/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /home/oradata/powerdes/undotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /home/oradata/powerdes/users01.dbf
channel ORA_DISK_1: restoring datafile 00005 to /home/oradata/powerdes/powerdesk01.dbf
channel ORA_DISK_1: restoring datafile 00006 to /home/oradata/powerdes/plas01.dbf
channel ORA_DISK_1: restoring datafile 00007 to /home/oradata/powerdes/pl01.dbf
channel ORA_DISK_1: restoring datafile 00008 to /home/oradata/powerdes/help01.dbf
channel ORA_DISK_1: restoring datafile 00009 to /home/oradata/powerdes/adobelc01.dbf
channel ORA_DISK_1: restoring datafile 00010 to /home/oradata/powerdes/sms01.dbf
channel ORA_DISK_1: restoring datafile 00011 to /home/oradata/powerdes/plcrm01.dbf
channel ORA_DISK_1: restoring datafile 00012 to /home/oradata/powerdes/powerdesk02.dbf
channel ORA_DISK_1: restoring datafile 00013 to /home/oradata/powerdes/datagm01.dbf
channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/full_POWERDES_20160204_5382.bak

channel ORA_DISK_1: piece handle=/oracle/2016-02-04/full_POWERDES_20160204_5382.bak tag=TAG20160204T030013
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 01:17:07
Finished restore at 04-FEB-16

RMAN> 
RMAN> 

7,開始recover操作

RMAN> recover database;

Starting recover at 04-FEB-16
using channel ORA_DISK_1

starting media recovery

channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=42421
channel ORA_DISK_1: reading from backup piece /oracle/2016-02-04/arch_POWERDES_20160204_5383.bak
channel ORA_DISK_1: piece handle=/oracle/2016-02-04/arch_POWERDES_20160204_5383.bak tag=TAG20160204T032901
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_04/o1_mf_1_42421_cc6o97x5_.arc thread=1 sequence=42421
channel default: deleting archived log(s)
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2016_02_04/o1_mf_1_42421_cc6o97x5_.arc RECID=83680 STAMP=902929321
unable to find archived log
archived log thread=1 sequence=42422
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/04/2016 13:42:07
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42422 and starting SCN of 11923509947

RMAN> 

看到RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42422 and starting SCN of 11923509947,须要将缺失的归档日志从原始备份库copy到微软云azure的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
[[email protected] archivelog]$ scp -P56922 *.dbf 142.119.218.19:/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/
[email protected]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> exit


Recovery Manager complete.
[[email protected] ~]$ rlwrap rman target /

Recovery Manager: Release 11.2.0.1.0 - Production on Thu Feb 4 14:05:49 2016

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: POWERDES (DBID=3391761643, not open)

RMAN> recover database;

Starting recover at 04-FEB-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=1 device type=DISK

starting media recovery

archived log for thread 1 with sequence 42422 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42422_821708334.dbf
archived log for thread 1 with sequence 42423 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42423_821708334.dbf
archived log for thread 1 with sequence 42424 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42424_821708334.dbf
archived log for thread 1 with sequence 42425 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42425_821708334.dbf
archived log for thread 1 with sequence 42426 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42426_821708334.dbf
archived log for thread 1 with sequence 42427 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42427_821708334.dbf
archived log for thread 1 with sequence 42428 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42428_821708334.dbf
archived log for thread 1 with sequence 42429 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42429_821708334.dbf
archived log for thread 1 with sequence 42430 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42430_821708334.dbf
archived log for thread 1 with sequence 42431 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42431_821708334.dbf
archived log for thread 1 with sequence 42432 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42432_821708334.dbf
archived log for thread 1 with sequence 42433 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42433_821708334.dbf
archived log for thread 1 with sequence 42434 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42434_821708334.dbf
archived log for thread 1 with sequence 42435 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42435_821708334.dbf
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42422_821708334.dbf thread=1 sequence=42422
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42423_821708334.dbf thread=1 sequence=42423
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42424_821708334.dbf thread=1 sequence=42424
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42425_821708334.dbf thread=1 sequence=42425
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42426_821708334.dbf thread=1 sequence=42426
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42427_821708334.dbf thread=1 sequence=42427
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42428_821708334.dbf thread=1 sequence=42428
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42429_821708334.dbf thread=1 sequence=42429
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42430_821708334.dbf thread=1 sequence=42430
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42431_821708334.dbf thread=1 sequence=42431
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42432_821708334.dbf thread=1 sequence=42432
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42433_821708334.dbf thread=1 sequence=42433
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42434_821708334.dbf thread=1 sequence=42434
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42435_821708334.dbf thread=1 sequence=42435
unable to find archived log
archived log thread=1 sequence=42436
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/04/2016 14:08:43
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42436 and starting SCN of 11924694090

RMAN>  

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

[[email protected] archivelog]$ pwd
/oracle/app/oracle/flash_recovery_area/archivelog
[[email protected] 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
[[email protected] archivelog]$ 

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

[[email protected] archivelog]$ scp -P56922 1_42436_821708334.dbf 142.119.218.19:/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/
[email protected]142.119.218.19‘s password: 
1_42436_821708334.dbf                                                                                                                                        100%   32MB  10.6MB/s   00:03    
[[email protected] archivelog]$

RMAN> exit


Recovery Manager complete.
[[email protected] ~]$ rlwrap rman target /

Recovery Manager: Release 11.2.0.1.0 - Production on Thu Feb 4 14:20:04 2016

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: POWERDES (DBID=3391761643, not open)

RMAN> recover database;

Starting recover at 04-FEB-16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK

starting media recovery

archived log for thread 1 with sequence 42436 is already on disk as file /oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42436_821708334.dbf
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/1_42436_821708334.dbf thread=1 sequence=42436
unable to find archived log
archived log thread=1 sequence=42437
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/04/2016 14:20:29
RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 42437 and starting SCN of 11924899775

RMAN> 

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

採用scn的方式来recover database:

RMAN> recover database until scn 11924899775;

Starting recover at 04-FEB-16
using channel ORA_DISK_1

starting media recovery
media recovery complete, elapsed time: 00:00:00

Finished recover at 04-FEB-16

RMAN> 

8,打开数据库报错

RMAN> alter database open resetlogs;     

using target database control file instead of recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 02/04/2016 14:27:35
RMAN-06403: could not obtain a fully authorized session
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory

RMAN> exit


Recovery Manager complete.
[[email protected] ~]$ rlwrap sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Thu Feb 4 14:27:50 2016

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to an idle instance.

SQL> startup
ORACLE instance started.

Total System Global Area 1453092864 bytes
Fixed Size          2213416 bytes
Variable Size         855640536 bytes
Database Buffers      587202560 bytes
Redo Buffers            8036352 bytes
Database mounted.
ORA-03113: end-of-file on communication channel
Process ID: 8917
Session ID: 1 Serial number: 5


SQL> 

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

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: 5


SQL> 

查看后台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 UNPROTECTED

SQL> alter database set standby to maximize performance;

Database altered.

SQL> alter database open;

Database altered.

SQL> 
SQL> select open_mode,database_role from v$database;

OPEN_MODE        DATABASE_ROLE
-------------------- ----------------
READ WRITE       PRIMARY

SQL> 

9,在本地測试连接下

然后在本地tnsnames.ora配置,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 dropped

SQL> 

10。PS:Oracle rman中recover和restore的差别:

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

restore 是还原。文件级的恢复。

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

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

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


(1)、restore database 还原全部的数据文件。
(2)、restore tablespace 还原特定表空间的数据文件。


(3)、restore datafile 还原特定的数据文件。
(4)、restore controlfile 还原控制文件。


(5)、restore archivelog 还原归档日志文件。

10.2、recover 命令:当数据库须要应用归档日志文件恢复数据文件时。使用recover命令。

使用该命令数据库系统会自己主动应用归档的日志文件。


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











以上是关于微软云 azure 数据迁移之oracle11g dataguard的主要内容,如果未能解决你的问题,请参考以下文章

Oracle应用也能跑在Azure上了!微软、甲骨文签定云互通协议

oracle11g和12c有啥区别?

微软Azure公有云之企业Exchange 2016部署5—配置DC可用性集

Oracle 11g 数据库迁移

将数据库从 oracle 11g 迁移到 MySql 5.7 的优点、缺点和问题是啥?

“云中论道”之——使用开源技术和Azure公有云服务快速搭建云端IoT解决方案(上)