成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

無備份 如何利用RMAN恢復Oracle數據庫詳解

作者：悠閑的魚
數據庫 Oracle 數據庫運維
當Oracle數據庫崩潰后發現沒有備份，是更令人崩潰的事情。本文將為大家介紹的是利用RMAN恢復Oracle數據庫。

在這里我們將介紹Oracle下利用RMAN恢復數據庫的相關操作，51CTO數據庫頻道向您推薦《Oracle 11g新特性與應用詳解》。

數據文件丟失, 沒有備份, 擁有文件創建以來的全部歸檔,使用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. CREATE TABLESPACE tzgl DATAFILE 'tzgl' SIZE 100M  
  3. Tue Feb 21 11:10:29 2006  
  4. Completed: CREATE TABLESPACE tzgl DATAFILE 'tzgl' SIZE 100M  
  5. Tue Feb 21 21:58:23 2006  
  6. Thread 1 advanced to log sequence 277  
  7. Current log# 3 seq# 277 mem# 0: /oradata/ora9roro/redo03.log  
  8. Tue Feb 21 21:58:23 2006 

3. 用戶說沒有備份(沒有確實檢查是否有備份),創建空文件,因為有全部的歸檔文件存在,考慮建空文件, 使用歸檔文件恢復.

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

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

4.rman target /
 

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

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. ERROR at line 1:  
  3. ORA-01665: controlfile is not a standby controlfile 

7. 嘗試通過sqlplus 恢復, 也失敗. ---但這里并沒有查看原因, 想當然認為rman恢復不行,sqlplus 執行也不行. 在step 16找到了原因.

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

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. RESETLOGS  
  3. --------- 

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

11. 嘗試恢復:

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

12. 帶庫有問題, 或者數據已經被覆寫. 所以, 不再考慮使用備份做恢復.

13. 查看v$recover_file, v$recovery_log, v$log_history,看系統狀態,信息存儲在recover.lst中

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

14恢復方案:

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

15. 注冊歸檔文件到controlfile (和catalog db 可選)
 

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

16. 在step7中登陸sqlplus恢復失敗, 查原因:

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


解決方法:

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


或者打補丁:Apply 9.2.0.7.0 patchset
不過, 在網上看到有人在10.2.0.2也遇到這樣的問題。

【編輯推薦】

  1. Oracle 11g R2恢復管理器RMAN的增強
  2. Oracle 11g 新特性- RMAN
  3. Oracle 恢復管理器 (RMAN) 的功能
  4. 深入Oracle 11g分區功能
  5. Oracle 11g R2中新特性一覽
責任編輯：彭凡 來源： ITPUB
RMANOracle
相關推薦

2011-08-23 11:09:36

Oraclerman恢復system表空間恢復

2011-08-29 16:41:14

OracleRMAN恢復數據文件的恢復

2011-04-11 13:46:17

Oracle數據庫備份

2011-08-15 23:14:34

Oraclerman環境配置

2009-04-03 10:54:49

Oracle備份恢復

2011-05-17 15:02:15

ORACLE數據庫備份

2011-08-30 09:35:10

OracleRMAN不完全恢復基于時間恢復

2011-08-30 09:50:22

OracleRMAN不完全恢復基于SCN恢復

2009-10-13 09:43:43

Oracle數據庫備份

2010-04-12 10:40:49

Oracle數據庫

2011-07-26 13:55:01

MongoDB備份與恢復

2009-11-20 14:08:39

Oracle數據庫備份

2011-08-29 17:00:47

Oracle數據庫RM表空間數據塊介質

2017-06-06 08:10:00

Oracle

2010-04-12 14:19:00

Oracle數據庫備份

2011-05-20 09:35:24

Oracle數據庫恢復備份

2009-03-17 16:00:47

Oracle數據庫備份

2009-04-17 11:28:16

Oracle備份恢復

2010-04-13 11:09:21

Oracle數據庫

2011-03-04 14:39:03

MySQL數據庫mysqldump
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板： 亚洲日本激情 | 日日操夜夜干 | 日本一区二区三区精品视频 | 女同videos另类 | 亚洲自拍偷拍欧美 | 在线三级电影 | 超碰在线播| 电影午夜精品一区二区三区 | 日韩一区二区在线视频 | 精品日韩在线 | 色综合成人网 | 黄色大片免费网站 | 天堂中文字幕av | 国产精品亚洲综合 | 亚洲国产精品一区二区第一页 | 日韩亚洲一区二区 | 欧美一级黄色免费看 | 国产精品区一区二 | 亚洲精品一区二区三区丝袜 | 久视频在线 | 国产精品欧美一区二区三区不卡 | 91国内精精品久久久久久婷婷 | 久久久av中文字幕 | 国产精品免费观看 | 国产高清一区二区三区 | 久久亚洲一区二区 | 日日日日操 | 国产精品久久久久国产a级 欧美日韩国产免费 | 国产99久久久国产精品 | 久久久久久久久久久久久久国产 | 欧美精品一区久久 | 午夜影院在线免费观看视频 | 一本大道久久a久久精二百 欧洲一区二区三区 | 日韩在线观看 | 91精品久久久久久久久中文字幕 | 成人超碰在线 | 黄色三级在线播放 | 欧美性网| 狠狠躁18三区二区一区 | 欧美在线视频一区二区 | 久久精品色欧美aⅴ一区二区 |