修改noarchivelog模式遇到的問題

wengtf發表於2011-04-08
之前增加資料檔案什麼的操作基本已經忘光光,N久了,肯定記不住咯o(╯□╰)o進入正題:
今天:2010-11-20,想在測試庫上切回到noarchivelog模式,出現:
ORA-01143: cannot disable media recovery - file 9 needs media recovery
ORA-01110: data file 9: '/oradata/testing.dbf'
ok,看到這個報錯,首先想到這個資料庫是啥狀態對吧,查一把:
====================================================================
select * from v$recover_file;
---OFFLINE狀態,ok基本上知道咋回事了
無敵的g了一把,2種方法:
1、既然提示要恢復暫就恢復吧,recover datafile 9;

SQL> recover datafiel 9;
ORA-00905: missing keyword

SQL> recover datafile 9;
ORA-00279: change 1891645 generated at 12/08/2010 16:35:11 needed for thread 1
ORA-00289: suggestion : /oracle/archivelog/1_68_734599521.dbf
ORA-00280: change 1891645 for thread 1 is in sequence #68

Specify log: {=suggested | filename | AUTO | CANCEL}
auto---讓他自動匹配歸檔檔案,我換過歸檔路徑,失敗原因沒找到,%>_
ORA-00308: cannot open archived log '/oracle/archivelog/1_68_734599521.dbf'
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3

得靠第二招了:
=====================================================================
2、直接將這個資料庫offilie drop掉,如下:
SQL> alter database datafile '/tmp/testing.dbf' offline drop;
Database altered.

SQL> startup mount force
ORACLE instance started.
Total System Global Area 1174405120 bytes
Fixed Size                  1219040 bytes
Variable Size             301991456 bytes
Database Buffers          855638016 bytes
Redo Buffers               15556608 bytes
Database mounted.
SQL> alter database noarchivelog;
Database altered.
OK,over。

補充下:當發生前面archive log (ORA-19815:flash_recovery_area---該問題見前面日誌)日誌已滿時候,如果急於清理歸檔日誌,就會出現解決方法的第一種情況,無法恢復
 
datafile offline drop與offline的區別
====================================================================
歸檔模式下是沒有區別的,非歸檔模式必須用offline drop。
alter database datafile ‘xxx’ offline drop 方法將某個datafile 刪除 ,
這個時候發現在dba_data_files中錯誤的表空間下還記錄著加錯的檔案清單,只是其中bytes,blocks,maxbytes是null,status是有效狀態。
簡單的對datafile的offline drop會在v$datafile及v$recover_file中留下資訊的,目的是為了恢復用(在dba_data_files裡面status為 recover即如此)。
這些資訊只有在drop tablespace時才會被清除掉,修改uet$,fet$等基表這樣的手法是非常非常不提倡的。
這樣的資訊存在著是不會影響表空間正常使用的,留著也無妨。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/22907091/viewspace-691962/,如需轉載,請註明出處,否則將追究法律責任。

相關文章