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

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

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

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

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

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

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

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

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

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

5.4 查找需要 RUNSTATS 的表和索引
?DB2 優化器使用數據庫統計信息來決定 SQL 語句的最佳訪問計劃。如果對表中的數據總量或者數據本身作了重大更改，則應使用 runstats工具捕捉新的統計信息，并將這些信息存儲在系統編目中。還應確保對于任何新的表或索引都捕捉到了統計信息。
?為了捕捉上述 ORG 表及其索引的統計信息，使用命令
?runstats on table <schema>.org with distribution and detailed indexes all
?注意：在使用 runstats 命令的時候，必須指定表所在的模式。
?可以使用如下語句來檢查任何沒有統計信息的表：
?select tabname from syscat.tables where stats_time is null
?可以使用如下語句來檢查任何沒有統計信息的索引：
?select indname from syscat.indexes where stats_time is null
?可以使用如下語句來查找具有時間超過 30 天的統計信息的表和索引：
?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 文件
?定時地清除診斷日志是一個很好的習慣。這樣一來，當發生錯誤時，就不必回顧日志中過去 6 個月的信息，這時日志要小得多，同時也容易編輯得多。在清除文件之前，應先做一個備份，以防在將來某個時候想要回頭調查系統在某個時間點上曾發生過什么。
?在 Windows 上，可以在 Event Viewer 中將事件日志保存到另一個文件，方法是選擇 Action 菜單，再選擇 Save Log File As& 選項。然后，就可以通過選擇 Action 菜單，再選擇 Clear All Events 選項將條目從日志中清除。
?注意：用當前日期命名該文件是一個好的習慣，這樣使得在以后某天回頭查看文件時更方便。
?對于 Linux 和 UNIX 上的 DB2DIAG.LOG 文件以及 administration notification log 文件，應該進行壓縮，然后在命名時也使用當前日期。
?在 Linux 或 UNIX 上，可以將 *.nfy 和 db2diag.log 文件歸檔到一起，然后使用 gzip或 compress減少最終文件的大小。

5.6 對軟件更新的檢查
?知道當前運行的軟件是否有更新總是有益的。如果系統運行順利，您可能不想應用任何服務到服務器上。通過閱讀 fixpak / service 包中所含的關于修復（fix）的信息，在面臨是否應用修復包（fixpack）時就能作出有根據的決定。如果碰到了問題，則可以查看修復描述，以判斷其中是否存在可以解決當前問題的修復。
?從 DB2 的角度來看，最重要的 Web 站點是 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 提供，一種方法是訂閱以下站點的 DB2 Alerts：
? http://www-3.ibm.com/cgi-bin/db2www/data/db2/udb/winos2unix/support/db2alert.d2w/report

六. 每月規程
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
?通過查看系統編目表，可以知道每個表的大小。只要統計信息是時新的，上述信息就可以準確無誤。為了獲得表的大小，可以使用語句
?select tabname, npages from syscat.tables where tabname not like 'SYS%'
?注意：如果沒有捕捉到某個表的統計信息，則 npages 上的值就是 -1。
?創建一個歷史表來存儲該信息，這樣就可以詳細調查表和表空間對空間的使用情況。

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

附錄 1：表空間信息腳本
-- 創建一個名為 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：表空間容器信息腳本
-- 輸出用于支撐每個表空間容器的名稱、大小和類型。
-- 設定數據庫名稱參數為空表明是從當前連接的數據庫獲取信息。
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：緩沖池 - 表空間信息
-- 輸出緩沖池的名稱和大小以及每個相關表空間的名稱和大小。這有助于更好地規劃表空間的大小。例子中首先按 bpname 分組來獲取與每個緩沖池相關的所有表空間。
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：檢索最重要的數據庫快照信息
-- 輸出從數據庫快照中得出的最重要的性能相關信息。
-- 設定數據庫名稱參數為空表明是從當前連接的數據庫獲取信息。
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 核對清單