ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 修改noarchivelog模式遇到的问题

修改noarchivelog模式遇到的问题

原创 Linux操作系统 作者:wengtf 时间:2011-04-08 16:08:41 0 删除 编辑
之前增加数据文件什么的操作基本已经忘光光,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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-04-07

  • 博文量
    62
  • 访问量
    196683