【MOS】Index Rebuild Is Hanging Or Taking Too Long (文档 ID 272762.1)

APPLIES TO:

Oracle Database - Enterprise Edition - Version 8.1.7.4 to 9.2.0.4 [Release 8.1.7 to 9.2]
Information in this document applies to any platform.

SYMPTOMS

 .

CHANGES

 .

CAUSE

 .

SOLUTION

(AuthWiz 1.2) Created from <<TAR:3405564.995>>

APPLIES TO

Oracle Server - Enterprise Edition - Version: 9.2.0.4
This problem can occur on any platform.

SYMPTOMS

Problem:
========
- Online Index rebuild takes a long time.
- ONLINE INDEX REBUILD SCANS THE BASE TABLE AND NOT THE INDEX

Symptoms:
=========
Performance issues while rebuilding very large indexes.
- The offline rebuilds of their index is relatively quick -finishes in 15 minutes.
- Issuing index rebuild ONLINE statement => finishes in about an hour.
- This behavior of ONLINE index rebuilds makes it a non-option for large tables 
as it just takes too long to scan the table to rebuild the index. The 
offline may not be feasible due to due to the 24/7 nature of the database.
- This may be a loss of functionality for such situations.
- If we attempt to simultaneously ONLINE rebuild the same indexes we may encounter
hanging behavior indefinitely (or more than 6 hours). 

DIAGNOSTIC ANALYSIS:
--------------------
We can trace the sessions rebuilding the indexes with 10046 level 12.
Comparing the IO reads for the index-rebuild and the index-rebuild-online 
reveals the following:

-ONLINE index rebuilds
It scans the base table and it doesn't scan the blocks of the index.

-OFFLINE index rebuilds
It scans the index for the build operation.

- This behaviour is across all versions.

TEST CASE:
----------
--connect as scott
--
sqlplus scott/tiger
--
--create some dummy table from the dba_objects view
--
create table objects as select * from dba_objects;
--
--create an index on the table
create index object_idx on objects(object_id,object_name);
--
--check out the file_id and block_id for the table and index
--
set linesize 150
set pagesize 4444
col segment_name format a40
select segment_name,file_id,block_id from dba_extents where owner = 'SCOTT' 
and segment_name like 'OBJECT%';
--
--trace the ONLINE index rebuild first
--
alter session set events '10046 trace name context forever, level 12';
alter index object_idx rebuild online;
--
--exit here and pull up the trace file. You'll see the reads
--for the cursor representing the cursor performing the rebuild that they
--are scanning the file and blocks belonging to the --base table
--called OBJECTS
--
exit
--
--Log back in and retry the same with the OFFLINE index rebuild
--
sqlplus scott/tiger
--
--get the new block_ids because the index has been rebuilt since we did this 
--last time
--
set linesize 150
set pagesize 4444
col segment_name format a40
select segment_name,file_id,block_id from dba_extents where owner = 'SCOTT' 
and segment_name like 'OBJECT%';
--
--trace and rebuild the index
--
alter session set events '10046 trace name context forever, level 12';
alter index object_idx rebuild;
--
--exit out and check the trace file again. You'll see that we read the index 
--blocks for the rebuild

On analyzing the trace file generated, we will notice that there are lots of
'db file scattered read' wait events.

CAUSE

Cause/Explanation
=============
When you rebuild index online,
- it will do a full tablescan on the base table.
- At the same time it will maintain a journal table for DML data, which has 
changed during this index rebuilding operation. 
So it should take longer time, specially if you do lots of DML on the same table,
while rebuilding index online.

On the other hand, while rebuilding the index without online option, Oracle will grab
the index in X-mode and rebuild a new index segment by selecting the data from 
the old index. So here we are
- not allowing any DML on the table hence there is no journal table involved 
- and it is doing an index scan
Hence it will be pretty fast.

FIX

Solution/Conclusion:
===========
- The ONLINE index rebuild reads the base table, and this is by design.
- Rebuilding index ONLINE is pretty slow.
- Rebuilding index offline is very fast, but it prevents any DML on the base table.

REFERENCES

BUG:3221809 - Online Index Rebuild Scans The Base Table And Not The Index


REFERENCES

BUG:3221809 - ONLINE INDEX REBUILD SCANS THE BASE TABLE AND NOT THE INDEX

  

  

 

   

 

时间: 2024-09-01 14:31:08

【MOS】Index Rebuild Is Hanging Or Taking Too Long (文档 ID 272762.1)的相关文章

【MOS】Limitations of the Oracle Cost Based Optimizer (文档 ID 212809.1)

[MOS]Limitations of the Oracle Cost Based Optimizer (文档 ID 212809.1) APPLIES TO: Oracle Database - Personal Edition - Version 7.1.4.0 and laterOracle Database - Enterprise Edition - Version 6.0.0.0 and laterOracle Database - Standard Edition - Versio

【MOS】EVENT: DROP_SEGMENTS - cleanup of TEMPORARY segments (文档 ID 47400.1)

[MOS]EVENT: DROP_SEGMENTS - Forcing cleanup of TEMPORARY segments (文档 ID 47400.1) ***Checked for relevance on 14-Jun-2012*** The DROP_SEGMENTS event ~~~~~~~~~~~~~~~~~~~~~~~ Available from 8.0 onwards. DESCRIPTION Finds all the temporary segments in a

【MOS】Troubleshooting Performance Issues (文档 ID 1377446.1)

[MOS]Troubleshooting Performance Issues (文档 ID 1377446.1) In this Document Purpose   Best Practices   Pro-Active Problem Avoidance and Diagnostic Collection   Performance Service Request Diagnostic Collection (SRDC) documents Troubleshooting Steps  

【MOS】为何在查询中索引未被使用 (文档 ID 1549181.1、英文文档为67522.1)

为何在查询中索引未被使用 (文档 ID 1549181.1)   "为什么索引没有被使用"是一个涉及面较广的问题.有多种原因会导致索引不能被使用.首要的原因就是统计信息不准,第二原因就是索引的选择度不高,使用索引比使用全表扫描效率更差.还有一个比较常见的原因,就是对索引列进行了函数.算术运算或其他表达式等操作,或出现隐式类型转换,导致无法使用索引.还有很多其它原因会导致不能使用索引,这个问题在MOS(MOS即My Oracle Support)"文档1549181.1为何在查

【MOS】在不同版本和平台之间进行还原或复制 (文档 ID 1526162.1)--跨版本恢复

[MOS]关于在不同版本和平台之间进行还原或复制的常见问题 (文档 ID 1526162.1)--跨版本恢复 Questions and Answers    1) 我能用更高版本的 Oracle 还原或复制旧版本的数据库吗?    2) 我能在两个不同的补丁程序集之间进行还原或复制吗?    3) 我能在同一操作系统的不同版本之间进行还原或复制吗?    4) Oracle 的位(bit)级别(32 位或 64 位)不匹配时,可以进行还原或复制吗?    5) 可以将更高版本的备份还原到较早版

【MOS】中文文档列表 - Oracle Database (文档 ID 1533057.1)

中文文档列表 - Oracle Database (文档 ID 1533057.1) 类型: 状态: 上次主更新: 上次更新: ANNOUNCEMENT PUBLISHED 2017-2-23 2017-2-23     文档内容 详细信息 操作   Oracle 数据库技术支持通讯   安装/升级/降级/迁移相关     日常管理相关   性能相关     集群及存储相关   高可用相关   TimesTen 内存数据库 联系人 参考 适用于: Oracle Database - Enterp

【MOS】OCR/Vote disk 维护操作: (添加/删除/替换/移动) (文档 ID 1674859.1)

[MOS]OCR/Vote disk 维护操作: (添加/删除/替换/移动) (文档 ID 1674859.1) 文档内容 目标 解决方案   准备磁盘   1. 磁盘大小   2. 裸设备或者块设备 (pre 11.2)   3. ASM disks (11.2+)   4. 集群文件系统   5. 权限   6. 冗余   添加/删除/替换/移动 OCR device   1. 当只有一个 OCR 设备时,添加一个 OCRMIRROR 设备:   2. 删除一个 OCR 设备   3. 替换

【MOS】RAC 环境中 gc block lost 和私网通信性能问题的诊断 (文档 ID 1674865.1)

[MOS]RAC 环境中 gc block lost 和私网通信性能问题的诊断 (文档 ID 1674865.1) 文档内容 症状   概要:   场景:   原因:   Global Cache Block Loss诊断指南 更改 原因 解决方案 参考 适用于: Oracle Database - Enterprise Edition - 版本 9.2.0.1 和更高版本本文档所含信息适用于所有平台Oracle Clusterware & Oracle Real Application Clu

【MOS】零宕机迁移ASM磁盘组到另一个SAN/磁盘阵列/DAS的准确步骤 (文档 ID 1946664.1)

[MOS]零宕机时间迁移 ASM 磁盘组到另一个 SAN/磁盘阵列/DAS 的准确步骤 (文档 ID 1946664.1) 文档内容 目标   提问,获得帮助,并分享您对于这篇文档的经验. 解决方案 参考 适用于: Oracle Database - Enterprise Edition - 版本 10.2.0.1 到 11.2.0.4 [发行版 10.2 到 11.2]本文档所含信息适用于所有平台 目标 本文详述了在零宕机时间的前提下将 ASM 磁盘组从一个存储设备(SAN/磁盘阵列/DAS等