如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：[email protected]
尝试强制打开数据的步骤：
1）在数据库关闭的时候备份数据库
如果在进行后续操作之前 ，你没备份的话，可能会由于其他操作而丢失数据库。
2）如果你的数据文件是不同时间点的，你最好使用和最老数据文件相近时间错的system表空间数据文件。这个会减少在开库节点bootstrap节点出现错误的机会。
3）编辑你的*init<sid>.ora文件来变更undo_management和增加2个参数：
•将undo_management=auto改变到undo_management=manual
•移除或注释掉 undo_tablespace 和undo_retention
•增加_allow_resetlogs_corruption=true,_corrupted_rollback_segments=(由逗号组成的自动undo端的列表)
例如：
_corrupted_rollback_segments=(SYSSMU1$,SYSMU2$, SYSMU3$, SYSMU4$, SYSMU5$, SYSMU6$, SYSMU7$ SYSMU8$, SYSMU9$, SYSMU10$)
注意：在alert.log中会告诉你 哪些自动undo段被使用。使用SYSS搜索。如果alter.log中没找到。格式是_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 | awk -F “$” ‘{print $1″$”}’ | 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 using backup controlfile until 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中。
note 5524381.1 how to adjust the SCN using parameter _minimum_giga_scn
note 74903.1（internal） how to force to database open
Leave a Reply