rman迁移时间点恢复

本来今天请假休息了，晚上8点吃饭的时候，主管打来电话让我恢复一个数据库，中午12点的时候开发人员不当操作，其中一个schema用来接收其他工厂的的数据，搞乱套了。
~
让我恢复到今天中午12点左右的数据，但是其他schema没问题，只恢复这一个schema，这个数据库1.7T大小，突然想到这套服务器是RAC，1节点数据泵中午12点备份，2节点是rman晚上8点备份，
吃完饭马上去找1节点备份，-_-||发现是空的，备份脚本出问题了。
只能用rman恢复了~马上去2节点拷贝昨天晚上的备份和昨天一天今天一天的归档文件，拷贝到新服务器，开始进行恢复，这相当于RAC到单节点的迁移了。

下面是操作步骤
安装数据库软件·······················很快就完成了。
拷贝其他的单实例数据库的init.ora文件， 启动到nomunt用到
修改init文件内数据库名和路径位置
直接启动

sql>STARTUP NOMOUNT;

然后rman进入rman管理界面恢复控制文件
恢复控制文件：

RMAN>RESTORE CONTROLFILE FROM '/oradata/backup/CTCNZQF/cntrl_540843_1_962057699';

注册备份目录到控制文件，-----------把拷贝过来的备份文件目录注册到控制文件，告诉控制文件我的备份在这个目录

RMAN> CATALOG START WITH '/oradata/backup/CTCNZQF/';

启动数据到MOUNT；

RMAN>alter database mount;

然后开始restore 还原数据文件，但是因为我RAC用的是ASM存储管理的，现在是本地文件，
需要修改数据文件名所以要newname一下
使用以下语句查出来所有的数据文件，改为本地文件名字

SQL>select 'SET NEWNAME FOR DATAFILE '|| file# ||' to ' ||''''|| name ||''''|| ';' from v$datafile;

然后把结果复制在文本上面，修改数据文件名字开始进行restore

RMAN>run {
allocate channel d1 type disk;   
allocate channel d2 type disk;
allocate channel d3 type disk;
allocate channel d4 type disk;
set newname for datafile 1 to '/oradata/CTCNZQF/system01.dbf';
set newname for datafile 2 to '/oradata/CTCNZQF/sysaux02.dbf';
··························
set newname for datafile 667 to '/oradata/CTCNZQF/ctcnzjf_n648.dbf';
set newname for datafile 668 to '/oradata/CTCNZQF/farmbjhs_idx649.dbf';
restore database;
switch datafile all;
release channel d4;
release channel d3;
release channel d2;
release channel d1;
} 

第一遍执行的时候报错，并且数据文件没有还原到指定位置，不知道原因重新执行了一遍，数据文件还原了过来。
然后开始recovery

[oracle@stat ~]$ export NLS_DATE_FORMAT='yyyy-mm-dd hh34:mi:ss' 指定时间格式
RMAN> recover database until time '2017-12-07 12:00:56' 指定恢复到的时间

然后报错，提示没有归档

但是我归档已经拷贝到我写的归档的目录下了，
查了很久之后才发现，因为控制文件不知道归档在那里，只知道备份，如果我不回复到中午12点，直接recovery就可以恢复到昨晚8点的状态，所以他要晚上8点到中午12点的归档。他找不到，，
那就注册，吧归档路径信息写到控制文件内，没找到怎么注册整个归档目录。只能一条条粘贴
-----注册拷贝过来的归档日志到控制文件 把所有最新的拷贝过来的归档日志一个个注册到控制文件内。

RMAN>catalog arcHivelog '/oradata/arch/CTCNZQF/thread_2_seq_92815.28569.962057619';
RMAN>···由于太多就不写那么多了
RMAN>catalog archivelog '/oradata/arch/CTCNZQF/thread_2_seq_93639.8125.962135299';

然后重新执行

RMAN> recover database until time '2017-12-07 12:00:56'；

这个图说明正在恢复

提示已经恢复到12点6分了。说明已经恢复成功了。

然后添加日志组，修改日志组的名字,查找数据库所有日志名字

select 'alter database rename file '''||member||q'[' to '/oradata/fast_recovery_area/CTCNZQF/redo';]' from v$logfile;

修改好名字之后 。。执行

alter database rename file '+ASM_REDO1/CTCNZQF/ONLINELOG/group_1.257.954793817' to '/oradata/fast_recovery_area/CTCNZQF/redo1';
alter database rename file '+ASM_REDO2/CTCNZQF/ONLINELOG/group_1.258.954793817' to '/oradata/fast_recovery_area/CTCNZQF/redo2';
··········
alter database rename file '+ASM_REDO1/CTCNZQF/ONLINELOG/group_24.277.955022759' to '/oradata/fast_recovery_area/CTCNZQF/redo31';
alter database rename file '+ASM_REDO2/CTCNZQF/ONLINELOG/group_24.282.955022759' to '/oradata/fast_recovery_area/CTCNZQF/redo32';

完成了~启动数据库

RMAN> alter database open resetlogs;

是要打开数据时，重置重做日志，即将重做日志的sequence置零

SQl>create spfile from pfile;       创建spfile文件。

然后发现alter日志里面一大串报错·······吓了一大跳，发下是临时表空间，

因为恢复的时候没有临时文件，所以现在数据库没有临时表空间，重建~~
因为控制文件记录说已经存在了temp表空间，所以创建temp1临时表空间，设置temp1为默认，然后删除temp，再重新创建TEMP。设置为默认删除temp
创建temp1表空间

CREATE TEMPORARY TABLESPACE TEMP1 TEMPFILE '/oradata/CTCNZQF/temp01.dbf' SIZE 1024 m
,'/oradata/CTCNZQF/temp02.dbf' SIZE 1024 m,'/oradata/CTCNZQF/temp03.dbf' SIZE 1024 m
AUTOEXTEND ON NEXT 10 m MAXSIZE UNLIMITED;

---修改临时表空间为TEMP1

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP1；

删除TEMP表空间，

DROP TABLESPACE temp1 INCLUDING CONTENTS AND DATAFILES;

创建TEMP表空间：

CREATE TEMPORARY TABLESPACE TEMP1 TEMPFILE '/oradata/CTCNZQF/temp01.dbf' SIZE 1024 m
,'/oradata/CTCNZQF/temp02.dbf' SIZE 1024 m,'/oradata/CTCNZQF/temp03.dbf' SIZE 1024 m
AUTOEXTEND ON NEXT 10 m MAXSIZE UNLIMITED;

修改临时表空间为TEMP

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP；

删除TEMP1表空间就可以了

ok历经了两天终于完成了。restore这一步骤就用了10个小时
如果有1节点的数据泵备份，我就可以单独恢复一个schema，也不用折腾了两天了。
所以最最最最最最重要的还是备份更更更更重要的是检查备份状态

剩下的就是让开发人员自己去整理数据了~(*￣︶￣)