【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.

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


  


  

 

   

 

目录
相关文章
|
JSON 前端开发 JavaScript
【SpringBoot+MyBatisPlus】分页的实现以及使用数值转换器来解决long型id精度丢失问题
分页的实现以及使用数值转换器来解决long型id精度丢失问题
471 0
【SpringBoot+MyBatisPlus】分页的实现以及使用数值转换器来解决long型id精度丢失问题
|
8月前
|
JSON JavaScript 前端开发
解决js中Long类型数据在请求与响应过程精度丢失问题(springboot项目中)
解决js中Long类型数据在请求与响应过程精度丢失问题(springboot项目中)
706 0
|
8月前
|
编译器 C语言
c语言中long的作用类型
c语言中long的作用类型
236 0
【面试题精讲】Java超过long类型的数据如何表示
【面试题精讲】Java超过long类型的数据如何表示
|
2月前
|
编译器 C#
c# - 运算符<<不能应用于long和long类型的操作数
在C#中,左移运算符的第二个操作数必须是 `int`类型,因此需要将 `long`类型的位移计数显式转换为 `int`类型。这种转换需要注意数据丢失和负值处理的问题。通过本文的详细说明和示例代码,相信可以帮助你在实际开发中正确使用左移运算符。
45 3
|
2月前
|
编译器 C#
c# - 运算符<<不能应用于long和long类型的操作数
在C#中,左移运算符的第二个操作数必须是 `int`类型,因此需要将 `long`类型的位移计数显式转换为 `int`类型。这种转换需要注意数据丢失和负值处理的问题。通过本文的详细说明和示例代码,相信可以帮助你在实际开发中正确使用左移运算符。
78 1
|
2月前
|
编译器 C#
c# - 运算符<<不能应用于long和long类型的操作数
在C#中,左移运算符的第二个操作数必须是 `int`类型,因此需要将 `long`类型的位移计数显式转换为 `int`类型。这种转换需要注意数据丢失和负值处理的问题。通过本文的详细说明和示例代码,相信可以帮助你在实际开发中正确使用左移运算符。
27 0
|
5月前
|
前端开发 Java 数据库
Java系列之 Long类型返回前端精度丢失
这篇文章讨论了Java后端实体类中Long类型数据在传递给前端时出现的精度丢失问题,并提供了通过在实体类字段上添加`@JsonSerialize(using = ToStringSerializer.class)`注解来确保精度的解决方法。
|
8月前
|
安全 Java 编译器
long类型在32位操作系统上的安全问题
long类型在32位操作系统上的安全问题
212 1
|
7月前
|
Java
springboot解决jackson序列化Long类型精度失效问题
springboot解决jackson序列化Long类型精度失效问题
166 0