以下演示有兩個重點：

1.BITMAP索引的局限性：? DML操作導致位圖索引鎖定；

2.分區索引的性能并沒有比全局索引更優。

書面作業，必須給出全部的演示過程。<br>

1.分別給出一個B-tree索引針對全表掃描性能高和低的例子。<br>
2.分別給出一個Bitmap索引針對b-tree索引性能高和低的例子。<br>
3.演示DML操作導致位圖索引鎖定示例。<br>
4.創建一個全文索引，比較它和傳統的模糊查詢的性能。<br>
5.分別演示分區索引的性能優化全局索引和差于全局索引的示例，并分析原因。<br>

====================================================================================
1.分別給出一個B-tree索引針對全表掃描性能高和低的例子。<br>

答：

?? ?延用上課使用的環境，表T 中的OBJECT_ID 中建有索引，現在使用兩種方法進行查詢：

?? ?1.1.1 使用索引查詢
?? ?SQL> explain plan for select *? from t where object_id=100;
?? ?Explained

?? ?SQL> select * from table(dbms_xplan.display(null,null,'typical'));
?? ?PLAN_TABLE_OUTPUT
?? ?--------------------------------------------------------------------------------
?? ?Plan hash value: 514881935
?? ?--------------------------------------------------------------------------------
?? ?| Id? | Operation?????????????????? | Name???? | Rows? | Bytes | Cost (%CPU)| Ti
?? ?--------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT??????????? |????????? |??? 63 |? 6111 |??? 67?? (0)| 00
?? ?|?? 1 |? TABLE ACCESS BY INDEX ROWID| T??????? |??? 63 |? 6111 |??? 67?? (0)| 00
?? ?|*? 2 |?? INDEX RANGE SCAN????????? | IDX_T_ID |??? 63 |?????? |???? 3?? (0)| 00
?? ?--------------------------------------------------------------------------------
?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------
?? ??? 2 - access("OBJECT_ID"=100)
?? ?14 rows selected

?? ?1.1.2 使用HINT 指定使用全表搜索查詢
?? ?SQL> explain plan for select /*+FULL(T)*/ *? from t where object_id=100;
?? ?Explained

?? ?SQL> select * from table(dbms_xplan.display(null,null,'typical'));
?? ?PLAN_TABLE_OUTPUT
?? ?--------------------------------------------------------------------------------
?? ?Plan hash value: 1601196873
?? ?--------------------------------------------------------------------------
?? ?| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
?? ?--------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT? |????? |??? 63 |? 6111 | 28636?? (1)| 00:05:44 |
?? ?|*? 1 |? TABLE ACCESS FULL| T??? |??? 63 |? 6111 | 28636?? (1)| 00:05:44 |
?? ?--------------------------------------------------------------------------
?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------
?? ??? 1 - filter("OBJECT_ID"=100)
?? ?13 rows selected



?? ?從以上執行計劃的成本 可以看到，索引搜索是全表搜索的1/400以上；


?? ?1.2 再看一個使用索引的性能比全表搜索差的演示：
?? ??? ?
?? ??? ?建立一個索引
?? ??? ?create index idx_t_status on t(status);


?? ?1.2.1 查詢表中object_id<=100 （基本上是全表數據一起查詢了）

?? ??? ?1.2.2 按索引查詢

?? ??? ?SQL> explain plan for select /*+ index(t idx_t_status)*/ * from T? WHERE status ='VALID';
?? ??? ?Explained

?? ??? ?SQL> select * from table(dbms_xplan.display(null,null,'typical'));
?? ??? ?PLAN_TABLE_OUTPUT
?? ??? ?--------------------------------------------------------------------------------
?? ??? ?Plan hash value: 709710412
?? ??? ?--------------------------------------------------------------------------------
?? ??? ?| Id? | Operation?????????????????? | Name???????? | Rows? | Bytes | Cost (%CPU)
?? ??? ?--------------------------------------------------------------------------------
?? ??? ?|?? 0 | SELECT STATEMENT??????????? |????????????? |? 2432K|?? 224M| 40808?? (1)
?? ??? ?|?? 1 |? TABLE ACCESS BY INDEX ROWID| T??????????? |? 2432K|?? 224M| 40808?? (1)
?? ??? ?|*? 2 |?? INDEX RANGE SCAN????????? | IDX_T_STATUS |? 2432K|?????? |? 5792?? (1)
?? ??? ?--------------------------------------------------------------------------------
?? ??? ?Predicate Information (identified by operation id):
?? ??? ?---------------------------------------------------
?? ??? ??? 2 - access("STATUS"='VALID')
?? ??? ?14 rows selected


?? ??? ?1.2.3 沒有指定使用索引，系統自動進行了全表搜索

?? ??? ?SQL> explain plan for select * from T? WHERE status ='VALID';
?? ??? ?Explained

?? ??? ?SQL> select * from table(dbms_xplan.display(null,null,'typical'));
?? ??? ?PLAN_TABLE_OUTPUT
?? ??? ?--------------------------------------------------------------------------------
?? ??? ?Plan hash value: 1601196873
?? ??? ?--------------------------------------------------------------------------
?? ??? ?| Id? | Operation???????? | Name | Rows? | Bytes | Cost (%CPU)| Time???? |
?? ??? ?--------------------------------------------------------------------------
?? ??? ?|?? 0 | SELECT STATEMENT? |????? |? 2432K|?? 224M| 28676?? (1)| 00:05:45 |
?? ??? ?|*? 1 |? TABLE ACCESS FULL| T??? |? 2432K|?? 224M| 28676?? (1)| 00:05:45 |
?? ??? ?--------------------------------------------------------------------------
?? ??? ?Predicate Information (identified by operation id):
?? ??? ?---------------------------------------------------
?? ??? ??? 1 - filter("STATUS"='VALID')
?? ??? ?13 rows selected

?? ??? ?SQL>

?? ??? ?從上面演示可以看出，沒有使用索引的執行計劃反而比使用了索引更優。是因為status ='VALID'
?? ??? ?的選擇性并不高，基本上所有數據都滿足此條件。


****************************************************************************************************
2.分別給出一個Bitmap索引針對b-tree索引性能高和低的例子。<br>

?? ?再延用上面的數據示例，使用索引查詢所有狀態為status ='VALID' 的總數。
?? ?看到這時的執行成本 為： 5792

?? ?SQL> explain plan for select /*+ index(t idx_t_status)*/? count(0) from T? WHERE status ='VALID';
?? ?Explained

?? ?SQL> select * from table(dbms_xplan.display(null,null,'typical'));
?? ?PLAN_TABLE_OUTPUT
?? ?--------------------------------------------------------------------------------
?? ?Plan hash value: 1684240785
?? ?--------------------------------------------------------------------------------
?? ?| Id? | Operation???????? | Name???????? | Rows? | Bytes | Cost (%CPU)| Time
?? ?--------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT? |????????????? |???? 1 |???? 7 |? 5792?? (1)| 00:01:10
?? ?|?? 1 |? SORT AGGREGATE?? |????????????? |???? 1 |???? 7 |??????????? |
?? ?|*? 2 |?? INDEX RANGE SCAN| IDX_T_STATUS |? 2432K|??? 16M|? 5792?? (1)| 00:01:10
?? ?--------------------------------------------------------------------------------
?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------
?? ??? 2 - access("STATUS"='VALID')
?? ?14 rows selected

?? ?SQL>




?? ?在表T 中，刪除上一個索引，另外建立一個bitmap索引：

?? ?create Bitmap index idx_t_status on t(status);


?? ?SQL> explain plan for select count(0) from T where status ='VALID';
?? ?Explained

?? ?SQL> select * from table(dbms_xplan.display(null,null,'typical'));
?? ?PLAN_TABLE_OUTPUT
?? ?--------------------------------------------------------------------------------
?? ?Plan hash value: 1122805388
?? ?--------------------------------------------------------------------------------
?? ?| Id? | Operation?????????????????? | Name???????? | Rows? | Bytes | Cost (%CPU)
?? ?--------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT??????????? |????????????? |???? 1 |???? 7 |??? 61?? (0)
?? ?|?? 1 |? SORT AGGREGATE???????????? |????????????? |???? 1 |???? 7 |
?? ?|?? 2 |?? BITMAP CONVERSION COUNT?? |????????????? |? 2432K|??? 16M|??? 61?? (0)
?? ?|*? 3 |??? BITMAP INDEX SINGLE VALUE| IDX_T_STATUS |?????? |?????? |
?? ?--------------------------------------------------------------------------------
?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------
?? ??? 3 - access("STATUS"='VALID')
?? ?15 rows selected

?? ?SQL>

?? ?這時，系統自動走了BITMAP 索引，這時的執行成本 只有 61.優勢明顯。

****************************************************************************************************

3.演示DML操作導致位圖索引鎖定示例。<br>

?? ?3.1 建立示例數據
?? ?create table t2 as
?? ?SELECT OBJECT_ID FROM T
?? ?WHERE OBJECT_ID<10

?? ?insert into t2
?? ?SELECT OBJECT_ID FROM T
?? ?WHERE OBJECT_ID<10



?? ?select object_id,count(0) from t2
?? ?group by object_id

?? ??? ?OBJECT_ID?? ?COUNT(0)
?? ??? ?---------------------------
?? ??? ?2?? ?960
?? ??? ?3?? ?960
?? ??? ?4?? ?960
?? ??? ?5?? ?960
?? ??? ?6?? ?960
?? ??? ?7?? ?960
?? ??? ?8?? ?960
?? ??? ?9?? ?960


?? ?3.2建立bitmap 索引

?? ?create bitmap index? idx_t2_id on t2(object_id);


?? ?3.3 測試BITMAP 鎖機制
?? ?
?? ?3.3.1 在一個窗口中修改數據，把 object_id in (2,3,4) 修改為1

?? ?SQL> select distinct sid from v$mystat s;
?? ??? ??? SID
?? ?----------
?? ??? ??? ?92

?? ?SQL> update t2 set object_id=1 where object_id in (2,3,4);
?? ?2880 rows updated

?? ?SQL>

?? ?3.3.2 再開3個窗口，插入OBJECT_ID 為2，3，4 的數據，看到，都已處在鎖狀態

?? ?SQL> select distinct sid from v$mystat s;
?? ??? ??? SID
?? ?----------
?? ??? ??? ?24

?? ?SQL> insert into t2 values(2);



?? ?SQL> select distinct sid from v$mystat s;
?? ??? ??? SID
?? ?----------
?? ??? ??? 103

?? ?SQL> insert into t2 values(3);

?? ?SQL> select distinct sid from v$mystat s;
?? ??? ??? SID
?? ?----------
?? ??? ??? 146

?? ?SQL> insert into t2 values(4);


?? ?再開一個窗口，把object_id =5 的也修改成1，這時看到，也是阻塞狀態
?? ?SQL> select distinct sid from v$mystat s;
?? ??? ??? SID
?? ?----------
?? ??? ??? 157

?? ?SQL>? update t2 set object_id=1 where object_id =5;


?? ?我們再查詢表：V$LOCK;
?? ?SELECT * FROM V$LOCK L WHERE L.TYPE IN ('TX','TM');

?? ??? ?ADDR?? ??? ??? ??? ?KADDR?? ??? ??? ??? ?SID?? ?TYPE?? ?ID1?? ??? ?ID2?? ??? ?LMODE?? ?REQUEST?? ?CTIME?? ?BLOCK
?? ?1?? ?00000002B13B6190?? ?00000002B13B61E8?? ?146?? ?TX?? ??? ?655364?? ?198442?? ?0?? ??? ?4?? ??? ?430?? ??? ?0
?? ?2?? ?00000002B13B66E8?? ?00000002B13B6740?? ?103?? ?TX?? ??? ?655364?? ?198442?? ?0?? ??? ?4?? ??? ?448?? ??? ?0
?? ?3?? ?00000002B13BD508?? ?00000002B13BD560?? ?157?? ?TX?? ??? ?655364?? ?198442?? ?0?? ??? ?4?? ??? ?254?? ??? ?0
?? ?4?? ?00000002B13BD968?? ?00000002B13BD9C0?? ?24?? ?TX?? ??? ?655364?? ?198442?? ?0?? ??? ?4?? ??? ?455?? ??? ?0
?? ?5?? ?0000000015FC4270?? ?0000000015FC42D0?? ?157?? ?TM?? ??? ?94186?? ?0?? ??? ?3?? ??? ?0?? ??? ?254?? ??? ?0
?? ?6?? ?0000000015FC4270?? ?0000000015FC42D0?? ?146?? ?TM?? ??? ?94186?? ?0?? ??? ?3?? ??? ?0?? ??? ?430?? ??? ?0
?? ?7?? ?0000000015FC4270?? ?0000000015FC42D0?? ?24?? ?TM?? ??? ?91329?? ?0?? ??? ?3?? ??? ?0?? ??? ?1437?? ?0
?? ?8?? ?0000000015FC4270?? ?0000000015FC42D0?? ?24?? ?TM?? ??? ?94186?? ?0?? ??? ?3?? ??? ?0?? ??? ?455?? ??? ?0
?? ?9?? ?0000000015FC4270?? ?0000000015FC42D0?? ?103?? ?TM?? ??? ?94186?? ?0?? ??? ?3?? ??? ?0?? ??? ?448?? ??? ?0
?? ?10?? ?0000000015FC4270?? ?0000000015FC42D0?? ?92?? ?TM?? ??? ?94186?? ?0?? ??? ?3?? ??? ?0?? ??? ?479?? ??? ?0
?? ?11?? ?00000002A9EB3090?? ?00000002A9EB3108?? ?157?? ?TX?? ??? ?458765?? ?11761?? ?6?? ??? ?0?? ??? ?254?? ??? ?0
?? ?12?? ?00000002A8D0A528?? ?00000002A8D0A5A0?? ?146?? ?TX?? ??? ?589855?? ?74744?? ?6?? ??? ?0?? ??? ?430?? ??? ?0
?? ?13?? ?00000002A9EED250?? ?00000002A9EED2C8?? ?24?? ?TX?? ??? ?65539?? ?10414?? ?6?? ??? ?0?? ??? ?1437?? ?0
?? ?14?? ?00000002A9EF1A28?? ?00000002A9EF1AA0?? ?103?? ?TX?? ??? ?262165?? ?10701?? ?6?? ??? ?0?? ??? ?448?? ??? ?0
?? ?15?? ?00000002A8D15D18?? ?00000002A8D15D90?? ?92?? ?TX?? ??? ?655364?? ?198442?? ?6?? ??? ?0?? ??? ?479?? ??? ?1


?? ?可以看到第15條記錄中，進程92有一個鎖，
?? ?1-4記錄中的 146，103，157，24 進程，都在等待申請中。

?? ?這就證明，位圖索引在修改中，會把相同的索引段都加鎖，而其它的相同索引段的對應操作（添加，修改）都會被阻塞。




****************************************************************************************************
4.創建一個全文索引，比較它和傳統的模糊查詢的性能。<br>

?? ?4.1 測試環境
?? ?select count(0) from? company
?? ?union all
?? ?select count(0) from? company_text_idx

?? ?COUNT(0)
?? ?-----------
?? ?9999
?? ?9999

?? ?4.2 在傳統表中建立索引
?? ?create index idx_name on company(name);?? ?

?? ?4.3 在全文索引測試表中建立全文索引
?? ?
?? ?BEGIN
?? ?? ctx_ddl.create_preference ('my_lexer', 'chinese_vgram_lexer');
?? ?END;
/
?? ?CREATE INDEX? idx_comp_text_idx ON company_text_idx(name) indextype is ctxsys.context parameters('lexer my_lexer');


?? ?4.4全文搜索執行計劃：
?? ??? ?從執行計劃中可以看到，查詢9條記錄，成本 為：6；字節為 79130k，唯一性讀為：473

?? ??? ?SQL> select * from company_text_idx where contains(name,'王飛')>0;

?? ??? ?已選擇9行。

?? ??? ?執行計劃
?? ??? ?----------------------------------------------------------
?? ??? ?Plan hash value: 3789291194

?? ??? ?---------------------------------------------------------------------------------------------------
?? ??? ?| Id? | Operation?????????????????? | Name??????????????? | Rows? | Bytes | Cost (%CPU)| Time???? |
?? ??? ?---------------------------------------------------------------------------------------------------
?? ??? ?|?? 0 | SELECT STATEMENT??????????? |???????????????????? |???? 5 | 79130 |???? 6?? (0)| 00:00:01 |
?? ??? ?|?? 1 |? TABLE ACCESS BY INDEX ROWID|??? COMPANY_TEXT_IDX |???? 5 | 79130 |???? 6?? (0)| 00:00:01 |
?? ??? ?|*? 2 |?? DOMAIN INDEX????????????? | IDX_COMP_TEXT_IDX?? |?????? |?????? |???? 4?? (0)| 00:00:01 |
?? ??? ?---------------------------------------------------------------------------------------------------

?? ??? ?Predicate Information (identified by operation id):
?? ??? ?---------------------------------------------------

?? ??? ??? 2 - access("CTXSYS"."CONTAINS"("NAME",'王飛')>0)

?? ??? ?Note
?? ??? ?-----
?? ??? ??? - dynamic sampling used for this statement (level=2)


?? ??? ?統計信息
?? ??? ?----------------------------------------------------------
?? ??? ??? ??? ?137? recursive calls
?? ??? ??? ??? ?? 0? db block gets
?? ??? ??? ??? ?473? consistent gets
?? ??? ??? ??? ?? 0? physical reads
?? ??? ??? ??? ?? 0? redo size
?? ??? ??? ?? 34324? bytes sent via SQL*Net to client
?? ??? ??? ?? 22618? bytes received via SQL*Net from client
?? ??? ??? ??? ? 78? SQL*Net roundtrips to/from client
?? ??? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ??? ?? 0? sorts (disk)
?? ??? ??? ??? ?? 9? rows processed

?? ?4.5傳統計索引搜索計劃：
?? ??? ?執行成本 為9，唯一性讀為91，字節為 138K,
?? ??? ?成本比全文搜索差一些。但讀取的字節數少，唯一性讀也少。從這里也可以看到，全文檢索使用了更大的存儲空間。


?? ??? ?SQL> select * from? company where name like '王飛%';

?? ??? ?已選擇9行。


?? ??? ?執行計劃
?? ??? ?----------------------------------------------------------
?? ??? ?Plan hash value: 1068597349

?? ??? ?------------------------------------------------------------------------------------------
?? ??? ?| Id? | Operation?????????????????? | Name?????? | Rows? | Bytes | Cost (%CPU)| Time???? |
?? ??? ?------------------------------------------------------------------------------------------
?? ??? ?|?? 0 | SELECT STATEMENT??????????? |??????????? |???? 9 |?? 138K|???? 9?? (0)| 00:00:01 |
?? ??? ?|?? 1 |? TABLE ACCESS BY INDEX ROWID|??? COMPANY |???? 9 |?? 138K|???? 9?? (0)| 00:00:01 |
?? ??? ?|*? 2 |?? INDEX RANGE SCAN????????? | IDX_NAME?? |???? 9 |?????? |???? 2?? (0)| 00:00:01 |
?? ??? ?------------------------------------------------------------------------------------------

?? ??? ?Predicate Information (identified by operation id):
?? ??? ?---------------------------------------------------

?? ??? ??? 2 - access("NAME" LIKE '王飛%')
?? ??? ??? ??? filter("NAME" LIKE '王飛%')

?? ??? ?Note
?? ??? ?-----
?? ??? ??? - dynamic sampling used for this statement (level=2)


?? ??? ?統計信息
?? ??? ?----------------------------------------------------------
?? ??? ??? ??? ?? 9? recursive calls
?? ??? ??? ??? ?? 0? db block gets
?? ??? ??? ??? ? 91? consistent gets
?? ??? ??? ??? ?? 0? physical reads
?? ??? ??? ??? ?? 0? redo size
?? ??? ??? ?? 34236? bytes sent via SQL*Net to client
?? ??? ??? ?? 22618? bytes received via SQL*Net from client
?? ??? ??? ??? ? 78? SQL*Net roundtrips to/from client
?? ??? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ??? ?? 0? sorts (disk)
?? ??? ??? ??? ?? 9? rows processed

?? ??? ?SQL>
?? ?4.6 再換一個傳統查詢中，包含條件的執行計劃。
?? ?這時可以看到，無法使用索引了，成本達到了 254,唯一性讀也達到了987。


?? ?SQL> select * from? company where name like '%王飛%';

?? ?已選擇9行。


?? ?執行計劃
?? ?----------------------------------------------------------
?? ?Plan hash value: 1376141687

?? ?--------------------------------------------------------------------------------
?? ?| Id? | Operation???????? | Name?????? | Rows? | Bytes | Cost (%CPU)| Time???? |
?? ?--------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT? |??????????? |??? 26 |?? 401K|?? 254?? (0)| 00:00:04 |
?? ?|*? 1 |? TABLE ACCESS FULL|??? COMPANY |??? 26 |?? 401K|?? 254?? (0)| 00:00:04 |
?? ?--------------------------------------------------------------------------------

?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------

?? ??? 1 - filter("NAME" IS NOT NULL AND "NAME" LIKE '%王飛%')

?? ?Note
?? ?-----
?? ??? - dynamic sampling used for this statement (level=2)


?? ?統計信息
?? ?----------------------------------------------------------
?? ??? ??? ?? 5? recursive calls
?? ??? ??? ?? 0? db block gets
?? ??? ??? ?987? consistent gets
?? ??? ??? ?? 0? physical reads
?? ??? ??? ?? 0? redo size
?? ??? ?? 34324? bytes sent via SQL*Net to client
?? ??? ?? 22618? bytes received via SQL*Net from client
?? ??? ??? ? 78? SQL*Net roundtrips to/from client
?? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ?? 0? sorts (disk)
?? ??? ??? ?? 9? rows processed

?? ?SQL>

?? ?從上面的3個執行計劃中可以看出，全文檢索的性能及搜索靈活性在包含條件下的查詢，是更高的。
?? ?但也使用了更多的存儲空間。


****************************************************************************************************

5.分別演示分區索引的性能優化全局索引和差于全局索引的示例，并分析原因。<br>（邊城日志 2013/11/15 15：50）

?? ?5.1構建演示環境：
?? ?
?? ?在一現有示例表中，基本每月有3000條記錄，現另建立表個表，按季度分區保存。

?? ?select to_char(po_dt,'yyyymm') as ym,count(0) from po
?? ?group by to_char(po_dt,'yyyymm')
?? ?order by
?? ?to_char(po_dt,'yyyymm')

?? ??? ?YM?? ?COUNT(0)
?? ??? ?----------------
?? ?1?? ?201001?? ?3099
?? ?2?? ?201002?? ?2800
?? ?3?? ?201003?? ?3100
?? ?4?? ?201004?? ?3000
?? ?5?? ?201005?? ?3100
?? ?6?? ?201006?? ?3000
?? ?7?? ?201007?? ?3100
?? ?8?? ?201008?? ?3100
?? ?9?? ?201009?? ?3000
?? ?10?? ?201010?? ?3100
?? ?11?? ?201011?? ?3000
?? ?12?? ?201012?? ?3100
?? ?13?? ?201101?? ?3100
?? ?14?? ?201102?? ?2800
?? ?15?? ?201103?? ?3100
?? ?16?? ?201104?? ?3000
?? ?17?? ?201105?? ?1500


?? ?--3個月一個分區
?? ?CREATE TABLE PO_R
?? (? POID NUMBER(10,0),
? QTY NUMBER(10,2),
? AMOUNT NUMBER(10,2),
? AUDIT_FLG NUMBER(1,0) DEFAULT 0,
? PO_DT DATE
?? )
?? ?PARTITION BY RANGE (PO_DT)
?? ?? INTERVAL (NUMTOYMINTERVAL(3, 'MONTH'))
?? ?? (PARTITION P1 VALUES LESS THAN (TO_DATE('2010-01-01', 'YYYY-MM-DD')))
?? ?? ;

?? ?insert into po_r
?? ?select * from PO
?? ?commit;



?? ?每個分區的數據量
?? ?select t.partition_name,t.num_rows
?? ?from all_tab_partitions t where table_name='PO_R'
?? ?
?? ??? ?PARTITION_NAME?? ?NUM_ROWS
?? ??? ?-------------------------------
?? ?1?? ?P1?? ?0
?? ?2?? ?SYS_P141?? ?8999
?? ?3?? ?SYS_P142?? ?9100
?? ?4?? ?SYS_P143?? ?9200
?? ?5?? ?SYS_P144?? ?9200
?? ?6?? ?SYS_P145?? ?9000
?? ?7?? ?SYS_P146?? ?4500



?? ?5.2.我用兩種索引來進行對比：

?? ?5.2.1 全局索引
?? ?create index IDX_PO_R_ID_GLOBAL on PO_R (poid);

?? ?5.2.2 分區索引
?? ?create index IDX_PO_R_ID_LOCAL on PO_R (POID)
?? ?? local;
?? ?
?? ?以下為兩次不同索引下的執行計劃：
?? ?全局索引：成本：1869，唯一性讀2403，總字節：187K
?? ?分區索引：成本：1871，唯一性讀2412，總字節：187K

?? ?對比看出，全局索引稍勝于分區索引

?? ?SQL> set autotrace on
?? ?SQL> set autotrace traceonly

?? ?SQL> select /*+INDEX(p IDX_PO_R_ID_GLOBAL)*/ * from po_r p where poid between 500? and 7900;

?? ?7401 rows selected.


?? ?Execution Plan
?? ?----------------------------------------------------------
?? ?Plan hash value: 1901754288

?? ?-------------------------------------------------------------------------------------------------------------------------
?? ?| Id? | Operation????????????????????????? | Name?????????????? | Rows? | Bytes | Cost (%CPU)| Time? | Pstart| Pstop |
?? ?-------------------------------------------------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT?????????????????? |??????????????????? |? 7402 |?? 187K|? 1868?? (1)| 00:00:23 |?????? |?????? |
?? ?|?? 1 |? TABLE ACCESS BY GLOBAL INDEX ROWID| PO_R?????????????? |? 7402 |?? 187K|? 1868?? (1)| 00:00:23 | ROWID | ROWID |
?? ?|*? 2 |?? INDEX RANGE SCAN???????????????? | IDX_PO_R_ID_GLOBAL |? 7402 |?????? |??? 21?? (0)| 00:00:01 |?????? |?????? |
?? ?-------------------------------------------------------------------------------------------------------------------------

?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------

?? ??? 2 - access("POID">=500 AND "POID"<=7900)


?? ?Statistics
?? ?----------------------------------------------------------
?? ??? ??? ?? 1? recursive calls
?? ??? ??? ?? 0? db block gets
?? ??? ??? 2403? consistent gets
?? ??? ??? ? 19? physical reads
?? ??? ??? ?? 0? redo size
?? ??? ? 231787? bytes sent via SQL*Net to client
?? ??? ??? 5942? bytes received via SQL*Net from client
?? ??? ??? ?495? SQL*Net roundtrips to/from client
?? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ?? 0? sorts (disk)
?? ??? ??? 7401? rows processed

?? ?SQL> select /*+INDEX(p IDX_PO_R_ID_LOCAL)*/ * from po_r p where poid between 500? and 7900;

?? ?7401 rows selected.


?? ?Execution Plan
?? ?----------------------------------------------------------
?? ?Plan hash value: 3357987540

?? ?------------------------------------------------------------------------------------------------------------------------
?? ?| Id? | Operation????????????????????????? | Name????????????? | Rows? | Bytes | Cost (%CPU)| Time???? | Pstart| Pstop |
?? ?------------------------------------------------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT?????????????????? |?????????????????? |? 7402 |?? 187K|? 1871?? (1)| 00:00:23 |?????? |?????? |
?? ?|?? 1 |? PARTITION RANGE ALL?????????????? |?????????????????? |? 7402 |?? 187K|? 1871?? (1)| 00:00:23 |???? 1 |1048575|
?? ?|?? 2 |?? TABLE ACCESS BY LOCAL INDEX ROWID| PO_R????????????? |? 7402 |?? 187K|? 1871?? (1)| 00:00:23 |???? 1 |1048575|
?? ?|*? 3 |??? INDEX RANGE SCAN??????????????? | IDX_PO_R_ID_LOCAL |? 7402 |?????? |??? 24?? (0)| 00:00:01 |???? 1 |1048575|
?? ?------------------------------------------------------------------------------------------------------------------------

?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------

?? ??? 3 - access("POID">=500 AND "POID"<=7900)


?? ?Statistics
?? ?----------------------------------------------------------
?? ??? ??? ?? 1? recursive calls
?? ??? ??? ?? 0? db block gets
?? ??? ??? 2412? consistent gets
?? ??? ??? ? 21? physical reads
?? ??? ??? ?? 0? redo size
?? ??? ? 231787? bytes sent via SQL*Net to client
?? ??? ??? 5942? bytes received via SQL*Net from client
?? ??? ??? ?495? SQL*Net roundtrips to/from client
?? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ?? 0? sorts (disk)
?? ??? ??? 7401? rows processed

?? ?SQL>?? ?


?? ?5.3再看一個演示，也是全局索引稍勝于分區索引

?? ?SQL> select /*+INDEX(p IDX_PO_R_ID_LOCAL)*/ * from po_r p where poid = 80;


?? ?Execution Plan
?? ?----------------------------------------------------------
?? ?Plan hash value: 3357987540

?? ?------------------------------------------------------------------------------------------------------------------------
?? ?| Id? | Operation????????????????????????? | Name????????????? | Rows? | Bytes | Cost (%CPU)| Time???? | Pstart| Pstop |
?? ?------------------------------------------------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT?????????????????? |?????????????????? |???? 1 |??? 26 |???? 9?? (0)| 00:00:01 |?????? |?????? |
?? ?|?? 1 |? PARTITION RANGE ALL?????????????? |?????????????????? |???? 1 |??? 26 |???? 9?? (0)| 00:00:01 |???? 1 |1048575|
?? ?|?? 2 |?? TABLE ACCESS BY LOCAL INDEX ROWID| PO_R????????????? |???? 1 |??? 26 |???? 9?? (0)| 00:00:01 |???? 1 |1048575|
?? ?|*? 3 |??? INDEX RANGE SCAN??????????????? | IDX_PO_R_ID_LOCAL |???? 1 |?????? |???? 8?? (0)| 00:00:01 |???? 1 |1048575|
?? ?------------------------------------------------------------------------------------------------------------------------

?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------

?? ??? 3 - access("POID"=80)


?? ?Statistics
?? ?----------------------------------------------------------
?? ??? ??? ?? 1? recursive calls
?? ??? ??? ?? 0? db block gets
?? ??? ??? ? 14? consistent gets
?? ??? ??? ?? 1? physical reads
?? ??? ??? ?? 0? redo size
?? ??? ??? ?811? bytes sent via SQL*Net to client
?? ??? ??? ?519? bytes received via SQL*Net from client
?? ??? ??? ?? 2? SQL*Net roundtrips to/from client
?? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ?? 0? sorts (disk)
?? ??? ??? ?? 1? rows processed

?? ?SQL> select /*+INDEX(p IDX_PO_R_ID_GLOBAL)*/ * from po_r p where poid = 80;


?? ?Execution Plan
?? ?----------------------------------------------------------
?? ?Plan hash value: 1901754288

?? ?-------------------------------------------------------------------------------------------------------------------------
?? ?| Id? | Operation????????????????????????? | Name?????????????? | Rows? | Bytes | Cost (%CPU)| Time? | Pstart| Pstop |
?? ?-------------------------------------------------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT?????????????????? |??????????????????? |???? 1 |??? 26 |???? 2?? (0)| 00:00:01 |?????? |?????? |
?? ?|?? 1 |? TABLE ACCESS BY GLOBAL INDEX ROWID| PO_R?????????????? |???? 1 |??? 26 |???? 2?? (0)| 00:00:01 | ROWID | ROWID |
?? ?|*? 2 |?? INDEX RANGE SCAN???????????????? | IDX_PO_R_ID_GLOBAL |???? 1 |?????? |???? 1?? (0)| 00:00:01 |?????? |?????? |
?? ?-------------------------------------------------------------------------------------------------------------------------

?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------

?? ??? 2 - access("POID"=80)


?? ?Statistics
?? ?----------------------------------------------------------
?? ??? ??? ?? 1? recursive calls
?? ??? ??? ?? 0? db block gets
?? ??? ??? ?? 4? consistent gets
?? ??? ??? ?? 1? physical reads
?? ??? ??? ?? 0? redo size
?? ??? ??? ?811? bytes sent via SQL*Net to client
?? ??? ??? ?519? bytes received via SQL*Net from client
?? ??? ??? ?? 2? SQL*Net roundtrips to/from client
?? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ?? 0? sorts (disk)
?? ??? ??? ?? 1? rows processed

?? ?SQL>
?? ?
?? ?5.4是不是全局索引就一定比分區索引更優呢，下面 我使用PO_DT 字段來建立索引。
?? ?從下面的執行計劃中可以看出：
?? ?這時的分區索引是稍優全局索引的。
?? ?所以就性能上來說，并不能武斷的說明哪咱索引更優。因為不管是哪種索引，在查詢時，都是查詢某一段(或一條)。
?? ?然后查詢對應一段(或一條)的數據


?? ?SQL> select? * from po_r p where PO_DT=TO_DATE('20100606','YYYYMMDD');

?? ?100 rows selected.


?? ?Execution Plan
?? ?----------------------------------------------------------
?? ?Plan hash value: 3172462535

?? ?-----------------------------------------------------------------------------------------------------------------------
?? ?| Id? | Operation????????????????????????? | Name???????????? | Rows? | Bytes | Cost (%CPU)| Time???? | Pstart| Pstop |
?? ?-----------------------------------------------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT?????????????????? |????????????????? |?? 100 |? 2600 |???? 4?? (0)| 00:00:01 |?????? |?????? |
?? ?|?? 1 |? PARTITION RANGE SINGLE??????????? |????????????????? |?? 100 |? 2600 |???? 4?? (0)| 00:00:01 |???? 3 |???? 3 |
?? ?|?? 2 |?? TABLE ACCESS BY LOCAL INDEX ROWID| PO_R???????????? |?? 100 |? 2600 |???? 4?? (0)| 00:00:01 |???? 3 |???? 3 |
?? ?|*? 3 |??? INDEX RANGE SCAN??????????????? | IDX_POR_DT_LOCAL |?? 100 |?????? |???? 1?? (0)| 00:00:01 |???? 3 |???? 3 |
?? ?-----------------------------------------------------------------------------------------------------------------------

?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------

?? ??? 3 - access("PO_DT"=TO_DATE(' 2010-06-06 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))


?? ?Statistics
?? ?----------------------------------------------------------
?? ??? ??? ?? 1? recursive calls
?? ??? ??? ?? 0? db block gets
?? ??? ??? ? 18? consistent gets
?? ??? ??? ?? 1? physical reads
?? ??? ??? ?? 0? redo size
?? ??? ??? 4026? bytes sent via SQL*Net to client
?? ??? ??? ?585? bytes received via SQL*Net from client
?? ??? ??? ?? 8? SQL*Net roundtrips to/from client
?? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ?? 0? sorts (disk)
?? ??? ??? ?100? rows processed

?? ?SQL> select? * from po_r p where PO_DT=TO_DATE('20100606','YYYYMMDD');

?? ?100 rows selected.


?? ?Execution Plan
?? ?----------------------------------------------------------
?? ?Plan hash value: 3915168380

?? ?------------------------------------------------------------------------------------------------------------------------
?? ?| Id? | Operation????????????????????????? | Name????????????? | Rows? | Bytes | Cost (%CPU)| Time???? | Pstart| Pstop |
?? ?------------------------------------------------------------------------------------------------------------------------
?? ?|?? 0 | SELECT STATEMENT?????????????????? |?????????????????? |?? 100 |? 2600 |???? 5?? (0)| 00:00:01 |?????? |?????? |
?? ?|?? 1 |? TABLE ACCESS BY GLOBAL INDEX ROWID| PO_R????????????? |?? 100 |? 2600 |???? 5?? (0)| 00:00:01 |???? 3 |???? 3 |
?? ?|*? 2 |?? INDEX RANGE SCAN???????????????? | IDX_POR_DT_GLOBAL |?? 100 |?????? |???? 1?? (0)| 00:00:01 |?????? |?????? |
?? ?------------------------------------------------------------------------------------------------------------------------

?? ?Predicate Information (identified by operation id):
?? ?---------------------------------------------------

?? ??? 2 - access("PO_DT"=TO_DATE(' 2010-06-06 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))


?? ?Statistics
?? ?----------------------------------------------------------
?? ??? ??? ?? 1? recursive calls
?? ??? ??? ?? 0? db block gets
?? ??? ??? ? 18? consistent gets
?? ??? ??? ?? 2? physical reads
?? ??? ??? ?? 0? redo size
?? ??? ??? 4026? bytes sent via SQL*Net to client
?? ??? ??? ?585? bytes received via SQL*Net from client
?? ??? ??? ?? 8? SQL*Net roundtrips to/from client
?? ??? ??? ?? 0? sorts (memory)
?? ??? ??? ?? 0? sorts (disk)
?? ??? ??? ?100? rows processed

?? ?SQL>

總結

以上是生活随笔為你收集整理的【性能优化】之 BITMAP 及分区表 的演示的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。