[20120509]IOT索引組織表相關資訊的學習(三).txt
[20120509]IOT索引組織表相關資訊的學習(三).txt
上次連結:
http://space.itpub.net/267265/viewspace-719517
http://space.itpub.net/267265/viewspace-717272
IOT 是一種特殊的索引結構,使用它能夠解決特定場合的應用問題,但是在許多應用中很少使用,更多的是使用堆表。
我僅僅在生產系統中對3個表使用,我偏向使用靜態以及"只讀"的小表。
如果IOT表存在除主鍵外的第2索引,如果使用它存在物理猜"physical guess",今天測試一下move IOT表看看,第2索引的一些變化。
1.測試環境:
4.移動IOT表空間
--移動IOT後,第2索引的PCT_DIRECT_ACCESS=0
--而IOT表的第2索引記錄的是主鍵以及對應IOT塊號,這樣IOT表移動後,第2索引記錄的主鍵依舊沒有變化,僅僅ioT表的塊號發生了變化。
--這樣使用第2索引查詢是物理猜失敗,僅僅透過主鍵能夠查詢到資訊,這樣邏輯讀會增加。
5.重新rebuild第2索引或者修改索引塊的相關資訊
總結:在移動IOT表後,第2索引的物理猜應該都會失敗,如果想提高第2索引的訪問效率,應該reuild或者使用ALTER INDEX XXX UPDATE BLOCK REFERENCES來索引塊的相關資訊。
上次連結:
http://space.itpub.net/267265/viewspace-719517
http://space.itpub.net/267265/viewspace-717272
IOT 是一種特殊的索引結構,使用它能夠解決特定場合的應用問題,但是在許多應用中很少使用,更多的是使用堆表。
我僅僅在生產系統中對3個表使用,我偏向使用靜態以及"只讀"的小表。
如果IOT表存在除主鍵外的第2索引,如果使用它存在物理猜"physical guess",今天測試一下move IOT表看看,第2索引的一些變化。
1.測試環境:
SQL> select * from v$version ;
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
PL/SQL Release 11.2.0.1.0 - Production
CORE 11.2.0.1.0 Production
TNS for Linux: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> create table t_iot ( a varchar2(10),b varchar2(10),vc varchar2(1200), constraint t_iot_pk PRIMARY KEY(a)) ORGANIZATION INDEX;
SQL> create index i_t_iot_b on t_iot(b);
insert into t_iot values ('1' ,'a',lpad('a',1000,'a'));
insert into t_iot values ('22' ,'b',lpad('a',1000,'a'));
insert into t_iot values ('333' ,'c',lpad('a',1000,'a'));
insert into t_iot values ('4444' ,'d',lpad('a',1000,'a'));
insert into t_iot values ('55555' ,'e',lpad('a',1000,'a'));
insert into t_iot values ('666666' ,'f',lpad('a',1000,'a'));
insert into t_iot values ('7777777' ,'g',lpad('a',1000,'a'));
insert into t_iot values ('88888888' ,'h',lpad('a',1000,'a'));
insert into t_iot values ('999999999','i',lpad('a',1000,'a'));
commit ;
SQL> exec dbms_stats.gather_table_stats(ownname=>USER, tabname=>'T_iot');
PL/SQL procedure successfully completed.
SQL> select index_name, index_type, pct_direct_access from user_indexes where index_name = 'I_T_IOT_B';
INDEX_NAME INDEX_TYPE PCT_DIRECT_ACCESS
------------------------------ --------------------------- -----------------
I_T_IOT_B NORMAL 22
SQL> SELECT index_name, table_name, blevel, leaf_blocks FROM dba_indexes WHERE table_name = 'T_IOT';
INDEX_NAME TABLE_NAME BLEVEL LEAF_BLOCKS
------------------------------ ------------------------------ ---------- -----------
T_IOT_PK T_IOT 1 2
I_T_IOT_B T_IOT 0 1
--PCT_DIRECT_ACCESS=22可以確定由於插入導致索引分裂,第2索引的物理猜都是失敗的多。
2.先修復看看。
SQL> ALTER INDEX I_T_IOT_B UPDATE BLOCK REFERENCES;
Index altered.
SQL> select index_name, index_type, pct_direct_access from user_indexes where index_name = 'I_T_IOT_B';
INDEX_NAME INDEX_TYPE PCT_DIRECT_ACCESS
------------------------------ --------------------------- -----------------
I_T_IOT_B NORMAL 22
SQL> exec dbms_stats.gather_table_stats(ownname=>USER, tabname=>'T_iot');
PL/SQL procedure successfully completed.
SQL> select index_name, index_type, pct_direct_access from user_indexes where index_name = 'I_T_IOT_B';
INDEX_NAME INDEX_TYPE PCT_DIRECT_ACCESS
------------------------------ --------------------------- -----------------
I_T_IOT_B NORMAL 100
--PCT_DIRECT_ACCESS=100.
3.查詢看看:
SQL> set autot traceonly ;
SQL> select vc from t_iot where b='a';
Execution Plan
----------------------------------------------------------
Plan hash value: 1095339046
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1003 | 1 (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| T_IOT_PK | 1 | 1003 | 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN| I_T_IOT_B | 1 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("B"='a')
2 - access("B"='a')
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
1523 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--邏輯讀=3
4.移動IOT表空間
SQL> alter table t_iot move tablespace users;
Table altered.
SQL> SELECT index_name, table_name, blevel, leaf_blocks,STATUS FROM dba_indexes WHERE table_name = 'T_IOT';
INDEX_NAME TABLE_NAME BLEVEL LEAF_BLOCKS STATUS
------------------------------ ------------------------------ ---------- ----------- --------
T_IOT_PK T_IOT 1 2 VALID
I_T_IOT_B T_IOT 0 1 VALID
--可以發現第2索引依舊有效,不像堆表,如果move後,表記錄的rowid發生了變化,這樣其他的索引記錄的rowid與原來對不上,
--索引必然處於novalid的狀態,必須rebuild。
SQL> select index_name, index_type, pct_direct_access from user_indexes where index_name = 'I_T_IOT_B';
INDEX_NAME INDEX_TYPE PCT_DIRECT_ACCESS
------------------------------ --------------------------- -----------------
I_T_IOT_B NORMAL 0
--移動IOT後,第2索引的PCT_DIRECT_ACCESS=0
--而IOT表的第2索引記錄的是主鍵以及對應IOT塊號,這樣IOT表移動後,第2索引記錄的主鍵依舊沒有變化,僅僅ioT表的塊號發生了變化。
--這樣使用第2索引查詢是物理猜失敗,僅僅透過主鍵能夠查詢到資訊,這樣邏輯讀會增加。
SQL> set autot traceonly
SQL> select vc from t_iot where b='a';
Execution Plan
----------------------------------------------------------
Plan hash value: 1095339046
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1003 | 2 (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| T_IOT_PK | 1 | 1003 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN| I_T_IOT_B | 1 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("B"='a')
2 - access("B"='a')
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
1523 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--邏輯讀=4.
5.重新rebuild第2索引或者修改索引塊的相關資訊
SQL> ALTER INDEX I_T_IOT_B UPDATE BLOCK REFERENCES;
或者
SQL> alter index i_t_iot_b rebuild ;
--再次執行查詢:
SQL> set autot traceonly
SQL> select vc from t_iot where b='a';
Execution Plan
----------------------------------------------------------
Plan hash value: 1095339046
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 1003 | 1 (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| T_IOT_PK | 1 | 1003 | 1 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN| I_T_IOT_B | 1 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - access("B"='a')
2 - access("B"='a')
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
3 consistent gets
0 physical reads
0 redo size
1523 bytes sent via SQL*Net to client
520 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
--邏輯讀=3.
SQL> select index_name, index_type, pct_direct_access from user_indexes where index_name = 'I_T_IOT_B';
INDEX_NAME INDEX_TYPE PCT_DIRECT_ACCESS
------------------------------ --------------------------- -----------------
I_T_IOT_B NORMAL 100
總結:在移動IOT表後,第2索引的物理猜應該都會失敗,如果想提高第2索引的訪問效率,應該reuild或者使用ALTER INDEX XXX UPDATE BLOCK REFERENCES來索引塊的相關資訊。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/267265/viewspace-723115/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料表相關操作
- MySQL學習筆記:組合索引-索引下推MySql筆記索引
- MYSQL學習(三) --索引詳解MySql索引
- 埋點表相關
- 一個關於組織學員學習技術的筆試題--求討論筆試
- Accelerated C++學習筆記--組織程式和資料C++筆記
- 關於轉儲Oracle索引資訊的相關命令Oracle索引
- HomeAssistantOS和docker的組織關係Docker
- [20210409]關於X$KCCDI的scn資訊.txt
- Mysql運維-資料庫及表相關操作MySql運維資料庫
- [20181123]關於降序索引問題.txt索引
- MySQL學習筆記:組合索引-最左原則MySql筆記索引
- [20190918]關於函式索引問題.txt函式索引
- [20210520]關於主鍵索引問題.txt索引
- MySQL索引統計資訊更新相關的引數MySql索引
- 學習資料庫索引機制資料庫索引
- 機器學習資源收集、索引機器學習索引
- FB被曝收集兒童資訊 多個保護組織呼籲關閉相關應用
- [20181124]關於降序索引問題4.txt索引
- [20181124]關於降序索引問題3.txt索引
- [20181124]關於降序索引問題2.txt索引
- [20190910]關於降序索引問題5.txt索引
- nodejs學習心得(三)fs模組NodeJS
- Elasticsearch 學習索引Elasticsearch索引
- MySQL學習 - 索引MySql索引
- 三維基因組相關資源
- 在樂位元組學習的第三天
- mybatise外掛反向生成資料庫表相關Java程式碼MyBatis資料庫Java
- 組織程式和資料
- 【深度學習】深度解讀:深度學習在IoT大資料和流分析中的應用深度學習大資料
- 危言聳聽?到2025年,30%的關鍵資訊基礎設施組織將遭遇安全漏洞
- [20191206]確定sys.file$相關資訊.txt
- Angular學習(三):元件-元件間的通訊Angular元件
- 三面位元組跳動,拿到Offer的我,分享閉關秘籍(複習要領+學習合集)
- 三大黑產組織情報!郵件釣魚背後操控的緬北魔方G組織
- MySQL鎖表相關問題查詢思路MySql
- MySQL學習之索引MySql索引
- [20230306]學習UNIFIED audit--dg相關問題.txtNifi
- 檢視錶和索引碎片情況相關資訊索引