本文摘自 http://www-128.ibm.com/developerworks/cn/db2/library/techarticles/dm-0404snow/index.html
DB2 UDB DBA 核對清單
一.簡介
?雖然數(shù)據(jù)庫越來越具有自我感知（self-aware）和自我修復(fù)（self-healing）的能力，但是仍然需要進(jìn)行一些監(jiān)控，才能使數(shù)據(jù)庫盡可能高效地運(yùn)行。就像汽車一樣，數(shù)據(jù)庫也需要進(jìn)行一些檢查，才能夠以最佳狀態(tài)運(yùn)行。本文被劃分為一些檢查或任務(wù)，這些檢查或任務(wù)應(yīng)該按不同時間間隔執(zhí)行。
?第一組檢查或任務(wù)應(yīng)該每天都執(zhí)行，以確保當(dāng)前或者將來一段時間內(nèi)沒有問題。第二組檢查或任務(wù)則需要每周運(yùn)行一次，以檢查本周內(nèi)曾出現(xiàn)的問題，或者下周很可能會出現(xiàn)的問題。最后一組檢查或任務(wù)不必每天或每周都運(yùn)行，但是應(yīng)該每個月都運(yùn)行一次，以保持系統(tǒng)正常運(yùn)行，如果的確出現(xiàn)了問題，則防止問題擴(kuò)大。
二.監(jiān)控系統(tǒng)
?有很多原因致使您應(yīng)該監(jiān)控數(shù)據(jù)庫，不過，最主要的原因是為了確保系統(tǒng)當(dāng)前或者在將來一段時間內(nèi)不存在問題。在問題還未發(fā)生之前就檢測到問題，并采取行動，總比等到問題已經(jīng)發(fā)生而被動地作出反應(yīng)要好。如果按照本文描述的那樣監(jiān)視 DB2 數(shù)據(jù)庫系統(tǒng)，就可以在很多問題發(fā)生之前檢測到它們，并維護(hù)系統(tǒng)的性能。
三.可用的監(jiān)控工具
?通常，您需要將對 DB2 的監(jiān)控與對操作系統(tǒng)的監(jiān)控結(jié)合起來，以便得到對數(shù)據(jù)庫服務(wù)器上所發(fā)生一切的完整描述。單憑 DB2 工具一般不能提供完整的描述。
?在捕捉用于分析的信息時，應(yīng)確保同時捕捉 DB2 和操作系統(tǒng)的信息，因為我們不能把在不同時間捕捉到的信息相關(guān)聯(lián)。
3.1 Linux 和 UNIX 工具
?在監(jiān)控系統(tǒng)時，每過一段時間就拍一次快照。如果只是拍一兩分鐘內(nèi)的快照，那么就無法提供系統(tǒng)活動的真正視圖。我建議每隔一兩分鐘就拍一次，并堅持至少一個小時。例如，為了捕捉 CPU、內(nèi)存以及其他操作系統(tǒng)使用情況，可以使用工具 vmstat。
?vmstat命令的參數(shù)如下：
?參數(shù) 1: 時間間隔，以秒計，該工具按照這個時間間隔捕捉系統(tǒng)信息。
?參數(shù) 2: 該工具應(yīng)該捕捉系統(tǒng)信息的次數(shù)。
?為了連續(xù)一個小時每一分鐘捕捉一次 vmstat 信息，并將輸出寫到一個名為 vmstat.out 的文件中，可以使用如下命令：
?vmstat 60 60 > vmstat.out
?為了連續(xù)一個小時每兩分鐘捕捉一次 vmstat 信息，并將輸出寫到一個名為 vmstat.out 的文件中，可以使用如下命令：
?vmstat 120 30 > vmstat.out
?既要捕捉正常/平均工作負(fù)載，也要捕捉峰值工作負(fù)載。雖然確保高效地處理正常工作負(fù)載很重要，然而同樣重要的是，還應(yīng)確保系統(tǒng)能夠在不使服務(wù)器超載的情況下處理峰值工作負(fù)載。
3.2 DB2 工具
?DB2 有很多工具可用于監(jiān)控數(shù)據(jù)庫和實(shí)例的活動。這些工具包括：
?Health Monitor / Health Center
?Snapshot Monitors / SQL Snapshot 函數(shù)
?Event Monitor
?還有其他一些工具和日志也可以提供關(guān)于數(shù)據(jù)庫和實(shí)例的信息，包括：
?administration notification log
?在 Linux 和 UNIX 中，這是一個獨(dú)立的文件，而在 Windows 中，這個文件被合并到 Event Log 中。
?DB2DIAG.LOG
?Memory Visualizer
??? 1. Health Monitor
?在 Version 8 中，DB2 引入了兩個新特性，用于幫助監(jiān)控 DB2 系統(tǒng)的健康狀況，這兩個新特性分別是：Health Monitor 和 Health Center。
?這兩個工具可以就系統(tǒng)潛在的健康問題向用戶發(fā)出警告，從而為 DB2 Universal Database 添加了 management by exception（基于異常的管理）功能。
?這樣就可以在那些會影響系統(tǒng)性能的健康問題真正發(fā)生之前，將它們解決掉。
?Health Monitor 運(yùn)行在 DB2 服務(wù)器上，并持續(xù)地監(jiān)控 DB2 實(shí)例和數(shù)據(jù)庫的健康狀況。如果 Health Monitor 檢測到用戶定義的某個閾值被超出
?（例如，可用日志空間占總空間的百分比下降到低于某個指定的百分?jǐn)?shù)），或者檢測到某個對象的狀態(tài)反常（例如，DB2 實(shí)例不再運(yùn)行），則 Health Monitor 將發(fā)出警告。
?當(dāng)有警告發(fā)出時，就可能發(fā)生兩件事情：
?發(fā)送警告通知。 可以通過 e-mail 發(fā)送，或者發(fā)送到尋呼臺。
?采取預(yù)先配置的行動。 執(zhí)行一個 CLP 腳本或者 Task Center 任務(wù)。
?健康指示器（health indicator）是 Health Monitor 所檢查的一個系統(tǒng)特征（system characteristic）。Health Monitor 自帶了一組針對這些健康指示器的預(yù)定義閾值。
?當(dāng)判斷是否發(fā)出警告時，Health Monitor 對照這些健康指示器閾值來檢查系統(tǒng)狀態(tài)。通過使用 Health Center、命令或 API，您可以定制這些健康指示器的閾值設(shè)置，
?并定義如果發(fā)出警告，則通知的對象是誰，應(yīng)該運(yùn)行什么樣的腳本或任務(wù)。
?Health Center 提供了 Health Monitor 的圖形化界面。您可以使用它來配置 Health Monitor，并查看實(shí)例和數(shù)據(jù)庫對象累積的（rolled up）警告狀態(tài)。
?通過使用 Health Center 的下鉆（drill-down）功能，可以訪問關(guān)于當(dāng)前警告的詳細(xì)信息，并獲得建議的行動清單，其中描述了如何處理警告。
?可以直接在該工具中選擇遵循某一條建議的行動。我們可以很容易地配置 Health Center，使其顯示狀態(tài)行健康提示（status line health beacon）和/或彈出一個對話框，
?告訴 Health Center 有一個處于警告狀態(tài)的對象。
??? 2. Snapshot Monitors / SQL Snapshot 函數(shù)
?DB2 維護(hù)著關(guān)于它的操作、性能以及訪問它的應(yīng)用程序的數(shù)據(jù)。這種數(shù)據(jù)是在數(shù)據(jù)庫管理器運(yùn)行時維護(hù)的，可以提供重要的關(guān)于性能和故障診斷的信息。
?例如，您可以發(fā)現(xiàn)：
?連接到數(shù)據(jù)庫的應(yīng)用程序的個數(shù)，這些應(yīng)用程序的狀態(tài)，以及每個應(yīng)用程序正在執(zhí)行的 SQL 語句。
?表明數(shù)據(jù)庫管理器和數(shù)據(jù)庫的配置情況的信息，這些信息可以幫助對數(shù)據(jù)庫管理器和數(shù)據(jù)庫進(jìn)行調(diào)優(yōu)。
?某個指定的數(shù)據(jù)庫何時發(fā)生了死鎖，調(diào)用了哪些應(yīng)用程序，以及哪些鎖存在競爭。
?由應(yīng)用程序或數(shù)據(jù)庫持有的鎖列表。如果應(yīng)用程序由于要等一個鎖而不能往前執(zhí)行，那么就要添加關(guān)于這個鎖的附加信息，包括哪個應(yīng)用程序正持有這個鎖。
?對某個特定數(shù)據(jù)庫執(zhí)行的 SQL 語句的清單，這些語句執(zhí)行的次數(shù)，跟這些語句有關(guān)的排序的次數(shù)，以及每條語句占用的 CPU 總時間。
?曾經(jīng)發(fā)生過的排序次數(shù)以及當(dāng)前正在發(fā)生的排序數(shù)目。
?由于監(jiān)視器的確會給系統(tǒng)增加一些開銷，所以應(yīng)該可以獨(dú)立地啟用或禁用 監(jiān)視器開關(guān)（monitor switch）。
?監(jiān)視器開關(guān)可以為整個實(shí)例而設(shè)，為實(shí)例中所有的數(shù)據(jù)庫而設(shè)，或者僅用于一個數(shù)據(jù)庫會話。
?如果在一個會話內(nèi)啟用監(jiān)視器開關(guān)，那么這些監(jiān)視器僅僅對于這個會話是“活動的（active）”，從其他會話中拍得的快照無法捕捉監(jiān)視器信息。
?如果使用 DB2 實(shí)例配置參數(shù)啟用監(jiān)視器開關(guān)，那么所有會話都可以使用監(jiān)視器，除非顯式地在某一個會話中將監(jiān)視器開關(guān)關(guān)掉。
?為了在一個會話內(nèi)設(shè)置監(jiān)視器開關(guān)，可以使用 UPDATE MONITOR SWITCHES 命令或 sqlmon() API。
?例如，要啟用緩沖池監(jiān)視，可以使用以下命令打開監(jiān)視器開關(guān)：
?update monitor switches using bufferpool on
?注意： 要想更新監(jiān)視器開關(guān)和/或拍 DB2 快照，必須具有 SYSADM、SYSCTRL 或 SYSMAINT 授權(quán)。
?可以通過拍快照或者使用事件監(jiān)視器來訪問由數(shù)據(jù)庫管理器維護(hù)的數(shù)據(jù)。我們可以使用下列方法中的任意一種來拍快照：
?在命令行中使用 GET SNAPSHOT 命令。
?調(diào)用 SQL Snapshot 函數(shù)。
?使用 Control Center。
?編寫自己的應(yīng)用程序，從該應(yīng)用程序調(diào)用 sqlmonss() API 。
??? 3. Event Monitor
?一旦創(chuàng)建并激活了一個事件監(jiān)視器（event monitor），則當(dāng)指定的事件發(fā)生時，該事件監(jiān)視器將收集關(guān)于數(shù)據(jù)庫和任何數(shù)據(jù)庫應(yīng)用程序的信息。
?所謂事件是指在數(shù)據(jù)庫活動中的一次更改，它可能由下列某一原因引起：
??數(shù)據(jù)庫連接/斷開連接。
??死鎖或鎖超時。
??語句執(zhí)行。
??事務(wù)開始或結(jié)束。
?事件監(jiān)視器是根據(jù)想要檢測和記錄的事件類型來創(chuàng)建的。
?例如， 死鎖事件監(jiān)視器（deadlock event monitor）等待死鎖的出現(xiàn)；當(dāng)出現(xiàn)死鎖時，該監(jiān)視器便收集并記錄關(guān)于涉及死鎖條件的應(yīng)用程序和鎖的信息。
?事件監(jiān)視器可以使用 CREATE EVENT MONITOR 語句來創(chuàng)建，只有在被激活的時候，它才會收集事件信息。
?可以使用 SET EVENT MONITOR STATE 語句激活或禁用事件監(jiān)視器。EVENT_MON_STATE 函數(shù)可以返回指定的事件監(jiān)視器的狀態(tài)。
?當(dāng)執(zhí)行 CREATE EVENT MONITOR 語句時，將創(chuàng)建事件監(jiān)視器的定義，并將其存儲在系統(tǒng)編目表中。
?SYSCAT.EVENTMONITORS：為數(shù)據(jù)庫定義的事件監(jiān)視器。
?SYSCAT.EVENTS：為數(shù)據(jù)庫監(jiān)視的事件類型。
?SYSCAT.EVENTTABLES：針對表事件監(jiān)視器的目標(biāo)表的名稱。

3.3 操作系統(tǒng)工具
?單憑數(shù)據(jù)庫工具/快照一般不能提供對系統(tǒng)性能的全面描述。
?例如，或許我們可以將一個數(shù)據(jù)庫調(diào)整到 100% 的最佳狀態(tài)，但是如果在服務(wù)器上出現(xiàn)了 I/O 競爭，那么該數(shù)據(jù)庫就不能很好地執(zhí)行。
?因此，一定要查看整體情況，確保整個 系統(tǒng)運(yùn)行良好。
四. 每日規(guī)程?
4.1 驗證所有實(shí)例是否已打開并且正在運(yùn)行
?這可以通過多種方法來完成：
??1.使用 Health Center。
??2.導(dǎo)出/設(shè)置 DB2INSTANCE=instancename? 并運(yùn)行 db2start。
??3.附加到所有實(shí)例。
??4.在 UNIX 或 Linux 中，運(yùn)行 ps -ef | grep db2sysc? 驗證對于每個實(shí)例都有一個 db2sysc 進(jìn)程。
??5.在 Windows 中，檢查針對每個 DB2 實(shí)例的服務(wù)是否已開啟。
??只要對工作站上的所有實(shí)例（即節(jié)點(diǎn)）進(jìn)行了編目，就可以很容易地將這種附加方法編寫成腳本。
??為了在 UNIX 和 Linux 中使用 ps 命令，首先需要遠(yuǎn)程登錄（telnet）到每臺服務(wù)器。

4.2 驗證所有數(shù)據(jù)庫是否為活動的和/或一致的
?關(guān)于一致（consistent）的定義容易混淆，而且 GET DB CFG 命令的報告方式也常常會引起問題。
?按照定義，對于一個數(shù)據(jù)庫，如果所有提交的事務(wù)都已經(jīng)寫到了磁盤上，并且任何未提交的事務(wù)都不在磁盤上，那么該數(shù)據(jù)庫就是一致的。當(dāng)一個數(shù)據(jù)庫正在運(yùn)行的時候，如果有應(yīng)用程序連接到它，那么就會有一些對頁作了更改的事務(wù)，也許這些事務(wù)已經(jīng)被提交，但是被更改的頁還沒有刷新到磁盤上。在這種情況下，GET DB CFG 將報告數(shù)據(jù)庫是不一致的，但實(shí)際上該數(shù)據(jù)庫完全沒問題。因此，僅僅獲得關(guān)于所有數(shù)據(jù)庫的數(shù)據(jù)庫配置信息是不夠的。
?一個好方法是成功地連接到所有數(shù)據(jù)庫，說它好是因為它還將使不一致的數(shù)據(jù)庫變得一致，從而減少將來請求連接的時間。只要對工作站上的所有數(shù)據(jù)庫進(jìn)行了編目，就可以很容易地將這種方法編寫成腳本。

4.3 查找任何新的 Notification Log 和/或 DB2DIAG.LOG 條目
?一定要確保夜里沒有發(fā)生問題。在 Version 7 中，所有錯誤和消息都被寫到 DB2DIAG.LOG 中。由于這個原因，日志文件中的很多消息對于大多數(shù) DBA 來說是沒有用的。而在 Version 8 中，消息被分離到兩個日志中。notification log （instance_ID.nfy）包含用于 DBA 的消息。而 DB2DIAG.LOG 文件則在需要報告關(guān)于 DB2 的問題時，可以為 DB2 服務(wù)小組（DB2 service team）所用。
?在 Windows 中，Notification log 被寫入到 Application Event Log 中，并且可以通過 Event Viewer 來查看，方法是選擇 Application log 并查找由名為 DB2 的應(yīng)用程序所寫的事件。
?在 Linux 和 UNIX 上，日志被寫入到一個名為 <instance_ID>.nfy 的文件中，這個文件位于由 DIAGPATH 實(shí)例級配置參數(shù)指定的目錄中。為了查看 notification log，可以：
?使用 telnet 或遠(yuǎn)程終端服務(wù)連接到每個服務(wù)器。
?對于每個實(shí)例，進(jìn)入到 DIAGPATH 目錄。
?在命令提示符下：
?對 notification log 運(yùn)行 tail 命令，列出最后 100 個條目。
?編輯該文件，并查看位于文件底部的最近的一些條目。?

4.4 檢查前一夜的備份是否成功
?最壞的情況莫過于在系統(tǒng)存在問題并決定利用最近的備份進(jìn)行恢復(fù)時，卻發(fā)現(xiàn)沒有作備份或者備份不完整。因此，檢查前一夜的備份是否成功，以及這些備份是否存儲在安全的地方，就顯得非常重要了。
?第一步是確保備份成功。這可以通過 List History 命令來完成，如下所示：
?list history backup all for <db_name>
?我們可以將其編寫成腳本，以便在備份完成之后運(yùn)行該腳本，并通過電子郵件發(fā)送報告。然后就可以在每天早晨驗證報告了。
?如果在一段持續(xù)的時間內(nèi)整個服務(wù)器崩潰，那么就可能需要借助災(zāi)難恢復(fù)計劃，將數(shù)據(jù)庫還原到另一臺服務(wù)器，這臺服務(wù)器也許在另一個不同的位置。因此，一定要將備份映像（backup image）存儲在一個安全的站點(diǎn)，而不是僅僅存放在采取備份的那臺服務(wù)器上。通過將備份映像復(fù)制到一個 LAN 驅(qū)動器、一個 NFS 已安裝的驅(qū)動器（mounted drive）或者一個磁帶設(shè)備，可以很容易地實(shí)現(xiàn)這一點(diǎn)。

4.5 驗證數(shù)據(jù)庫日志是否被成功歸檔
?如果數(shù)據(jù)庫是只讀的，或者很容易從頭開始重建，那么您很可能不會啟用日志保留功能，所以可以略過這一步驟。然而，對于那些事務(wù)處理數(shù)據(jù)庫來說，由于丟失任何提交的事務(wù)都是承受不起的，因此確保日志保留功能處于啟用狀態(tài)，并且日志可以成功地歸檔，這就顯得非常重要了，因為這樣一來就可以在出現(xiàn)災(zāi)難的時候重建數(shù)據(jù)庫，并讓事務(wù)重演。
?雖然災(zāi)難恢復(fù)是驗證日志是否被成功歸檔的首要原因，但是還存在另外一個重要原因。如果日志沒有歸檔的話，它們就會留在 LOGPATH 中。由于 LOGPATH 通常是在一個大小固定的文件系統(tǒng)中，如果日志文件沒有歸檔，那么隨著新日志的創(chuàng)建，文件系統(tǒng)就會慢慢地被填滿。當(dāng)出現(xiàn)這種情況時，DB2 將無法再創(chuàng)建日志文件，從而會停下來。
?當(dāng)調(diào)用 userexit 歸檔一個日志文件時，它將把信息寫到兩個地方。第一個地方是 userexit audit log，對于 userexit 收到的每個歸檔日志請求，都要寫一個條目到這里。如果在 userexit 執(zhí)行過程中發(fā)生了錯誤，那么還要將一條消息寫入到 userexit error log 文件中。這些日志文件位于 LOGPATH 中，文件名分別為 ARCHIVE.LOG 和 USEREXIT.ERR。
?為了檢查這些日志，您可以很容易地編寫一個腳本，為所有實(shí)例從這兩個文件中捕捉最后 50 到 100 行（使用 tail 命令），并通過電子郵件發(fā)送給您自己。然后就可以在每天早晨將這些行與恢復(fù)歷史信息放在一起研究。

4.6 學(xué)習(xí) DB2
?從長遠(yuǎn)來看，最有價值的還是經(jīng)驗豐富、閱讀廣泛的 DBA。可供 DBA 學(xué)習(xí)的內(nèi)容應(yīng)該包括 DBA 手冊、雜志、新聞組和郵件列表。
?對于 DBA 同仁來講，comp.databases.ibm-db2 新聞組是學(xué)習(xí)知識、共享信息的好地方。
?在這個站點(diǎn)上還提供了大量的信息。
?要了解更詳細(xì)的信息，您應(yīng)該查找我們的 DB2 Certification Guide 系列，因為這些書籍包含的信息非常豐富。

五. 每周規(guī)程
5.1尋找新對象
?重要的是，要知道人們是否在您的生產(chǎn)數(shù)據(jù)庫中創(chuàng)建新表、新索引、新存儲過程，等等。新對象通常表明服務(wù)器上安裝了新的應(yīng)用程序，任何新的應(yīng)用程序和/或?qū)ο蠖紝⒂绊懴到y(tǒng)的操作特征（operational characteristics）。
?此外，新的對象將消耗數(shù)據(jù)庫里的空間，因此重要的是在這些對象變得太大并可能填滿一個表空間之前，將它們識別出來。如果這些對象不是由 DBA 創(chuàng)建的，那么很可能就是在錯誤的表空間中創(chuàng)建的，這樣就會導(dǎo)致空間和/或性能問題。
?這里有一些方法可用于檢查系統(tǒng)中的任何新對象：
?1.每周運(yùn)行 db2look 并寫報告到一個文件中。
?檢查新輸出與上周輸出之間的不同。
?2.從 SYSCAT.TABLES、SYSCAT.INDEXES 和 SYSCAT.PROCEDURES 中選擇對象名稱。
?檢查新輸出與上周輸出之間的不同。
?對于任何不同之處，您可以從編目表中判定該對象的 CREATOR，并利用該信息追溯到創(chuàng)建該對象的人。

5.2 查找新的或更改過的應(yīng)用程序
?如果根據(jù)當(dāng)前工作負(fù)載對數(shù)據(jù)庫作了優(yōu)化，那么最令人沮喪的就是收到一個呼叫，說數(shù)據(jù)庫沒有運(yùn)行良好，并且發(fā)現(xiàn)這么差的性能是由于新應(yīng)用程序或者對已有應(yīng)用程序的更改引起的，而關(guān)于這一點(diǎn)沒有人告訴您什么。不幸的是，這種現(xiàn)象隨處可見。對于新的和/或更改過的應(yīng)用程序，通過監(jiān)控數(shù)據(jù)庫，就很有希望在這些更改導(dǎo)致性能問題之前就檢測到它們。
?為了查找新的應(yīng)用程序，可以使用 list applications show detail命令。如果將該命令的輸出重定向到一個文件，并將這些文件保留一段時間，就可以在每個星期比較一下這些文件，看看輸出中是否突然出現(xiàn)了新的應(yīng)用程序名。
?為了查找更改過的應(yīng)用程序，可以查看當(dāng)前正在系統(tǒng)運(yùn)行的 SQL，并查找之前沒有運(yùn)行過的新的 SQL。要做這些事情，可以像下面這樣創(chuàng)建一個表：
?create table SQLstmts ( stmt varchar(200), tstamp timestamp not null with default)
?接著從當(dāng)前的包緩存中獲取 SQL 語句，并使用下面的語句將這些 SQL 語句插入到一個表中以用于分析：
?insert into SQlstmts (stmt)
?selectsubstr(stmt_text,1,200) as SQL_Stmt
?from table (snapshot_dyn_sql ('sample', -1) ) as snapshot_dyn_sql
?然后使用以下語句檢查這個表，看有沒有之前未執(zhí)行過的 SQL 語句：
?select distinct stmt, count(stmt),tstamp from sqlstmts group by stmt, tstamp
?在該語句的輸出中，任何計數(shù)為 1 并且 timestamp 列顯示的是當(dāng)前日期的語句，都是之前未運(yùn)行過的語句。

5.3 查找需要 REORG 的表和索引
?當(dāng)插入、更新和刪除表中的行時，都要對表中的數(shù)據(jù)進(jìn)行 REORG（重組），以便：
?1.按照最重要索引的順序重新群集（re-cluster）數(shù)據(jù)。
?2.去掉散布在整個表中的自由空間。
?3.去掉溢出的記錄。
?reorgchk工具將對表進(jìn)行檢查，并表明需要對哪些表進(jìn)行 reorg。可以對單個的表、所有用戶表、某個特定模式中的所有表或者所有系統(tǒng)編目表運(yùn)行 reorgchk工具。還可以指示該工具是應(yīng)該使用當(dāng)前統(tǒng)計信息作為基礎(chǔ)，還是應(yīng)該首先收集新的統(tǒng)計信息。
?為了對所有表運(yùn)行 reorgchk工具，并確保您正在使用當(dāng)前統(tǒng)計信息，可使用命令：
?reorgchk update statistics on table user
?這里應(yīng)將該命令的輸出重定向到一個文件中，以供進(jìn)一步的分析。
?當(dāng)查看 reorgchk工具的輸出時，找到用于表的 F1、F2 和 F3 這幾列，以及用于索引的 F4、F5、F6、F7 和 F8 這幾列。如果這些列中的任何一列有星號 (*)，則說明當(dāng)前的表和/或索引超出了閾值。
?記住，對于一個表，如果任何列中有一個星號，那么通常就需要 reorg該表。然而，由于很多表都擁有不止一個索引，按照定義，如果某個索引是 100% 群集的，那么其他索引就不是群集的。因此，在判斷是否 reorg 索引時，需要調(diào)查 reorgchk輸出的索引部分，并考慮表上的所有索引。
?對 reorgchk所使用的度量的考慮因素包括：
?F1: 屬于溢出記錄的行所占的百分比。當(dāng)這個百分比大于 5% 時，在輸出的 F1 列中將有一個星號 (*)。
?F2: 數(shù)據(jù)頁中使用了的空間所占的百分比。當(dāng)這個百分比小于 70% 時，在輸出的 F2 列上將有一個星號 (*)。
?F3: 其中含有包含某些記錄的數(shù)據(jù)的頁所占的百分比。當(dāng)這個百分比小于 80% 時，在輸出的 F3 列上將有一個星號 (*)。
?F4: 群集率，即表中與索引具有相同順序的行所占的百分比。當(dāng)這個百分比小于 80% 時，那么在輸出的 F4 列上將有一個星號 (*)。
?F5: 在每個索引頁上用于索引鍵的空間所占的百分比。當(dāng)這個百分比小于 50% 時，在輸出的 F5 列上將有一個星號 (*)。
?F6: 可以存儲在每個索引級的鍵的數(shù)目。當(dāng)這個數(shù)字小于 100 時，在輸出的 F6 列上將有一個星號 (*)。
?F7:在一個頁中被標(biāo)記為 deleted 的記錄 ID（鍵）所占的百分比。當(dāng)這個百分比大于 20% 時，在輸出的 F7 列上將有一個星號 (*)。
?F8: 索引中空葉子頁所占的百分比。當(dāng)這個百分比大于 20% 時，在輸出的 F8 列上將有一個星號 (*)。
?在重組一個表的時候，可以選擇指定 DB2 應(yīng)該按哪個索引群集數(shù)據(jù)。為了基于 ORGX 索引 reorgORG 表，可以使用命令
?reorg table org index orgx

5.4 查找需要 RUNSTATS 的表和索引
?DB2 優(yōu)化器使用數(shù)據(jù)庫統(tǒng)計信息來決定 SQL 語句的最佳訪問計劃。如果對表中的數(shù)據(jù)總量或者數(shù)據(jù)本身作了重大更改，則應(yīng)使用 runstats工具捕捉新的統(tǒng)計信息，并將這些信息存儲在系統(tǒng)編目中。還應(yīng)確保對于任何新的表或索引都捕捉到了統(tǒng)計信息。
?為了捕捉上述 ORG 表及其索引的統(tǒng)計信息，使用命令
?runstats on table <schema>.org with distribution and detailed indexes all
?注意：在使用 runstats 命令的時候，必須指定表所在的模式。
?可以使用如下語句來檢查任何沒有統(tǒng)計信息的表：
?select tabname from syscat.tables where stats_time is null
?可以使用如下語句來檢查任何沒有統(tǒng)計信息的索引：
?select indname from syscat.indexes where stats_time is null
?可以使用如下語句來查找具有時間超過 30 天的統(tǒng)計信息的表和索引：
?select tabname from syscat.tables
?where stats_time < current timestamp - 30 days
?select indname from syscat.indexes
?where stats_time < current timestamp - 30 days

5.5 歸檔所有 Alert Logs 和 DB2DIAG.LOG 文件
?定時地清除診斷日志是一個很好的習(xí)慣。這樣一來，當(dāng)發(fā)生錯誤時，就不必回顧日志中過去 6 個月的信息，這時日志要小得多，同時也容易編輯得多。在清除文件之前，應(yīng)先做一個備份，以防在將來某個時候想要回頭調(diào)查系統(tǒng)在某個時間點(diǎn)上曾發(fā)生過什么。
?在 Windows 上，可以在 Event Viewer 中將事件日志保存到另一個文件，方法是選擇 Action 菜單，再選擇 Save Log File As& 選項。然后，就可以通過選擇 Action 菜單，再選擇 Clear All Events 選項將條目從日志中清除。
?注意：用當(dāng)前日期命名該文件是一個好的習(xí)慣，這樣使得在以后某天回頭查看文件時更方便。
?對于 Linux 和 UNIX 上的 DB2DIAG.LOG 文件以及 administration notification log 文件，應(yīng)該進(jìn)行壓縮，然后在命名時也使用當(dāng)前日期。
?在 Linux 或 UNIX 上，可以將 *.nfy 和 db2diag.log 文件歸檔到一起，然后使用 gzip或 compress減少最終文件的大小。

5.6 對軟件更新的檢查
?知道當(dāng)前運(yùn)行的軟件是否有更新總是有益的。如果系統(tǒng)運(yùn)行順利，您可能不想應(yīng)用任何服務(wù)到服務(wù)器上。通過閱讀 fixpak / service 包中所含的關(guān)于修復(fù)（fix）的信息，在面臨是否應(yīng)用修復(fù)包（fixpack）時就能作出有根據(jù)的決定。如果碰到了問題，則可以查看修復(fù)描述，以判斷其中是否存在可以解決當(dāng)前問題的修復(fù)。
?從 DB2 的角度來看，最重要的 Web 站點(diǎn)是 DB2 for Linux, UNIX, and Windows Technical Support Page：
? http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/download.d2w/WINV8FP
?為了確保自己清楚何時有新的 fixpak 提供，一種方法是訂閱以下站點(diǎn)的 DB2 Alerts：
? http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report

六. 每月規(guī)程
6.1 查找異常增長的指示器
?檢查表和表空間，看看上個月它們的增長情況。如果知道了表和表空間的增長速度，以及還剩下多少可用空間，就可以事先檢測潛在的空間問題。
?通過使用以下語句，可以獲得表空間的大小和可用空間的大小。
?select substr(tablespace_name,1,120) as TBSPC_NAME,
?used_pages, free_pages,
?from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg
?通過查看系統(tǒng)編目表，可以知道每個表的大小。只要統(tǒng)計信息是時新的，上述信息就可以準(zhǔn)確無誤。為了獲得表的大小，可以使用語句
?select tabname, npages from syscat.tables where tabname not like 'SYS%'
?注意：如果沒有捕捉到某個表的統(tǒng)計信息，則 npages 上的值就是 -1。
?創(chuàng)建一個歷史表來存儲該信息，這樣就可以詳細(xì)調(diào)查表和表空間對空間的使用情況。

6.2基于有計劃的增長規(guī)劃未來的性能
?比較一直以來收集到的關(guān)于系統(tǒng)級 CPU、內(nèi)存、網(wǎng)絡(luò)和磁盤利用率的信息，以及收集到的 DB2 對象信息，以便識別出可能導(dǎo)致將來這些資源存在爭用或短缺現(xiàn)象的趨勢。
?根據(jù)對上述信息的分析，就可以在這些狀況發(fā)生之前制訂針對性的計劃，并采取行動組織這些狀況的發(fā)生。
?下面的附錄包含了一些有用的腳本，這些腳本可用于監(jiān)控系統(tǒng)和數(shù)據(jù)庫。注意，這些腳本寫在用 CLP 運(yùn)行的文件中，因此含有注釋。注釋的前面有雙破折號（ --），如果直接在命令行中運(yùn)行這些命令的話，需要將注釋去掉。

附錄 1：表空間信息腳本
-- 創(chuàng)建一個名為 tablespaceinfo 的表來存儲從表空間的快照信息以用于分析。
create table TablespaceInfo(
timestmp timestamp,
tablespace_name char(128),
pct_free int,
-- Percent of space free in the table space
type char(5),
-- SMS or DMS
contents char(5),
total_pages int,
-- total # of pages
usable_pages int,
-- useable pages, total - tag, etc..
used_pages int,
-- # of pages used
free_pages int,
-- # of free pages
page_size int);
-- page size

-- 向 tablespaceinfo 表中插入快照信息以用于分析。
insert into tablespaceinfo
select
current timestamp,
substr(tablespace_name,1,120) as TBSPC_NAME,
(case
-- We can calculate pct free for DMS table spaces only as total_pages is
set to 0 for SMS by this stmt...
-- Therefore, check if DMS, and then calculate pct_free as 1-
(used/total) * 100%
when tablespace_type = 0 then (int( (1- (decimal(used_pages) /
decimal(total_pages))) * 100) )
-- For SMS set pct_free to 100... Could set to any numeric value.
else 100
end) as pct_free,
(case
-- Display the table space type, i.e. DMS or SMS as a string, not the numeric
value in the info.
when tablespace_type = 0 then 'DMS'
when tablespace_type = 1 then 'SMS'
-- Only 0 and 1 are VALID, therefore return an error for anything else.
else 'Error'
end) as Managed_By,
(case
-- Display the type of data that can stored in the table space, i.e. TEMP,
LARGE/LOB OR ALL,
not the numeric value in the info.
when tbs_contents_type = 2 then 'TEMP'
when tbs_contents_type = 1 then 'LARGE'
when tbs_contents_type = 0 then 'ALL' end) as Data_Type,
-- Also return the total_pages using the heading ALLOCATED PAGES,
total_pages as allocated_pages,
usable_pages,
used_pages,
free_pages,
page_size
from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg
order by pct_free;
select tablespace_name,
date(timestmp) as dte,
pct_free
from tablespaceinfo
group by tablespace_name, pct_free, timestmp ;

附錄 2：表空間容器信息腳本
-- 輸出用于支撐每個表空間容器的名稱、大小和類型。
-- 設(shè)定數(shù)據(jù)庫名稱參數(shù)為空表明是從當(dāng)前連接的數(shù)據(jù)庫獲取信息。
select
substr(tablespace_name,1,12) as TBSPC_Name,
substr(Container_name,1,67) as Cont_Name,
(case
when container_type = 0 then 'SMS Directory'
when container_type = 6 then 'DMS File'
else 'DMS Device'
end) as Container_Type,
usable_pages
from table (snapshot_container (' ', -1) ) as snapshot_container;

附錄 3：緩沖池 - 表空間信息
-- 輸出緩沖池的名稱和大小以及每個相關(guān)表空間的名稱和大小。這有助于更好地規(guī)劃表空間的大小。例子中首先按 bpname 分組來獲取與每個緩沖池相關(guān)的所有表空間。
select substr(b.bpname,1,12) as BufferPool,
b.npages as BP_Pages,
substr(t.tbspace,1,12) as TableSpace,
usable_pages as TBSPC_Pages
from table (snapshot_tbs_cfg ('sample', -1) ) as snapshot_tbs_cfg ,
syscat.tablespaces t, syscat.bufferpools b
where t.bufferpoolid = b.bufferpoolid
and t.tbspace = tablespace_name
group by b.bpname, t.tbspace, usable_pages, npages;

附錄 4：檢索最重要的數(shù)據(jù)庫快照信息
-- 輸出從數(shù)據(jù)庫快照中得出的最重要的性能相關(guān)信息。
-- 設(shè)定數(shù)據(jù)庫名稱參數(shù)為空表明是從當(dāng)前連接的數(shù)據(jù)庫獲取信息。
select
db_name,
rows_read,
rows_selected,
-- The ratio of rows read to rows selected should be as close to 1-1 as possible.
lock_waits,
lock_wait_time,
deadlocks,
lock_escals,
total_sorts,
total_sort_time from table (snapshot_database (' ', -1) ) as snapshot_database;

DB2 UDB DBA 核對清單