⑴ oracle索引問題，刪除再重建索引與索引分析
1. 應該是可行的， 具體 會不會節省時間 試一下就可以了。
2. 大概每個月存儲四五十萬的數據，裡面只保存最新四個月的數據
每次create這7個索引用時都特別長，大概需要三四個小時；
200萬的數據，重建索引花費的時間太長了；很奇怪。
3. 估計之前的 先drop掉索引，然後插入數據完畢後create索引 也是為了避免 插入數據時，索引對插入效率的影響。
⑵ oracle 怎麼看需要重建索引
在ORACLE資料庫中，如果一個比較大的索引在重建過程中耗費時間比較長，那麼怎麼查看索引重建耗費的時間，以及完成了多少(比例)了呢，我們可以通過V$SESSION_LONGOPS視圖來查看索引重建的時間和進度。
⑶ oracle中如何重建索引
alter index ind_id_idx rebuild;--重建索引
select if_rows,if_rows_len,del_id_rows_len from index_stats;
.....
⑷ Oracle分區索引什麼情況下會重建
1.上述的語句是對單個分區索引進行重建。
2.索引分區的意思是指建立一個分區索引，而不是一個普通索引。
3.重建分區索引，這個比如說碎片太多，想換個表空間都可以重建的。
4.執行完了，就表示執行成功了。索引的分區信息可以在 user_ind_partitions 查詢！
⑸ 在PL-sql中如何給oracle資料庫重建索引
重建索引有多種方式，如drop and re-create、rebuild、rebuild online等。下面簡單比較這幾種方式異同以及優缺點：
首先建立測試表及數據：
SQL> CREATE TABLE TEST AS SELECT CITYCODE C1 FROM CITIZENINFO2;
Table created
SQL> ALTER TABLE TEST MODIFY C1 NOT NULL;
Table altered
SQL> SELECT COUNT(1) FROM TEST;
COUNT(1)
----------
16000000
一、drop and re-create和rebuild
首先看看正常建立索引時，對表的加鎖情況。
suk@ORACLE9I> @show_sid
SID
----------
14
suk@ORACLE9I> CREATE INDEX IDX_TEST_C1 ON TEST(C1);
索引已創建。
SQL> SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
OBJ$ 3
TEST 4
可見，普通情況下建立索引時，oracle會對基表加share鎖，由於share鎖和 row-X是不兼容的，也就是說，在建立索引期間，無法對基表進行DML操作。
對於刪除重建索引的方法就不介紹了，它與上面的描述是一樣的，下面我們看看用rebuild的方式建立索引有什麼特別。
suk@ORACLE9I> ALTER INDEX IDX_TEST_C1 REBUILD;
索引已更改。
另開一個會話，查詢此時test的加鎖情況：
SQL> SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
TEST 4
可見，rebuild的方式對基表的加鎖方式與CREATE時是一樣的。
另開一個會話，在索引正在rebuild時，執行如下SQL：
suk@ORACLE9I> SET AUTOTRACE TRACE
suk@ORACLE9I> SELECT /*+ INDEX(TEST) */ COUNT(1) FROM TEST WHERE ROWNUM<10;
執行計劃
----------------------------------------------------------
0 SELECT STATEMENT ptimizer=CHOOSE (Cost=26 Card=1)
1 0 SORT (AGGREGATE)
2 1 COUNT (STOPKEY)
3 2 INDEX (FULL SCAN) OF 'IDX_TEST_C1' (NON-UNIQUE) (Cost=
26 Card=1986621)
可以看到索引在重建時，查詢仍然可以使用舊索引。實際上，oracle在rebuild時，在創建新索引過程中，並不會刪除舊索引，直到新索引rebuild成功。
從這點可以知道rebuild比刪除重建的一個好處是不會影響原有的SQL查詢，但也正由於此，用rebuild方式建立索引需要相應表空間的空閑空間是刪除重建方式的2倍。
重建索引有多種方式，如drop and re-create、rebuild、rebuild online等。下面簡單比較這幾種方式異同以及優缺點：
相關文章：
oracle重建索引（一）
二、rebuild 和rebuild online
首先我們跟蹤一下rebuild online的過程。
另開一個會話查看鎖的信息：
SQL> SELECT OBJECT_NAME,LMODE FROM V$LOCK L,DBA_OBJECTS O WHERE O.OBJECT_ID=L.ID1 AND L.TYPE='TM' AND SID=14;
OBJECT_NAME LMODE
------------------------------ ----------
SYS_JOURNAL_10499 4
TEST 2
SQL> INSERT INTO TEST VALUES(11);
1 row inserted
SQL> COMMIT;
Commit complete
可以看到，在rebuild online期間，oracle對基表加的是RS所，此時我們可以對基表進行DML操作。但奇怪的話在相同的session中有一個SYS_JOURNAL_10499表被加SHARE鎖，這個表是干什麼用的呢？
我們看看trace文件，有這樣的信息：
create table "SUK"."SYS_JOURNAL_10499" (C0 NUMBER(6,0), opcode char(1),
partno number, rid rowid, primary key( C0 , rid )) organization index
TABLESPACE "TEST"
CREATE UNIQUE INDEX "SUK"."SYS_IOT_TOP_10605" on
"SUK"."SYS_JOURNAL_10499"("C0","RID") INDEX ONLY TOPLEVEL TABLESPACE "TEST"
NOPARALLEL
drop table "SUK"."SYS_JOURNAL_10499"
我們在查查10499是什麼東西：
SQL> SELECT OBJECT_NAME,OBJECT_TYPE FROM DBA_OBJECTS WHERE OBJECT_ID=10499;
OBJECT_NAME OBJECT_TYPE
------------------------------ ------------------
IDX_TEST_C1 INDEX
從這些信息可以推測：表SYS_JOURNAL_10499就是實現在重建索引時不阻塞DML操作而設計的，它存儲的是在索引重建期間發生在基表的數據變化。可以推測，CREATE INDEX .... ONLINE應該也有一張類似的表。
實際上，oracle之所以在創建索引時鎖表阻止DML操作就是為了防止不能索引新變化的數據，在online方式重建時，有了臨時表SYS_JOURNAL_XXXX，oracle就可以放心大膽地讓用戶操作了，因為所有重建索引期間的數據變化信息都會保留在SYS_JOURNAL_XXX表中，當索引重建完後再加上SYS_JOURNAL_XXX記錄的數據，就不會漏索引數據了。（XXX是被重建的索引對應的OBJECT_ID)
導讀：
重建索引有多種方式，如drop and re-create、rebuild、rebuild online等。下面簡單比較這幾種方式異同以及優缺點：
相關文章：
oracle重建索引（一）
oracle重建索引（二）
三、rebuild和rebuild online的數據源
網上一直有這樣一個說法：重建索引是以原索引作為數據源的。那麼，這種說法是否准確呢？我們做實驗來驗證一下：
suk@ORACLE9I> COL SEGMENT_NAME FORMAT A30
--首先看看錶和索引的大小
suk@ORACLE9I> SELECT SEGMENT_NAME,BYTES FROM USER_SEGMENTS WHERE SEGMENT_NAME IN ('TEST','IDX_TEST_C1');
SEGMENT_NAME BYTES
------------------------------ ----------
TEST 201326592
IDX_TEST_C1 293601280
suk@ORACLE9I> EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD;
已解釋。
suk@ORACLE9I> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
--從執行計劃可以看出，當索引比表大時，rebuild索引用的數據源是基表。
suk@ORACLE9I> EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD ONLINE;
已解釋。
suk@ORACLE9I> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
--從執行計劃可以看出，當索引比表大時，rebuild online索引用的數據源是基表。
--我們為TEST添加一列，使得表比索引大
suk@ORACLE9I> ALTER TABLE TEST ADD(C2 CHAR(30) DEFAULT '1');
表已更改。
suk@ORACLE9I> SELECT SEGMENT_NAME,BYTES FROM USER_SEGMENTS WHERE SEGMENT_NAME IN ('TEST','IDX_TEST_C
1');
SEGMENT_NAME BYTES
------------------------------ ----------
TEST 1476395008
IDX_TEST_C1 293601280
suk@ORACLE9I> EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD;
已解釋。
suk@ORACLE9I> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | INDEX FAST FULL SCAN| IDX_TEST_C1 | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
--從執行計劃可以看出，當表比索引大時，執行計劃已經改變，rebuild索引是以索引作為數據源的。
suk@ORACLE9I> EXPLAIN PLAN FOR ALTER INDEX IDX_TEST_C1 REBUILD ONLINE;
已解釋。
suk@ORACLE9I> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY());
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------
-----------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost |
-----------------------------------------------------------------------
| 0 | ALTER INDEX STATEMENT | | | | |
| 1 | INDEX BUILD NON UNIQUE| IDX_TEST_C1 | | | |
| 2 | SORT CREATE INDEX | | | | |
| 3 | TABLE ACCESS FULL | TEST | | | |
-----------------------------------------------------------------------
Note: rule based optimization
已選擇11行。
--從執行計劃可以看出，當表比索引大時，rebuild online仍然以基表作為數據源。
rebuild模式下，因為表數據不會產生變化，oracle主要考慮性能問題，把更快掃描完成的段作為數據源。在上面的例子中，我們並沒有對表進行分析，故oracle應該根據數據段的大小來決定那個作為數據源的。一般索引欄位比較多，或者對索引欄位的DML操作較多，可能會導致索引比表大，這時oracle就會使用基表作為新索引的數據源進行rebuild了。
而在rebuild online模式下，因為允許DML操作，而表數據變化的同時索引也會跟著變化，為了索引與基表數據的一致性，比如採用基表數據作為數據源，而不能用原索引數據作為數據源。
我們用反證法證明不能用原索引作為新索引的數據源。
例如：
T1發出rebuild online命令
T2刪除某條數據，刪數據的同時，oracle會自動維護了舊索引
T3掃描經過T2數據所在索引節點
T4插入一條記錄，新記錄對應的索引節點剛好重用了T2刪除的數據對應的索引節點空間
如果是這樣的話，新建的索引將不包含T4插入的記錄的信息。所以，rebuild online情況下新索引的數據源不能是原索引。
rebuild online情況下，如果非用原索引作為新索引的數據源的話，用中間表記錄索引變化的方法應該是可以實現的，但由於數據變化會同時引起索引變化的特定決定了這種方法將異常復雜及效率底下，所以oracle不考慮舊索引作為新索引的數據源是有道理的。
結論：
1、rebuild會阻塞對基表的DML操作，但不會影響rebuild期間查詢對原有索引的使用。
2、rebuild的數據源可能是基表，也可能是原索引。取決於基表和原索引的大小，那個小，rebuild時就會用那個作為數據源。這也說明了網上盛傳的rebuild以原索引作為資料庫的說法是不完全正確的。
3、rebuild online運行用戶在索引重建期間執行DML操作。
4、rebuild online的數據源是基表
⑹ oracle 資料庫如何建立索引 如何用索引
創建索引語法：
CREATE [UNIQUE] | [BITMAP] INDEX index_name
--unique表示唯一索引
ON table_name([column1 [ASC|DESC],column2
--bitmap，創建點陣圖索引
[ASC|DESC],…] | [express])[TABLESPACE tablespace_name][PCTFREE n1]
--指定索引在數據塊中空閑空間
[STORAGE (INITIAL n2)][NOLOGGING]
--表示創建和重建索引時允許對表做DML操作，默認情況下不應該使用
[NOLINE][NOSORT];
--表示創建索引時不進行排序，默認不適用，如果數據已經是按照該索引順序排列的可以使用
(6)oracle資料庫重建索引擴展閱讀：
1、如果有兩個或者以上的索引，其中有一個唯一性索引，而其他是非唯一，這種情況下oracle將使用唯一性索引而完全忽略非唯一性索引
2、至少要包含組合索引的第一列（即如果索引建立在多個列上，只有它的第一個列被where子句引用時，優化器才會使用該索引）
3、小表不要簡歷索引
4、對於基數大的列適合建立B樹索引，對於基數小的列適合簡歷點陣圖索引
5、列中有很多空值，但經常查詢該列上非空記錄時應該建立索引
6、經常進行連接查詢的列應該創建索引
7、使用create index時要將最常查詢的列放在最前面
8、LONG（可變長字元串數據，最長2G）和LONG RAW（可變長二進制數據，最長2G）列不能創建索引
9、限製表中索引的數量（創建索引耗費時間，並且隨數據量的增大而增大；索引會佔用物理空間；當對表中的數據進行增加、刪除和修改的時候，索引也要動態的維護，降低了數據的維護速度）
⑺ oracle 資料庫 索引有必要定時重建嗎
索引重建時會做兩個工作：
1，空間重新分配，
2，統計信息從新收集。
對於空間足夠前者可以忽略
對於後者，不僅索引的統計信息需要重新收集，表的統計信息也需要收集。
高版本oracle 會自動收集統計信息。如果執行計劃明顯異常時，可以手工收集統計信息，采樣率高些。正常不用重建索引。
⑻ oracle 索引什麼時候重建和重建方法討論
Normal 0 7.8 pt 0 2 false false false MicrosoftInternetExplorer4
oracle 索引什麼時候重建和重建方法討論
分類：資料庫技術 字型大小： 大大中中小小 索引什麼時候需要重建和重建的方法
一提到索引，大家都知道，但是怎樣建索引，什麼時候重建索引，重建索引用什麼方法，可能有的就不太清楚了，我根據一些資料簡單的整理一點，如果哪裡不對或是不妥請大家指點，希望大家有更好經驗也share出來。
索引的目的是為了加快尋找數據的速度，但是如果對表經常做改動，則索引也會相應改動，時間長了，查詢速度的效率就會降低，就有可能要重建索引，那麼什麼時候需要重建索引和用什麼方法重建索引可能是大家關心的。
一. 索引在內部進行自身的管理以確保對數據行的快速訪問。但是數據表中大量的活動會導致oracle索引動態地對自身的進行重新配置，這些配置包括三個方面：
1．索引分割
當新數據行產生的索引節點要建立在現有級別上時，出現此動作。
2．索引生成
在某些位置，索引達到此級索引的最大容量的時候，就會生成更深一級的索引結構。
3．索引節點的刪除
你可能了解到，刪除表中的數據行後，索引中相應的節點不會從物理意義上刪除，也沒有從索引中刪除此項目。而是從邏輯上刪除此索引項目，並在索引樹中留下了一個「死「節點，當索引刪除了葉節點或是生成了過深的的級別層次後，就需要進行重建。
二 索引的種類：
a.B-tree（B樹）索引
b.壓縮B樹索引
c.Bitmap（點陣圖）索引
d.函數索引
e.Reverse Key Index（反向鍵索引）
f.Index Organized Table（索引組織表）
三 下面分別對各種索引進行說明
在進行介紹前先說明幾個術語：
高基數：簡單理解就是表中列的不同值多
低基數：建單理解就是表中的列的不同值少
以刪除的葉節點數量：指得是數據行的delete操作從邏輯上刪除的索引節點的數量，要記住oracle在刪除數據行後，將「死「節點保留在索引中，這樣做可以加快sql刪除操作的速度，因此oracle刪除數據行後可以不必重新平衡索引。
索引高度：索引高度是指由於數據行的插入操作而產生的索引層數，當表中添加大量數據時，oracle將生成索引的新層次以適應加入的數據行，因此， oracle索引可能有4層，但是這只會出現在索引數中產生大量插入操作的區域。Oracle索引的三層結構可以支持數百萬的項目，而具備4層或是更多層的需要重建。
每次索引訪問的讀取數：是指利用索引讀取一數據行時所需要的邏輯I/O操作數，邏輯讀取不必是物理讀取，因為索引的許多內容已經保存在數據緩沖區，然而，任何數據大於10的索引都需要重建。
1. B-tree（B樹）索引
是現代關系型資料庫中最常用的索引。除了存儲索引數據外，還存儲一個行ID，用來指出該行其餘數據存儲在這個被索引表中的什麼地方。該索引以一種數結構格式存儲這些值。
Oracle建議如果表經過排序，當返回40%一下的數據時使用索引，如果高於40%則使用全表掃描，如果沒有經過排序，則當返回7%以下時，使用索引。看錶是否排序，可以看dba_indexes字典中的CLUSTERING_FACTOR列，如果與表佔用的數據塊數相近，則經過了排序，如果與行數相近，則沒有排序。那麼什麼時候重建呢？我們可以利用analyze index …….. compute statistics 對表進行分析。然後察看dba_indexes中的blevel。這列是說明索引從根塊到葉快的級別，或是深度。如果級別大於等於4。則需要重建，如下：
Select index_name,blevel from dba_indexeswhere blevel>=4.
另一個從重建中受益的指標顯然是當該索引中的被刪除項占總的項數的百分比。如果在20%以上時，也應當重建，如下
SQL>anlyze index ------ validatestructure
SQL>select(del_lf_rows_len/lf_rows_len)*100 from index_stats where 刪除並從頭開始建立索引。
b. 使用alter index -------- rebuild 命令重建索引
c. 使用alter index -------- coalesce命令重建索引。
下面討論一下這三種方法的優缺點：
1).刪除並從頭開始建索引：方法是最慢的，最耗時的。一般不建議。
2).Alter index ---- rebuild 快速重建索引的一種有效的辦法，因為使用現有索引項來重建新索引，如果客戶操作時有其他用戶在對這個表操作，盡量使用帶online參數來最大限度的減少索引重建時將會出現的任何加鎖問題，alter index ------- rebuild online.但是,由於新舊索引在建立時同時存在，因此，使用這種技巧則需要有額外的磁碟空間可臨時使用，當索引建完後把老索引刪除，如果沒有成功，也不會影響原來的索引。利用這種辦法可以用來將一個索引以到新的表空間。
Alter index ------ rebuild tablespace -----。
這個命令的執行步驟如下：
首先，逐一讀取現有索引，以獲取索引的關鍵字。
其次，按新的結構填寫臨時數據段。
最後，一旦操作成功，刪除原有索引樹，降臨時數據段重命名為新的索引。
需要注意的是alterindex ---rebuild 命令中必須使用tablespace字句，以保證重建工作是在現有索引相同的表空間進行。
3).alter index ----- coalesce 使用帶有coalesce參數時重建期間不需要額外空間，它只是在重建索引時將處於同一個索引分支內的葉塊拼合起來，這最大限度的減少了與查詢過程中相關的潛在的加鎖問題，但是，coalesce選項不能用來講一個索引轉移到其他表空間。
2．壓縮B樹索引
當B樹索引基於大表時，尤其是當基於數據倉庫或決策支持系統中的大表時，這些索引會耗費大量的存儲空間，壓縮（compressed）B樹索引用來最大限度的減少某些類型的B樹索引使用的空間。當一個B樹索引得到壓縮時，被索引的獵的重復出現就被消除掉，進而減少了存儲索引的總的存儲空間。例如：
壓縮前：smith每次出現還要存儲它的相關的rowid.
姓 關聯rowid
smith AAABSOAAEAAAABTAAB
smith AAABSOAAEAAAABTAAC
smith AAABSOAAEAAAABTAAD
壓縮後:smith項和rowid指存儲一次。
smith AAABSOAAEAAAABTAAB,AAABSOAAEAAAABTAAB, AAABSOAAEAAAABTAAB
創建方法：
SQL>create index index_name ontable_name(column_name)
tablespace tablespace_name
compress;
另一種方法：
SQL>alter index index_name rebuildcompress;
3． itmap(點陣圖)索引。
B樹索引在數據具有高基數的列工作的最好，對於低基數的列，點陣圖索引可能是更有效的選擇。點陣圖索引創建錶行的一個二進制映像，並把映像存儲在索引塊中，這種類型的索引的DML操作少，長度大並且含有極少不同的值得列特別有用。點陣圖索引不應當用在頻繁發生insert,update,delete操作的表上，這些dml操作在性能方面的代價很高，因為，他們會引起點陣圖級的加鎖發生，而且要求動態的重建所有可能值的點陣圖。為圖索引最適合數據倉庫和決策支持系統。
4．基於函數的索引
當把一個函數運用於被索引的列上時，該列德索引都變得無效，基於函數的索引就是為了解決這個問題。
5．反向鍵索引
是一種特殊類型的B樹索引，在索引基於含有序數的列時使非常有用的，如果一個傳統的B樹索引基於一個含有這種數據的列，往往會產生許多級，由於B樹索引有 4級以上的深度會降低性能，因此反向鍵索引更適合這種類型，反向鍵索引通過簡單的煩象被索引的列中的數據來解決問題，他首先反向每個列鍵值的位元組，然後在反向後的新數據上進行索引，而新數據在值的范圍上的分布通常比原來的有序數更均勻。
6．索引組織表
由於B樹、點陣圖、反向鍵索引的使用而引起的性能將會導致這樣的事實，這些索引中的項目直接指向索引基表中對應數據的行ID,這是從錶行沒有按任何特定的順序來物理地存儲表中檢索錶行的一種有效方法，這種表叫做堆表，oracle大多數表中以一種堆疊方式存儲行數據，因為行以一種或多或少的隨機方式被分配給表內的塊，之所以出現這種隨機性，是因為oracle在決定把一個行存儲在何處時並不考慮改行的內容，oracle只是把該行存儲在它從該表的freelist 上所發現的第一個塊中。
如果希望按一種指定順序來存儲一個表的數據，就不能使用堆表，為此oracle提供了索引組織表，索引組織表不是存儲一個指向行數據的其餘部分存儲在了何處的行的ID指針，而是把行數據全部存儲在索引本身內，這產生了兩個性能好處：
n 錶行按索引順序來存儲。
n 使用B樹索引時引起的先讀取索引後讀取表鎖使用的額外I/O操作得到消除。
例如：
sql>create table emp
(last_name varchar2(9) primary key,
first_name varchar2(9),
hire_date date)
organization index tablespace users
pctthreshold 25
including first name
overflow tablespace qyl
mapping table;
所有索引組織表在將要作為索引基礎的那一列上都必須有一個主鍵約束，索引組織表不能含有唯一性約束或是被聚簇。
下面說明各個參數的含義：
organization index：說明該表是索引組織表
pctthreshold :指定整個數據塊的什麼百分比要保持打開，以便存儲一個與主鍵值相關聯的行數據，其中主鍵值必須在0到50之間（50是默認值）
including : 指定在行長度超過pctthershold中所設置的大小時按那一列 把行分解成兩段
overflow tablespace ：指定在行長度超過pctthreshold中設置的大小時行數的的另一部分存儲到的表空間。
Mapping table:致使在創建索引組織表的點陣圖索引時所必需的一個關聯映像表的創建。
以上是我根據一些資料對索引的一個簡單闡述，大家可能有不同的見解，希望對大家有幫助，那些不妥的地方還希望大家提出來。
參考資料：ocp困惑racle9i性能調整
oracle statspack 高性能調整技術
[@more@]
analyze index t_id_ind validate structure
select (del_lf_rows_len/lf_rows_len)*100 from index_stats
>20%
b. 使用alter index t_id_ind rebuild 命令重建索引
c. 使用alter index t_id_ind coalesce命令重建索引。
alter indext_id_ind rebuild online.
但是,由於新舊索引在建立時同時存在，因此，使用這種技巧則需要有額外的磁碟空間可臨時使用，當索引建完後把老索引刪除，如果沒有成功，也不會影響原來的索引。利用這種辦法可以用來將一個索引以到新的表空間。
Alter index ------ rebuild tablespace -----。
這個命令的執行步驟如下：
首先，逐一讀取現有索引，以獲取索引的關鍵字。
其次，按新的結構填寫臨時數據段。
最後，一旦操作成功，刪除原有索引樹，降臨時數據段重命名為新的索引。
需要注意的是alter index ---rebuild 命令中必須使用tablespace字句，以保證重建工作是在現有索引相同的表空間進行
alter index ----- coalesce 使用帶有coalesce參數時重建期間不需要額外空間，它只是在重建索引時將處於同一個索引分支內的葉塊拼合起來，這最大限度的減少了與查詢過程中相關的潛在的加鎖問題，但是，coalesce選項不能用來講一個索引轉移到其他表空間
⑼ oracle 重建索引
1、重新收集統計信息
analyze table 表名 compute statistics for table for all indexes for all indexed columns
analyze index 索引名 compute statistics
2、把表現不同的sql及其執行計劃發上來看看