正在看的db2教程是:DB2最佳化（簡易版）。預備—monitors ON
db2 "update monitor switches using
lock ON sort ON bufferpool ON uow ON
table ON statement ON"
開啟監視開關,擷取需要的效能資訊
最簡單而最見成效的—Bufferpool
緩衝池是記憶體中的一Block Storage地區,用於臨時讀入和更改資料庫頁(包含表行或索引項目)。緩衝池的用途是為了提高資料庫系統的效能。從記憶體訪問資料要比從磁碟訪問資料快得多。因此,資料庫管理員需要從磁碟讀取或寫入磁碟的次數越少,效能就越好。對一個或多個緩衝池進行配置之所以是調優的最重要方面,是因為串連至資料庫的應用程式的大多數資料(不包括大對象和長欄位資料)操作都在緩衝池中進行。
預設情況下,應用程式使用緩衝池 IBMDEFAULTBP,它是在建立資料庫時建立的。當 SYSCAT.BUFFERPOOLS 目錄表中該緩衝池的 NPAGES 值為 -1 時,DB2 資料庫配置參數 BUFFPAGE 控制著緩衝池的大小。否則會忽略 BUFFPAGE 參數,並且用 NPAGES 參數所指定的頁數建立緩衝池。
建議對於僅使用一個緩衝池的應用程式,將 NPAGES 更改成 -1,這樣 BUFFPAGE 就可以控制該緩衝池的大小。這使得更新和報告緩衝池大小以及其它 DB2 資料庫配置參數變得更加方便。
確保可以使用資料庫配置中的 BUFFPAGE 參數來控制緩衝池大小之後,將該參數設定成合適的值。根據資料庫的大小和應用程式的性質將該參數設定成一個合理的大值,這種做法很安全。通常,該參數的預設值非常小,可能滿足不了要求。
db2 "get snapshot for all bufferpools"
在資料庫快照集或緩衝池快照的快照輸出中,尋找下列"logical reads"和"physical reads",這樣就可以計算出緩衝池命中率,它可以協助調優緩衝池:
緩衝池命中率表明資料庫管理員不需要從磁碟裝入頁(即該頁已經在緩衝池中)就能處理頁請求的時間百分比。緩衝池的命中率越高,使用磁碟 I/O 的頻率就越低。按如下計算緩衝池命中率:
(1 - ((buffer pool data physical reads + buffer pool index physical reads) /
(buffer pool data logical reads + pool index logical reads))
) * 100%
這個計算考慮了緩衝池快取的所有頁(索引和資料)。理想情況下,該比率應當超過 95%,並儘可能接近 100%。要提高緩衝池命中率,請嘗試下面這些方法:
增加緩衝池大小。
考慮分配多個緩衝池,如果可能的話,為每個經常被訪問的大表所屬的資料表空間分配一個緩衝池,為一組小表分配一個緩衝池,然後嘗試一下使用不同大小的緩衝池以查看哪種組合會提供最佳效能。
如果已指派的記憶體不能協助提高效能,那麼請避免給緩衝池分配過多的記憶體。應當根據取自測試環境的快照資訊來決定緩衝池的大小。
太小的緩衝池會產生過多的、不必要的物理 I/O。太大的緩衝池使系統處在作業系統頁面調度的風險中並消耗不必要的 CPU 週期來管理資源過度分派的記憶體。正好合適的緩衝池大小就在"太小"和"太大"之間的某個平衡點上。適當的大小存在於回報將要開始減少的點上。
獲得最佳效能的—SQL
一條糟糕的 SQL 陳述式會徹底破壞一切。一個相對簡單的 SQL 陳述式也能夠搞糟一個調整得很好的資料庫和機器。對於很多這些語句,天底下(或在檔案中)沒有 DB2 UDB 配置參數能夠糾正因錯誤的 SQL 陳述式導致的高成本的情況。
更糟糕的是,DBA 常常受到種種束縛:不能更改 SQL(可能是因為它是應用程式供應商提供的)。這給 DBA 只留下三條路可走:
1. 更改或添加索引
2. 更改群集
3. 更改目錄統計資訊
健壯的應用程式由成千上萬條不同的 SQL 陳述式組成。這些語句執行的頻率隨應用程式的功能和日常的業務需要的不同而不同。SQL 陳述式的實際成本是它執行一次的成本乘以它執行的次數。
每個 DBA 所面臨的重大的任務是,識別具有最高"實際成本"的語句的挑戰,並且減少這些語句的成本。
通過本機 DB2 Explain 公用程式、一些第三方供應商提供的工具或 DB2 UDB SQL Event Monitor 資料,可以計算出執行一次 SQL 陳述式所用的資源成本。但是語句執行頻率只能通過仔細和耗時地分析 DB2 UDB SQL Event Monitor 的資料來瞭解。
最佳效能不僅需要排除高成本 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 "get db cfg for DBNAME"
並尋找包含以下文本的行:
Lock timeout (sec) (LOCKTIMEOUT) = -1
如果值是 -1,考慮使用以下命令將它更改為 
[1] [2] 下一頁
正在看的db2教程是:DB2最佳化（簡易版）。;15 秒(一定要首先詢問應用程式開發人員或供應商以確保應用程式能夠處理鎖逾時):
db2 "update db cfg for DBNAME using LOCKTIMEOUT 15"
同時應該監視鎖等待的數量、鎖等待時間和正在使用鎖列表記憶體(lock list memory)的量。請發出以下命令:
db2 "get snapshot for database on DBNAME"
如果 Lock list memory in use (Bytes) 超過所定義 LOCKLIST 大小的 50%,那麼在 LOCKLIST 資料庫配置中增加 4k 頁的數量。
本新聞共2頁,當前在第1頁 1 2
上一頁 [1] [2]
