oracle 索引修复 Oracle索引重建

本文介绍了在Oracle数据库中遇到索引坏块时的修复方法,包括如何通过ORA-1578、DBVERIFY、RMAN和ORA-600 [6200]错误定位坏块,以及如何重建损坏的索引。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

当数据库出现坏块而坏块所涉及对象为索引时,我们一般进行修复索引的方法是重建索引。
相对其它坏块,索引坏块修复起来最容易的。不过在修复前,我们需要确认这个坏块确实来自于某索引。

因此,这里我们会介绍一些块定位方法:

1. 如何在ORA-1578/RMAN/DBVERIFY的日志记录中确认讹误受损对象

首先需要确认绝对文件号(Absolute File Number: AFN)和块号(Block Number: BL)
 
绝对文件号(AFN)和相对文件号(RFN)经常相同,但也有时候不同。特别当:

  • 数据库是从Oracle7迁移而来
  • 或是使用了可传输表空间(Transportable/Plugged Tablespace)时
  • 或是配置的12c多租户
  • 或使用的bigfile表空间

提示的编号总是相对文件号(RFN)。

因此获取正确的AFN和RFN并分清含义可以节约你判断问题和定位的时间。


从ORA-1578报错中找到AFN

这里AFN是由ORA-1110报错提供的,并紧跟在ORA-1578之后。在下面例子中AFN为5,BL为34。

SQL> select * from scott.dept_view;
select * from scott.dept_view
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 11, block # 34)
ORA-01110: data file 5: '/home/oracle/oradata/users.dbf'

从DBVERIFY输出中找到AFN
在dbverify中坏块的定位描述会有些不同。DBVERIFY一般提供受到影响的RDBA地址。其中可以提取RFN并用于从dba_data_files表中查询到AFN。

  • 看下面例子(RFN=11 BL=34):
Page 34 is marked corrupt
Corrupt block relative dba: 0x02c00022 (file 11, block 34)
Bad check value found during dbv:
Data in bad block:
   type: 6 format: 2 rdba: 0x02c00022
   last change scn: 0x0771.4eebe71c seq: 0x2 flg: 0x04
   spare1: 0x0 spare2: 0x0 spare3: 0x0
   consistency value in tail: 0xe71c0602
   check value in block header: 0xd3ce
   computed block checksum: 0x2

Dbverify会在输出中显示相对数据块地址(rdba/dba)。上例从“Corrupt block relative dba: 0x02c00022 (file 11, block 34)”中可知rdba HEX值为0x02c00022。
这个实际上就提供了RFN和BL。当然这里之后也直接告诉你了“(file 11, block 34)”。
我们就可以从dba_data_files表中查到AFN。

  • 再看另一个例子(RFN=11 BL=35):
Dbv output:

DBV-200: Block, dba 46137379, already marked corrupted"

需要使用查询来先获取RFN和块号:

select dbms_utility.data_block_address_file(&&rdba) RFN,
       dbms_utility.data_block_address_block(&&rdba) BL
from dual;

可知:

SQL> select dbms_utility.data_block_address_file(&&rdba) RFN,
   2 dbms_utility.data_block_address_block(&&rdba) BL
   3 from dual;
Enter value for rdba: 46137379


RFN        BL
---------- ----------
11         35

通过RFN从dba_data_files获知AFN:

select file_id AFN, relative_fno, tablespace_name
from dba_data_files
where relative_fno=&RFN;

可知:

SQL> select file_id AFN, relative_fno, tablespace_name
   2 from dba_data_files
   3 where relative_fno=&RFN;
Enter value for rfn: 11

AFN        RELATIVE_FNO TABLESPACE_NAME
---------- ------------ ------------------------------
5          11           USERS

AFN是5。

从RMAN中获取AFN

在v$database_block_corruption中我们可以看到RMAN报告的讹误块信息。

FILE#列给出了AFN. BLOCK#列则是BL.


定位讹误对象
一旦我们取得了AFN,就可以用以下查询来定位讹误对象了:

select * 
from dba_extents
where file_id = &AFN
and &BL between block_id AND block_id + blocks - 1;

如:

SQL> select *
2 from dba_extents
3 where file_id = &AFN
4 and &BL between block_id AND block_id + blocks - 1;
Enter value for afn: 5
Enter value for bl: 34

OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES      BLOCKS RELATIVE_FNO
----- ------------ -------------- ------------ --------------- --------- ------- -------- ---------- ------ ------------
SCOTT DEPT                        TABLE        USERS           0         5       33       65536      8      11

如果出现上面的查询未返回行,那么可能坏块出现在本地表空间管理(Locally Managed Tablespace:LMT)下的段头上。
坏块出现在段头上,那么上面的查询不会返回结果,但是其会在alert日志中生产坏块报错信息。在这种情况下,你可以执行以下查询:

select owner, segment_name, segment_type, partition_name 
from   dba_segments
where  header_file = &AFN
  and  header_block = &BL;

如果坏块在空的EXTENT上(和某个对象无关),或者是在临时表上,上面的查询也会无返回。
对于临时表,Segment Type应该是TEMPORARY。

如果坏块在空的EXTENT上,那信息应该在DBA_FREE_SPACE上:

select * 
from  dba_free_space
where file_id = &AFN
  and &BL between block_id AND block_id + blocks - 1;

可以注意到在Oracle 10g和更高版本中的ORA-1578报错,alert日志中已经有指出讹误对象的相关信息了。如:

Corrupt Block Found
TSN = 5, TSNAME = USERS
RFN = 11, BLK = 34, RDBA = 46137378
OBJN = 46107, OBJD = 36440, OBJECT = DEPT, SUBOBJECT =
SEGMENT OWNER = SCOTT, SEGMENT TYPE = Table Segment

 

2. 如何在ORA-600 [6200] 报错中定位讹误的索引

描述:
在访问某张表时,你遇到ORA-600 [6200]报错,这个报错意味着相关索引被探测到存在讹误。
标准的解决方法是drop掉索引并为这张表重建所有相关索引。
不过,我们可以从trace文件当时生成的报错中定位哪个索引出的问题。
 
例如:

例子中显示的是从trace文件中看到的索引报错信息。

  • trace file报错信息:
  ksedmp: internal or fatal error
  ORA-00600: internal error code, arguments: [6200], [260], [262], [], [], [], [], []

  Block header dump: dba: 0x7b404757
   Object id on Block? Y
   seg/obj: 0x6190 csc: 0x00.4e537b5  itc: 2  flg: -typ: 2 - INDEX
       fsl: 0  fnx: 0x0 
  • 注意这里seg/obj指出的Hex值,我们可以将其转为十进制值,这个值就是对象id号。

    0x6190 也就是24976   Hex = 00006190  Octal = 00000060620

  • 这样我们就能在DBA_OBJECTS视图中找到索引对象了.
SVRMGR> SELECT OBJECT_ID, OBJECT_NAME FROM DBA_OBJECTS
          WHERE DATA_OBJECT_ID  = '24976';

DATA_OBJEC OBJECT_NAME                                                                 
---------- ------------------------------------------------------
     24976 tab1_index5

 这个索引就是我们应该去重建的那个。

 

重建索引语法

ALTER INDEX [schema.]index REBUILD  
     [PARAMETERS ('rebuild_params [physical_storage_params]' ) ] 
     [{ NOPARALLEL | PARALLEL [ integer ] }] ;
或

ALTER INDEX [schema.]index REBUILD ONLINE 
     [PARAMETERS ('rebuild_params [physical_storage_params]' ) ] 
     [{ NOPARALLEL | PARALLEL [ integer ] }] ;
或

ALTER INDEX [schema.]index REBUILD PARTITION partition  
     [PARAMETERS ('rebuild_params [physical_storage_params]' ) ];

需要注意的部分参数使用     
rebuild_params:

  • index_status=cleanup
    在进行online rebuild操作(ALTER INDEX REBUILD ONLINE)后,对相关表的旧版本索引(用户查询已经结束)进行清理。 

如:

ALTER INDEX [schema.]index REBUILD ONLINE PARAMETERS ('index_status=cleanup');

physical_storage_params:

  • tablespace
    指定索引建立在哪个表空间下。语法上和CREATE TABLE 所使用的指定TABLESPACE的STORAGE语法相同。
  • { NOPARALLEL | PARALLEL [ integer ] }
    默认为NOPARALLEL

如:

ALTER INDEX oldindex REBUILD PARAMETERS('tablespace=TBS_3');

一、重建索引的前提 1、表上频繁发生update,delete操作; 2、表上发生了alter table ..move操作(move操作导致了rowid变化)。 二、重建索引的标准 1、索引重建是否有必要,一般看索引是否倾斜的严重,是否浪费了空间, 那应该如何才可以判断索引是否倾斜的严重,是否浪费了空间, 对索引进行结构分析(如下): SQL>Analyze index index_name validate structure; 2、在执行步骤1的session中查询index_stats表,不要到别的session去查询。 SQL>select height,DEL_LF_ROWS/LF_ROWS from index_stats; 说明:当 查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 , 该索引考虑重建 。 举例: (t_gl_assistbalance 26 万多条信息 ) SQL> select count(*) from t_gl_assistbalance ; 输出结果: COUNT(*) ---------- 265788 SQL> Analyze index IX_GL_ASSTBAL_1 validate structure; Index analyzed SQL> select height,DEL_LF_ROWS/LF_ROWS from index_stats; 输出结果: HEIGHT DEL_LF_ROWS/LF_ROWS ---------- ------------------- 4 1 三、重建索引的方式 1、drop 原来的索引,然后再创建索引; 举例: 删除索引:drop index IX_PM_USERGROUP; 创建索引:create index IX_PM_USERGROUP on T_PM_USER (fgroupid); 说明:此方式耗时间,无法在24*7环境中实现,不建议使用。 2 、直接重建: 举例: alter index indexname rebuild; 或alter index indexname rebuild online; 说明:此方式比较快,可以在24*7环境中实现,建议使用此方式。 四、alter index rebuild 内部过程和注意点 alter index rebuild 和alter index rebuil online的区别 1、扫描方式不同 1.1、Rebuild以index fast full scan(or table full scan) 方式读取原索引中的数据来构建一个新的索引,有排序的操作; 1.2、rebuild online 执行表扫描获取数据,有排序的操作; 说明:Rebuild 方式 (index fast full scan or table full scan 取决于统计信息的cost) 举例1 SQL> explain plan for alter index IX_GL_ASSTBAL_1 rebuild; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | 999K| 4882K| 3219 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID2 | | | | | 2 | SORT CREATE INDEX | | 999K| 4882K| | | 3 | INDEX FAST FULL SCAN | IDX_POLICY_ID2 | 999K| 4882K| | --------------------------------------------------------------------- 举例2 SQL> explain plan for alter index idx_policy_id rebuild; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------- | 0 | ALTER INDEX STATEMENT | | 2072K| 9M| 461 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID | | | | | 2 | SORT CREATE INDEX | | 2072K| 9M| | | 3 | TABLE ACCESS FULL | TEST_INDEX | 2072K| 9M| 461 | 举例3 ( 注意和 举例1 比较 ) Rebuil online 方式 : SQL> explain plan for alter index idx_policy_id2 rebuild online; Explained SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT --------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | ---------------------------------------------------------------------| 0 | ALTER INDEX STATEMENT | | 999K| 4882K| 3219 | | 1 | INDEX BUILD NON UNIQUE| IDX_POLICY_ID2 | | | | | 2 | SORT CREATE INDEX | | 999K| 4882K| | | 3 | TABLE ACCESS FULL | TEST_INDEX2 | 999K| 4882K| 3219 | 2 、rebuild 会阻塞 dml 操作 ,rebuild online 不会阻塞 dml 操作 ; 3 、rebuild online 时系统会产生一个 SYS_JOURNAL_xxx 的 IOT 类型的系统临时日志表 , 所有 rebuild online 时索引的变化都记录在这个表中 , 当新的索引创建完成后 , 把这个表的记录维护到新的索引中去 , 然后 drop 掉旧的索引 ,rebuild online 就完成了。 注意点: 1、 执行rebuild操作时,需要检查表空间是否足够; 2、虽然说rebuild online操作允许dml操作,但是还是建议在业务不繁忙时间段进行; Rebuild操作会产生大量redo log ; 五、重建分区表上的分区索引 重建分区索引方法: Alter index indexname rebuild partition paritionname tablespace tablespacename; Alter index indexname rebuild subpartition partitioname tablespace tablespacename; Partition name 可以从user_ind_partitions查找 Tablepace 参数允许alter index操作更改索引的存储空间; 六、索引状态描述 在数据字典中查看索引状态,发现有三种: valid:当前索引有效 N/A :分区索引 有效 unusable:索引失效 七、术语 1、高基数:简单理解就是表中列的不同值多。 2、低基数:建单理解就是表中的列的不同值少。 3、以删除的叶节点数量:指得是数据行的delete操作从逻辑上删除的索引节点 的数量,要记住oracle在删除数据行后,将 “ 死 “ 节点保留在索引中,这样做可以加快sql删除操作的速度,因此oracle删除数据行后可以不必重新平衡索引。 4、索引高度:索引高度是指由于数据行的插入操作而产生的索引层数,当表中添加大量数据时,oracle将生成索引的新层次以适应加入的数据行,因此,oracle索引可能有4层,但是这只会出现在索引数中产生大量插入操作的区域。Oracle索引的三层结构可以支持数百万的项目,而具备4层或是更多层的需要重建。 5、每次索引访问的读取数:是指利用索引读取一数据行时所需要的逻辑I/O操作数,逻辑读取不必是物理读取,因为索引的许多内容已经保存在数据缓冲区,然而,任何数据大于10的索引都需要重建。 6、什么时候重建呢? 察看 dba_indexes 中的 blevel 。这列是说明索引从根块到叶快的级别,或是深度。如果级别大于等于4。则需要重建, 如下 :Select index_name,blevel from dba_indexes where blevel>=4. 另一个从重建中受益的指标显然是当该索引中的被删除项占总的项数的百分比。如果在20%以上时,也应当重建,如下 SQL>analyze index index_name validate structure SQL>select (del_lf_rows_len/lf_rows_len)*100 from index_stats where name= ’ index_name ’ 就能看到是否这个索引被删除的百分比。 7、什么样的重建方式更好? (1)、建索引的办法: 1.1、删除并从头开始建立索引。 1.2 、 使用 alter index index_name rebuild 命令重建索引。 1.3 、 使用 alter index index_name coalesce 命令重建索引。 (2)、下面讨论一下这三种方法的优缺点: 2.1、删除并从头开始建索引:方法是最慢的,最耗时的。一般不建议。 2.2、Alter index index_name rebuild 快速重建索引的一种有效的办法,因为使用现有索引项来重建索引,如果客户操作时有其他用户在对这个表操作,尽量使用带online参数来最大限度的减少索引重建时将会出现的任何加锁问题,alter index index_name rebuild online。 但是,由于新旧索引在建立时同时存在,因此,使用这种技巧则需要有额外的磁盘空间可临时使用,当索引建完后把老索引删除,如果没有成功,也不会影响原来的索引。利用这种办法可以用来将一个索引移到新的表空间。 Alter index index_name rebuild tablespace tablespace_name 。 这个命令的执行步骤如下: 首先,逐一读取现有索引,以获取索引的关键字。 其次,按新的结构填写临时数据段。 最后,一旦操作成功,删除原有索引树,降临时数据段重命名为新的索引。 需要注意的是alter index index_name rebuild 命令中必须使用tablespace字句,以保证重建工作是在现有索引相同的表空间进行。 2.3、alter index index_name coalesce 使用带有coalesce参数时重建期间不需要额外空间,它只是在重建索引时将处于同一个索引分支内的叶块拼合起来,这最大限度的减少了与查询过程中相关的潜在的加锁问题,但是,coalesce选项不能用来将一个索引转移到其他表空间。 八、其他 1、truncate 分区操作和truncate 普通表的区别? 1.1、Truncate 分区操作会导致全局索引失效; truncate 普通表对索引没有影响; 1.2、Truncate 分区操作不会释放全局索引中的空间,而truncate 普通表会释放索引所占空间; 2、rename 表名操作对索引没有影响,因为rename操作只是更改了数据字典,表中数据行的rowid并没有发生变化 总结: 1、判断是否需要重建索引: SQL>analyze index index_name validate structure; SQL> select height,DEL_LF_ROWS/LF_ROWS from index_stats; ( 或 Select index_name,blevel from dba_indexes where blevel>=4 ); 说明 : 当查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 , 该索引考虑重建 ; 2 、重建索引方法 : 方法一、 Alter index index_name rebuild tablespace tablespace_name; 优点:是快速重建索引的一种有效的办法,可以用来将一个索引移到新的表空间。 缺点:重建期间需要额外空间。 方法二、 alter index index_name coalesce; 优点:重建期间不需要额外空间。 缺点:coalesce选项不能用来将一个索引转移到其他表空间。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值