如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
Oracle force open强制打开数据库的步骤:
1)在数据库关闭的时候备份数据库
如果在进行后续操作之前 ,你没备份的话,可能会由于其他操作而丢失数据库。
2)如果你的数据文件是不同时间点的,你最好使用和最老数据文件相近时间错的system表空间数据文件。这个会减少在开库节点bootstrap节点出现错误的机会。
3)编辑你的*init<sid>.ora文件来变更undo_management和增加2个参数:
- 将undo_management=auto改变到undo_management=manual
- 移除或注释掉 undo_tablespace 和undo_retention
- 增加_allow_resetlogs_corrution=true,_corrupted_rollback_segments=(由逗号组成的自动undo端的列表)
例如:
_corrupted_rollback_segments=(SYSSMU1$,SYSMU2$, SYSMU3$, SYSMU4$, SYSMU5$, SYSMU6$, SYSMU7$ SYSMU8$, SYSMU9$, SYSMU10$)
注意:在alert.log中会告诉你 哪些自动undo、端被使用。使用SYSS搜索。如果alter.log中没找到。在11g之前undo段的名称和上面例子有些不同,格式是_SYSMU_$,例如:
_SYSSMU1_3423929671$
_SYSSMU2_3471197032$
_SYSSMU3_1940572779$
_SYSSMU4_703930491$
_SYSSMU5_2293911943$
_SYSSMU6_2782670761$
_SYSSMU7_3176421677$
_SYSSMU8_1585569843$
_SYSSMU9_1242704454$
_SYSSMU10_777531512$
在UNIX中,你可以使用下列命令来得到undo段的名称:
strings system01.dbf|grep _SYSSMU | cut -d $ -f1 |sort -u
在得到输出后,每个字符串中加上$
•如果你有可用的参数文件,你可以创建一个pfile:
create pfile from spfile;
不要修改spfile
4)在SQL*PLUS中,startup mount,检查是否使用了正确的参数文件,所有的数据文件是online或system状态
show parameter corrupt
show parameter undo
select name,file#,status from v$datafile where status not in(‘ONLINE’,’SYSTEM’,);
如果有任何行返回的话,使用下面用来将文件在线:
alter database datafile file# online;
如果有文件在你试图online的时候状态变更为reover,那么继续进行步骤5.
5)
进行一个虚假的不完全恢复,并使用resetlogs打开数据库。
recover database until cancel;
或者
recover database usibg backup controlfile until cancel
当出现执行归档类型cancel,然后按回车
alter database open resetlogs;
6)如果数据库open,试图查询表,例如:
select sysdata from dual;
如果正常返回了行,那么可以查询其他表来确定数据库是足够正常的来执行导出。
当数据库打开了,你应该立即进行数据库导出。一旦你导出了数据库,可以从幸存的地方重建。这意味着删除所有数据文件和创建一个新的数据库。
已这种方式打开,但是不重建是不被Oracle支持的。任何延时的导出文件或任何试图使用system会导致无法挽回的损害。
注意:确认在init.ora中移除在步骤3中增加的参数。否则你使用这个init
.ora创建新的数据库可能会受到意外的损坏。
7)如果在步骤5open 的时候,实例崩溃了,检查trace文件。如果有trace文件,检查里面是否有ORA-00600[2662]或ORA-00600[4000]。这些错误也可能会在alert.log中。
Comment