oracle数据库遇到ora-00600[6711]错误 数据库打不开怎么办

oracle数据库遇到ora-00600[6711]错误 数据库打不开怎么办,第1张

ORA-00600: internal error code, arguments: [6711], [4256248], [1], [4256242], [0], [], [], []

SMON_SCN_TO_TIME是SMON_SCN_TIME表的基簇,SMON_SCN_TIME表用以记录数据库中scn对应的时间戳。

问题出在SMON_SCN_TO_TIME的索引smon_scn_to_time_idx身上,极有可能是该索引上出现了逻辑讹误。

如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!

套Power AIX上的9.2.0.1系统在数据库打开过程中遇到ORA-00600:[2667]内部错误,详细日志如下:

Wed Mar 9 19:03:38 2011

RESETLOGS is being done without consistancy checks. This may result

in a corrupted database. The database should be recreated.

RESETLOGS after incomplete recovery UNTIL CHANGE 117699122479

Resetting resetlogs activation ID 2197911857 (0x83017931)

Wed Mar 9 19:03:47 2011

LGWR: Primary database is in CLUSTER CONSISTENT mode

Assigning activation ID 2284878888 (0x88307c28)

Thread 1 opened at log sequence 1

Current log# 3 seq# 1 mem# 0: /s01/maclean/oradata/PROD/redo03.log

Successful open of redo thread 1.

Wed Mar 9 19:03:47 2011

SMON: enabling cache recovery

Wed Mar 9 19:03:47 2011

Errors in file /s01/maclean/admin/PROD/udump/PROD_ora_585914.trc:

ORA-07445: exception encountered: core dump [] [] [] [] [] []

Wed Mar 9 19:03:48 2011

Errors in file /s01/maclean/admin/PROD/bdump/PROD_pmon_602286.trc:

ORA-07445: exception encountered: core dump [] [] [] [] [] []

Wed Mar 9 19:03:50 2011

Errors in file /s01/maclean/admin/PROD/bdump/PROD_lgwr_548884.trc:

ORA-00600: internal error code, arguments: [2667], [1], [1], [3], [1739273391], [1739273391], [1739273391], [7267]

LGWR: terminating instance due to error 600

相关的初始化参数

fast_start_mttr_target = 300

_allow_resetlogs_corruption= TRUE

undo_management = AUTO

undo_tablespace = UNDOTBS1

以上可以看到lgwr关键进程在数据库open后几秒后遭遇了ORA-00600:[2667]内部错误后终止了实例。

该数据库在之前因为丢失当前日志文件进行了已经实施了一系列的非常规恢复 *** 作,包括设置一系列的underscore参数:

Before I provide the steps to fix the ora-00600 error, I want to tell you that this database is opened with the unsupported parameter

"allow_resetlogs_corruption".

*************************************************************************

* By forcing open the database using this parameter, there is a strong *

* likelihood of logical corruption, possibly affecting the data *

* dictionary. Oracle does not guarantee that all of the data will be *

* accessible nor will it support a database that has been opened by *

* this method and that the database users will be allowed to continue *

* work. All this does is provide a way to get at the contents of the *

* database for extraction, usually by export. It is up to you to *

* determine the amount of lost data and to correct any logical *

* corruption issues. *

* *

*************************************************************************

2) The steps to get rid of the ora-00600 are as follows:

+ Change UNDO_MANAGEMENT=AUTO to

UNDO_MANAGEMENT=MANUAL

+ Remove or comment out UNDO_TABLESPACE and UNDO_RETENTION.

+ Add

_CORRUPTED_ROLLBACK_SEGMENTS =(comma separated list of Automatic Undo segments)

Example:

_CORRUPTED_ROLLBACK_SEGMENTS = (_SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$,

_SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$)

Note, sometimes the alert log will tell you what Automatic Undo segments are in use. 

Search the alert log for SYSS. If the alert log does not contain that information then use _SYSSMU1$ 

through _SYSSMU10$ as shown in the example above.

In UNIX you can issue this command to get the undo segment names:

$ strings system01.dbf | grep _SYSSMU | cut -d $ -f 1 | sort -u

From the output of the strings command above, add a $ to end of each _SYSSMU undo segment name.

++ Startup mount the database as follows:

SQL > startup mount

SQL > recover database

SQl > alter database open

*._corrupted_rollback_segments= (_SYSSMU730$, _SYSSMU731$, _SYSSMU732$, _SYSSMU733$, _SYSSMU734$, 

_SYSSMU735$, _SYSSMU736$, _SYSSMU737$, _SYSSMU738$, _SYSSMU739$, _SYSSMU744$, _SYSSMU740$, _SYSSMU741$, 

_SYSSMU742$, _SYSSMU743$, _SYSSMU744$, _SYSSMU745$, _SYSSMU746$, _SYSSMU747$, _SYSSMU748$, _SYSSMU749$, _SYSSMU74t$, 

_SYSSMU75$, _SYSSMU750$, _SYSSMU751$, _SYSSMU752$, _SYSSMU753$, _SYSSMU754$, _SYSSMU755$, _SYSSMU756$, _SYSSMU757$, 

_SYSSMU758$, _SYSSMU759$, _SYSSMU76$, _SYSSMU760$, _SYSSMU761$, _SYSSMU762$, _SYSSMU763$, _SYSSMU764$, _SYSSMU765$, 

_SYSSMU766$, _SYSSMU767$, _SYSSMU768$)

如果自己搞不定可以找ASKMACLEAN专业ORACLE数据库修复团队成员帮您恢复!


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/sjk/9624865.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-30
下一篇 2023-04-30

发表评论

登录后才能评论

评论列表(0条)

保存