數據庫系統就像一輛高性能的賽車，需要一些例行檢查來保證其運行良好。本文介紹何時去監視數據庫的運行以及階段時間內數據庫管理人員應該如何做。隨着數據庫自動運行維護技術的提高，維護數據庫的人工勞力也降低了不少。監視數據庫系統的運行是爲了確保當前狀態下數據庫沒有錯誤配置並且能發現潛在故障。
正常情況下，需要對DB2和操作系統兩方面來進行監視，以獲得服務器上數據庫的運行狀態的全面信息。建議至少連續1個小時地監視每隔1到5分鐘的系統快照狀態數據來分析系統的健康狀況。
正常情況下，需要對DB2和操作系統兩方面來進行監視，以獲得服務器上數據庫的運行狀態的全面信息。建議至少連續1個小時地監視每隔1到5分鐘的系統快照狀態數據來分析系統的健康狀況。
基本知識
在Linux或Unix平臺下可使用vmstat和iostat等命令工具來監視CPU和內存的使用情況，這些命令後面可帶2個參數，第一個是以秒記的間隔時間，按這個時間間隔運行命令，第二個是以秒記的連續時間段，在這個時間段結束時命令也就會自動停止執行。例如，下面兩條命令：vmstat 300 28800 >vmstat.out 以及 iostat -tx 300 28800 > iostat.out，其中300秒是5分鐘，28800秒是指8個小時。第二個參考命令中的-tx開關不是在所有的Linux/Unix平臺下都有效，有了-tx開關將在每條輸出的系統狀態快照信息的開頭位置打上信息產生的時間標誌。
注意保證數據庫運行的峯值負載別超過服務器系統許可的範圍。Windows平臺下可以使用圖示化的任務管理器窗口來監視系統內CPU和內存的運行狀態，但不能將結果記錄到文件中。
DB2使用多種工具用來監視數據庫系統以及數據庫實例的運行和活動情況，這些工具比如健康中心、快照監控器、SQL快照函數以及事件監控器等。還有一些管理日誌文件也記錄了一些系統運行狀態信息，比如DB2DIAG.LOG以及內存可視化工具等。
1-健康狀況監視器，通過監視DB2數據庫實例的運行狀態來預測發生潛在問題的可能性，及時通知用戶對非健康實例進行處理。一旦監測到錯誤，可以通過email告知用戶或運行預設CLP腳本的方式來進行處理。健康狀態監視器對預先設定的各種健康指標的閥值進行監視，指標突破閥值將產生警報或觸發預設處理腳本。健康管理中心則提供了對健康監視器的圖形化顯示接口，命令和API都可以從健康管理中心運行，在管理中心可對健康管理器進行配置，看到數據庫實例和對象的累積的報警信息以及處理辦法。
2-快照監視器及SQL快照函數，DB2負責維護的數據有操作方面、性能方面、以及來訪數據庫的應用程序方面，比如你可以從數據中找到，正在連接數據庫的應用程序數以及應用程序正在執行哪些SQL語句，還可幫助你進行數據庫配置調優，以及正在被應用程序佔用和鎖住的表等數據庫對象有哪些，以及SQL語句的執行內容和次數等等詳細信息，還有每條SQL語句佔用的CPU時間等等。還有排序動作的發生次數以及正在發生的排序動作也可以被快照監視器記錄到。
監視器開關（monitor switches）可單獨地針對特定數據庫對象進行監視，這些對象有實例、實例中的全部數據庫、或數據庫會話。使用會話監視開關的命令是UPDATE MONITOR SWITHES或調用sqlmon()接口API函數。舉例說明，開啓緩衝池、鎖以及動態SQL語句監視可以使用以下命令：update monitor switches using bufferpool on lock on statement on。注意你必須要擁有sysadm,sysctrl,sysmaint,或sysmon（db2 9新增）權限纔可以扳動監視器開關執行快照運算。利用事件察看器也可以訪問數據，在命令行下使用GET SNAPSHOT命令，調用SQL快照表函數，使用控制中心，以及調用sqlmonss()接口函數自己編程來進行數據訪問。
3-事件監視器，啓動該監視器後，將記錄數據庫的連接/斷開，死鎖或鎖超時，語句執行以及事務開始或結束等事件信息。比如一個死鎖事件監視器負責監視死鎖事件的發生，一旦死鎖情況發生應用程序的信息以及造成死鎖的條件將被收集和記錄，可以使用CREATE EVENT MONITOR語句來生成事件監視器，監視器只有在激活的情況下纔可以記錄事件信息，激活/停止監視器的命令是：SET EVENT MONITOR語句。EVENT_MONITOR_STATE函數將返回指定的事件監視器的當時狀態。
一旦執行了CREATE EVENT MONITOR命令，事件監視器的定義集將生成並存放在系統類目表中，例如：
爲數據庫定義的事件監視器SYSCAT.EVENTMONITORS，
爲數據庫監視的事件類型SYSCAT.EVENTS，
以及需要監視的目標表的名稱SYSCAT.EVENTTABLES等。
在Linux或Unix平臺下可使用vmstat和iostat等命令工具來監視CPU和內存的使用情況，這些命令後面可帶2個參數，第一個是以秒記的間隔時間，按這個時間間隔運行命令，第二個是以秒記的連續時間段，在這個時間段結束時命令也就會自動停止執行。例如，下面兩條命令：vmstat 300 28800 >vmstat.out 以及 iostat -tx 300 28800 > iostat.out，其中300秒是5分鐘，28800秒是指8個小時。第二個參考命令中的-tx開關不是在所有的Linux/Unix平臺下都有效，有了-tx開關將在每條輸出的系統狀態快照信息的開頭位置打上信息產生的時間標誌。
注意保證數據庫運行的峯值負載別超過服務器系統許可的範圍。Windows平臺下可以使用圖示化的任務管理器窗口來監視系統內CPU和內存的運行狀態，但不能將結果記錄到文件中。
DB2使用多種工具用來監視數據庫系統以及數據庫實例的運行和活動情況，這些工具比如健康中心、快照監控器、SQL快照函數以及事件監控器等。還有一些管理日誌文件也記錄了一些系統運行狀態信息，比如DB2DIAG.LOG以及內存可視化工具等。
1-健康狀況監視器，通過監視DB2數據庫實例的運行狀態來預測發生潛在問題的可能性，及時通知用戶對非健康實例進行處理。一旦監測到錯誤，可以通過email告知用戶或運行預設CLP腳本的方式來進行處理。健康狀態監視器對預先設定的各種健康指標的閥值進行監視，指標突破閥值將產生警報或觸發預設處理腳本。健康管理中心則提供了對健康監視器的圖形化顯示接口，命令和API都可以從健康管理中心運行，在管理中心可對健康管理器進行配置，看到數據庫實例和對象的累積的報警信息以及處理辦法。
2-快照監視器及SQL快照函數，DB2負責維護的數據有操作方面、性能方面、以及來訪數據庫的應用程序方面，比如你可以從數據中找到，正在連接數據庫的應用程序數以及應用程序正在執行哪些SQL語句，還可幫助你進行數據庫配置調優，以及正在被應用程序佔用和鎖住的表等數據庫對象有哪些，以及SQL語句的執行內容和次數等等詳細信息，還有每條SQL語句佔用的CPU時間等等。還有排序動作的發生次數以及正在發生的排序動作也可以被快照監視器記錄到。
監視器開關（monitor switches）可單獨地針對特定數據庫對象進行監視，這些對象有實例、實例中的全部數據庫、或數據庫會話。使用會話監視開關的命令是UPDATE MONITOR SWITHES或調用sqlmon()接口API函數。舉例說明，開啓緩衝池、鎖以及動態SQL語句監視可以使用以下命令：update monitor switches using bufferpool on lock on statement on。注意你必須要擁有sysadm,sysctrl,sysmaint,或sysmon（db2 9新增）權限纔可以扳動監視器開關執行快照運算。利用事件察看器也可以訪問數據，在命令行下使用GET SNAPSHOT命令，調用SQL快照表函數，使用控制中心，以及調用sqlmonss()接口函數自己編程來進行數據訪問。
3-事件監視器，啓動該監視器後，將記錄數據庫的連接/斷開，死鎖或鎖超時，語句執行以及事務開始或結束等事件信息。比如一個死鎖事件監視器負責監視死鎖事件的發生，一旦死鎖情況發生應用程序的信息以及造成死鎖的條件將被收集和記錄，可以使用CREATE EVENT MONITOR語句來生成事件監視器，監視器只有在激活的情況下纔可以記錄事件信息，激活/停止監視器的命令是：SET EVENT MONITOR語句。EVENT_MONITOR_STATE函數將返回指定的事件監視器的當時狀態。
一旦執行了CREATE EVENT MONITOR命令，事件監視器的定義集將生成並存放在系統類目表中，例如：
爲數據庫定義的事件監視器SYSCAT.EVENTMONITORS，
爲數據庫監視的事件類型SYSCAT.EVENTS，
以及需要監視的目標表的名稱SYSCAT.EVENTTABLES等。
注意對整個數據庫系統（包含OS以及DBMS兩個方面）的狀態進行監視，以確保數據庫環境能良好地運行。
每天做的
1-確保所有實例啓動並運行。有以下一些方法：
每天做的
1-確保所有實例啓動並運行。有以下一些方法：
使用健康中心圖形環境；
export/set DB2INSTANCE=實例名稱，然後運行db2start命令；
使用腳本來附加所有實例；
察看每個實例至少有一個db2sysc進程，具體命令是ps -ef|grep db2sysc；在Windows平臺下檢查每個DB2實例的服務是否啓動。
2-校驗所有數據庫處在活動和一致性的狀態中。
一致性定義混亂後，執行GET DB CFG命令經常會引發問題。只有被確認後的事務數據才寫入磁盤中保存，比如某些應用程序發生的事務改變了一些數據庫頁，事務可能被確認，但那些被改變的數據庫頁面文件也可能不會從緩衝寫入磁盤。也有事務回滾但頁面內容寫入磁盤的情況發生。檢查這種數據庫一致性問題，可以用編寫腳本的方式來完成，前提是所有數據庫應該被分類在工作之上。
3-檢查管理員提醒日誌或DB2DIAG.LOG文件中的條目。
管理員提醒日誌爲DBA準備，DB2DIAG.LOG文件爲DB2服務小組而準備。在windows平臺上通過察看事件管理器中的應用程序事件來獲得DB2事件信息。在Linux/Unix平臺下日誌文件被寫入<instant_ID>.nfy的文件中，存放在DIAGPATH指定的目錄中，察看的方法有：使用TELNET或遠程終端服務登陸數據庫服務器進行察看，對單獨的實例可察看DIAGPATH目錄，在命令行模式下，針對管理員提醒日誌文件運行tail命令獲取最後100條日誌信息，編輯文件察看文件底部最近的日誌紀錄條目。
4-檢查昨天晚上的備份是否成功。
晚上備份如果有錯或沒有存放在安全的地方，那麼對日後的恢復來說簡直就是災難。確認備份成功的命令是：list history backup all for 跟上數據庫名稱作爲參數。可以使用腳本方式在備份過程結束後運行該命令，並且將結果email給用戶，異地的備份文件可通過LAN驅動器、NFS驅動器或磁帶設備來恢復。如果不能丟失任何確認事務信息記錄，請開啓數據庫日誌功能。<待續...>
5-校驗數據庫日誌文件是否歸檔成功。
如果是隻讀數據庫或內容可以從草稿中方便地恢復，那麼管理員就不必啓用數據庫日誌功能，因此可略過此段介紹。但如果管理的是事務性的數據庫，那麼任何一個確認性事務處理都應該被記錄到日誌中，而且日誌文件應該成功備份，當災害發生時，數據庫內容以及發生的事務才能夠被恢復和再現。需要校驗日誌文件是否被成功歸檔的另外一個重要原因是，日誌文件如果不歸檔，那麼它們將遺留在LOGPATH目錄中，該目錄空間大小固定，一旦被舊日誌內容充滿沒有歸檔處理，將使新的日誌文件無建立的空間而導致DB2數據庫的停機。歸檔一個日誌文件時，將調用userexit進程，調用結果會被寫入到LOGPATH目錄中的ARCHIVE.LOG和USEREXIT.ERR兩個文件中，管理員可通過編寫並執行含有tail命令的腳本來讀取這些日誌文件的最後50到100行的日誌記錄條目，供分析用。
6-檢查並確認數據庫和管理系統的配置參數沒有被更改。
在有多個管理員的數據庫環境下，經常會發生某個管理員改動配置參數而其他管理員不知曉的情況，所以管理員需要檢查數據庫相關配置文件的正確性，通過下列命令實現：“get dbm cfg” 和“get db cfg for 具體數據庫名稱”。將這些命令的結果輸出到一個文件，文件名可寫上當時的時間，比如結果文件名“DB_DBM_CFG.06122006.out” ；使用diff命令來比較各天的配置文件有無改變，例如：“diff DB_DBM_CFG.02032006.out DB_DBM_CFG.02042006.out”，如果兩個配置文件內容有不一樣的地方，將被顯示出來。
7-根據工作負載來檢查重要性能的度量。
對一個在線事務處理系統(OLTP)來說，緩衝池的利用比率是非常重要的。數據倉庫應用中不可能有非常高的緩衝池利用率，所以根據工作負載量來進行各項性能檢查就顯得很重要了。
下面的這條語句將計算日期、索引和緩衝池利用率以及異步讀取內容的百分比：
“select substr(bp_name,1,20) as BP_NAME, int ((1- (decimal(pool_data_p_reads) / nullif(pool_data_l_reads,0)))*100) as data_hit_ratio, int ((1-(decimal(pool_index_p_reads)/nullif(pool_index_l_reads,0)))*100) as index_hit_ratio, int ((1-(decimal(pool_data_p_reads+pool_index_p_reads)/nullif((pool_data_l_reads+pool_index_l_reads),0)))*100) as BP_hit_ratio, int ((1-(decimal(poo_asyn_data_reads+pool_asyn_index_reads)/nullif((pool_async_data_reads+pool_async_index_reads+direct_reads),0)))*100) as Async_read_pct, int ((1-(decimal(direct_writes)/nullif(direct_reads,0)))*100) as Direct_RW_Ratio from table (snapshot_bp ('sample', -1)) as snapshot_bp;” 。
注意上面語句中的nullif函數，當()中的值等於零時將返回NULL，否則除零語句將會出錯。下面的查詢語句將報告被讀或被寫的記錄的行數等：“select substr(table_schema,1,8) as Schema, substr(table_name,1,30) as Table_Name, rows_read, rows_written, overflow_accesses from table (snapshot_table ('sample', -1)) as snapshot_table;”。
如果要檢查所有數據庫中的讀寫行數對比、發生的等鎖數、總的鎖佔用時間、單位時間內的鎖佔用數量、死鎖或鎖增加趨勢、發生了多少次排序操作以及相關的時間量等數據庫使用模式，可以執行下一條語句：“select db_name, SNAPSHOT_TIMESTAMP,rows_read, rows_selected, lock_waits, lock_wait_time, lock_wait_time/nullif(lock_waits,0) as avg_wt_time, deadlocks, lock_escals, total_sorts, total_sort_time, total_sort_time/nullif(total_sorts,0) as avg_sort_time, sort_overflows, sort_overflows/nullif(total_sorts,0) as pct_ovflow_sorts from table (snapshot_database ('',-1)) as snapshot_database;”。
8-檢查DB2是否按要求執行了自動動作。
雖然自動化程度提高了，但對於自動化的結果管理員還是需要關注的，這些就包括配置參數以及表空間的分配的細節了。跟蹤表空間分配情況用“list tablespaces show detail” 命令；內存自動調優的日誌記錄到stmmlog目錄下的stmm.#.log文件中。在windows系統下stmmlog目錄位於SQLLIB\Instance目錄下，Unix/Linux系統下的stmmlog目錄位於不同用戶的SQLLIB目錄下。
9-確信還有足夠的剩餘內存空間可供數據庫使用。
察看服務器上的總內存大小和DB2數據庫佔用的內存大小情況是很重要的一件事，在Unix/Linux平臺下使用free命令將顯示出系統的總內存大小以及被應用程序佔用掉的內存大小，和當前系統剩餘可用的內存大小。
10-每天建議學習DB2的相關知識。
廣泛的閱讀相關資料，比如“DBA手冊、雜誌、新聞組以及郵件列表等”對數據庫管理員有幫助，comp.databases.ibm-db2新聞組就是一個不錯的參考知識站點。而且DB2認證系列圖書也很有提醒價值。
每週做的
1-查找新的數據庫對象。
察看是否有人在你的生產型數據庫中建立了新的數據庫對象（比如，表、索引、存儲進程、）也是一件重要的事情。新對象的出現，一般意味着服務器上有新的應用出現了，否則新出現的對象會影響到系統操作的特性。另外新對象也會消耗掉系統的一部分存儲空間，如果是非管理員建立的新數據庫對象將可能會對數據庫表空間和運行效率產生不良影響。有幾種方法用來檢查DB2數據庫中的新對象，比如，通過運行“db2look”命令並對每週輸出結果寫報告對比的方式；或者採用從SYSCAT.TABLES,SYSCAT.INDEXES,SYSCAT.PROCEDURES表中列出對象名的方法來進行每週的比較處理。通過發現新對象的建立者CREATOR來進行維護管理。
2-查找新的或改變了的應用程序。
因爲經常會發現應用程序開發人員調整了應用程序中的代碼，而沒有及時告訴數據庫管理調優人員，導致調優工作經常需要反覆。所以數據庫管理員經常需要查找新的或變化了的應用程序。採用“list applications show detail”命令將輸出結果保存到文件供每週對照，以發現有無新應用程序出現。
採用建立新表來觀察運行的sql語句的方式，來發現有無改變了的應用程序代碼：首先“create table SQLstmts (stmt varchar(200), tstamp timestamp not null with default)” ，然後“insert into SQLstmts (stmt) select substr(stmt_text,1,200) as SQL_Stmt from table (snapshot_dyn_sql ('sample', -1)) as snapshot_dyn_sql” 最後察看有無當前未執行的語句“select distinct stmt, count(stmt), tstamp from sqlstmts group by stmt, tstamp”結果中注意那些是1的語句對象。
3-查找需要重新組織的表或索引。
當在表上插入、更新、刪除記錄行時，表中的數據需要重新組織，以便使索引、空間、記錄等能更優化地存在。採用的命令工具是“reorgchk”，該工具可針對單個表、所有用戶表、以及指定計劃中的所有表、或所有的系統分類表。該工具還能直接讀取系統表中的已有統計或自己重新收集統計數據，例如，執行命令“reorgchk update statistics on table user” 檢查用戶的所有表的已有統計數據。當察看reorgchk命令工具輸出的結果時，F1,F2,F3用戶的表列；F4,F5,F6,F7和F8用戶的索引列，其中如果發現*值，就表示那列的值超出了DB2的限制。出現*值需要部分調整索引的組織，這裏比較繁瑣，暫時忽略。各列相關內容簡介：“F1列：超值記錄條，F2列：數據頁面上的已用空間，F4列：叢串的比率，F5列：每索引頁面使用鍵值的空間，F6列，每索引級別上可存放的鍵數量，F7列：每頁上已經被標記刪除的記錄IDs，F8列：索引中的空子頁”。比如針對ORG表進行ORGX索引重新組織，可採用命令“reorg table org index orgx”。DB2優化器可以根據使用數據庫的統計數據來安排SQL語句的優化執行。如果用戶的數據庫表中數據發生了很大的變化，那麼就有必要使用“runstats” 命令工具捕獲新的統計數據，並將這些新數據存到系統表中去，確信對新表和新索引做了統計數據捕獲。比如，使用命令“runstats on table <schema>.org with distribution and detailed indexes all”對ORG表進行捕獲操作，注意命令中必須指定對象表的schema值。
4-查找需要捕獲運行狀態的表和索引。
察看7天以上或無相關統計數據的表的命令是“select substr(name,1,30),substr(creator,1,10),stats_time from sysibm.systables where stats_time < ((current timestamp) - 7 days) or stats_time is null” 或者執行“select substr(name,1,30),substr(creator,1,10),stats_time from sysibm.sysindexes where stats_time < ((current timestamp) - 7 days) or stats_time is null”。
5-查找最活躍的10張表。
根據被讀的頻率來確定需要執行reorg或runstats命令的表，使用以下語句：“select substr(table_schema,1,10) as tbschema, substr(table_name,1,30) as tbname,rows_read,rows_written,overflow_accesses,page_reorgs from table (SNAPSHOT_TABLE(' ', -1)) as snapshot_table order by rows_read desc fetch first 10 rows only”，根據被寫的次數找出10張更新最頻繁的表使用以下語句：“select substr(table_schema,1,10) as tbschema,substr(table_name,1,30) as tbname, rows_read, rows_written, overflow_accesses, page_reorgs from table (SNAPSHOT_TABLE(' ', -1)) as snapshot_table order by rows_written desc fetch first 10 rows only”，通過這些命令發現的表需要做runstats或reorg等處理。
6-將所有報警日誌和DB2DIAG.LOG文件歸檔處理。
這些日誌文件需要每週做處理，保存以便將來調查分析，壓縮保存以節省存儲空間，Unix/Linux系統下使用tar命令將所有*.nfy文件以及db2diag.log文件聚集在一起，然後用gzip或compress命令壓縮結果文件的大小，Windows平臺下使用日誌文件窗口處理這裏就不再囉嗦了。
7-注意檢查並更新軟件到新版本。
當系統平穩運行時，一般不需要升級或補丁自己的DB2軟件。可關注的兩個DB2相關軟件更新的地址是：“[url]http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/WINV8FP[/url]” 和“[url]http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report[/url]” 。
每月做的
1-查找異常增長的指示器。
回顧表空間在過去的一個月時間裏，增長了多少，發現特別消耗空間的表，以便提前做預處理。比如，採用以下命令“select substr(tablespace_name,1,120) as TBSPC_NAME,used_pages, free_pages from table (snapshot_tbs_cfg (' ', -1)) as snapshot_tbs_cfg”獲取表空間大小以及剩餘可用空間大小。從系統類別表中察看用戶表空間的大小，執行語句是“select tabname,npages from syscat.tables where tablename not like 'SYS%'”，注意如果表的統計數據沒有捕獲，那麼npages值將顯示-1。結果可以輸出到外部文件來分析。
2-根據增長適當規劃數據庫系統的擴張問題。
比較你收集到的處理器、內存、以及磁盤利用率等系統級信息，規劃DB2數據庫對象今後擴展的對策。
(若需轉載發佈，請註明來源：51CTO.com)