預備—monitorsON
db2"updatemonitorswitchesusing
lockONsortONbufferpoolONuowON
tableONstatementON"
打開監視開關,獲取需要的性能信息
最簡單而最見成效的—Bufferpool
緩沖池是內存中的一塊存儲區域,用于臨時讀入和更改數據庫頁(包含表行或索引項)。緩沖池的用途是為了提高數據庫系統的性能。從內存訪問數據要比從磁盤訪問數據快得多。因此,數據庫管理器需要從磁盤讀取或寫入磁盤的次數越少,性能就越好。對一個或多個緩沖池進行配置之所以是調優的最重要方面,是因為連接至數據庫的應用程序的大多數數據(不包括大對象和長字段數據)操作都在緩沖池中進行。
缺省情況下,應用程序使用緩沖池IBMDEFAULTBP,它是在創建數據庫時創建的。當SYSCAT.BUFFERPOOLS目錄表中該緩沖池的NPAGES值為-1時,DB2數據庫配置參數BUFFPAGE控制著緩沖池的大小。否則會忽略BUFFPAGE參數,并且用NPAGES參數所指定的頁數創建緩沖池。
建議對于僅使用一個緩沖池的應用程序,將NPAGES更改成-1,這樣BUFFPAGE就可以控制該緩沖池的大小。這使得更新和報告緩沖池大小以及其它DB2數據庫配置參數變得更加方便。
確保可以使用數據庫配置中的BUFFPAGE參數來控制緩沖池大小之后,將該參數設置成合適的值。根據數據庫的大小和應用程序的性質將該參數設置成一個合理的大值,這種做法很安全。通常,該參數的缺省值非常小,可能滿足不了要求。
db2"getsnapshotforallbufferpools"
在數據庫快照或緩沖池快照的快照輸出中,查找下列"logicalreads"和"physicalreads",這樣就可以計算出緩沖池命中率,它可以幫助調優緩沖池:
緩沖池命中率表明數據庫管理器不需要從磁盤裝入頁(即該頁已經在緩沖池中)就能處理頁請求的時間百分比。緩沖池的命中率越高,使用磁盤I/O的頻率就越低。按如下計算緩沖池命中率:
(1-((bufferpooldataphysicalreads+bufferpoolindexphysicalreads)/
(bufferpooldatalogicalreads+poolindexlogicalreads))
)*100%
這個計算考慮了緩沖池高速緩存的所有頁(索引和數據)。理想情況下,該比率應當超過95%,并盡可能接近100%。要提高緩沖池命中率,請嘗試下面這些方法:
增加緩沖池大小。
考慮分配多個緩沖池,如果可能的話,為每個經常被訪問的大表所屬的表空間分配一個緩沖池,為一組小表分配一個緩沖池,然后嘗試一下使用不同大小的緩沖池以查看哪種組合會提供最佳性能。
如果已分配的內存不能幫助提高性能,那么請避免給緩沖池分配過多的內存。應當根據取自測試環境的快照信息來決定緩沖池的大小。
太小的緩沖池會產生過多的、不必要的物理I/O。太大的緩沖池使系統處在操作系統頁面調度的風險中并消耗不必要的CPU周期來管理過度分配的內存。正好合適的緩沖池大小就在"太小"和"太大"之間的某個平衡點上。適當的大小存在于回報將要開始減少的點上。
獲得最佳性能的—SQL
一條糟糕的SQL語句會徹底破壞一切。一個相對簡單的SQL語句也能夠搞糟一個調整得很好的數據庫和機器。對于很多這些語句,天底下(或在文件中)沒有DB2UDB配置參數能夠糾正因錯誤的SQL語句導致的高成本的情況。
更糟糕的是,DBA常常受到種種束縛:不能更改SQL(可能是因為它是應用程序供應商提供的)。這給DBA只留下三條路可走:
1.更改或添加索引
2.更改群集
3.更改目錄統計信息
健壯的應用程序由成千上萬條不同的SQL語句組成。這些語句執行的頻率隨應用程序的功能和日常的業務需要的不同而不同。SQL語句的實際成本是它執行一次的成本乘以它執行的次數。
每個DBA所面臨的重大的任務是,識別具有最高"實際成本"的語句的挑戰,并且減少這些語句的成本。
通過本機DB2Explain實用程序、一些第三方供應商提供的工具或DB2UDBSQLEventMonitor數據,可以計算出執行一次SQL語句所用的資源成本。但是語句執行頻率只能通過仔細和耗時地分析DB2UDBSQLEventMonitor的數據來了解。
最佳性能不僅需要排除高成本SQL語句,而且需要確保相應的物理基礎結構是適當的。當所有的調節旋鈕都設置得恰到好處、內存被有效地分配到池和堆而且I/O均勻地分配到各個磁盤時,才可得到最佳性能。
不可遺漏的—Lock
這些與鎖相關的控制都是數據庫配置參數:
LOCKLIST表明分配給鎖列表的存儲容量。每個數據庫都有一個鎖列表,鎖列表包含了并發連接到該數據庫的所有應用程序所持有的鎖。鎖定是數據庫管理器用來控制多個應用程序并發訪問數據庫中數據的機制。行和表都可以被鎖定。根據對象是否還持有其它鎖,每把鎖需要32個或64個字節的鎖列表:
需要64個字節來持有某個對象上的鎖,在這個對象上,沒有持有其它鎖。
需要32個字節來記錄某個對象上的鎖,在這個對象上,已經持有一個鎖。
MAXLOCKS定義了應用程序持有的鎖列表的百分比,在數據庫管理器執行鎖升級之前必須填充該鎖列表。當一個應用程序所使用的鎖列表百分比達到MAXLOCKS時,數據庫管理器會升級這些鎖,這意味著用表鎖代替行鎖,從而減少列表中鎖的數量。當任何一個應用程序所持有的鎖數量達到整個鎖列表大小的這個百分比時,對該應用程序所持有的鎖進行鎖升級。如果鎖列表用完了空間,那么也會發生鎖升級。數據庫管理器通過查看應用程序的鎖列表并查找行鎖最多的表,來決定對哪些鎖進行升級。如果用一個表鎖替換這些行鎖,將不再會超出MAXLOCKS值,那么鎖升級就會停止。否則,鎖升級就會一直進行,直到所持有的鎖列表百分比低于MAXLOCKS。MAXLOCKS參數乘以MAXAPPLS參數不能小于100。
雖然升級過程本身并不用花很多時間,但是鎖定整個表(相對于鎖定個別行)降低了并發性,而且數據庫的整體性能可能會由于對受鎖升級影響的表的后續訪問而降低。
LOCKTIMEOUT的缺省值是-1,這意味著將沒有鎖超時(對OLTP應用程序,這種情況可能會是災難性的)。許多DB2用戶用LOCKTIMEOUT=-1。將LOCKTIMEOUT設置為很短的時間值,例如10或15秒。在鎖上等待過長時間會在鎖上產生雪崩效應。
首先,用以下命令檢查LOCKTIMEOUT的值:
db2"getdbcfgforDBNAME"
并查找包含以下文本的行:
Locktimeout(sec)(LOCKTIMEOUT)=-1
如果值是-1,考慮使用以下命令將它更改為;15秒(一定要首先詢問應用程序開發者或供應商以確保應用程序能夠處理鎖超時):
db2"updatedbcfgforDBNAMEusingLOCKTIMEOUT15"
同時應該監視鎖等待的數量、鎖等待時間和正在使用鎖列表內存(locklistmemory)的量。請發出以下命令:
db2"getsnapshotfordatabaseonDBNAME"
如果Locklistmemoryinuse(Bytes)超過所定義LOCKLIST大小的50%,那么在LOCKLIST數據庫配置中增加4k頁的數量。
