无备份如何利用RMAN恢复Oracle数据库详解

在这里我们将介绍Oracle下利用RMAN恢复数据库的相关操作，数据库频道向您推荐《Oracle 11g新特性与应用详解》。

成都创新互联公司长期为成百上千家客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为永福企业提供专业的网站制作、成都网站制作，永福网站改版等技术服务。拥有十多年丰富建站经验和众多成功案例,为您定制开发。

数据文件丢失, 没有备份, 拥有文件创建以来的全部归档,使用RMAN恢复, 报错RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 726 scn 1757142927; 使用sqlplus恢复, 执行 'Alter Database recover datafile ' Fails with ORA-279

总结: RMAN备份没有使用catalog, controlfile默认保留7天的备份/归档信息,v$archived_log没有记录足够多的归档信息, 所以报RMAN-06102, 需要通过CATALOG命令注册.

SQLPLUS 执行 'Alter Database recover datafile ' Fails with ORA-279 因为9.2.0.6版本使用这个命令不能自动执行recover. 用户版本9.2.0.1也遇到同样的问题, 使用RECOVER DATAFILE即可.
处理步骤:

1. 生成controlfile 备份到文本ora9roro_ora_479268.trc

2. 查询该文件创建时间为Feb 21 11:10:24 2006 (查询alert.log)

 
 
 
    
  
  
  
  1. Tue Feb 21 11:10:24 2006  
    2.   
  
  
  2. CREATE TABLESPACE tzgl DATAFILE 'tzgl' SIZE 100M  
    3.   
  
  
  3. Tue Feb 21 11:10:29 2006  
    4.   
  
  
  4. Completed: CREATE TABLESPACE tzgl DATAFILE 'tzgl' SIZE 100M  
    5.   
  
  
  5. Tue Feb 21 21:58:23 2006  
    6.   
  
  
  6. Thread 1 advanced to log sequence 277  
    7.   
  
  
  7. Current log# 3 seq# 277 mem# 0: /oradata/ora9roro/redo03.log  
    8.   
  
  
  8. Tue Feb 21 21:58:23 2006 
    9.

3. 用户说没有备份(没有确实检查是否有备份),创建空文件,因为有全部的归档文件存在,考虑建空文件, 使用归档文件恢复.

 
 
 
    
  
  
  
  1. alter database create datafile '/oracle/product/9.2.0/dbs/tzgl' as '/oracle/product/9.2.0/dbs/tzgl'; 
    2.

或者就写alter database create datafile 12 as '/oracle/product/9.2.0/dbs/tzgl';
该文件file#=12.

4.rman target /

 
 
 
    
  
  
  
  1. rman> recover datafile 12; 失败  
    2.   
  
  
  2. archive log thread 1 sequence 1116 is already on disk as file /oradata/ora9roro/archive/1_1116.dbf  
    3.   
  
  
  3. archive log thread 1 sequence 1117 is already on disk as file /oradata/ora9roro/archive/1_1117.dbf  
    4.   
  
  
  4. archive log thread 1 sequence 1118 is already on disk as file /oradata/ora9roro/archive/1_1118.dbf  
    5.   
  
  
  5. ...  
    6.   
  
  
  6. RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 728 scn 1757357012  
    7.   
  
  
  7. RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 727 scn 1757357009  
    8.   
  
  
  8. RMAN-06102: no channel to restore a backup or copy of log thread 1 seq 726 scn 1757142927 
    9.

5. 检查归档文件是否存在, 发现从1_1.dbf直到现在, 所有的ARCHIVELOGS都存在.但RMAN-06102错误信息表明controlfile并没有记录下所有的归档信息.查看参数control_file_record_keep_time 为默认值7. 所以只保留7天的备份信息.

调整control_file_record_keep_time=365以保证以后的备份可以保留更长的时间.

6. 企图注册归档文件到controlfile. 但不支持, 只针对standby controlfile.

 
 
 
    
  
  
  
  1. alter database register logfile '/oradata/ora9roro/archive/1_726.dbf';  
    2.   
  
  
  2. ERROR at line 1:  
    3.   
  
  
  3. ORA-01665: controlfile is not a standby controlfile 
    4.

7. 尝试通过sqlplus 恢复, 也失败. ---但这里并没有查看原因, 想当然认为rman恢复不行,sqlplus 执行也不行. 在step 16找到了原因.

 
 
 
    
  
  
  
  1. SQL> conn / as sysdba  
    2.   
  
  
  2. Connected.  
    3.   
  
  
  3. SQL> alter database recover datafile 12;  
    4.   
  
  
  4. alter database recover datafile 12  
    5.   
  
  
  5. *  
    6.   
  
  
  6. ERROR at line 1:  
    7.   
  
  
  7. ORA-00279: change 1181419363 generated at 02/21/2006 11:10:29 needed for thread  
    8.   
  
  
  8. 1  
    9.   
  
  
  9. ORA-00289: suggestion : /oradata/ora9roro/archive/1_276.dbf  
    10.   
  
  
  10. ORA-00280: change 1181419363 for thread 1 is in sequence #276 
    11.

8. 验证问题是否出在归档文件, 尝试移动/oradata/ora9roro/archive/1_276.dbf到其他目录, 然后进行恢复alter database recover datafile 12;

错误同上.所以, 不是归档文件本身故障的问题. 继续查无法读取归档文件的原因.

9. 查看是否重建过controlfile或open resetlogs操作.

从2006年2月21日开始，有没有做过重建controlfile或open resetlogs之类的操作？

 
 
 
    
  
  
  
  1. select RESETLOGS_TIME from v$database;  
    2.   
  
  
  2. RESETLOGS  
    3.   
  
  
  3. --------- 
    4.

16-APR-05

结果表示, 没有resetlog过, 也没有重建过controlfile

10.查看v$bakcup_piece, v$backup_datafile发现有记录, 是2006年12月29日的备份记录,备份到带库.

原来并非像用户所说没有备份

root身份查看
#crontab -l找到备份,每天执行,可是查看/tmp/bkdb_$dt.log文件, 最后一次成功备份是bkdb_200612250100.log

 
 
 
    
  
  
  
  1. 0 1 * * * /usr/tivoli/tsm/client/oracle/orabackup.sh >/dev/null#  
    2.   
  
  
  2. # cat /usr/tivoli/tsm/client/oracle/orabackup.sh  
    3.   
  
  
  3. export dt=`date +%Y%m%d%H%M`  
    4.   
  
  
  4. su - oracle -c "rman target / nocatalog cmdfile /oracle/sched/bkdb.scr msglog /tmp/bkdb_$dt.log"  
    5.   
  
  
  5.  
    6.   
  
  
  6. /oracle/sched/bkdb.scr备份脚本内容: bkdb_200612290100.log  
    7.   
  
  
  7. RUN{  
    8.   
  
  
  8. ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' parms =  
    9.   
  
  
  9. 'ENV=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';  
    10.   
  
  
  10. BACKUP  
    11.   
  
  
  11. FORMAT 'df_T%T_s%s_p%p_t%t'  
    12.   
  
  
  12. FILESPERSET 2  
    13.   
  
  
  13. DATABASE;  
    14.   
  
  
  14. RELEASE CHANNEL ch00;  
    15.   
  
  
  15. } 
    16.

11. 尝试恢复:

 
 
 
    
  
  
  
  1. RMAN> RUN{  
    2.   
  
  
  2. ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE' parms =  
    3.   
  
  
  3. 'EN2> 3> V=(TDPO_OPTFILE=/usr/tivoli/tsm/client/oracle/bin64/tdpo.opt)';  
    4.   
  
  
  4. 4> restore datafile 12;  
    5.   
  
  
  5. 5> release channel ch00  
    6.   
  
  
  6. 6> ;  
    7.   
  
  
  7. 7> }  
    8.   
  
  
  8.  
    9.   
  
  
  9. using target database controlfile instead of recovery catalog  
    10.   
  
  
  10. allocated channel: ch00  
    11.   
  
  
  11. channel ch00: sid=11 devtype=SBT_TAPE 
    12.   
  
  
  12. channel ch00: Tivoli Data Protection for Oracle: version 5.2.0.0  
    13.   
  
  
  13.  
    14.   
  
  
  14. Starting restore at 07-APR-08  
    15.   
  
  
  15.  
    16.   
  
  
  16. channel ch00: starting datafile backupset restore  
    17.   
  
  
  17. channel ch00: specifying datafile(s) to restore from backup set  
    18.   
  
  
  18. restoring datafile 00012 to /oracle/product/9.2.0/dbs/tzgl  
    19.   
  
  
  19. released channel: ch00  
    20.   
  
  
  20. RMAN-00571: ===========================================================  
    21.   
  
  
  21. RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============  
    22.   
  
  
  22. RMAN-00571: ===========================================================  
    23.   
  
  
  23. RMAN-03002: failure of restore command at 04/07/2008 14:20:09  
    24.   
  
  
  24. ORA-19501: read error on file "df_T20061229_s2660_p1_t610419667", blockno 1 (blocksize=512)  
    25.   
  
  
  25. ORA-27190: skgfrd: sbtread2 returned error  
    26.   
  
  
  26. ORA-19511: Error received from media manager layer, error text:  
    27.   
  
  
  27. ANS1314E (RC14) File data currently unavailable on server 
    28.

12. 带库有问题, 或者数据已经被覆写. 所以, 不再考虑使用备份做恢复.

13. 查看v$recover_file, v$recovery_log, v$log_history,看系统状态,信息存储在recover.lst中

 
 
 
    
  
  
  
  1. set pagesize 20000  
    2.   
  
  
  2. set linesize 180  
    3.   
  
  
  3. set pause off  
    4.   
  
  
  4. set serveroutput on  
    5.   
  
  
  5. set feedback on  
    6.   
  
  
  6. set echo on  
    7.   
  
  
  7. set numformat 999999999999999  
    8.   
  
  
  8. Spool recover.lst  
    9.   
  
  
  9. select substr(name, 1, 50), status from v$datafile;  
    10.   
  
  
  10. select file#,substr(name,1,50), recover, fuzzy, to_char(checkpoint_time,'dd/mm/yyyy:hh24:mi:ss') ckpt_time, checkpo  
    11.   
  
  
  11. int_change#, resetlogs_change#, to_char(resetlogs_time,'dd/mm/yyyy HH24:MI:SS')  
    12.   
  
  
  12. tm from v$datafile_header;  
    13.   
  
  
  13. select * from v$backup;  
    14.   
  
  
  14. select name, open_mode, checkpoint_change#, ARCHIVE_CHANGE# from v$database;  
    15.   
  
  
  15. select GROUP#,THREAD#,SEQUENCE#,MEMBERS,ARCHIVED,STATUS,FIRST_CHANGE# from v$log;  
    16.   
  
  
  16. select GROUP#,substr(member,1,60) from v$logfile;  
    17.   
  
  
  17. select * from v$log_history;  
    18.   
  
  
  18. select * from v$recover_file;  
    19.   
  
  
  19. select * from v$recovery_log;  
    20.   
  
  
  20. select HXFIL File_num,substr(HXFNM,1,40) File_name,FHTYP Type,HXERR Validity,  
    21.   
  
  
  21. FHSCN SCN, FHTNM TABLESPACE_NAME,FHSTA status ,FHRBA_SEQ Sequence   
    22.   
  
  
  22. from X$KCVFH;  
    23.   
  
  
  23. spool off 
    24.

14恢复方案:

 
 
 
    
  
  
  
  1. 1. alter database create datafile 12 as '/oracle/product/9.2.0/dbs/tzgl'; ----ÒѾ­×öÁËin step3  
    2.   
  
  
  2. 2. recover datafile 12;  
    3.   
  
  
  3. 3. now start applying archives from the time of creation of datafile.  
    4.   
  
  
  4. 4. once the archives are applied and redo logs are applied, you can issue the command, "alter database open". 
    5.

15. 注册归档文件到controlfile (和catalog db 可选)

 
 
 
    
  
  
  
  1. rman target /  
    2.   
  
  
  2. RMAN> list archivelog all; --[1_1116.dbf, 1_1164.dbf]  
    3.   
  
  
  3. RMAN> CATALOG ARCHIVELOG '/oradata/ora9roro/archive/1_1.dbf'; ---添加到v$archived_log  
    4.   
  
  
  4. RMAN> list archivelog all; --多显示1_1.dbf记录  
    5.   
  
  
  5. Key Thrd Seq S Low Time Name  
    6.   
  
  
  6. ------- ---- ------- - --------- ----  
    7.   
  
  
  7. 1165 1 1 A 16-APR-05 /oradata/ora9roro/archive/1_1.dbf 
    8.

16. 在step7中登陆sqlplus恢复失败, 查原因:

 
 
 
    
  
  
  
  1. metalink<352617.1> 'Alter Database recover datafile ' Fails with ORA-279  
    2.   
  
  
  2. Noticable difference between 9.2.0.6 and other versions is that the "recover datafile" syntax does not auotmatically   
    3.   
  
  
  3. perform auto recover, Oracle prompts for each log. On other versions this is not the case.  
    4.   
  
  
  4. This is reported as Bug: 4178579 - ALTER DATABASE RECOVER DATAFILE IS BROKEN IN 9.2.0.6 
    5.

解决方法:

 
 
 
    
  
  
  
  1. Use different syntax:  
    2.   
  
  
  2. recover datafile x   
    3.   
  
  
  3. recover automatic datafile x  
    4.   
  
  
  4. alter database recover automatic datafile x  
    5.

或者打补丁:Apply 9.2.0.7.0 patchset
不过, 在网上看到有人在10.2.0.2也遇到这样的问题。

标题名称：无备份如何利用RMAN恢复Oracle数据库详解
链接URL：http://www.gawzjz.com/qtweb2/news19/2169.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

自适应网站知识

同城分类信息

西部信息机房　　 　LOGO设计　　 　虚拟主机　　 　内江托管服务器　　 　犀浦封阳台　　 　八点广告　　 　成都网站推广　　 　网络营销推广　　 　外贸营销网站建设　　 　一带一路　　 　营销型网站建设　　 　成都茶叶销售　　 　java虚拟主机　　 　乐至网站建设　　 　成都帛金建站　　 　做网站公司　　 　格蓝特设备　　 　郫县网站建设　　 　成都网站制作　　 　泸州网站建设