索引坏块引起的ORA-600错误，及解决办法

 

首先介绍引起

ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []的六大原因

 

Lost writes

Parallel DML issues

Index corruption

Data block corruption

Consistent read [CR] issues

Buffer cache corruption

==============================================================================================

 

实际中遇到的问题

 

发现alert文件报600错误

Thu Aug 04 17:17:56 2011

Errors in file /u01/app/oracle/orcl/trace/download_ora_24012.trc (incident=9961):

ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []

Incident details in: /u01/app/oracle/orcl/download/incident/incdir_9961/download_ora_24012_i9961.trc

去metalink上搜索这个问题的解决办法，越来越发现metalink真是个好平台，里面的资料很全很好用。

在285586.1中的Causes and Solutions for ora-600 [kdsgrp1] [ID 1332252.1] 这个文档中，对引起ORA-00600: internal error code, arguments: [kdsgrp1], [], [], [], [], [], [], []错误的不同情况进行了解释及解决问题引导。

下面是详细步骤

1.查看trace文件中是否有这种报错

----- Current SQL Statement for this session (sql_id=9mamr7xn4wg7x) -----

如果有，基本可以判断是索引中有坏块引起的ORA-600错误

2.继续定位错误，metalink提示看trace文件中的‘Plan Table’,通过查看SQL语句的执行计划，确定执行计划用到了哪些索引

Searching the trace file for the text string 'Plan Table' will locate the SQL execution plan that is dumped within this trace file.

 

3.分析用到的索引（如果用到多个索引，那么要依次进行分析）

下面是metalink提示使用的命令，个人觉得是错误的，因为以online模式分析，在index_stats视图中不记录索引的坏块信息。

SQL> analyze index scott.pk_dept validate structure online;

online和offline的资料在这里

validate structure有两种模式： online, offline， 默认是offline模式。

以offline模式分析时， 会对表加一個4级别的锁（表共享锁），对运行中的系统可能造成一定的影响。

而online模式没有表lock的影响，但当以online模式分析时， 在视图index_stats没有统计信息。

最后要在index_stats视图查找存在坏块的索引，所以要用offline模式来分析索引

应该执行这个语句去分析

SQL> analyze index scott.pk_dept validate structure offline;

如果存在多个索引，那么索引都要分析！

4.查看视图index_stats，确定坏块在哪个索引中

注意：如果ratio的值大于20%,那么索引就可以重建了，

SELECT name,height,lf_rows,del_lf_rows,(del_lf_rows/lf_rows)*100 as ratio FROM INDEX_STATS;

NAME      HEIGHT       LF_ROWS    DEL_LF_ROW  RATIO

------- ------------  ---------- ---------- ----------
pk_dept    1             235       74        31.4893617

5.重建索引

alter index scott.pk_dept rebuild;

6.验证是否还有坏块

 

SELECT name,height,lf_rows,del_lf_rows,(del_lf_rows/lf_rows)*100 as ratio FROM INDEX_STATS;



NAME      HEIGHT      LF_ROWS     DEL_LF_ROW RATIO


------- ------------ ---------- ---------- ----------

pk_dept      1           235       0           0

ratio已经为0，表示没有坏块了。

 

经过几天观察，没有索引坏块报警了，问题解决！！