RAC数据恢复到单节点

最新推荐文章于 2024-06-23 21:58:42 发布
最新推荐文章于 2024-06-23 21:58:42 发布
阅读量1.6k 收藏
点赞数
分类专栏： oracle 文章标签： oracle
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/a743044559/article/details/77847069
版权

前提：由于密码过期导致自动备份任务失败，正好同事需要这期间的数据，真实悲催啊，不哭了，赶紧干活，接着看
环境：
Source:
Centos 6.6
Oracle 11R2 11.2.4.0
RAC jhdb jhdb1 jhdb2
Target：
Centos 6.6
Oracle 11R2 11.2.4.0
单实例 jhdb
以上交代完了，开始挽起裤衩子干活了。
准备工作：
面包、水、纸和小电影~~~~，算了不准备了，这东西太贵
在source端有rman自动备份任务，辛亏你没歇菜，好基友一辈子，如下：
jhdb02-> crontab -l
10 4 * * 1 /home/oracle/JHDB_controb/level_1.sh
10 4 * * 3 /home/oracle/JHDB_controb/level_0.sh
10 4 * * 5 /home/oracle/JHDB_controb/level_1.sh
10 4 * * 0 /home/oracle/JHDB_controb/level_0.sh
You have new mail in /var/spool/mail/oracle

脚本就不贴出来了，反正都一样，现在客户要8.3之后的数据，掐指一算，有了，8.3正好是周三，但是我的任务是凌晨4点运行的，所以还得还得找8.3之后的备份，为了方便，我直接拿了8.7号的数据，把数据文件、归档文件、控制文件和参数文件都拷贝到target端，
1、第一步：修改参数文件
把参数文件拿过来修改下：
之前的：

jhdb2.__db_cache_size=15560867840
jhdb1.__db_cache_size=19520290816
jhdb1.__java_pool_size=469762048
jhdb2.__java_pool_size=469762048
jhdb1.__large_pool_size=33554432
jhdb2.__large_pool_size=33554432
jhdb1.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
jhdb2.__oracle_base='/u01/app/oracle'#ORACLE_BASE set from environment
jhdb1.__pga_aggregate_target=16324231168
jhdb2.__pga_aggregate_target=17137926144
jhdb1.__sga_target=24477958144
jhdb2.__sga_target=23664263168
jhdb1.__shared_io_pool_size=0
jhdb2.__shared_io_pool_size=0
jhdb2.__shared_pool_size=7340032000
jhdb1.__shared_pool_size=4194304000
jhdb1.__streams_pool_size=134217728
jhdb2.__streams_pool_size=134217728
*.audit_file_dest='/u01/app/oracle/admin/jhdb/adump'
*.audit_trail='db'
*.cluster_database=true
*.compatible='11.2.0.4.0'
*.control_files='+DATA/jhdb/controlfile/current.260.884618887','+ARCH/jhdb/controlfile/current.256.884618887'
*.cursor_sharing='force'
*.db_block_size=8192
*.db_create_file_dest='+DATA'
*.db_domain=''
*.db_flashback_retention_target=10080
*.db_name='jhdb'
*.db_recovery_file_dest='+ARCH'
*.db_recovery_file_dest_size=46210744320
*.deferred_segment_creation=FALSE
*.diagnostic_dest='/u01/app/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=jhdbXDB)'
jhdb2.instance_number=2
jhdb1.instance_number=1
*.local_listener='LISTENER_LIST'
jhdb1.local_listener='(address=(protocol=tcp)(host=10.37.2.30)(port=1521))'
jhdb2.local_listener='(ADDRESS = (PROTOCOL = TCP)(HOST=10.37.2.31)(port=1521))'
jhdb1.log_archive_dest_1='location=+arch/jhdb/archivelog/jhdb1'
jhdb2.log_archive_dest_2='location=+arch/jhdb/archivelog/jhdb2'
*.memory_max_target=40802189312
*.memory_target=40802189312
*.open_cursors=300
*.pga_aggregate_target=0
*.processes=1500
*.remote_listener='jhdbcluster-scan:1521'
*.remote_login_passwordfile='exclusive'
*.sga_max_size=0
*.sga_target=0
jhdb2.thread=2
jhdb1.thread=1
*.undo_retention=3600
jhdb1.undo_tablespace='UNDOTBS1'
jhdb2.undo_tablespace='UNDOTBS2'

修改后的：

*.audit_file_dest='/u01/app/oracle/admin/jhdb/adump'
*.cluster_database=true
*.compatible='11.2.0.4.0'
*.control_files='/u01/app/oracle/product/oradata/control01.ctl','/u01/app/oracle/product/oradata/control02.ctl'
*.db_block_size=8192
*.db_create_file_dest='/u01/app/oracle/product/oradata/'
*.db_domain=''
*.db_name='jhdb'
*.instance_number=1
*.diagnostic_dest='/u01/app/oracle/product/'
*.memory_max_target=600m
*.open_cursors=300
*.processes=100
*.remote_login_passwordfile='exclusive'
*.undo_retention=3600
undo_tablespace='UNDOTBS'

2、创建相关目录

mkdir –p /u01/app/oracle/product/oradata/
mkdir –p /u01/app/oracle/admin/jhdb/adump
mkdir -p  /u01/app/oracle/product/
SQL> startup nomount pfile=’<pfile_path>’;

3、设置dbid,
RMAN>set dbid= ;这个参数是干啥的，到现在也懒得弄明白
4、恢复控制文件
RMAN>restore controlfile from ‘backupset_path’;
5、启动数据库到mount状态
RMAN>alter database mount;
6、加载备份文件
RMAN>catalog start with ‘’;
7、还原数据文件到指定路径
以上步骤很easy,接下来很苦恼，准备纸巾吧和泡面吧，泡面是留着吃的纸巾是留着擦汗的。
由于是从rac环境祸福数据到单机环境，数据文件路由都有变化，所以在rman还原的时候要制定好路径，可以采用

select 'set newname for datafile '''||name||''' to ''/u01/app/oracle/product/oradata/'||substr(name,21)||'''' from v$datafile;

语句打印出路径变化地址，登录到rman 恢复数据，脚本如下：

run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
set newname for datafile '+DATA/jhdb/datafile/dv_data.dbf' to '/u01/app/oracle/product/oradata/dv_data.dbf';
set newname for datafile '+DATA/jhdb/datafile/opis_data.dbf' to '/u01/app/oracle/product/oradata/opis_data.dbf';
set newname for datafile '+DATA/jhdb/datafile/boboke.dbf' to '/u01/app/oracle/product/oradata/boboke.dbf';
set newname for datafile '+DATA/jhdb/datafile/abs.dbf' to '/u01/app/oracle/product/oradata/abs.dbf';
set newname for datafile '+DATA/jhdb/datafile/absp.dbf' to '/u01/app/oracle/product/oradata/absp.dbf';
restore database;
switch datafile all;
};

8、恢复archivelog到指定路径

select ' alter database rename file '''||member||''' to '' /u01/app/oracle/product/oradata'||substr(member,21)||'''' from v$logfile;

日志路径也需要改变。

数据还原了，下面接着恢复数据，在恢复之前把redolog地址修改下，

alter database rename file '+ARCH/jhdb/onlinelog/group7_2.log' to '/u01/app/oracle/product/oradata/arch_group7_2.log';
alter database rename file '+DATA/jhdb/onlinelog/group8_2.log' to '/u01/app/oracle/product/oradata/data_group8_2.log';
alter database rename file '+ARCH/jhdb/onlinelog/group8_2.log' to '/u01/app/oracle/product/oradata/arch_group8_2.log';
RMAN>recover database until time ‘2016/08/09 04:00:00’;

RMAN> recover database until time '2016/08/09 03:00:00';
Starting recover at 2016/08/11 21:42:51
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/11/2016 21:42:51
RMAN-06555: datafile 1 must be restored from backup created before 2016/08/09 03:00:00
在网上查看解决方法如下：
RMAN-06555: datafile … must be restored from backup created before …
Message:
RMAN-06555: datafile string must be restored from backup created before string
Cause:
An incomplete recovery session was started, but the file is in newer than the UNTIL TIME clause.
Action:
Check the UNTIL TIME clause or restore the file from a sufficient old backup.

说白了就是先还原到指定时间点在恢复，

Restore database until time ‘2016/08/09 04:00:00’
Recover database until time ‘2016/08/09 04:00:00’

如果提示找不到归档数据，则是缺少redolog，去source端通过备份日志找到对应的redolog归档就好了；

如果报错，一般都是日志文件找不到之类的信息，根据报错信息去找日志就OK了。
先还原数据库，restore database until time ‘2016/08/09 03:00:00’;在执行recover database until time ‘2016/08/09 03:00:00’;，如果报错：

RMAN> restore database until time ‘2016/08/09 09:25:00’;

Starting restore at 2016/08/15 09:55:54
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/15/2016 09:55:54
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time
，报错的意思是until time制定的时间在当前库incarnation 之后，故而恢复失败。查看数据库当前的incarnation时间点：
RMAN>list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

1 1 JHDB 1103974919 PARENT 1 2013/08/24 11:37:30
2 2 JHDB 1103974919 PARENT 925702 2015/07/09 15:28:09
3 3 JHDB 1103974919 CURRENT 100214027 2016/08/11 22:32:02
库当前的incarnation 时间是2016/08/11 ，而指定的until time是2016/08/09,所以会失败。解决方法：
重置库incarnation ：
RMAN> reset database to incarnation 2;在进行还原和恢复。
(restore database until time “to_date(‘2017/08/14 04:00:00’,’yyyy/mm/dd hh24:mi:ss’)”;)
如果出现ORA-19751,19750 找不到asm磁盘组的错误，一般把block_tracking 禁用就可以了，
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;
因为rac库使用了增量备份的策略，会记录数据备份信息到block_tracking,恢复到单节点会检测block_tracking数据，故而会提示找不到ASM磁盘组。

关于incarnation概念：
一般在做了不完全恢复的时候会更新数据库incarnation记录，上图所示 我在8.11号做了一个不完全恢复（resetlogs），所以数据库当前的incarnation是8.11的，如果想恢复到8.11后之后的数据这个incarnation就可以使用，如果想恢复到8.11号之前的数据，这个current incarnation就不能使用，因为resetlogs之后，数据库会重置SCN并记录到控制文件中，所以后期的恢复都会基于current incarnation 去搜索并恢复，搜索不到就会报错；一般这个情况我们会重置current incarnation，说白了current incarnation就是恢复操作搜索文件的起点，current incarnation 时间越久就代表搜索的文件越多恢复就越长。

注意：
1、//系统检查点
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE

    1104793472

2、//文件SCN
SQL> select name,checkpoint_change# from v$datafile;
NAME CHECKPOINT_CHANGE#

/home/oracle/app/oracle/product/oradata/ 1104794788
system.dbf

/home/oracle/app/oracle/product/oradata/ 1104794762
sysaux.dbf

/home/oracle/app/oracle/product/oradata/ 1104794785
undotbs1.dbf

/home/oracle/app/oracle/product/oradata/ 1104794783
users.dbf

SQL> select name,last_change# from v$datafile; //stop scn

NAME LAST_CHANGE#

/home/oracle/app/oracle/product/oradata/
system.dbf

/home/oracle/app/oracle/product/oradata/
sysaux.dbf

/home/oracle/app/oracle/product/oradata/
undotbs1.dbf

/home/oracle/app/oracle/product/oradata/

SQL>
SQL> select name,checkpoint_change# from v$datafile_header;// start scn

NAME CHECKPOINT_CHANGE#

/home/oracle/app/oracle/product/oradata/ 1104794788
system.dbf

/home/oracle/app/oracle/product/oradata/ 1104794762
sysaux.dbf

/home/oracle/app/oracle/product/oradata/ 1104794785

recover database:

SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

    1104793472

SQL> select name,checkpoint_change# from v$datafile;

NAME

CHECKPOINT_CHANGE#

/home/oracle/app/oracle/product/oradata/system.dbf
1106185988

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1106185988

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1106185988

SQL> select name,last_change# from v$datafile; //stop scn

NAME LAST_CHANGE#

/home/oracle/app/oracle/product/oradata/
system.dbf

/home/oracle/app/oracle/product/oradata/
sysaux.dbf

/home/oracle/app/oracle/product/oradata/
undotbs1.dbf

/home/oracle/app/oracle/product/oradata/

SQL> select name,checkpoint_change# from v$datafile_header; //start scn

NAME

CHECKPOINT_CHANGE#

/home/oracle/app/oracle/product/oradata/system.dbf
1106185988

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1106185988

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1106185988

alter database open resetlogs；
1、系统SCN
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

    1106185992

2、文件SCN
SQL> select name,checkpoint_change# from v$datafile;

NAME

CHECKPOINT_CHANGE#

/home/oracle/app/oracle/product/oradata/system.dbf
1106185992

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1106185992

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1106185992

3、stop scn
SQL> select name,last_change# from v$datafile;

NAME LAST_CHANGE#

/home/oracle/app/oracle/product/oradata/
system.dbf

4、start scn
SQL> select name,checkpoint_change# from v$datafile_header;

NAME

CHECKPOINT_CHANGE#

/home/oracle/app/oracle/product/oradata/system.dbf
1106185992

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1106185992

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1106185992

3、

RMAN> restore database until time “to_date(‘2017/08/14 04:00:00’,’yyyy/mm/dd hh24:mi:ss’)”;

Starting restore at 2017/08/21 23:02:00
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 08/21/2017 23:02:00
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

RMAN> list incarnation
2> ;

using target database control file instead of recovery catalog

List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time

1 1 JHDB 1103974919 PARENT 1 2013/08/24 11:37:30
2 2 JHDB 1103974919 PARENT 925702 2015/07/09 15:28:09
3 3 JHDB 1103974919 CURRENT 1106185989 2017/08/21 22:23:36

RMAN> reset database to incarnation 2;

RMAN> restore database until time “to_date(‘2017/08/14 04:00:00’,’yyyy/mm/dd hh24:mi:ss’)”;

查询SCN信息：

系统scn
SQL> select checkpoint_change# from v$database;

CHECKPOINT_CHANGE#

    1106230155

SQL> select GROUP#, STATUS, FIRST_CHANGE#,next_change# from v$log;

GROUP# STATUS           FIRST_CHANGE# NEXT_CHANGE#

     5 CURRENT             1106229382   2.8147E+14
     6 UNUSED                       0            0
     4 INACTIVE            1106185989   1106229382
     8 UNUSED                       0            0
     7 UNUSED                       0            0
     3 INACTIVE            1106185989   1106185996

数据文件scn
SQL> select name,checkpoint_change# from v$datafile ;

NAME

CHECKPOINT_CHANGE#

/home/oracle/app/oracle/product/oradata/system.dbf
1106230155

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1106230155

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1106230155

数据文件结束scn
SQL> select name,last_change# from v$datafile;

NAME

LAST_CHANGE#

/home/oracle/app/oracle/product/oradata/system.dbf
1106230155

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1106230155

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1106230155

数据文件头scn:
SQL> select name,checkpoint_change# from v$datafile_header;

NAME

CHECKPOINT_CHANGE#

/home/oracle/app/oracle/product/oradata/system.dbf
1104794788

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1104794762

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1104794785

SQL> select first_change#,next_change# from v$archived_log
FIRST_CHANGE# NEXT_CHANGE#

1103583305 1104793622
1104793622 1104800953
1104793472 1104800956
1104793622 1104800953
1104793472 1104800956
1104800953 1104801099
1104800956 1104801028
1104801028 1106183645
1104801099 1106185140
1106183645 1106185131
1106185131 1106185878

FIRST_CHANGE# NEXT_CHANGE#

1106185140 1106185875
1106185875 1106186022
1106185878 1106185988
1106185989 1106185996
1106185989 1106229382

由以上可知：
需要保持系统scn，文件scn，stop scn一致且stop 为null 才能正常打开数据库，
由以上可知系统scn,数据文件scn,stop scn都一样，这些信息都存放在控制文件中，说明是按照控制文件还原数据的，由于stop 不是null ，说明数据库未打开，start scn 比其他的小，start scn存放在每个数据文件头中的，说明数据文件比较旧，需要恢复，恢复的数据可以查询日志scn，查询v log可知恢复需要的日志不在v log中，

RMAN> recover database until time “to_date(‘2017/08/14 04:00:00’,’yyyy/mm/dd hh24:mi:ss’)”;

1、系统scn
select checkpoint_change# as “system scn” from v$database ;

system scn

1106230155
2、
select name,checkpoint_change# “file scn” , last_change# “stop scn” from v$datafile;

NAME

file scn stop scn

/home/oracle/app/oracle/product/oradata/system.dbf
1106230155

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1106230155

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1106230155

3、
select name,checkpoint_change# as “start scn” from v$datafile_header;

NAME

start scn

/home/oracle/app/oracle/product/oradata/system.dbf
1106177736

/home/oracle/app/oracle/product/oradata/sysaux.dbf
1106177736

/home/oracle/app/oracle/product/oradata/undotbs1.dbf
1106177736

recover 之后，发现start scn < system scn = file scn = stop scn
数据文件记录的scn小，说明数据文件是旧的，需要恢复，

SQL> select GROUP#, STATUS, FIRST_CHANGE#,next_change# from v$log;

GROUP# STATUS           FIRST_CHANGE# NEXT_CHANGE#

     5 CURRENT             1106229382   2.8147E+14
     6 UNUSED                       0            0
     4 INACTIVE            1106185989   1106229382
     8 UNUSED                       0            0
     7 UNUSED                       0            0
     3 INACTIVE            1106185989   1106185996

6 rows selected.

可以得知，1106177736到1106230155 之间的数据需要恢复，
SQL> alter session set NLS_DATE_FORMAT=’YYYY-MM-DD HH24:MI:SS’;
SQL> set linesize 200;
select stamp,sequence#,first_change#,first_time,next_change#,next_time,completion_time from v$archived_log where 1106177736 < first_change# and next_change#<1106230155 ;

 STAMP  SEQUENCE# FIRST_CHANGE# FIRST_TIME          NEXT_CHANGE# NEXT_TIME           COMPLETION_TIME

952640058 6597 1106183645 2017-08-14 04:10:05 1106185131 2017-08-14 04:10:31 2017-08-21 22:14:18
952640060 6598 1106185131 2017-08-14 04:10:31 1106185878 2017-08-14 04:11:26 2017-08-21 22:14:20
952640061 8453 1106185140 2017-08-14 04:10:32 1106185875 2017-08-14 04:11:26 2017-08-21 22:14:21
952640063 8454 1106185875 2017-08-14 04:11:26 1106186022 2017-08-14 04:11:38 2017-08-21 22:14:23
952640064 6599 1106185878 2017-08-14 04:11:26 1106185988 2017-08-14 04:11:36 2017-08-21 22:14:24
952640630 1 1106185989 2017-08-21 22:23:36 1106185996 2017-08-21 22:23:50 2017-08-21 22:23:50
952643113 1 1106185989 2017-08-21 22:23:36 1106229382 2017-08-21 23:05:12 2017-08-21 23:05:13

7 rows selected.

查看本地归档日志信息：
RMAN> list archivelog all;

using target database control file instead of recovery catalog

List of Archived Log Copies for database with db_unique_name JHDB

Key Thrd Seq S Low Time

15560 1 8449 A 2017/08/12 10:59:33
Name: +ARCH/jhdb/archivelog/jhdb1/1_8449_884618889.dbf

15577 1 8450 A 2017/08/13 04:10:30
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_8450_884618889.dbf

15565 1 8451 A 2017/08/13 04:17:45
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_8451_884618889.dbf

15568 1 8452 A 2017/08/13 04:17:54
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_8452_884618889.dbf

15571 1 8453 A 2017/08/14 04:10:32
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_8453_884618889.dbf

15572 1 8454 A 2017/08/14 04:11:26
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_8454_884618889.dbf

15576 2 6594 A 2017/08/13 04:10:27
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch2_6594_884618889.dbf

15564 2 6594 A 2017/08/13 04:10:27
Name: +ARCH/jhdb/archivelog/jhdb2/2_6594_884618889.dbf

15566 2 6595 A 2017/08/13 04:17:45
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch2_6595_884618889.dbf

15567 2 6596 A 2017/08/13 04:17:52
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch2_6596_884618889.dbf

15569 2 6597 A 2017/08/14 04:10:05
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch2_6597_884618889.dbf

15570 2 6598 A 2017/08/14 04:10:31
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch2_6598_884618889.dbf

15573 2 6599 A 2017/08/14 04:11:26
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch2_6599_884618889.dbf

15575 1 1 A 2017/08/21 22:23:36
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch1_1_952640616.dbf

15574 2 1 A 2017/08/21 22:23:36
Name: /home/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/arch2_1_952640616.dbf
由上图可知，完全恢复需要1106177736到1106230155的备份数据，但是本地归档数据缺失，
到主库查询1106177736到1106230155的备份数据：
由于scn范围不好提取数据没所以使用racid来过滤1106177736到1106230155的备份数据：
select recid,sequence#,first_change#,first_time,next_change#,next_time,completion_time from v$archived_log where recid >= 15571 and recid <= 15583
1 15571 8452 1104801099 2017/8/13 4:17:54 1106185140 2017/8/14 4:10:32 2017/8/14 4:10:33
2 15572 6597 1106183645 2017/8/14 4:10:05 1106185131 2017/8/14 4:10:31 2017/8/14 4:10:33
3 15573 8452 1104801099 2017/8/13 4:17:54 1106185140 2017/8/14 4:10:32 2017/8/14 4:10:40
4 15574 6597 1106183645 2017/8/14 4:10:05 1106185131 2017/8/14 4:10:31 2017/8/14 4:11:06
5 15575 8453 1106185140 2017/8/14 4:10:32 1106185875 2017/8/14 4:11:26 2017/8/14 4:11:26
6 15576 8453 1106185140 2017/8/14 4:10:32 1106185875 2017/8/14 4:11:26 2017/8/14 4:11:26
7 15577 6598 1106185131 2017/8/14 4:10:31 1106185878 2017/8/14 4:11:26 2017/8/14 4:11:27
8 15578 6598 1106185131 2017/8/14 4:10:31 1106185878 2017/8/14 4:11:26 2017/8/14 4:11:27
9 15579 6599 1106185878 2017/8/14 4:11:26 1106185988 2017/8/14 4:11:36 2017/8/14 4:11:36
10 15580 6599 1106185878 2017/8/14 4:11:26 1106185988 2017/8/14 4:11:36 2017/8/14 4:11:36
11 15581 8454 1106185875 2017/8/14 4:11:26 1106186022 2017/8/14 4:11:38 2017/8/14 4:11:38
12 15582 8454 1106185875 2017/8/14 4:11:26 1106186022 2017/8/14 4:11:38 2017/8/14 4:11:38
13 15583 8455 1106186022 2017/8/14 4:11:38 1107954835 2017/8/14 19:00:42 2017/8/14 19:00:46
由上图可知备份数据库缺失8452,8454,8455 6597,6598,6599,文件，找到如上文件，重新执行restore，recover。

钢板堆场部署外网，需要同步数据
开始考虑使用dg，但是经过测试发现dg只能是单向同步，而且备库是read only状态，不符合需求，
ogg是个很好的方案 ，但是ogg是收费版，暂时放弃。
因为业务需要双向复制，为了避免数据被覆盖问题建议改成单向复制方式，单向复制数据使用物化视图效果最好。
下面讲一讲概念：
引用Dave大神的原话：

返璞归真素闲人
关注
专栏目录
RAC备份恢复到单节点
Paladin的专栏
03-27 1708
1简单说明：   版本：11.2.0.3  平台：linux-x86-64 到 win7-64bit  实例： bdstar1，bdstar2  还原到   bdstar  上  参考：三思笔记数据库备份与恢复 2 windows平台系统恢复环境创建 创建实例：oradim -new -sid bdstar 编写一个简单的参数文件： *.audit_file_dest='E:
记录一次Oracle19RAC恢复到单机文件系统
CSDNEND的博客
03-24 801
记录一次Oracle19RAC恢复到单机文件系统（rac19.6---单机19.3） 源端库：rac19c（双节点RAC） 版本：19.6.0.0.0 操作系统：centos7.5 目标库：rac19c（单实例文件系统） 版本：19.3.0.0.0 操作系统：centos7.5 客户需求，生产库数据发生变化，需要使用昨天备份恢复一套单实例做数据对比加数据恢复 19RAC 19.6 恢复至单实例文件系统19c 19.3 （同时验证可以19c可以跨小版本恢复） ---批量数...
恢复-恢复多节点RAC至单节点
06-12 146
pfile模板 *.compatible='11.2.0.4.0' *.db_block_size=8192 *.db_name='rmsdb' *.log_archive_dest_1='location=/home/...
Oracle RAC异机恢复到单机步骤及常见问题
最新发布
qq_16066907的博客
06-23 737
查看控制文件记录的归档信息,最后一个归档SEQUENCE#是18023，NEXT_CHANGE#是375681013。将 +DATA/cjc/datafile 转换为 /db/oracle/oradata/cjc。实例是mount状态，不支持查询dba_data_file表、dba_temp_files表。之前查到，控制文件中记录的最后一个归档是18023，没有18024。执行rename报错:ORA-01511，ORA-01516。源、目标数据文件、临时文件路径不同时，需要路径转换。
oracle rac单节点恢复,如何Oracle_RAC恢复一个节点总结
weixin_34517745的博客
04-11 408
Rac1 已坏Rac3 正常先在rac3上把rac1的信息删干净,然后重新填加rac1步骤如下:1,在rac1上运行DBCA,删除instance;2,如果有ASM,删除ASM实例,srVCtl stop asm -n rac1srvctl remove asm -n rac1;3,在rac3上执行updateNodeList脚本/u01/Oracle/oracle/product/10.2.0/...
rac恢复到单实例
11-21 300
1、将使用rman备份的rac的备份文件传输到异地单节点上 [oracle@ora0 ~]$ ls /data_back/racbk/ 20120514_3snav1p2_1_1.bk ...
HowTo Restore RMAN Disk backups of RAC Database to Single Instance On Another No
coco3600的博客
07-18 123
How To Restore RMAN Disk backups of RAC Database to Single Instance On Another Node (文档 ID 4...
裸设备rac数据库到单节点文件系统恢复
08-30
本主题将深入探讨“裸设备RAC数据库到单节点文件系统恢复”的过程，这对于Oracle数据库管理员来说是一项复杂而关键的任务。裸设备（Raw Device）是指不经过操作系统文件系统的磁盘空间，直接由数据库系统访问和管理...
rac恢复到单机
07-31
从提供的文件信息来看，主题是关于Oracle RAC（Real Application Clusters）数据库如何恢复到单实例数据库的过程。RAC是Oracle数据库的一种高可用性配置选项，它允许多个实例同时访问同一个数据库。在特定情况下，...
RAC结构删除一个节点并删除数据库软件的解决方案
kiwi的专栏
10-21 781
1 节点2 使用dbca删除一个节点 2 节点1 alter database disable thread 2; 3 节点1 验证是否已经删除一个节点数据库 [03:49:06 oracle(db)@rac1 ~]$ srvctl config database -d vposrac Database unique name: prod Database name
Oracle RMAN增量迁移Windows单机到Linux Oracle RAC
你好我是李白
03-08 839
最小停机跨平台迁移Windows Oracle到Linux Oracle RAC
RAC+ASM在单机上恢复的过程
conghai7026的博客
05-19 160
从rac上生成pfile文件并移除cluster_database_instances，cluster_database的等与RAC相关的参数,移除多余的undo_tablespace,只保留一个undo_tables...
RMAN-6556 datafile %s&…
babymouse1212的博客
05-02 636
做了不完全恢复（也就是运行了recover database ***),然后又recover database until SCN=***)   但Oracle发现目前datafile比指定的SCN要新（大),因此提示restore the datafile比你指定的SCN小 ，然后再recover      OERR: RMAN-6556 datafile %s must be restored
Oracle RMAN不完全恢复遇到的RMAN-06556
dbhang的博客
09-30 4454
RMAN-06556: datafile 1 must be restored from backup older than SCN 1350000 这个问题在不完全恢复时经常出现，最近整理以前文档发现了以前自己遇到的两个案例 案例1： 正常进行不完全恢复： 进行一次RMAN全备： RMAN> backup as compressed backupset database; Starting backup at 24-JUN-20 using target database control file
基于时间不完全恢复之rman篇
chen5131421的专栏
08-06 6713
基于时间不完全恢复之rman篇
Oracle恢复（六）------RMAN整库恢复
Cages的专栏
04-10 142
再次强调，要想恢复，先有备份 此处忽略N条启动报错 select * from v$recover_file; 此处忽略N条记录rman connect target / ;我一般习惯不用恢复目录数据库 run{ allocate channel c1 type disk; restore database; recover database; sql 'alter ...
【识记】文件系统损坏引起部分文件丢失，导致oracle 宕机记录
weixin_30823227的博客
04-26 261
还没到公司，就接到电话，数据库宕机了。紧接着一天都忙着处理宕机事件，连午饭都没吃得上。 直到晚上才搞定，再此证明DBA的第一法则：数据备份高于一切呀！No 备份 Shi 翘翘！ -------------------------------------------------------------------------------------------------------------...
rman 异机恢复及0级1级备份脚本
weixin_40913898的博客
07-28 1681
rman 异机恢复及0级1级备份脚本 创建测试环境： [oracle@standby back]$ sqlplus scott/scott SQL*Plus: Release 11.2.0.4.0 Production on 星期三 7月 28 16:02:08 2021 Copyright © 1982, 2013, Oracle. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 -
Oracle RAC异机恢复到单机环境的步骤
当面临需要将RAC数据库恢复到一个单独的服务器（非RAC环境）时，我们需要遵循特定的步骤来确保数据的完整性和一致性。 首先，我们来看一下环境介绍： - 原始RAC环境有两个节点：10.204.101.45 (racdb1) 和 10.204....
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值