使用REVERSE INDEX改善大规模数据插入【IMPROVE INSERT STATEMENT USING REVERSE INDEX】
生活随笔
收集整理的這篇文章主要介紹了
使用REVERSE INDEX改善大规模数据插入【IMPROVE INSERT STATEMENT USING REVERSE INDEX】
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
我們有的一個應用系統需要在某些時段向其日志記錄表中集中插入數據。
? 通過觀察發現該表的一些特征;
? 1.主鍵是使用SEQUENCE單調遞增生成的。
? 2.對日志表的查詢不會掃描多條連續記錄(主鍵)
? 當然最為直接的辦法就是去掉索引、主鍵。但是該主鍵不能停止或直接刪除。
? 在這種情況下,試圖將該主鍵改造成為REVERSE類型的主鍵,雖然數據庫只有一個單實例。
?
? 在測試數據庫上進行相關實驗:
? 背景:
? 一張表(LARRY_TEST)中含有1100000條數據,另外建立了一張和LARRY_TEST結構完全相同的表(LARRY_TESTINSERT)。然后創建主鍵:
? ALTER TABLE larry_testinsert ADD CONSTRAINT pk_test_insert PRIMARY KEY (terminal_id);??
??? 將LARRY_TEST的數據插入到測試表LARRY_TESTINSERT中
SQL> insert /*+append*/ into larry_testinsert select * from larry_test;
1100000 rows created.
Elapsed: 00:01:30.86
Statistics
----------------------------------------------------------
?????? 1908??recursive calls
??????61366??db block gets
??????11367??consistent gets
?????? 8191??physical reads
?? 72506424??redo size
????????612??bytes sent via SQL*Net to client
????????568??bytes received via SQL*Net from client
??????????3??SQL*Net roundtrips to/from client
??????????4??sorts (memory)
??????????1??sorts (disk)
????1100000??rows processed
SQL> commit;
Commit complete.
Elapsed: 00:00:00.14???
??? 然后清除(TRUNCATE TABLE)該表記錄,將主鍵pk_test_insert轉換成REVERSE的
SQL> alter index pk_test_insert rebuild reverse;
Index altered
Executed in 0.469 seconds???
??? 檢查該主鍵的類型
SQL> select INDEX_NAME,INDEX_TYPE from dba_indexes where index_name ='PK_TEST_INSERT';
INDEX_NAME???????????????????? INDEX_TYPE
------------------------------ ---------------------------
PK_TEST_INSERT???????????????? NORMAL/REV
Elapsed: 00:00:00.09
?? 我們發現該主鍵已經是REVERSE類型的了。開始插入數據:
SQL> insert /*+append*/ into larry_testinsert select * from larry_test;
1100000 rows created.
Elapsed: 00:01:22.90
Statistics
----------------------------------------------------------
?????? 1923??recursive calls
??????61328??db block gets
?????? 9872? consistent gets
?????? 8197??physical reads
?? 72446936??redo size
????????614??bytes sent via SQL*Net to client
????????568??bytes received via SQL*Net from client
??????????3??SQL*Net roundtrips to/from client
??????????1??sorts (memory)
??????????1??sorts (disk)
????1100000??rows processed
SQL> commit;
Commit complete.
Elapsed: 00:00:00.01???
??? 結論:
??? 我們不難發現,后者在插入數據時爭用有所下降(減少了插入操作的索引熱點塊),執行的插入效率有所提高(減少了近8秒鐘)。
??? 同時,這種通過序列、時間戳或按某種規則單調生成主鍵的表,可以因為使用REVERSE(反轉)類型索引來有效的降低索引“單向右增長”(right-growing index)的可能性,即會影響到響應時間和吞吐量。如果在基于RAC的環境中,REVERSE類型的索引會更為適用。
???? 但要注意,使用REVERSE類型的索引在查詢操作時會被限制使用基于索引區間的掃描(index range scans).
????
???? 在數據庫的優化中你經常會發現沒有絕對的好,也沒有絕對的差。
???? 人生亦如此 -:)
???
? 通過觀察發現該表的一些特征;
? 1.主鍵是使用SEQUENCE單調遞增生成的。
? 2.對日志表的查詢不會掃描多條連續記錄(主鍵)
? 當然最為直接的辦法就是去掉索引、主鍵。但是該主鍵不能停止或直接刪除。
? 在這種情況下,試圖將該主鍵改造成為REVERSE類型的主鍵,雖然數據庫只有一個單實例。
?
? 在測試數據庫上進行相關實驗:
? 背景:
? 一張表(LARRY_TEST)中含有1100000條數據,另外建立了一張和LARRY_TEST結構完全相同的表(LARRY_TESTINSERT)。然后創建主鍵:
? ALTER TABLE larry_testinsert ADD CONSTRAINT pk_test_insert PRIMARY KEY (terminal_id);??
??? 將LARRY_TEST的數據插入到測試表LARRY_TESTINSERT中
SQL> insert /*+append*/ into larry_testinsert select * from larry_test;
1100000 rows created.
Elapsed: 00:01:30.86
Statistics
----------------------------------------------------------
?????? 1908??recursive calls
??????61366??db block gets
??????11367??consistent gets
?????? 8191??physical reads
?? 72506424??redo size
????????612??bytes sent via SQL*Net to client
????????568??bytes received via SQL*Net from client
??????????3??SQL*Net roundtrips to/from client
??????????4??sorts (memory)
??????????1??sorts (disk)
????1100000??rows processed
SQL> commit;
Commit complete.
Elapsed: 00:00:00.14???
??? 然后清除(TRUNCATE TABLE)該表記錄,將主鍵pk_test_insert轉換成REVERSE的
SQL> alter index pk_test_insert rebuild reverse;
Index altered
Executed in 0.469 seconds???
??? 檢查該主鍵的類型
SQL> select INDEX_NAME,INDEX_TYPE from dba_indexes where index_name ='PK_TEST_INSERT';
INDEX_NAME???????????????????? INDEX_TYPE
------------------------------ ---------------------------
PK_TEST_INSERT???????????????? NORMAL/REV
Elapsed: 00:00:00.09
?? 我們發現該主鍵已經是REVERSE類型的了。開始插入數據:
SQL> insert /*+append*/ into larry_testinsert select * from larry_test;
1100000 rows created.
Elapsed: 00:01:22.90
Statistics
----------------------------------------------------------
?????? 1923??recursive calls
??????61328??db block gets
?????? 9872? consistent gets
?????? 8197??physical reads
?? 72446936??redo size
????????614??bytes sent via SQL*Net to client
????????568??bytes received via SQL*Net from client
??????????3??SQL*Net roundtrips to/from client
??????????1??sorts (memory)
??????????1??sorts (disk)
????1100000??rows processed
SQL> commit;
Commit complete.
Elapsed: 00:00:00.01???
??? 結論:
??? 我們不難發現,后者在插入數據時爭用有所下降(減少了插入操作的索引熱點塊),執行的插入效率有所提高(減少了近8秒鐘)。
??? 同時,這種通過序列、時間戳或按某種規則單調生成主鍵的表,可以因為使用REVERSE(反轉)類型索引來有效的降低索引“單向右增長”(right-growing index)的可能性,即會影響到響應時間和吞吐量。如果在基于RAC的環境中,REVERSE類型的索引會更為適用。
???? 但要注意,使用REVERSE類型的索引在查詢操作時會被限制使用基于索引區間的掃描(index range scans).
????
???? 在數據庫的優化中你經常會發現沒有絕對的好,也沒有絕對的差。
???? 人生亦如此 -:)
???
總結
以上是生活随笔為你收集整理的使用REVERSE INDEX改善大规模数据插入【IMPROVE INSERT STATEMENT USING REVERSE INDEX】的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: LVS配置指南
- 下一篇: 2008年IT业界10大预言 [转]