2. 程式人生 > 其它 >關於虛擬索引的學習（r3筆記第75天)

關於虛擬索引的學習（r3筆記第75天)

阿新 • • 發佈：2022-05-04

昨天簡單總結了下不可見索引，今天來說說虛擬索引。 這兩個索引聽起來有點類似。其實差別還是比較大。 不可見索引有對應的索引段，而虛擬索引沒有對應的索引段存在。 不可見索引可以通過alter語句來直接切換可見不可見。而對於虛擬索引而言這些操作都不支援。 不可見索引可以在user_indexes中查到對應的資料字典資訊。但是虛擬索引在user_indexes中都沒有記錄，最後只能從dba_objects裡面勉強查到一條它存在的記錄。 不可見索引和虛擬索引都有對應的資料庫引數，可以通過alter session,system來修改生效。 不可見索引在優化器中進行了遮蔽，使得索引的可見/不可見都可以靈活的切換，而虛擬索引是在希望在優化器中做標識，使得語句的執行計劃能夠考慮到對應的虛擬索引的作用。 個人覺得，在日常的使用中對於索引建立存在爭議的場景中，可以考慮使用虛擬索引，來通過檢視執行計劃來比較前後的變化。如果提升的幅度很大，再考慮建立對應的索引。 我們來舉個簡單的例子來說明一下虛擬索引。 我們來建立一個表，然後首先驗證建立一個普通索引驗證索引能夠正常啟用，然後刪除索引，建立虛擬索引來看看語句的執行情況。 建立表t SQL> create table t as select *from dba_objects where object_id is not null and rownum<100000; Table created.

然後隨機抽取4條資料。 SQL> select *from (select object_id from t order by dbms_random.value()) where rownum<5; OBJECT_ID ---------- 22969 20703 13851 8040 SQL> set autot trace exp stat 我們來看看當前的執行計劃，因為沒有索引，索引會走全表掃描。


SQL> select *from t where object_id=8040;
Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1233 |   249K|   267   (2)| 00:00:04 |
|*  1 |  TABLE ACCESS FULL| T    |  1233 |   249K|   267   (2)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_ID"=8040)
Statistics
----------------------------------------------------------
         18  recursive calls
          0  db block gets
       1525  consistent gets
          0  physical reads
          0  redo size
       1632  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

我們建立對應的索引。來看看語句的執行情況。


SQL> create unique index inx_t on t(object_id) ;
Index created.
SQL> select *from t where object_id=8040;
Execution Plan
----------------------------------------------------------
Plan hash value: 1855406669
-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |     1 |   207 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T     |     1 |   207 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | INX_T |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("OBJECT_ID"=8040)
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          3  consistent gets
          1  physical reads
          0  redo size
       1499  bytes sent via SQL*Net to client
        509  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

刪除索引，建立一個虛擬索引。來對比一下執行計劃的情況。

SQL> drop index inx_t;
Index dropped.
SQL> create unique index inx_t on t(object_id) nosegment;
Index created.
SQL> select *from t where object_id=8040;
Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1233 |   249K|   267   (2)| 00:00:04 |
|*  1 |  TABLE ACCESS FULL| T    |  1233 |   249K|   267   (2)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_ID"=8040)
Statistics
----------------------------------------------------------
          9  recursive calls
          0  db block gets
       1487  consistent gets
          0  physical reads
          0  redo size
       1632  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

發現建立了虛擬索引之後，這個測試的效果跟沒有建立一樣。我們來看看使用hint是否有作用。


SQL> select /*+index(t inx_t)*/ *from t where object_id=8040;
Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  1233 |   249K|   267   (2)| 00:00:04 |
|*  1 |  TABLE ACCESS FULL| T    |  1233 |   249K|   267   (2)| 00:00:04 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   1 - filter("OBJECT_ID"=8040)
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       1483  consistent gets
          0  physical reads
          0  redo size
       1632  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

這個時候，我們得知虛擬索引沒有啟用，至於啟用的方法，就是通過一個數據庫引數_use_nosegment_indexes來實現。可以在session,system級別做設定。一般來說我們在session級做簡單的對比測試，如果執行計劃的效果提升很多，然後可以根據情況再建立存在段的索引。或者在系統級開啟這個開關。 我們先在session級別開啟。

SQL> alter session set "_USE_NOSEGMENT_INDEXES" = true;
Session altered.

我們來檢視一下語句的執行情況。

SQL> select *from t where object_id=8040;
Execution Plan
----------------------------------------------------------
Plan hash value: 1855406669
-------------------------------------------------------------------------------------
| Id  | Operation                   | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |       |     1 |   207 |     1   (0)| 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID| T     |     1 |   207 |     1   (0)| 00:00:01 |
|*  2 |   INDEX UNIQUE SCAN         | INX_T |     1 |       |     1   (0)| 00:00:01 |
-------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("OBJECT_ID"=8040)
Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       1483  consistent gets
          0  physical reads
          0  redo size
       1632  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

可以看到，索引被啟用了。其實這個過程中的資源消耗很低，因為沒有對應的索引段存在，完全是根據優化器的判斷。 我們關閉這個開關。

SQL> alter session set "_USE_NOSEGMENT_INDEXES" = false;
Session altered.

嘗試使用alter語句來rebuild這個虛擬索引。

SQL> alter index inx_t rebuild;
alter index inx_t rebuild
*
ERROR at line 1:
ORA-08114: can not alter a fake index

alter語句在虛擬索引中式不支援的。 我們來查查資料字典裡的資訊。

SQL> set autot off
SQL>  select segment_name,segment_type,blocks from user_segments where segment_name='INX_T';
no rows selected
SQL> select index_name ,dropped ,segment_created from user_indexes where index_name='INX_T';
no rows selected
在user_segments,user_indexes中都沒有對應的記錄存在，我都懷疑索引是否存在。
SQL> create unique index inx_t on t(object_id) nosegment;
create unique index inx_t on t(object_id) nosegment
                    *
ERROR at line 1:
ORA-00955: name is already used by an existing object

最後在dba_objects裡面終於找到一條記錄。

SQL> select object_name, object_type from dba_objects where object_name = 'INX_T';
OBJECT_NAME                                                                                                                      OBJECT_TYPE
-------------------------------------------------------------------------------------------------------------------------------- -------------------
INX_T                                                                                                                            INDEX

關於虛擬索引，可以在metalink上參考Virtual Indexes (Doc ID 1401046.1)

相關推薦

關於虛擬索引的學習（r3筆記第75天)

昨天簡單總結了下不可見索引，今天來說說虛擬索引。 這兩個索引聽起來有點類似。其實差別還是比較大。

關於糾結的recycle pool的設定（r3筆記第5天)

現在生產環境中目前有一個很大的中繼表，作為多個流程的資料流動所用，資料量很大。裡面有clob欄位，加上龐大的資料量，表就顯得很臃腫了。

shell基礎學習總結(二) (r3筆記第72天)

-->關於shell程式設計之檔案比較 可以使用如下的選項來做檔案的比較。有了這些選項，檔案的比較來說都是遊刃有餘。

生產環境大型sql語句調優實戰第一篇（一） （r2筆記第31天）

在生產環境中有一條sql語句的效能極差，在早晨非高峰時段執行抽取資料，平均要花費40分鐘，有時候竟然要跑10個多小時。

關於分頁查詢的優化思路(r3筆記第7天)

目前在生產環境中有一個sql語句執行時間長達7分鐘，而且執行頻率極高。 其中PROC_INST中有將近6千萬的資料。其中STEP_INST是一個物化檢視，裡面還有5千多條資料。

關於檢視檔案的幾個小命令(r3筆記第6天)

關於檢視檔案磁碟空間的情況，有時候df -k, df -h的時候老是顯示錯行。 一般的顯示效果如下,這樣看起來不是很清楚。

融會貫通學習trigger(r2筆記第4天)

很多的東西在工作中用到的時候才能理解深刻，有些東西停留在理論層面而不去實踐，就不會真正理解。

使用dbms_parallel_execute來完成DML的並行(r3筆記第1天)

在工作中使用並行可以極大的提高工作效率。可以Object,session.hint級別引入並行。可以使大量的資料處理更加高效。

檢視並行程序的一些簡單資訊(r3筆記第17天)

在使用並行的時候，總能看到程序中出現一些ora_p這樣的程序。有時候檢視問題的時候只看到並行程序在執行，卻沒有思路去查詢倒底是哪些session在幹些什麼，下面簡單分析一下。怎麼去對映系統級的程序和資料庫級的並行

多行資料的批處理之bulk collect(r3筆記第16天)

在寫pl/sql的時候，很多時候都會用比較經典的模式，定義一個遊標cursor，然後迴圈從遊標中取值進行處理。

pl/sql中錯誤的異常處理 (r3筆記第15天)

pl/sql中對於錯誤的處理是很重要的一個部分，就跟寫程式中對於異常的處理一樣。可能程式中正常的流程實現部分不是很複雜，但是對於各種可能發生的異常情況都需要面面俱到的處理要佔一半以上的程式碼量。

關於session leak的問題分析(r3筆記第13天)

在生產環境中，作為dba需要對系統的負載有一個很清晰的認識。能夠在很快的時間內能夠發現系統潛在的問題，並且及時定位問題，高效的響應和處理問題。

聯絡生活來簡化sql(r3筆記第43天）

目前生產環境中有一條sql語句的CPU消耗很高。執行時間比較長。從awr中抓到的sql語句如下：

使用strace分析exp的奇怪問題(r3筆記第41天)

exp算是一個經典的資料匯出工具了。對於小數量的表來說，個人還是比較鍾愛exp。畢竟expdp還需要配置directory而且還在服務端。exp在資料量小的情況下速度還是很理想的。

由一條日誌警告所做的調優分析(r3筆記第40天)

這個案例發生有段時間了，但是今天無意中看到當時的郵件，感覺還是收益匪淺，看來還是細節決定成敗啊。從一些日誌或trace 檔案中的警告資訊中我們可以發掘出潛在的問題。

生產環境sql語句調優實戰第十篇(r3筆記第39天)

陸陸續續寫了九篇關於生產環境sql語句的調優案例，發現了不少問題，可能有些問題回頭來看是比較低階的錯誤，稍加改動就能夠執行在秒級，有些可能是在秒級到毫秒級的小步提升等等，不管調優的改進多大，從dba的角度來

memory_target設定不當導致資料庫無法啟動的問題(r3筆記第38天)

今天在做一個問題排查的時候碰到了另外一個有些“奇怪的”問題。 我們在測試庫中已經禁用了SGA自動儲存管理,結果在spfile檔案裡丟掉了shared_pool_size的配置

資料庫靜默安裝總結(r3筆記第58天)

在學習資料庫的時候，不知道dbca的命令用了多少遍，但是越是安裝也是覺得自己會的越少，因為圖形介面的清晰直白反而不知道哪些準備工作是需要特別準備的，如果在遠端支援的環境中，圖形介面就會受到網路頻寬的影響，

關於表聯結方法(一)(r3筆記第57天)

分類： Oracle 在sql語句中，如果from後面有多個表時，關於表的聯結方法是很重要的一個環節。

關於正則表示式第三篇(r3筆記第52天)

在正則表示式中，還有很多的內容值得學習。 之前的兩篇中列舉了很少的一部分。沒有做更多的分析。