摘 要: HWM(High Water Mark)是表中已經使用過的存儲空間與未使用過的存儲空間之間的分界線,,HWM對全表掃描的性能有非常大的影響,。當全表掃描時,Oracle會讀取HWM下所有的塊,,即使這些塊中有很多是空塊,,空塊的存在,也即是表中碎片的存在,,必將增加全表掃描額外的物理I/O開銷及CPU開銷,,嚴重降低訪問Oracle數(shù)據(jù)表的性能。通過對Oracle中關于表中HWM的原理及性能優(yōu)化問題的討論,,針對HWM下的碎片問題提出相關的優(yōu)化策略,,并對其空間重組前后進行性能對比測試。
關鍵詞: Oracle; HWM; 性能優(yōu)化
Web2.0與Web3.0的發(fā)展都離不開后臺支持數(shù)據(jù)庫,,數(shù)據(jù)庫運行的好壞,、快慢,直接影響到使用者的應用,,因而本文將重點研究信息資源建設中后臺數(shù)據(jù)庫的優(yōu)化策略,。Oracle 數(shù)據(jù)庫是具有高可靠性、高安全性,、高兼容性的大型關系型數(shù)據(jù)庫,,是信息化建設的重要基礎平臺。網(wǎng)絡中的信息資源數(shù)據(jù)庫具有異構,、數(shù)據(jù)量大,、多媒體內容多、查詢頻繁等特點,,伴隨網(wǎng)絡不斷深入的應用,,其存儲在數(shù)據(jù)庫中的數(shù)據(jù)量越來越多,而傳統(tǒng)的數(shù)據(jù)庫設計方法使得數(shù)據(jù)庫隨著訪問數(shù)據(jù)量的增大其性能明顯地降低[1],。Oracle的邏輯空間管理是Oracle管理和優(yōu)化的重要部分,,ASSM段空間自動管理下的HWM問題對Oracle的存儲管理和性能優(yōu)化有重大影響。本文在探討Oracle 10g邏輯存儲管理的基礎上,針對HWM下的碎片問題提出了相關的優(yōu)化策略,,并對其空間重組前后進行了性能測試,。
1 Oracle存儲管理
1.1 Oracle邏輯存儲管理
Oracle在邏輯存儲上分4個粒度,如圖1所示。
(1) Block(塊):粒度最小的存儲單位,,標準默認大小是8 KB,,Oracle每一次I/O操作都是按Block來進行的。
(2) Extent(區(qū)):由一系列相鄰的Block組成,,是Oracle空間分配的基本單位[2],,Oracle是以Extent為單位進行擴展的。
(3) Segment(段):由一系列的Extents所組成[2],,當創(chuàng)建一個對象時(表或索引),,就會分配一個Segment給這個對象。
(4) Tablespace(表空間):包括Segment,、Extent和Block,,Tablespace的數(shù)據(jù)物理上存儲在其所在的數(shù)據(jù)文件中,一個數(shù)據(jù)庫最少要有一個Tablespace,。
1.2 HWM
高水標記HWM(High-Water Mark)這個概念在Segment的存儲內容中是比較重要的,。簡單來說,,HWM代表一個表使用的最大(top limit)塊(如圖2所示),就是一個Segment中已使用和未來使用的Block的分界線[3],。圖2顯示了HWM首先位于新創(chuàng)建表的第一個塊中,,隨著數(shù)據(jù)的插入和更新,使用了越來越多的塊,,當現(xiàn)有空間不足而進行空間擴展時HWM會隨之向上移,。如果刪除一部分行數(shù)據(jù),可能會有許多塊不再包含數(shù)據(jù),,但HWM不會往下移,,被占用的最高空間稱為HWM。
Oracle在做全表掃描時會讀取HWM下的所有Blocks,,即使其中不包含任何數(shù)據(jù),,Oracle都會一一讀取,這會大大影響系統(tǒng)的性能,,特別是當HWM之下的大多數(shù)塊都為空時,。
如果一個OLTP系統(tǒng)(即聯(lián)機事務處理,就是常說的關系數(shù)據(jù)庫,,對記錄進行增,、刪、改,、查)應用頻繁地對某個表里的記錄進行DML(Data Manipulation Language)操作(即數(shù)據(jù)操縱語言,,一種命令使用戶能夠查詢數(shù)據(jù)庫以及操作已有數(shù)據(jù)庫中的數(shù)據(jù)的計算機語言),會造成Block中數(shù)據(jù)分布稀疏,導致HWM下存在大量的碎片,浪費大量的空間,。當做全表掃描時,,Oracle會讀取HWM之下的所有塊,即使其中不包含數(shù)據(jù)[3],。對于HWM以下表的碎片,做全表訪問時必然增加一致性讀,,因而影響到響應時間,降低系統(tǒng)性能,。
2 優(yōu)化策略
對于增,、刪、改操作比較頻繁的表,,尤其是刪除操作比較頻繁的表,,一般表的高水位HWM值會偏高,也就是表中數(shù)據(jù)塊碎片高,,雖然ASSM的自動空間管理能提高DML操作并發(fā)訪問的性能,,但是HWM下高碎片的產生會大大影響訪問效率,而減少碎片,、降低對象的HWM可提高對象的訪問效率,,從而達到性能優(yōu)化,,大大提高數(shù)據(jù)的訪問效率。表對象可以通過shrink或move方法實現(xiàn)重組,、減少碎片,、降低HWM,進行性能優(yōu)化,;索引對象可以提供rebuild的方法來實現(xiàn)重組、減少碎片,、降低HWM,,進行性能優(yōu)化。當然,,在對表及索引進行shrink或move及rebuild操作時,,最好選擇在非業(yè)務高峰時進行,避免影響業(yè)務的正常運轉,。
shrink與move操作有一些不同,,但都可以完成表中碎片的整理,在此可做一些比較:
(1) move的執(zhí)行效率比shrink高,,因為shrink會產生redo log,、undo log;
(2) shrink對數(shù)據(jù)的移動是從后往前的,,所以shrink不需要使用額外的空閑空間,,而move是需要額外空閑空間的;
(3) 對帶有索引的表進行shrink操作時,,索引是不需要重建的,;而對帶有索引的表進行move操作時,索引是需要rebuild重建的,,否則索引不可用,;
(4) 對表進行shrink操作時,必須打開表的行遷移屬性,。
shrink和move都會對操作的表加表級獨占鎖,,因此其他session對此表執(zhí)行 DML操作時,存在鎖等待,;當shrink或move操作執(zhí)行完成,,鎖釋放。
索引的rebuild是可以在線完成的,,比較適合在高可用環(huán)境下完成,。
另外,shrink是10g的新特性,,僅對ASSM管理表空間有效,。
具體命令操作如下:
shrink命令:
Alter table XXX enable row movement(打開表XXX的行遷移屬性);
Alter table XXX shrink space(僅僅對表XXX進行縮小,,不對表中的索引進行空間縮小);
Alter table XXX shrink space cascade(縮表的同時,也對表中的索引進行縮小);
Alter table XXX disable row movement(縮表完成后,,關閉表XXX的行遷移屬性),。
move命令:
Alter table XXX move(對表進行move);
Alter index YYY rebuild(如果表有索引,則需要對表的索引進行重建),。
3 性能優(yōu)化測試
對于碎片較多的表,,可以通過shrink或move操作降低表中HWM高水位的值來進行性能優(yōu)化。下面以shrink命令為例子進行測試,。
3.1 對TEST表進行分析
(1) 表大小
SQL> select segment_name, bytes/1024/1024 表大小MB from dba_segments where segment_name=′TEST′;
SEGMENT_NAME 表大小MB
TEST 5.632
(2) 表的實際數(shù)據(jù)大?。?.439 MB
SQL>select table_name, AVG_ROW_LEN ,NUM_ROWS,AVG_ROW_LEN*NUM_ROWS/1024/1024 表實際大小MB,LAST_ANALYZED from dba_tables where table_name=′TEST′;
TABLE_NAME AVG_ROW_LEN NUM_ROWS 表實際大小MB LAST_ANALYZED
TEST 157 16290 2.439 2012-12-01 00:13:12
(3)根據(jù)表實際大小公式可得出該表的碎片率為:56.7%
(1-表實際數(shù)據(jù)大小/表大小)×100/%=(1-2.439/5.632)×100%=56.7%碎片率:56.7%
(4)執(zhí)行SQL語句:select * from test;
查詢表test中所有記錄,,查詢所需時間為2 s,。
SQL的解釋計劃如下:
Execution Plan
|Id|Operation |Name |Rows | Cost (%CPU)| Time|
|0| SELECT STATEMENT | | | 141 (0)| |
|1| TABLE ACCESS FULL|TEST|16290|141(0)|00:00:02|
從以上的SQL解釋計劃來看,SQL采用的是全表掃描讀的方式訪問,SQL將讀取表的高水位HWM以下的所有數(shù)據(jù)塊。
由上可知: (1)表TEST的大小為5.632 MB,, 但實際數(shù)據(jù)大小約為2.439 MB,,碎片率約為56.7%,表TEST中存在大量的碎片; (2)查詢該表所有記錄所需要的時間為2 s,。
3.2 碎片重組 優(yōu)化處理
通過shrink方式對表TEST作碎片重組實現(xiàn)對表的優(yōu)化處理,。
SQL> select segment_name, bytes/1024/1024 表大小MB from dba_segments where segment_name=′TEST′;
segment_name 表大小MB
TEST 5.632
SQL>alter table test enable row movement;
SQL>alter table test shrink space;
SQL>alter table test disable row movement;
SQL>select segment_name,bytes/1024/1024 表大小MB from dba_segments where segment_name=′TEST′;
SEGMENT_NAME 表大小MB
TEST 3.072
通過對上對TEST表進行優(yōu)化處理后可以看到:(1) shrink縮表操作后TEST表的大小從5.632 MB縮小到3.072 MB,縮小了近一半,從而降低了表TEST的HWM值,; (2)再次執(zhí)行全表掃描的查詢SQL:select * from test;查詢時間縮短為1 s,,SQL執(zhí)行速度大大提高。
3.3 測試結論
在對高碎片表進行全表掃描讀的訪問方式時,碎片增加了不必要的物理讀與內存讀,也就增加了不必要的物理I/O與CPU的消耗,,最終降低了對表數(shù)據(jù)的訪問速度,,即影響了SQL語句的響應時間。通過shrink或者move操作對表碎片空間進行重組,,可以有效降低表中的HWM值,,提高表的訪問效率,進而提高block的命中率,,在一定程度上,,可以起到系統(tǒng)優(yōu)化的作用。
本文針對HWM下碎片問題對性能的影響,,探討減少碎片空間的優(yōu)化策略,,通過對碎片空間的重組來減少碎片的產生,以提高訪問效率,。
數(shù)據(jù)庫性能優(yōu)化是一項復雜的系統(tǒng)工程,,是一個循序漸進的過程,應該針對Oracle運行過程中出現(xiàn)的各種問題,找出性能瓶頸,,有針對性地對系統(tǒng)進行調整,,保證數(shù)據(jù)庫高效可靠的運行。
參考文獻
[1] 高敬媛, 趙克寶.校園網(wǎng)數(shù)據(jù)庫性能優(yōu)化技術[J].煤炭技術,2011,30(07):226-228.
[2] KYTE T, ORACLE E, Signature edition programming techniques and solutions for Oracle 7.3 through 8.1.7 (Expert One-On-One)[M]. New York: Apress,,2010.
[3] KYTE T. Expert Oracle database architecture: 9i and 10g programming techniques and solutions[M]. 2006,,San Bernardino: Macsource press,2006.