db2資料庫監控

『壹』 什麼是資料庫資料庫中的數據有什麼特點

資料庫系統DBS（Data Base System，簡稱DBS）通常由軟體、資料庫和數據管理員組成。其軟體主要包括操作系統、各種宿主語言、實用程序以及資料庫管理系統。資料庫由資料庫管理系統統一管理，數據的插入、修改和檢索均要通過資料庫管理系統進行。數據管理員負責創建、監控和維護整個資料庫，使數據能被任何有權使用的人有效使用。資料庫管理員一般是由業務水平較高、資歷較深的人員擔任。

資料庫系統
資料庫系統的個體含義是指一個具體的資料庫管理系統軟體和用它建立起來的資料庫；它的學科含義是指研究、開發、建立、維護和應用資料庫系統所涉及的理論、方法、技術所構成的學科。在這一含義下，資料庫系統是軟體研究領域的一個重要分支，常稱為資料庫領域。
資料庫系統是為適應數據處理的需要而發展起來的一種較為理想的數據處理的核心機構。計算機的高速處理能力和大容量存儲器提供了實現數據管理自動化的條件。
資料庫研究跨越於計算機應用、系統軟體和理論三個領域，其中應用促進新系統的研製開發，新系統帶來新的理論研究，而理論研究又對前兩個領域起著指導作用。資料庫系統的出現是計算機應用的一個里程牌，它使得計算機應用從以科學計算為主轉向以數據處理為主，並從而使計算機得以在各行各業乃至家庭普遍使用。在它之前的文件系統雖然也能處理持久數據，但是文件系統不提供對任意部分數據的快速訪問，而這對數據量不斷增大的應用來說是至關重要的。為了實現對任意部分數據的快速訪問，就要研究許多優化技術。這些優化技術往往很復雜，是普通用戶難以實現的，所以就由系統軟體（資料庫管理系統）來完成，而提供給用戶的是簡單易用的資料庫語言。由於對資料庫的操作都由資料庫管理系統完成，所以資料庫就可以獨立於具體的應用程序而存在，從而資料庫又可以為多個用戶所共享。因此，數據的獨立性和共享性是資料庫系統的重要特徵。數據共享節省了大量人力物力，為資料庫系統的廣泛應用奠定了基礎。資料庫系統的出現使得普通用戶能夠方便地將日常數據存入計算機並在需要的時候快速訪問它們，從而使計算機走出科研機構進入各行各業、進入家庭。
資料庫系統有大小之分，大型資料庫系統有sql Server、Oracle、DB2等，中小型資料庫系統有Foxpro、Access。

『貳』 什麼是資料庫管理系統它的主要功能是什麼

資料庫管理系統是一種操縱和管理資料庫的大型軟體。是一個能夠提供數據錄入、修改、查詢的數據操作軟體。它對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。主要功能是：

1、數據定義：提供數據定義語言DDL，供用戶定義資料庫的三級模式結構、兩級映像以及完整性約束和保密限制等約束。DDL所描述的庫結構僅僅給出了資料庫的框架，資料庫的框架信息被存放在數據字典中。

2、數據操作：提供數據操作語言DML，供用戶實現對數據的追加、刪除、更新、查詢等操作。

3、資料庫的運行管理：資料庫的運行管理功能是DBMS的運行控制、管理功能，包括多用戶環境下的並發控制、安全性檢查和存取限制控制、完整性檢查和執行、運行日誌的組織管理、事務的管理和自動恢復，即保證事務的原子性。

4、數據組織、存儲與管理：DBMS要分類組織、存儲和管理各種數據，包括數據字典、用戶數據、存取路徑等，需確定以何種文件結構和存取方式在存儲級上組織這些數據，如何實現數據之間的聯系。

5、資料庫的保護：保護通過4個方面來實現：資料庫的恢復、資料庫的並發控制、資料庫的完整性控制、資料庫安全性控制。DBMS的其他保護功能還有系統緩沖區的管理以及數據存儲的某些自適應調節機制等。

6、資料庫的維護：這一部分包括資料庫的數據載入、轉換、轉儲、資料庫的重組合重構以及性能監控等功能，這些功能分別由各個使用程序來完成。

7、通信：具有與操作系統的聯機處理、分時系統及遠程作業輸入的相關介面，負責處理數據的傳送。

(2)db2資料庫監控擴展閱讀：

資料庫管理系統的優點

1、控制數據冗餘。資料庫管理應盡可能地消除了冗餘，但是並沒有完全消除，而是控制大量資料庫固有的冗餘。

2、保證數據一致性。通過消除或控制冗餘，可降低不一致性產生的危險。如果數據項在資料庫中只存儲了一次，則任何對該值的更新均只需進行一次，而且新的值立即就被所有用戶獲得。

3、提高數據共享。資料庫應該被有許可權的用戶共享。DBMS的引入使更多的用戶可以更方便的共享更多的數據。新的應用程序可以依賴於資料庫中已經存在的數據，並且只增加目前沒有存儲的數據，而不用重新定義所有的數據需求。

『叄』 怎麼監控DB2執行了了哪些SQL

在DB2資料庫建立了一個statement的event monitor，monitor的時候可以指定IP地址，這樣就能監控軟體執行過程中用到語句。

『肆』 請教關於db2pd 監控事務日誌的問題

具體空間大小時如何計算出來的，我覺得不是IBM內部人員，又不是要去Debug DB2的源程序，未必需要深究。

我了解的是DB2 UDB V8.2，現在沒什麼機會使用DB2了，也不好隨便說。只能大致說下以前了解到的一些內容供你參考。

假設在某一個時刻，其他事務都已經提交，從這個時刻起有一個DB2的進程A開始一個事務T1，DB2實例就會記住這個進程的APPL HANDL，就是進程的句柄，上面db2bp都有顯示的，只要進程A一直沒有將它的事務提交，資料庫實例服務就會一直保持著進程A的句柄，這個值在抓取DB快照有專門的一個指標：APP ID HOLDING THE OLDEST TRANSACTION。只要事務T1一直沒有提交，就會導致隨後其他進程所開始的事務都會佔用住實例的活動日誌文件，即使日誌文件的空間被全部占滿了，也不能正常的日誌文件歸檔到DB參數指定的歸檔日誌路徑。當DB參數配置的所有活動日誌空間，即：（LOGPRIMARY +LOGSECOND ）* LOGFILSIZ 都全部被占滿，資料庫就會報出：SQL0964C The transaction log for the database is full，這樣的一個錯誤提示。之後整個資料庫的所有數據變更操作都會無法繼續進行，理論上查詢的語句不會受到影響，可以正常返回結果。

如果遇到這樣的問題，最好的解決方法，不是直接中斷所有的進程，只要
db2 get snapshot for db on DBNAME
找出APP ID HOLDING THE OLDEST TRANSACTION對應的那個進程的句柄
之後再用
db2 force application agentdi APPLID
這樣最多隻是中斷一個進程，將一直沒有提交的事務回滾，所有活動日誌文件都能順利歸檔，並成功釋放。

擴展的說，對於一個繁忙的OLTP資料庫日常監控，可以用SNAPSHOT_DATABASE這個監控表函數，監控APPL_ID_OLDEST_XACT是否在很長的一段時間（例如兩個小時）都是同一個ID，而且TOTAL_LOG_USED在不斷增大，TOTAL_LOG_AVAILABLE在持續的減少，這樣就可能是應用程序出現問題長時間未能提交事務，或者程序有BUG，沒有正確提交結束事務了。

『伍』 請教zabbix如何監控DB2

用 春 眯 圓 王 寫

『陸』 什麼是資料庫管理系統它具有哪些功能

資料庫管理系統(database
management
system)是一種操縱和管理資料庫的大型軟體，是用於建立、使用和維護資料庫，簡稱dbms。它對資料庫進行統一的管理和控制，以保證資料庫的安全性和完整性。用戶通過dbms訪問資料庫中的數據，資料庫管理員也通過dbms進行資料庫的維護工作。它提供多種功能，可使多個應用程序和用戶用不同的方法在同時或不同時刻去建立，修改和詢問資料庫。它使用戶能方便地定義和操縱數據，維護數據的安全性和完整性，以及進行多用戶下的並發控制和恢復資料庫。
按功能劃分，資料庫管理系統大致可分為6個部分：
(1)模式翻譯：提供數據定義語言(ddl)。用它書寫的資料庫模式被翻譯為內部表示。資料庫的邏輯結構、完整性約束和物理儲存結構保存在內部的數據字典中。資料庫的各種數據操作(如查找、修改、插入和刪除等)和資料庫的維護管理都是以資料庫模式為依據的。
(2)應用程序的編譯：把包含著訪問資料庫語句的應用程序，編譯成在dbms支持下可運行的目標程序。
(3)互動式查詢：提供易使用的互動式查詢語言，如sql。dbms負責執行查詢命令，並將查詢結果顯示在屏幕上。
(4)數據的組織與存取：提供數據在外圍儲存設備上的物理組織與存取方法。
⑸事務運行管理：提供事務運行管理及運行日誌，事務運行的安全性監控和數據完整性檢查，事務的並發控制及系統恢復等功能。
(6)資料庫的維護：為資料庫管理員提供軟體支持，包括數據安全控制、完整性保障、資料庫備份、資料庫重組以及性能監控等維護工具。
基於關系模型的資料庫管理系統已日臻完善，並已作為商品化軟體廣泛應用於各行各業。它在各戶伺服器結構的分布式多用戶環境中的應用，使資料庫系統的應用進一步擴展。隨著新型數據模型及數據管理的實現技術的推進，可以預期dbms軟體的性能還將更新和完善，應用領域也將進一步地拓寬。
它所提供的功能有以下幾項：
（1）數據定義功能。dbms提供相應數據語言來定義（ddl）資料庫結構，它們是刻畫資料庫框架，並被保存在數據字典中。
（2）數據存取功能。dbms提供數據操縱語言（dml），實現對資料庫數據的基本存取操作：檢索，插入，修改和刪除。
（3）資料庫運行管理功能。dbms提供數據控制功能，即是數據的安全性、完整性和並發控制等對資料庫運行進行有效地控制和管理，以確保數據正確有效。
（4）資料庫的建立和維護功能。包括資料庫初始數據的裝入，資料庫的轉儲、恢復、重組織，系統性能監視、分析等功能。
（5）資料庫的傳輸。dbms提供處理數據的傳輸，實現用戶程序與dbms之間的通信，通常與操作系統協調完成。
著名資料庫管理系統
ms
sql
sybase
db2
oracle
mysql
access
vf
常見的資料庫管理系統
目前有許多資料庫產品，如oracle、sybase、informix、microsoft
sql
server、microsoft
access、visual
foxpro等產品各以自己特有的功能，在資料庫市場上佔有一席之地。下面簡要介紹幾種常用的資料庫管理系統。

『柒』 如何在 SAP 系統中監控和分析 DB2 UDB 性能

性能問題總是資料庫領域裡面永恆的話題，使用 DB2 作為底層數據平台的 SAP 系統為我們提供了許多方法監控和檢測資料庫性能問題。本文從資料庫性能問題檢測的一般思路和方法論入手，介紹了如何通過 SAP 系統對 DB2 的性能進行監控和分析。回頁首資料庫性能問題檢測的思路及方法論在資料庫運維工作中遇到性能問題時，通常會讓資料庫管理員感到無從下手，不容易斷定問題的根源所在。如果能有一種可操作的一般性的方法作為指導，我們通常就能夠發現大部分資料庫性能問題的根源。那麼，首先根據我們對資料庫性能監控的一些實踐經驗來總結一下在遇到性能問題時應該進行哪些檢查。我們不能保證通過文中介紹的方法就能找到所有性能瓶頸，性能問題的原因很多，解決方法也多種多樣，我們在這里只是提供一些普遍的，一般性的方法，具體的實施還需要根據系統的具體情況和不斷的實踐經驗積累。同時，通過進行這些監控，也有利於為技術支持人員提供更詳細診斷信息，以便於快速定位性能問題。當遇到一個性能問題，我們首先進行以下排查: 性能問題是在何時發生的; 性能問題持續存在的還是間斷性的; 系統范疇的性能問題還是資料庫本身的性能問題; 性能問題是否只存在於某一個應用; 性能問題是隨機出現的還是必然出現的。如果性能問題存在於所有應用，我們可以進行以下排查: 如果發現系統存在大量的 I/O 操作: 檢查設備使用情況; 檢查排序情況和臨時表空間; 檢查查詢性能是否有效的得到優化; 檢查緩沖池的使用狀況。 如果發現 CPU 具有很高的負載: 檢查排序狀況; 檢查緩沖池的使用狀況。 如果發現 CPU 和 I/O 操作的負荷都很大: 檢查用戶數量; 檢查排序狀況。 如果發現 CPU 和 I/O 操作的負荷都很小而資料庫響應仍然很慢: 檢查並發性和鎖的使用狀況; 檢查緩沖池的使用狀況。如果性能問題可以被定位在一個應用，我們可以進行以下排查: 檢查排序情況。 檢查並發性和鎖的使用狀況。 檢查統計信息是否更新。回頁首通過SAP 系統的工具對 DB2 UDB 進行監控通過前一部分的描述，我們了解到了在遇到性能問題以後應該用什麼思路尋找性能的瓶頸，從而想辦法解決性能問題。在對資料庫進行檢查的過程中，我們通常會用到數據管理工具，命令行以及操作系統的工具，還要結合 SAP 的自身特點尋找性能問題的根源，這將是一個比較繁瑣和費事的工作。在使用 SAP 作為底層資料庫的 SAP 系統中，由於 SAP 實現了與 DB2 緊密的結合。SAP 的 DBA Cockpit 提供了許多功能來支持資料庫的管理工作，使得資料庫性能監控和分析變得更加簡單。下面我們就來看看，SAP 為 DB2 性能監控和分析提供了哪些支持。磁碟I/O 性能監控概念對於資料庫來說，最消耗時間的操作實際上是從磁碟中檢索數據。這是由磁碟的物理特性決定的。盡管磁碟存儲技術已經取得了極大的進步，但磁碟的讀寫速度與內存的讀寫速度仍然相差幾個數量級。從性能調整的角度來說，如果一個機器的磁碟出現問題，那麼其他的任何優化工作都無法提供幫助。因此我們應該保證運行資料庫的磁碟系統是健康的。SAP 系統為我們提供了監控磁碟讀寫速度的功能，讓我們可以直接了解當前磁碟的性能狀況。監控我們首先進入 SAP 的 DBA Cockpit ( 可以直接輸入 st04)，然後在 Performance 的目錄下雙擊 Database, Buffer Pool 的標簽內，可以看到當前資料庫磁碟的讀寫狀況。圖1. 磁碟 I/O 信息從圖中我們可以看到磁碟物理平均讀速度為 3.25ms，寫速度為 7.45ms。分析磁碟物理讀寫速度反應了磁碟子系統的性能。一般情況下，磁碟讀寫速度應該小於 5ms，讀速度一般要大於寫速度，但在一些具有大量緩存的存儲系統中，寫速度可能會快於讀速度。磁碟性能的優化已經超出了本文討論的范圍，這里只是提供一些基本的指導。緩沖池監控概念緩沖池是資料庫單獨開辟的一塊存儲區域，這片區域用來緩存從磁碟讀出的包含數據表和索引的數據頁。當數據第一次被檢索出來以後便被暫時緩存在緩沖池中，當數據下次被訪問時，資料庫將直接從緩沖池中讀取數據，這樣減少了相對緩慢的磁碟 I/O 操作。因此，緩沖池的配置對於資料庫性能十分重要。在緩沖池中，目前還不支持存儲大對象和長數據記錄。反映緩沖池質量的一個重要性能指標是緩沖池命中率。緩沖池命中率指資料庫管理器不需從磁碟讀入頁就能處理頁請求的時間百分比。其計算方法為:緩沖池命中率 = (1 - (( 緩沖池數據物理讀 + 緩沖池索引物理讀 ) / ( 緩沖池數據邏輯讀 + 緩沖池索引邏輯讀 ) ) ) * 100%另外兩個重要性能指標是索引命中率和數據命中率。索引命中率反映了可以在緩沖池中找到的頁面能夠滿足的對索引頁的所有讀請求所佔的百分比。其計算方法為:索引命中率 = (1 - ( 緩沖池索引物理讀 / 緩沖池索引邏輯讀 ) ) ) * 100%數據命中率說明了可以在緩沖池中找到的頁面能夠滿足的對數據頁的所有讀請求所佔的百分比。其計算方法為:數據命中率 = (1 - ( 緩沖池數據物理讀 / 緩沖池數據邏輯讀 ) ) ) * 100%監控我們可以從三個級別來看緩沖池的質量，這三個層次分別是資料庫級，緩沖池級，表空間級。在 SAP 系統中我們可以使用 DBA Cockpit 來查看不同級別的緩沖池質量。首先可以在資料庫級查看緩沖池的質量，我們進入 SAP 的 DBA Cockpit，然後在 Performance 的目錄下雙擊 Database, 在 Buffer Pool 的標簽內，可以看到當前資料庫總體的緩沖池質量。圖2. 緩沖池總體狀況我們從圖中可以看出，資料庫緩沖池的總體命中率是 99.81%，數據命中率為 99.86%，索引命中率為 99.70%。如果在 st04 中選中 Performance -> Buffer pools， 我們也可以在緩沖池級別看到命中率，如果一個資料庫只有一個緩沖池，那麼這個命中率與我們在資料庫級別看到的命中率相同。圖3. 資料庫級別緩沖池信息如果在 st04 中選中 Performance -> Tablespaces，我們就可以在表空間級別看到緩沖池的命中率。圖4. 表空間級別緩沖池信息分析緩沖池的理想命中率對於索引應該大於 90%, 對於數據應該大於 95%。要提高緩沖池的命中率，可以增加緩沖池的大小，也可以為不同類型數據分配不同緩沖池，可以為每個經常訪問的具有自己的表空間的大型表使用一個緩沖池，也可以為一組小型表使用一個緩沖池。緩存監控概念資料庫的緩存主要有包緩存 (Package Cache) 和編目錄緩存 (Catalog Cache)。它們與資料庫的查詢性能息息相關。包緩存(Package Cache) :SQL 語句編譯通常消耗的資源比較大，為了提高系統性能，動態 SQL 語句在被編譯後一般存放於包緩存中。當用戶下一次請求同一條 SQL 語句，就無需再次編譯 SQL 語句。包緩存的質量一般通過包緩存命中率來衡量，它表明了包緩存的設置是否成功的避免了 SQL 語句的重新編譯。其計算方法為:包緩存命中率 = (1 - ( 在包緩存中的插入次數 / 查詢包緩存的次數 )) * 100編目錄緩存 (Catalog Cache):編目錄緩存用來緩存系統編目錄信息，如系統表，許可權，系統存儲過程。系統編目錄的訪問速度對於系統的性能有著十分重要的影響。在 DPF 環境下，系統編目錄的訪問速度至關重要。通過使用編目錄緩存可以大大提高訪問系統編目錄的速度。編目錄緩存質量一般通過編目錄命中率來衡量，它表明了編目錄緩存是否成功的避免了從磁碟中讀取編目錄信息。其計算方法為:包緩存命中率 = (1 - ( 在編目錄緩存中的插入次數 / 查詢編目錄緩存的次數 )) * 100監控我們進入 SAP 的 DBA Cockpit，然後在 Performance 的目錄下雙擊 Database, 在 Cache 的標簽內，可以看到當前資料庫緩存的統計信息。圖5. 資料庫緩存信息從圖中我們可以看到編目錄緩存的質量是 99.93%，在圖中的 quality 就是我們前面所說的命中率。當前資料庫編目錄緩存的大小為 10240KB，沒有緩存溢出。在左邊一欄，我們可以看到，包緩存的質量是 97.64%，包緩存的大小為 62080KB，沒有緩存溢出。分析包緩存的理想命中率應該大於 98%，用戶通常不用關注包緩存的大小，如果 PCKCACHESZ 被設置為 automatic，其大小由 DB2 自動調節。編目錄緩存的理想命中率也應該大於 98%，其大小應該保證編目錄緩存不應該發生任何溢出。我們可以調整資料庫配置參數 CATALOGCACHE_SZ 來改變編目錄緩存大小，由於編目錄緩存是從資料庫堆中分配的，因此，在改變 CATALOGCACHE_SZ 變數的同時，應該注意到資料庫堆的大小也會相應改變。排序監控概念DB2 在運行過程中時經常要做排序操作。一般說來，在 OLTP 類型的資料庫中，排序操作通常少於 OLAP 類型的資料庫環境。排序操作通常會在三種情況下發生，第一種情況是數據的查詢處理，比如 order by, group, 哈希連接，索引操作，內存的表操作等等。第二種是當我們載入操作的對象是帶有索引的表時，再載入操作過程中就會涉及到對索引鍵的列表和排序，這樣就會產生排序操作。第三種情況發生在創建索引的時候。排序的效率因而直接影響到資料庫的響應時間，我們必須對排序進行有效監控。監控我們進入 SAP 的 DBA Cockpit，然後在 Performance 的目錄下雙擊 Database, 在 Sorts 的標簽內，可以看到當前資料庫的排序狀況。圖6. 資料庫排序狀況可以從圖中看出，共享排序堆的大小為 1676KB, 私有排序堆的大小為 1340KB。如果沒有索引滿足所取的行的要求順序，或者 DB2 查詢優化器認為排序的代價低於索引掃描，那麼就需要在排序堆中進行排序。DB2 的排序分為私有排序和共享排序。私有排序發生在代理的私有代理內存中，而共享排序發生在資料庫的資料庫共享內存中。我們還可以看出，排序堆溢出次數 1174 次，總的排序次數為 310642 次。分析如果資料庫分配的排序堆大小不夠大，就會出現排序溢出的情況，這樣就需要動用臨時表空間來輔助排序的進行，由於臨時表空間存在於磁碟，這將大大影響排序的速度。理想情況下，排序溢出率 ((Sort overflows * 100) / Total sorts ) 不應該超過 1%。如果這個溢出率過高，那麼資料庫中很可能發生了大的排序，我們就需要調查出現過度排序的原因。在發現根源之前，一個簡易的解決方案是增加 SORTHEAP 的大小。然而，這樣做通常是治標不治本並且掩蓋了真實的性能問題。比較徹底的解決方案應該是確定引起排序的 SQL 並更改該語句，或通過增加索引來避免或減少排序開銷。並發性和鎖的監控概念資料庫的鎖是資料庫管理器用來控制應用程序並發訪問資料庫數據並且保證資料庫數據的一致性的重要機制，資料庫中行和表都可以上鎖。資料庫的鎖在保證了資料庫數據一致性同時也在一定程度上降低了資料庫的響應速度。鎖等待和死鎖是影響資料庫相應速度的重要因素，糟糕的應用程序設計和不合理的 SQL 查詢計劃的生成都會導致鎖等待和死鎖。鎖升級 (Lock Escalation):一個鎖通常作為一個記錄存儲在內存鎖表中，鎖表的大小可以由資料庫自動調節。鎖升級一般發生在鎖的數量超過了資料庫配置參數 MAXLOCKS 所指定的大小，為了減少鎖的數量，資料庫會把若干行一級的鎖合並為表鎖。這樣資料庫的並發性就會受到影響。監控我們進入 SAP 的 DBA Cockpit，然後在 Performance 的目錄下雙擊 Database, 在 Locks and Deadlocks 的標簽內，可以看到當前資料庫的鎖的狀況。圖7. 資料庫鎖狀況從圖中可以看到，當前鎖表的大小為 22144KB，已經使用了 94KB。鎖等待的平均時間為 10.40ms，沒有鎖升級和死鎖被檢測到。分析影響數據性能的有關鎖的問題主要集中在鎖等待，死鎖和鎖升級。這些問題的根源很可能是資料庫應用的設計問題。因此，我們應該仔細調查造成死鎖，鎖等待和鎖升級的應用程序，以及其用到的 SQL 語句。同時，在問題定位之前，我們也可以通過下面方法來解決資料庫鎖造成的性能問題。鎖等待和死鎖:如果要避免鎖等待和死鎖的問題我們需要注意資料庫參數中的 DLCHKTIME 和 LOCKTIMEOUT 兩個參數的設置。其中 DLCHKTIME 單位是毫秒，是 DB2 檢查死鎖的間隔時間，如果該值為 10000ms，則表明每隔 10 秒鍾資料庫會檢查一下有無死鎖存在，如有死鎖，會選擇回滾其中的某一個事務，讓另外一個事務完成交易。LOCKTIMEOUT 單位是秒，是鎖等待最長時間，超過該時間仍未獲得鎖，則返回錯誤。LOCKTIMEOUT 的默認值為 -1，這意味著鎖等待時間無限大，一般不推薦這種設置。DLCHKTIME 時間通常要設得比 LOCKTIMEOUT 時間小一些，否則還未發現死鎖，就會返回鎖等待超時錯誤 (SQL0911N 返回碼 68) 。鎖升級:要避免鎖升級，我們應該正確設置資料庫參數 LOCKLIST 和 MAXLOCKS。LOCKLIST 表明分配給鎖表的內存大小。每個資料庫都有一個鎖表，鎖表包含了並發連接到該資料庫的所有應用程序所持有的鎖。MAXLOCKS 定義了應用程序可以佔有鎖表空間的百分比，當一個應用程序所使用的鎖表百分比達到 MAXLOCKS 時，資料庫管理器會升級這些鎖，用表鎖代替行鎖，從而減少列表中鎖的數量。我們一般可以通過增加鎖表大小的方法解決鎖升級問題。日誌性能監控概念DB2 事務日誌對於恢復來說極其重要。它們記錄對資料庫對象和數據所做的更改。在 DB2 中數據和索引的改變都會先被寫入日誌緩沖區，保證對數據所做的修改在記錄到資料庫之前，總是被具體化為日誌文件。日誌緩沖區的數據由日誌處理器寫入磁碟。在下列情況下，查詢處理必須等待日誌數據寫入磁碟後才能進行: 事務提交時。 在將相應數據頁寫入磁碟之前，因為 DB2 使用預寫日誌記錄。預寫日誌記錄的好處是當執行 COMMIT 語句完成事務之後，並非所有更改的數據和索引頁都需要寫入磁碟。 在元數據更改(一般通過執行 DDL 語句產生的)之前。 日誌緩沖區已滿。DB2 以這種方法管理向磁碟寫入日誌數據的目的是盡可能地縮短處理延遲時間。在存在許多較小的並發事務的環境中，許多處理延遲是由 COMMIT 造成的，因為它必須等待日誌數據寫入磁碟後才能進行。因此，日誌處理器進程頻繁地將少量日誌數據寫入磁碟會造成大量處理延遲，另外一些延遲是由日誌 I/O 開銷造成的。監控我們進入 SAP 的 DBA Cockpit，然後在 Performance 的目錄下雙擊 Database, 在 Logging 的標簽內，可以看到當前資料庫日誌的狀況。圖8. 資料庫日誌狀況我們在圖中可以看到日誌文件以及日誌緩沖區的情況。包括日誌文件的數量，大小，資料庫使用的日誌空間以及可用日誌空間的大小。還可以看到日誌緩沖區的情況，當前日誌緩沖區的命中率為 100%。分析由於資料庫中的處理必須等待日誌數據寫入磁碟才能進行，日誌文件的讀寫速度對資料庫的響應速度也會產生很大影響。因此，應該把日誌文件放到速度比較快的磁碟上，以減少磁碟 I/O 開銷。日誌文件寫入的性能可以通過平均寫時間來觀察。另外，我們可以通過調整資料庫配置參數 LOGBUFSZ 來指定日誌緩沖區的大小。如果資料庫對於日誌磁碟有相當多的讀操作，或者希望有較高的磁碟利用率。一般來說，如果日誌緩沖區的命中率小於 98%，那麼可以增加這個緩沖區的大小以提高命中率。當增加這個參數的值時，也要考慮 DBHEAP 參數，日誌緩沖區使用的空間是 DBHEAP 參數所定義的內存空間的一部分。資料庫統計信息監控概念資料庫的統計信息反映了表及其相關索引的物理特點。統計信息主要包含: 表信息:表的行數，使用的數據頁，溢出的行數，列的平均長度，列的最大最小值等。 索引信息:索引條目的數量，索引所關聯列的不同值的數量，索引的層數等。這些信息被資料庫查詢優化器用來生成查詢計劃。好的訪問計劃對於 SQL 語句的快速執行至關重要。我們需要想辦法保證統計信息准確地反映了當前資料庫的狀況。由於資料庫的表和索引總是隨著資料庫處理各種更新請求而不斷發生變化的，因此，總會出現統計信息過時，而不能正確反映資料庫數據現狀的情況。這時，資料庫查詢優化器生成的查詢計劃可能不是最優的，這將大大影響資料庫的查詢性能。我們應該經常檢查資料庫的統計信息是否為最新的，並及時更新統計信息。SAP 系統為我們提供了監控和執行統計信息收集的方法。監控我們進入 SAP 的 DBA Cockpit，然後在 Performance 的目錄下雙擊 Tables, 在 Table 列表中雙擊要監控的表，在 Table 的標簽中，我們可以看到當前表的基本信息。這時，如果我們點擊 Count 按鈕，就會看到統計信息的質量。圖9. 表的統計信息狀況從圖中我們看到，表的當前行數為 27，Deviation 為 8%。分析如果我們監控到一個表的 Deviation 超過了 15%，我們就應該重新收集這個表的統計信息。在 SAP 中我們可以選擇手動收集統計信息。我們也可將系統配置成自動收集統計信息，這樣大大減少了系統手動維護的工作量。自動統計信息收集通常每隔 2 個小時觸發一次，它會自動選擇在 24 小時之內沒有收集過統計信息的持久的基表。如果 SAP 系統進行 Client Copy 或在 BI 表中載入大量數據，由於這些操作在短時間就可以改變表的數據狀況及分布，因此會導致統計信息的過時。在 DB2 V9.5 中，為了解決這個問題，提供了一種 RTS (Real Time Statistics) 的特性，該特性可以允許在查詢被處理並優化前對表的統計信息進行收集或采樣，如果優化器認為重新收集統計信息比用過時的統計信息進行查詢的速度快，那麼會在處理該查詢之前重新收集表的統計信息，從而達到實時收集統計信息的目的。我們一般需要將資料庫配置參數 AUTO_STMT_STATS 設為 ON 來開啟 RTS 特性，但在 SAP 系統中，RTS 已經是默認設置，我們無需進行任何改變。回頁首結束語本文從資料庫問題檢測的一般思路和方法論出發，介紹了如何通過 SAP 系統對 DB2 的性能進行監控。

『捌』 DB2報已經達到了MAXFILES和MAXFILESIZE CREATE EVENT MONITOR參數的限制，所以取消激活了"事件監視器"

ADM2001W 是個報警，可以忽略掉。
1、創建資料庫的時候，默認會創建一個名叫 DB2DETAILDEADLOCK 的event monitor用來記錄發生的死鎖事件信息。當需要分析的時候，可以通過該信息用於定位出現死鎖的事務。同時，它是有大小限制的。這里就是說達到限制了。
2、如果就是不想它記錄，首先取消激活該event monitor（db2 set event monitor db2detaildeadlock state 0 ）；然後找到對應的目錄C:\DB2\NODE0000\SQL0000*\DB2EVENT\db2detaildeadlock 刪除其下的所有文件，然後再次激活即可（db2 set event monitor db2detaildeadlock state 1）。

注意：對於路徑 C:\DB2\NODE0000\SQL0000*\DB2EVENT\db2detaildeadlock，
1、你的資料庫可能不在C:你要去找找，但都是在盤符下的db2目錄。
2、SQL0000* 可以用命令去確認，
比如，我知道我的資料庫 TEST 在d:下，執行命令db2 list db directory on d:
看到 "資料庫目錄 = SQL00005"了么？（木有v8的環境，拿9.1的對比，類似的）

C:\Documents and Settings\Administrator>db2 list db directory on d:

d: 上的本地資料庫目錄

目錄中的條目數 = 2

資料庫 1 條目：

資料庫別名 = TEST
資料庫名稱 = TEST
資料庫目錄 = SQL00005
資料庫發行版級別 = b.00
注釋 =
目錄條目類型 = 本地
目錄資料庫分區號 = 0
資料庫分區號 = 0

『玖』 如何使用Spotlight和loadrunner進行DB2資料庫的監控

如何使用Spotlight和loadrunner進行DB2資料庫的監控
loadrunner監控資料庫很雞肋,幾乎沒幾個性能指標,這里建議你用spotlight專門的工具去監控oracle

『拾』 windows系統上DB2資料庫在哪裡開啟監控

DB2中使用BACKUP生成文件，只能使用DB2 RESTORE讀取，這些文件是按IBM自己的格式生成的，用文本工具打開它之後你也基本看不懂它是什麼東西。