IBAnalyst如何幫助你發現Firebird或InterBase數據庫的問題

讓我們來看看IBAnalyst的關鍵特性。當你第一次看IBAnalyst的數據庫統計信息時，可能會覺得不是很清楚，特別是當IBAnalyst在總覽視圖、表格視圖以及索引視圖上用了大量的紅黃單元格來作為警告提示的時候。 讓我們來參考一些實際方面的例子。

總覽視圖

總覽頁面顯示了大量的信息，但是其中最有價值的是事務狀態。（請點擊F1或者幫助按鈕，在IBAnalyst幫助中閱讀關于對事務狀態種類的描述）

從下面的截圖可以到看到，有一些事務已經活躍了很長一段時間，平均每日有61%的事務處于活躍狀態。（“61% of daily average”） IBAnalyst將這些事務的狀態標記為紅色，防止因為版本的更替而被服務器認定為是內存垃圾而被回收。

導致系統變得緩慢有一個很重要的因素：對于某些記錄的版本數量越多時，讀取所花的時間也就越多。為了找到這些長時間運行的事務，你可以使用FBScanner的MON$Logger模塊或者對MON$表格進行直接查詢。而為了找到被長時間運行的事務所影響的表格（就是那些有大量版本的表格），你需要查看IBAnalyst的表格視圖。

表格視圖

在表格視圖，你可以看見這些表格以及它們的重要參數：記錄總數、記錄的版本總數、記錄的長度、版本的最大數量等等。

你可以通過排序來查看這個最大的表格。我們對那些有許多記錄版本的表格特別感興趣-大量的記錄版本會使表格的垃圾回收時間更長。通常只有改變更新和刪除的算法才能擺脫大量的記錄版本。

Versions行顯示的是某個表格的版本總數，Max Vers行顯示的是由某些記錄達到的最大版本數量。例如，來看下圖中的NAB表格，這里有1190萬多條記錄，版本總數為20932，其中一個記錄有176個版本。從硬盤中讀取和分析這樣一個數據包會花費更多的時間，因此，讀取這個記錄會比其它記錄更慢。 

這張圖也顯示了許多數據已被刪除的表格。但是因為長時間運行的事務的緣故，服務器不能刪除這些版本，因此它們仍然留在硬盤里，仍然會被編入索引，當讀取數據的時候，它們仍然會被讀取。

索引視圖

某些生產數據庫把唯一鍵值來作為索引。出現這種情況的原因是數據庫的開發會在未來進行擴展或者只是在開發和測試中對索引進行的實驗。你可以在下圖的IBAnalyst中看到這些被標注為“Useless”的索引。

SKIN04、SKIN05、SKOUT03等等，對于這些在同一列上鍵值相同的所有行（成千上萬行），其索引都是完全無用的，因為

• 如果你指定“where field = ...”，優化器就會使用此索引。由于field只包含了一個值，使用索引將會引起對索引頁從硬盤到內存的無用讀取，而服務器準備用于顯示該查詢的行數時，又會引起內存和時間的浪費。
• 創建索引是恢復過程的一部分。額外的索引會增加額外的時間。

當然，這并不是在IBAnalyst中你能夠找到的關于數據庫的一切。你還可以找到：

• 每天的平均事務數量。
• 回退與丟失連接的位置和時間。
• 每個表格和索引的大小（字節為單位）。
• 空表格-這是當統計資料被拿走后被遺忘或者清空的東西,等等。