DB2 性能監控2[翻譯]
2024-09-06 23:58:06
供稿：網友
性能監控2
performance monitoring, part 2
roger sanders 著
笑熬漿糊 譯
天堂鳥自由空間原創作品
天堂鳥自由空間©2002-2005版權所有
轉載請保持文檔的完整性
訪問更多可以瀏覽http://hbird.vicp.net/myself.html
或http://hbird.myrice.com/myself.html
blog: http://blog.csdn.net/mr_bean
bbs討論: http://hbird.vicp.net
mail:[email protected]
性能監控2
roger sanders 著
笑熬漿糊 譯
原文出處：《db2 magazine》 quarter 3, 2004 vol. 9, issue 3
英文原文（由于文章翻譯未經授權，請在轉載時保留原文鏈接）
事件監視器超越了性能線索快照。在此系列的第一篇中，我指出db2的性能監視工具趨向于一個有組織、有目標導向的調整結果。簡單的說，他們能幫助你確定性能問題的癥結所在并且給你一些改進的方法。你也許還記得數據庫系統監視器是由兩種不同的監視工具組成：一個快照監視器和一個或多個事件監視器。在上個章節，我詳細介紹了快照監視器以及它是怎樣用于捕獲實例或數據庫在既定時間點上的當前狀態信息。在本章，我將要來介紹事件監視器是怎么被用于捕獲那些不能被快照監視器所抓取情況下的監視器數據。事件監視器
事件監視器收集監視器數據例如特定事件或者事務發生。因此，事件監視器提供了一個當事件或者活動發生的時候不能使用快照監視器監視時搜集數據庫系統監視器數據的方法。例如，假設你想要捕獲每當死鎖周期的發生時的監視器數據。如果你對死鎖的概念比較熟悉的話，你應該知道一個被稱之為死鎖監聽器的特殊進程在后臺安靜的運行并且在預定的間隔時間內會“蘇醒”用以為死鎖周期掃描當前正在鎖定的系統。如果死鎖周期被發現，死鎖監聽器將會隨機選擇、回滾并且終止涉及在此次周期中的任意一個事務。結果，被選擇出來的那個事務將會接受到是一個sql錯誤代碼，并且所有實際上已經獲得的所被釋放以便于剩下的事務能夠繼續執行。像這樣一系列的事件信息不能被快照監視器所捕獲，這有很大的可能是因為死鎖周期可能在快照執行很久之前就已經被破壞了。然后，事件監視器卻可以捕獲該事件的重要信息，因為它可以在死鎖周期被檢測到的瞬間被激活。這兩種監視器的另外一個顯著的不同是：快照監視器以后臺進程的方式駐留，從一個數據庫連接建立就開始捕獲監視器數據；相反地，事件監視器必須在他們使用之前專門去建立和激活。幾個不同的事件監視器可以共存，并且每個事件監視器只有在特定類型的事件或者事務發生的時候才會被激活。表1顯示的就是可以導致事件監視器被激活的一些事件類型，以及被每個事件類型所搜集的監視器數據的種類。
表1 事件類型和他們對應的數據由于事件監視器是特殊的數據庫對象因此它必須在使用之前創建，它們只能收集發生在它們被定義的數據庫中事件或者事務的監視器數據。你不能在實例級使用事件監視器來收集監視器數據。創建事件監視器
你可以直接在控制中心中創建事件監視器（從事件監視器菜單選擇創建事件監視器），也可以通過執行create event monitor 的sql語句來創建它，它的基本語法如下：
create event monitor [name]for [database |bufferpools |tablespaces |tables |deadlocks < with detail > |connections < where [eventcondition] > |statements < where [eventcondition] > |transactions < where[eventcondition] > , ...]write to [table [groupname] (table [tablename]) |pipe [pipename] |file [directoryname]][manualstart | autostart]
說明：name是被分配給這個事件監視器的名稱
eventcondition用于確定事件監視器將會為哪一個連接、語句或者事務收集數據的條件
groupname確定被定義的目標表上的邏輯數據群組（使用這個參數的可用值可以參見表1）
tablename確定指派給所有事件監視器寫入的數據庫表的名稱
pipename確定指派給所有事件監視器寫入命名管道的名稱
directoryname確定指派個包含事件監視器的一個或者多個文件寫入目錄的名稱
注意：在尖括號中出現的參數是可選擇的；出現在方括號里面的參數或者選擇是必須的。察看create event monitor sql語句的完整語法，參見ibm db2 universal database, version 8 sql reference volume 2文檔。我們假設如果你想創建一個關于捕獲所有應用級的計數器的值并且每當應用程序中止與數據庫的時候把它們寫入名為conn_data的數據庫表中的一個事件監視器。你可以執行下面的create event monitor語句來完成它。create event monitor conn_eventsfor connectionswrite to table
conn
(table conn_data)
現在我們假使你要創建一個用來捕獲緩沖池和表空間事件的監視器數據并且要把所有收集到的數據寫入到一個名為/export/home/bpts_data目錄的事件監視器。你可以執行下面的create event monitor語句來完成它。create event monitor bpts_eventsfor bufferpools, tablespaceswrite to file '/export/home/bpts_data'
正如你所看到的，當你創建一個事件監視器的時候你必須去指定激活監視器的事件的類型以及所有收集到的數據寫入的地方。一個事件監視器的輸出可以寫入到一個或者多個的數據庫表、外部文件或一個命名管道。表和管道型的事件監視器流事件直接記錄到指定表或者命名管道中。另一方面，文件型事件監視器流事件記錄成一系列具有.evt擴展名的8位編碼的文件（例如00000000.evt, 00000001.evt等等）。存儲在這些文件中的數據也許被處理成類似于一個單獨的數據流存儲的一個單獨的文件中。雖然這些數據實際上是被分割成許多小的數據塊。（數據流開始于00000000.evt文件的第一個字節，結束于創建的最后一個文件的最后一個字節）如果你指明事件監視器的輸出會存儲在數據庫表里面的話，那么所有的目標表將會在create event monitor語句被執行的時候自動被創建。（如果由于一些原因創建表失敗，那么會返回一個錯誤代碼同時create event monitor語句執行也就失?。┤欢绻阒该魇录O視器的輸出會寫入一個或者多個外部文件，或者一個命名管道的時候，這個輸出目錄或者命名管道則必須事先存在并且當事件監視器被激活時db2數據庫管理器實例自身必須能夠對它進行寫入。另外，如果使用的是一個命名管道，應用程序監視的命名管道必須要運行同時它也必須在事件監視器被激活之前將管道打開準備讀取信息。開始和停止事件監視器
如果你在創建一個事件監視器的時候指明使用autostart選項，那么監視器將會在包含它的數據庫開始的時候自動開始。（數據庫開始于使用activate database命令來激活或者第一個與該數據庫連接建立的時候。）如果你使用manualstart或者不知名任何選項（在這里，manualstart是缺省值），它的結果就是事件監視器不會收集監視器數據直至它開始活動。事件監視器可以通過執行set event monitor sql語句來開始（停止）。它的基本語法如下：
set event monitor [monitorname] state < = > [monitorstate]
說明：monitorname指明需要改變狀態的事件監視器的名稱
monitorstate指明指派給需要修改狀態的事件監視器的狀態。想要開始事件監視器的話（換句話說，也就是把它置為激活狀態），你要把它的值置為1。相反地，需要置為0。
現在我們假設你想要開始名為conn_events的事件監視器，它創建的時候采用了manualstart選項。你可以這么作：
set event monitor conn_events state 1
如果你想要得到與上面相反地結果，也就是說停止conn_events事件監視器的話，你可以執行這句：
set event monitor conn_events state 0
同時，你也可以通過在控制中心的事件監視器菜單中選中并且選擇你想要得動作來開始和停止事件監視器事件監視器一旦開始運行，它就會在后臺靜靜等待所為他設計的要監視的相應事件或者事務的出現。當這種情況出現的時候，事件監視器會收集合適的監視器數據信息并且將它們寫入到監視器的輸出對象中（表、目錄或者命名管道）。在這個時候，這些步驟將由事件或者事務自身去控制；數據庫管理員不需要去執行任何額外的步驟去收集事件監視器數據，這點與快照監視器在使用的時候是不同的。強制輸出
在有些時候，低記錄執行頻率的事件監視器（例如被設計于監視數據庫事件的監視器）會把事件監視器數據存儲在內存中而沒有存儲在事件監視器的目標空間上（因為這時候僅僅是部分事件記錄存在）。如果你在此時想要去檢查一下事件監視器的活動內部緩存里面的內容的話，可以執行flush event monitor sql語句。該語句的語法是flush event monitor [monitorname] <buffer>。monitorname指明你需要強制立即輸出他的活動內部緩存到目標空間的事件監視器的名稱。強制將conn_events事件監視器活動內部緩存的內容寫入到相應的空間，你可以執行flush event monitor conn_events語句。缺省情況下，早先被寫入事件監視器目標空間的那些記錄被記錄在事件監視器日志當中并且打上了一個部分記錄信息的標志。然而，如果你在執行flush event monitor的過程中指明了buffer選項的話，只有出現在事件監視器活動內部緩存的監視器數據才會被寫入到事件監視器的目標空間中，同時在事件監視器日志中沒有部分的記錄被記錄。當事件監控器被清除后，計數器并沒有復位。結果會造成，當事件監控器被正常觸發時，已經被生成的沒有使用flush event monitor語句的事件監控器記錄，仍然會被生成。事件監視器數據
有些時候，你想要察看事件監視器收集的數據。如果這些收集到的數據是寫入到一個命名管道，那么在管道末端負責接受的應用程序通常是以在它接受到數據的時候顯示出監視器數據的形式作為相應。如果事件監視器把數據寫入表或者一系列文件中的話，你可以通過一個名為事件分析器（event analyzer）的專用工具來察看數據或者使用event monitor productivity tool。事件分析器是一個gui工具，它可以通過在控制中心選中你所想得到的事件監視器并且從事件監視器菜單中選擇適當的動作或通過執行db2eva命令來激活。圖1顯示事件分析器在它第一次激活時候的典型示例。
圖1 時間分析工具
一旦它被激活，事件分析器允許你向下挖掘并瀏覽一個詳細的事件監視器捕獲的信息。事件分析器只能用于查看那些被收集并且存儲與數據庫表中的事件監視器數據。如果要查看被寫入到文件或者命名管道里面的監視器數據，你將要使用基于文本的event monitor productivity tool，它可以從一個事件監視器數據文件或命名管道中收取數據并且將這些數據處理成一個格式化的報告。（事件監視器文件和命名管道包含一個必須要在展示之前格式化的二進制邏輯數據群流）通過db2evmon命令可以激活event monitor productivity tool。這個命令的基本語法是
db2evmon -db [databasealias] -evm [monitorname] 或者 db2evmon -path [monitortarget]
說明：databasealias指明所要定義事件監視器的數據庫的別名
monitorname指明所分配的需要顯示數據的事件監視器的名稱
monitortarget指明已經被指定事件監視器收集的數據存儲的位置（目錄或命名管道）
作為例子，為了格式化和輸出被定義在sample數據庫中的事件監視器conn_events所有被收集的數據，你可以通過執行db2evmon -db sample -evm conn_events命令來得到。例如，假設你要使用下面的語句創建conn_events事件監視器
create event monitor conn_eventsfor connectionswrite to file 'c:/mondata'autostart
假設一個應用程序與sample數據庫已經建立起一個連接（使事件監視器可以收集和記錄監視數據）。db2evmon -db sample -evm conn_events命令返回輸出信息的文件頭部分表1中的樣例輸出類似。表1事件監視器conn_events的輸出樣例
reading c:/dbsio/00000000.evt ...
-----------------------------------------------------------------------
event log header
event monitor name: conn_events
server product id: sql08015
version of event monitor data: 7
byte order: little endian
number of nodes in db2 instance: 1
codepage of database: 1252
territory code of database: 1
server instance name: db2
-----------------------------------------------------------------------
-----------------------------------------------------------------------
database name: sample
database path: c:/db2/node0000 ql00001/
first connection timestamp: 03-24-2004 16:53:00.020233
event monitor start time: 03-24-2004 16:53:00.155733
-----------------------------------------------------------------------
3) connection header event ...
appl handle: 16
appl id: *local.db2.0120c4215303
appl seq number: 0001
drda as correlation token: *local.db2.0120c4215303
program name : db2evmon.exe
authorization id: rsanders
execution id : rsanders
codepage id: 1252
territory code: 0
client process id: 1788
client database alias: sample
client product id: sql08015
client platform: unknown
client communication protocol: local
client network name:
connect timestamp: 03-24-2004 16:53:00.020233
4) connection event
appl handle: 16
appl id: *local.db2.0120c4215303
appl seq number: 0003
record is the result of a flush: false
application status: sqlm_uowwait
lock statistics:
lock waits: 0
total time waited on locks (milliseconds): 0
deadlocks: 0
lock escalations: 0
x lock escalations: 0
lock timeouts: 0
sort statistics:
sorts: 0
total sort time (milliseconds): 0
sort overflows: 0
hash statistics:
hash joins: 0
hash loops: 0
hash join small overflows: 0
hash join overflows: 0
buffer pool statistics:
buffer pool logical data page reads: 12
buffer pool physical data page reads: 4
buffer pool data page writes: 0
buffer pool logical index page reads: 30
buffer pool physical index page reads: 18
buffer pool index page writes: 0
buffer pool read time (microseconds): 0
buffer pool write time (microseconds): 0
time spent waiting for a prefetch: 0 milliseconds
unread prefetch pages: 0
workspace statistics:
shared workspace high water mark: 0
total shared workspace overflows: 0
total shared workspace section lookups: 0
total shared workspace section inserts: 0
private workspace high water mark: 13746
total private workspace overflows: 0
total private workspace section lookups: 2
total private workspace section inserts: 2
direct i/o statistics:
sectors read directly: 14
sectors written directly: 0
direct read requests: 5
direct write requests: 0
direct read time: 0
direct write time: 0
sql statement counts
commit sql statements: 1
rollback sql statements: 0
dynamic sql statements: 1
static sql stmts: 3
failed sql statements: 0
select sql statements: 2
data definition language sql statements: 0
update/insert/delete sql statements: 0
internal counts
internal auto rebinds: 0
internal rows deleted: 0
internal rows updated: 0
internal rows inserted: 0
internal commits: 0
internal rollbacks: 0
internal rollbacks due to deadlock: 0
row counts
rows deleted: 0
rows inserted: 0
rows updated: 0
rows selected: 2
rows read: 6
rows written: 0
binds/precompiles: 0
rejected block cursor requests: 0
accepted block cursor requests: 0
package cache statistics
package cache lookups: 3
package cache inserts: 2
section lookups: 3
section inserts: 2
catalog cache statistics
catalog cache overflows: 0
catalog cache high water mark: 0
catalog cache lookups: 2
catalog cache inserts: 0
cpu times
user cpu time: 0.000000 seconds
system cpu time: 0.000000 seconds
memory usage:
memory pool type: other memory
current size (bytes): 16384
high water mark (bytes): 98304
maximum size allowed (bytes): 1071644672
memory pool type: application heap
current size (bytes): 212992
high water mark (bytes): 212992
maximum size allowed (bytes): 1277952
memory pool type: application control heap
current size (bytes): 16384
high water mark (bytes): 16384
maximum size allowed (bytes): 704512
disconnection time: 03-24-2004 16:53:00.191692
接下來
快照監視器和事件監視器被設計用于幫助你確定并修正那些已經影響數據庫系統的性能問題。db2 udb v.8.1還提供了兩種額外的工具（the health monitor and health center）來幫助你在它們變成真正的問題之前找出它的前兆來。這就是接下來的章節中要說的主題。
完整版本（包含圖片的pdf文件）請到http://hbird.vicp.net/viewthread.php?tid=1486處下載
