Jquery中文網 www.8833040.live
Jquery中文網 >  數據庫  >  DB2  >  正文 DB2數據庫設計和最高性能原則

DB2數據庫設計和最高性能原則

發布時間:2014-07-20   編輯:www.8833040.live
DB2數據庫設計和最高性能原則

數據壓縮
  DB2提供了壓縮表空間或分區內數據的功能。通過指定CREATE TABLESPACE(創建表空間)語句中的 COMPRESS YES(壓縮許可)選項,之后在表空間上同時執行LOAD或REORG實用工具集,即可完成該功能。數據的壓縮是通過用更短的串來替換頻繁出現的字符串實現的。系統還創建了一個字典,包含了原始字節串和它們的替代串之間的映射信息。
  一定數量的CPU資源被用于在執行數據存儲對其進行壓縮,之后,當外部存儲設備讀取時,數據又被解壓縮。然而,數據壓縮也能夠提供性能方面的好處,因為更多的數據存儲在更小的空間內(在DASD上和緩沖池中);同未經壓縮的數據相比,這樣可以產生更少的同時讀取、更小的I/O等。
接下來是當試圖決定是否壓縮一個表空間或分區時,需要考慮的一些事情:
  行的長度:行越長(尤其是在接近頁的尺寸時),壓縮的有效性就越低。DB2的行不能夠跨頁,當一頁上有多于一行的情況時,你也許不能獲得足夠的壓縮。
  表的尺寸:對于較大的表,壓縮具有較好的效果。對于很小的表,壓縮字典的大?。?KB到64KB)可能會抵消壓縮節省下的所有空間。
  數據中的模式:對于一個特定的表空間或分區,數據中重復出現的模式的頻率,決定了壓縮的效果。含有大量重復字符串的數據能夠獲得顯著的壓縮效果。
  壓縮估計:DB2提供了一個單獨的實用工具集,DSN1COMP,它可以用來測定數據壓縮將有怎樣的效果。想獲得有關運行該使用工具的額外信息,請參考DB2實用工具集指南和參考手冊。
  處理成本:在壓縮和解壓縮DB2數據時,會消耗一些CPU資源。如果你用IBM的同步數據壓縮硬件特征,所消耗的CPU資源將比利用DB2軟件仿真程序低得多(當DB2啟動時,這決定了硬件壓縮特征是否可用)。
  更好的字典:當用LOAD使用工具集來建立壓縮字典時,DB2用戶用最初載入的n行(n取決于你能夠壓縮的數據量)來決定字典的內容。REORG采用取樣技術來建立字典。它不僅使用最初載入的n行,還在實用工具執行UNLOAD(未載入)階段的剩余時間里繼續對數據行采樣。
  通常情況下,我們推薦你在自己的特定環境下,壓縮那些DB2表空間和分區,這將會使你的環境受益;因為在更小的空間內存儲更多的數據的性能優勢,幾乎總是在價值上超過壓縮和解壓縮數據所消耗的CPU資源。

載入大表
  在處理大批量數據時,將數據初始載入表中可能會對系統性能產生挑戰。為了在載入過程中實現并行性,你可以手動創建多個LOAD作業,每個分區建一個;或者作為另一個選擇,你可以在一個LOAD程序中載入多個分區。每個分區都延伸至I/O子系統,這種方式可以更容易地實現最理想的并行性。
  為了使性能最優化,在LOAD語句中指定SORTKEYS參數也很重要。這個參數指示DB2將索引方法傳遞給內存中的分類程序,而不是將關鍵字寫入或者再次讀取DASD上的排序任務文件。SORTKEYS也能夠實現載入和分類之間的交迭,因為分類是作為一個獨立的任務運行的。
還有一些關于載入大表的額外的建議,如下:
一次LOAD一個表。
如果可能的話,為你預期的任務賦予較高的優先級,來獲得最高的消耗時間。
在系統綜合體上分配工作。
將二級索引分解為小段,以便獲得并行性(見PIECESIZE內的討論)。
在數據的初始載入過程中,指定LOG NO(用于防止記錄日志,它耗費了相當多的資源),在成功載入數據之后運行一個圖像復制。

自由空間考慮事項
  分配自由空間的主要目的,是為了將數據行保存在相同的物理序列中作為群集索引,這樣一來將減少需要重新組織數據的頻率。此外,較好的行聚簇將導致更快的讀取訪問和更快的行插入。但是,自由空間的過度分配又將導致DASD空間的浪費、每一個I/O傳輸的數據較少、緩沖池的利用效率較低,以及需要掃描更多的頁。
  表空間和索引中的自由空間分配,由CREATE或ALTER TABLESPACE和CREATE或ALTER INDEX 語句中的PCTFREE和FREEPAGE選項決定。
  PCTFREE在載入或者重新組織數據時,為DB2指示表空間或索引中有多大的百分比是閑置的。在插入新的行和索引條目時,DB2將利用那些自由空間。如果沒有足夠的自由空間在正確的頁(即以正確的聚簇序列)上寫入行或者索引條目,那么DB2必須將多出來的數據放在另外的頁上作為代替。在越來越多的記錄放置在物理序列之外的情況下,系統性能將會受到嚴重影響。
  FREEPAGE在載入或者重新組織數據時,為DB2指示一個整頁成為自由空間的次數。例如,如果你將FREEPAGE確定為5,在每填滿5頁的數據之后,DB2將分配一整頁的自由空間。如果你的表中的行大于半頁,FREEPAGE將是很有用的,因為在這樣的情況下,你不能在這一頁中插入第二行。
  是否在你的表空間內定義自由空間,分配的數量又是多少,這些都主要取決于表空間中表的插入特性(刪除活動性居于次要程度)。換句話說,向表中插入行有多大的頻率,并且這些行插入的位置是在哪里?根據上述標準,四種主要的類別如下:
  只讀表:如果在表上不會有任何修正,定義時就可以不分配自由空間。同樣,也就不需要運行REORG實用工具集。
  隨機插入:對于含有相當大數量已有行和相對較少插入行的動作的表,使用默認的PCTFREE(表為5,索引為10)是一個好的起始點。之后,用RUANSTATS來監視數據組織破壞的程度,并且結合你要求的運行REORG的頻率,根據需要上調或下調PCTFREE。對于插入活動很頻繁的表,你可能需要使用比默認值較高的PCTFREE的值。對于初始為空或只含有極少數行的表(例如,在一個新數據庫部署的過程中),你也許需要確定一個非常高的PCTFREE值,并相當頻繁地運行REORG,直到表中的行數比較多了。
  在表的末端插入:如果表中行的長度不增加,那么就沒有必要分配自由空間,因為它們可以加在表的末端。而且既然它們是以物理聚簇序列的形式寫入的,REORG也不需要了。但是如果表含有可修改的VARCHAR類型的列,或是如果表是壓縮過的,那么行的長度有可能增加,這將使得一行被擠到另外一頁上去。通過在表空間上執行RUNSTATS然后核查DB2目錄表SYSIBM.SYSTABLEPART的NEARINDREF和FARINDREF列,你就能夠確定這些。如果你的表變亂了,那么為表空間設定一個PCTFREE值,并且用RUNSTATS繼續監視放錯位置的行的數目。根據你觀察到的數據和趨勢,相應地調整你的REORG的頻率和PCTFREE值。通過設定REORG TABLESPACE中的INDREFLIMIT和REPORTONLY選項,你就能夠在更新后的DB2表中監視紊亂的數量和速度。
  插入一個熱點:這是表具有很頻繁的插入活動的情況,這種插入活動集中在一個位置(或多個位置),而不是正好處于表的末端。這可能是要應付的最困難的種類。試著增加PCTFREE的數值。如果插入保持在開頭的段,行也不是很長,幾行可以存儲在同一頁之內。FREEPAGE是在這種情形下另外的一個考慮。有必要嚴密監視表變亂有多么快,這樣就可以在性能顯著下降之前運行REORG。

索引設計考慮事項
  索引是一個DB2對象(獨立的VSAM數據集),它是從相應表中的一個或更多列中摘錄出來的一系列有規則的條目。很多DB2專家主張為一個表空間建立恰當的索引,這也許是將訪問DB2數據應用程序的性能最優化的惟一最有效的方法。幾年前,在I/T中DASD的成本和空間是一個更重要的考慮因素。隨著技術的發展,通過以特大硬盤為代價,加上更多索引(或增加現有索引的列)來減少I/O的折中方法,在這幾年里越來越具吸引力。索引主要的性能優勢表現在:
為表中被請求的數據行提供直接指針
消除了排序,如果結果集的請求順序與索引相匹配的話
避免了必須讀取數據行,如果被請求的列全部包含在索引條目中的話

分區索引
  當在DB2 UDB V7中創建分區表空間時,DB2依照CREATE INDEX語句中的PART子句將分區中的數據進行劃分。那個索引則成為所謂的分區索引,這種分區方法被稱為受控索引分區。為了對索引進行分區,建議你選擇不易改變的關鍵列。對這些列的更改可能使得一個行從某一分區移動到另外一個分區,從而導致性能下降。
  受控表分區是DB2 V8的一個重要的特征?,F在,當創建分區表時,分區界限的確定由CREATE TABLE語句代替了原來的CREATE INDEX。在受控索引分區中,分區表的、分區索引和聚簇的概念全都結合在一起。而對于受控表分區,這三個概念是獨立的。這就增加了靈活性,允許你去考慮更有潛力的設計方法;并且也因此增加了改善DB2數據庫及其應用程序性能的可能性。

構建索引的時機
CREATE INDEX(創建索引)
  CREATE INDEX語句使用戶具有了這樣的能力:立即構建索引,或者將構建推遲到更加方便的時間。如果你立即構建索引,將會對表空間進行掃描,這會占用相當長的時間。通過設定DEFER,你可以推遲索引的構建。
  無論什么時候,只要可能,在最初載入一個表之前創建表上的所有索引,因為LOAD實用工具集構建索引比CREATE INDEX過程更加有效。如果你需要在已存在(并且有很多數據)的表上創建一個索引,那么可以使用DEFER語句。稍后,你就可以用REBUILD INDEX實用工具集,它和LOAD實用工具集一樣,是一種更加有效的填充索引的方法。

PIECESIZE(片段尺寸)
  DB2 UDB V5引進了一個新特征,它給了你一定的靈活性,從而可以將非分區索引(NPI)分解為小段,并且控制組成索引空間的多個數據集的大小。分段的這種用法能夠使一個NPI的索引頁展開為多個數據集。
  片段的尺寸由CREATE或ALTER INDEX語句中的關鍵字PIECESIZE確定。PIECESIZE的值必然是兩個強制值中的一個,其變動范圍為最小256KB到最大64GB。常規表空間的默認值為2GB,大的表空間默認值是4GB。如果你的NPI有可能顯著增長,那么選擇相對較大的表空間。同樣,在確定首要和次要的空間分配數值(CREATE INDEX語句的PRIQTY和SECQTY選項)時,記住PIECESIZE的值。
  利用這一選項,可以通過發揮并行性來改善NPI的掃描性能。另一個優勢是可以減少讀取或更新過程中的I/O沖突。通過設定較小的PIECESIZE值,你可以創建更多的片段,因而對片段的位置有更好的控制。將片段置于獨立的I/O路徑,可以減少了訪問NPI所需的SQL操作的沖突。

理想的索引
通過檢查一個應用程序中的SQL語句,你可以建立一個假想的完美的索引。
  首先,索引所包括的所有列都是WHERE子句,這使得索引的審查可以用于將不合格的行拒于結果集之外。將這些列放在索引的開始。當在SQL語句上執行EXPLAIN時,這會使得MATCHCOLS的價值最大化。
  其次,確保索引以適當的順序含有這些列(依照ORDER BY子句),從而可以避免進行排序。這可以在執行EXPLAIN時,通過檢查PLAN_TABLE的所有不同的SORT*列來驗證。
  最后,如果可能的話,將所有的列包含在索引的SELECT中,這樣就不需要訪問表中的行了。索引條目可以提供所有的請求數據。這將在EXPLAIN中以INDEXONLY = Y的方式表現出來。
  在很多情況下,實現如此理想的索引的代價太大了,或者說是不切合實際的,甚至是不可能實現的,因為所涉及的列的數量太大了。組成一個索引的列的數目在體系結構方面有限制,并且對于一個索引條目的總長也有限制(盡管這些限制實際上允許相當大的索引條目尺寸和靈活性)。此外,這也是出于索引維護成本的考慮。建立理想的索引可使查詢性能獲得極大提高,但是對于SQL寫入DB2數據庫(INSERT、UPDATE或DELETE)就有消極的影響。因此,你應該經常選擇實現只包含WHERE和ORDER BY語句中涉及的列的索引。

并行處理的考慮事項
  幾年來,通過實現了并行處理的各種方法,DB2在數據訪問方面的性能獲得了改進。為了改進數據密集型只讀查詢的性能,DB2 V3引進了查詢I/O并行機制。在這種類型的并行性中, DB2充分利用了可用的I/O帶寬,并使分區表空間中成為可能。利用這種方法,DB2使得一個查詢中的多個并發I/O請求可同時進行,并在多個數據分區中執行了并行的I/O處理。這代表性地使得I/O綁定查詢所耗費時間的顯著降低,同時出現了CPU時間的較小增長。
  DB2 V4引入了另外的并行性技術,稱為查詢CP并行性。該方法將并行處理擴展至處理密集型的查詢。用該方法,單個查詢可使DB2生成數個任務,并行執行數據訪問。對于這種類型的并行性,分區表空間顯示出最佳的性能提升。
  DB2 UDB V5通過引進綜合系統查詢并行性,更進一步地擴展了并行處理。當查詢CP并行性在DB2子系統中為某個查詢使用了多個任務時,該方法使得DB2數據共享群中的所有成員能夠處理一個單一的查詢。主要為只讀形式的I/O密集型和處理密集型查詢可以從這種類型的并行性中獲益。

并行訪問的授權
  在DB2環境下使系統獲得并行性能力有一定的難度。首先,在DB2子系統級別,并行訪問由安裝面板DSNTIP4控制。DSNTIP4上的MAX DEGREE 選項決定并行性的最大程度(并行任務的最大數目)。默認值為0,意味著對于DB2可調用的并行性程度沒有上限。我建議你估計虛擬存儲容量,以及你的z/OS環境限制,還應根據需要調整該參數,因此DB2將不會創建超過你的虛擬存儲容量可以應對的并行任務。
  通過BIND PLAN和BIND PACKAGE命令的DEGREE選項,你能夠控制DB2是否使用并行處理。設定DEGREE(1)阻止并行處理,而DEGREE(ANY)允許并行處理。為了獲得進一步的靈活性,動態SQL允許在一個計劃或包內更改該選項,通過SET CURRENT DEGREE語句即可實現,SET CURRENT DEGREE語句用于控制某個寄存器中的數值。
  當一個計劃或包與DEGREE(ANY)綁定,或者CURRENT DEGREE寄存器設定為ANY時,DB2優化器考慮并行性是否是可能的,從而獲得最有效的最終計劃。如果并行性是不可能的,那么將會選擇下一個允許并行性的最有效的最終計劃。

限制分區掃描
  限制分區掃描是允許DB2在分區表空間中限制數據掃描的一種方法。根據SQL謂詞的值,DB2能夠決定最低和最高的分區,這可能包含了被SQL語句所請求的表的行,之后便將數據掃描限制在分區的范圍內。為了使用該技術,SQL必須提供一個在分區索引的第一個關鍵列上的謂詞。

并行性建議
為了使并行處理的性能最優化,需要考慮以下事項:
  盡可能均勻地對表空間進行分區,因為并行性程度會受到數據不均勻的影響。DB2通常在最大物理分區的基礎上將表空間劃分為邏輯片段。
為DB2的應用程序處理分配盡可能多的中央處理器(CP),以及盡可能多的I/O設備和通道。
對于I/O密集型查詢,確保分區的數量與可以訪問表空間的I/O通道數量相同。
對于處理密集型查詢,確保分區的數量與用于跨共享數據群處理查詢的CP數量相同。
  將表空間和索引的分區放在單獨的DASD卷上,并且(如果可能的話)獨立控制這些單元以便使I/O沖突最小化。
在規則的基礎上執行RUNSTATS實用工具集,以便獲得分區級別的統計表。
監視虛擬緩沖池的閾值和使用情況,確信你提供了足夠的緩沖池空間來使調用的并行性程度最大化。

緩沖池的考慮事項
緩沖池的重要性
大多數專家認為在DB2環境下,數據庫緩沖池是影響性能的最關鍵的因素。很多DB2的體系結構和設計是基于盡可能多的或實際上避免物理I/O這一概念。
  DB2緩沖池由臨近存儲器的插槽組成。從DASD讀入之后,數據和索引頁進入這些插槽并且呆在其中,直到DB2緩沖管理器決定這些插槽需要被其他數據占用。被應用程序請求的數據通常存儲在存儲器內,而不是在外部的DASD,這種情形越經常出現,整體的性能就越好。本質上,數據是被重新利用了,從而使得應用程序需要的I/O數量最小化。
  釋放緩沖池插槽的決定基于最近最少使用(LRU)法則。DB2維護著兩個LRU列表,一個是關于隨機訪問頁的,另一個是關于順序訪問頁的。這便阻止了完全占用緩沖池的大表掃描,以及對隨機操作的負面影響。通過各種閾值的使用,DB2為你提供了改進緩沖池性能的額外靈活性。關于這些閾值的進一步詳細討論見DB2 SQL參考手冊的2.7.4部分。
緩沖池的合適大小
  緩沖池尺寸的指定取決于可用的存儲量(包括中央部分和擴展部分)。我建議你分析一下緩沖池分配,并且增加它的尺寸直到再也沒有由于增加的分配而產生的額外吞吐量,或是MVS分頁速率到達不可接受的程度。這將通過逐漸增加的VPSIZE來實現,只要DASD I/Os的數目保持減少,在分頁的成本超過減少I/O的收益之前,VPSIZE將持續增加。
  在早期,GETPAGES的數量可能是DB2工作量的最好衡量標準。緩沖池的用途是為了使I/O最小化(異步讀取通常意味著一次做一個,這是基于性能立場上的一般要求。另一方面,同步讀取通常意味著從DASD的隨機I/O,因為所請求的頁在緩沖池內找不到)。統計報告顯示le 每一個緩沖池中的GETPAGES和同步讀取的數量。一個被普遍接受的ROT說,如果同步讀取的GETPAGES比率小于10:1,那么你應該考慮配置更大緩沖池了。
多緩沖池配置
  如果你的操作環境允許為DB2緩存配置容量相當大的存儲器,那么多緩沖池配置可以最大限度地為特定的應用程序或數據庫提供改善的性能。然而,請注意由于采用多個緩沖池,監視它們的工作效率變得更加重要。
普遍來講,對配置多緩沖池有如下建議:
將表空間和它們相聯系的索引分離到不同的池,以便使索引I/O最小化。
  將具有不同數據訪問模式的數據分別置于不同的緩沖池中。典型地,批處理和查詢應用程序含有大量的連續處理,而OLTP的數據訪問在本質上往往比較隨機。這就提供了一種方法,來開發不同的閾值以在一個緩沖池適應各種特定類型的數據訪問。
  為了隔離應用程序,提供一個單獨的緩沖池。這就提供了一種方法,來嚴密監視一個存在運行問題的應用程序,或是測試新的應用程序。
如果分類性能在你的環境下很重要,那么就為共作文件創建一個獨立的緩沖池。
對于相對比較小但是更新很快的表,足夠大的獨立緩沖池可以同時消除讀取和書寫I/Os。
為只讀表(小的、參考表)設立單獨的緩沖池也可以提高性能。

總結
  經過深思熟慮的數據庫設計可以提供重大的性能優勢,但是它必須在應用程序的開發過程中盡早開始。上述很多原則,在DB2的早期就已經被明智的開發人員所利用,并且至今仍保持著它們的正確性。然而清楚DB2功能上的進步,以及影響你當前和以后應用程序的其他領域內的硬件和軟件技術的變化,同樣也是至關緊要的。當數據庫性能成為發展過程的一個重要焦點時,你的數據庫設計,將使你更有可能為你的DB2應用程序提供最優化的性能。

您可能感興趣的文章:
DB2基礎知識(1)了解DB2
DB2數據庫設計和最高性能原則
db2常用命令大全-基礎篇
DB2 V9.7 Linux安裝記錄
DB2數據庫性能調優的十個辦法
DB2實驗教程:DB2實驗環境設置
在Linux下使用命令行安裝DB2
DB2常用知識
DB2基礎知識(2)DB2數據庫的安裝
收集了一些常用的DB2命令(附例子)

[關閉]
000069股票行情