Q1：oracle 怎么看需要重建索引
oracle 怎么看需要重建索引
select * from user_indexes where table_name = student
create index i_student_num on student(num)
Q2：Oracle关于重建索引争论的总结
索引重建是一个争论不休被不断热烈讨论的议题。当然Oracle官方也有自己的观点，我们很多DBA也是遵循这一准则来重建索引，那就是Oracle建议对于索引深度超过4级以及已删除的索引条目至少占有现有索引条目总数的20% 这2种情形下需要重建索引。近来Oracle也提出了一些与之相反的观点，就是强烈建议不要定期重建索引。本文是参考了1525787.1并进行相应描述。
1、重建索引的理由
a、Oracle的B树索引随着时间的推移变得不平衡(误解)
b、索引碎片在不断增加
c、索引不断增加，删除的空间没有重复使用
d、索引 clustering factor （集群因子）不同步，可以通过重建修复(误解)
2、重建索引的本质
本质：重建索引在数据库内部是先执行删除操作，再执行插入操作。
3、反对重建索引的理由
a. 大多数脚本都依赖 index_stats 动态表。此表使用以下命令填充：
analyze index ... validate structure;
尽管这是一种有效的索引检查方法，但是它在分析索引时会获取独占表锁。对于大型索引，其影响会是巨大的，因为在此期间不允许对表执行DML 操作。
虽然该方法可以在不锁表的情况下在线运行，但是可能要消耗额外的时间。
b. 重建索引的直接结果是 REDO 活动可能会增加，总体系统负载也可能会提高。
插入/更新/删除操作会导致索引随着索引的分割和增长不断发展。
重建索引后，它将连接的更为紧凑；但是，随着对表不断执行 DML 操作，必须再次分割索引，直到索引达到平衡为止。
结果，重做活动增加，且索引分割更有可能对性能产生直接影响，因为我们需要将更多的 I/O、CPU 等用于索引重建。
经过一段时间后，索引可能会再次遇到“问题”，因此可能会再被标记为重建，从而陷入恶性循环。
因此，通常最好是让索引处于自然平衡和（或）至少要防止定期重建索引。
4、Oracle的最终建议
一般而言，极少需要重建 B 树索引，基本原因是 B 树索引很大程度上可以自我管理或自我平衡。
大多数索引都能保持平衡和完整，因为空闲的叶条目可以重复使用。
插入/更新和删除操作确实会导致索引块周围的可用空间形成碎片，但是一般来说这些碎片都会被正确的重用。
Clustering factor群集因子反映了给定的索引键值所对应的表中的数据排序情况。重建索引不会对群集因子产生影响，集群因子只能通过重组表的数据改变。
强烈建议不要定期重建索引，而应使用合适的诊断工具。
个人结论，如果重建索引的巨大工作量与之对应的是极小的收益，那就得不偿失。如果系统有可用空闲期，重建之前和之后的测量结果表明性能有提高，值得重建。
5、改良方法
通常是优先考虑index coalesce（索引合并），而不是重建索引。索引合并有如下优点：
a、不需要占用近磁盘存储空间 2 倍的空间
b、可以在线操作
c、无需重建索引结构，而是尽快地合并索引叶块，这样可避免系统开销过大。
6、真正需要重建索引的情形
索引或索引分区因介质故障损坏
标记为UNUSABEL的索引需要重建
索引移动到新的表空间或需要改变某些存储参数
通过SQL*Loader加载数据到表分区后，需要重建索引分区
重建索引以启用键压缩
位图索引本质不同于B树索引，建议重建
Q3：oracle查询数据速度慢，已建索引的。求助
方法如下：
Oracle中建立索引，会提高查询速度： create index 索引名 on 表名(列名);
例如：
create index index_userid on tbl_detail(userid);
如何找数据库表的主键字段的名称?
SELECT * FROM user_constraints WHERE CONSTRAINT_TYPE=P and table_name=AAA; select * from dba_cons_columns where CONSTRAINT_NAME=SYS_AAA;
Oracle 在创建主键（可以不加constraint SYS_AAA），会为库表自动创建索引，
索引的列为主键列。 并且当库表某些列名或者库表名改变时候，
Oracle自动创建的索引SYS_AAA,中的索引列也会自动更新（类似于视图），并且SYS_AAA会与名字更改后的库表还是保持索引关系。 关键系统库表： desc dba_constraints desc dba_cons_columns
desc dba_indexes desc dba_ind_columns desc DBA_TAB_COLUMNS
例子1：更改库表的列名
ALTERTABLE AAARENAMECOLUMNID TOAAA_ID; create table AAA ( ID NUMBER(8), NAME CHAR(20),
constraint SYS_AAA primary key(ID) );
//查找约束名字
select c.CONSTRAINT_NAME,c.table_name,cc.COLUMN_NAME from user_constraints c, user_cons_columns cc
where c.constraint_name=cc.constraint_name and c.table_name =AAAAND C.CONSTRAINT_TYPE=P;
CONSTRAINT_NAMETABLE_NAMECOLUMN_NAME ------------------------------ ------------------------- SYS_AAAAAAID
//查找索引
select index_name,index_type,uniqueness from user_indexes where table_name=AAA; INDEX_NAMEINDEX_TYPEUNIQUENES
Q4：oracle中如何重建索引?
alter index ind_id_idx rebuild;--重建索引
select if_rows,if_rows_len,del_id_rows_len from index_stats;
.....
Q5：Oracle重建索引多长时间?
这个时间没有具体数字的,因为具体使用多少时间取决于你的数据量有多大、系统负载情况、服务器的性能等。
Q6：oracle重建索引有什么影响
首先来看看网上关于索引需要重建的准则或标准：
一：分析(analyze)指定索引之后，查询index_stats的height字段的值，如果这个值>=4 ,最好重建（rebuild）这个索引。虽然这个规则不是总是正确，但如果这个值一直都是不变的，则这个索引也就不需重建。
二：在分析(analyze)指定索引之后，查询index_stats的del_lf_rows和lf_rows的值,如果(del_lf_rows/lf_rows)*100 > = 20，则这个索引也需要重建。
关于这个论据，我们找到可以考证的官方资料为Various Aspects of Fragmentation (文档 ID 186826.1) ，其中有这么一段
Along with the REBUILD clause of the ALTER INDEX, Oracle8i introduces the
COALESCE clause as another way to address fragmentation issues.
In the following cases, it may be worthwhile to rebuild the index:
--> the percentage of the space used is bad - lower than 66%: PCT_USED
--> deleted leaf blocks represent more than 20% of total leaf blocks: DEL_LF_ROWS
--> the height of the tree is bigger than 3: HEIGHT or BLEVEL
Q7：oracle重建索引会锁表吗
应该是没有默认索引，建立主键或者索引之后，oracle会在单独的一块区域建立索引的数据，索引的数据和表的数据是分别存放的，不是在一起的，索引的数据就对应表的主键或者其他索引，例如，你的表里有100条数据，并且有主键，那么在索引的区域就会有100条数据和它们对应，并且由于是主键数据，所以每条数据都是唯一的，不会重复，数据检索的时候，先去检索索引区，因为那里的数据比较少，所以速度很快。但如果没有主键，一个表中可以有重复的数据，所以系统也不知道按照什么样的规则自动建索引，就不会有默认的索引，oracle每次查询都会进行全表查询。
