最近幾年隨著新的政策安全法規的出臺，像Sarbanes-Oxley Act，HIPPA，California SB 1386和其它的公司一樣，正在對現有應用進行一些修補，以期改善系統安全。關于數據庫服務器，修補的一部分是應用的一些安全策略，這些安全策略與OS和數據庫補丁相關；審計那些直接登錄訪問；使這類網絡訪問協議不再起作用，這些協議像te.net，FTP和rsh等。但IT部門也需要確定需要捕獲什么樣的信息用于審計�；厮莸�2002，Senator Sarbanes和Representative Oxley可能不知道影響它們對美國信任社團或法人的是什么。Sarbanes-Oxley的影響將被摸索好幾年，正如它的影響達到其它相關的區域，并且能感覺到它以新的和更嚴格規定條規的余震。
關于數據庫本身，當創建，變化，更新或刪除數據庫對象的時候，IT部門最需要做的是審計變化。一些公司對于跟蹤"誰"和"從哪里來"的信息也感興趣。變化這些對象的一些例子如：創建視圖，變化表，編譯程序和重建或刪除索引。
查詢執行
跟蹤SQL查詢計劃執行的變化被認為是變化數據庫和應用的重要地方。當正確地優化SQL語句時，它們的數據庫訪問和修復速率能夠有效地服務，并且不用擔心用戶應用。然而，如果沒有正確地優化，它們就會嚴重影響應用的性能。幾乎所有的DBA，從入門級的到熟練級的，都知道為完成SQL語句苦惱好幾個小時的情況。這時，有了正確的SQL調優，這個優化就可以很快完成。在解決應用性能問題時，知道什么時候查詢計劃在生產環境中變化極其有用。另外，當跟蹤這種變化時，捕獲變化之前和變化之后的查詢計劃和它們之間的不同點非常有價值。
用戶定義
這種變化類型是使用最廣泛和最有效的類型，用于模仿和跟蹤發生在你特有業務環境中的變化。它給IT部門一種方式，測量那些幾乎不可能量化的變化項目，就像以下的性能影響：
OS升級或數據庫補丁
ERP/CRM應用升級
數據庫空間重組
用于執行各種數據庫維護任務的特殊腳本
添加新的應用到系統
添加50個新的用戶或整個新的分支功能到生產系統
這種類型的變化使DBA無從評估，并且通常沒有在數量上監測。IT部門始終渴望從這些經常變化的項目中獲得好的性能影響信息。
這種變化類型可以包含絕大部分任何一種與數據庫相關的變化。當公司評估數據庫變化跟蹤系統時，通過提供方法，輸入用戶定義的變化來支持這種重要的變化類型是有必要。很容易地采用這些變化和在工具界面中識別這種變化跟蹤系統。
這種類型的變化能夠用于證明影響的出現。例如，當系統管理員安裝操作系統補丁時，記錄下這個事件能夠幫助確定性能中的變化是否直接跟這個事件相關。
上面提到的所有變化指出了關鍵的數據庫和應用系統的重要方面，而這些方面需要我們長期持之以恒的監測和跟蹤，為了重要的數據庫和應用系統。當這些地方發生變化時，不管是有計劃的還是無計劃的，有見識的IT部門將測量和報告變化的影響。當發現不利的影響時他們能夠很快地對變化事件進行管理，或者一旦出現有利的結果，就把這些有利結果報告給管理部門，作為成本理由或投資回報分析的重要數據要點。
系統變化用例研究
在2004年，我能夠在示范機中出現的內存故障影響應用性能之前快速地發現它。我們使用這個示范機向客戶介紹我們的產品解決方案，所以要求這個示范機有個好的性能。這個機器有兩條512M的內存條共計1G的內存。其中一條內存條是完全壞了，這使得系統運行緩慢。首先，我沒想到內存壞了。畢竟，我加載"demo"數據和運行一些報表，并且認為雖然系統看起來比平常運行慢多了，但還是可以解釋為什么性能下降了。之后，我再一次確認這機器不能合理的解釋它的運行狀況，因為正常情況下它運行很快，這時我開始懷疑系統是否負荷過載。這個提示我檢查一下我的變化跟蹤系統（我使用其中一個在常規基楚上），看看是否有重要的變化。畢竟，昨天系統還是運行良好的。什么變化了呢？當我調查監測系統，它立即報告其中一個512M內存條壞了。我通過使用Unix OS命令行很快地確定這個信息，并且真的系統不再注冊RAM為1G了，而是512M。這解釋了為什么"示范機運行緩慢"。那個下午，我們的MIS部門用一個新的內存條把那個壞的換了下來，準備著再給用戶介紹產品。
我使用什么樣的變化跟蹤來診斷和解決這個問題呢？答案是：Quest Central Performance Analysis，一個全面的變化跟蹤和歷史的分析工具，用于幫助解決性能和與性能相關變化的問題。
使用性能分析跟蹤變化
Quest Central's Performance Analysis提供一套全面的變化跟蹤工具，它能自動地跟蹤和報告發生在Oracle和Microsoft SQLServer數據庫環境中的變化。變化跟蹤工具與Performance Analysis監測工具集成在一起，提供以下功能：
定期地跟蹤環境，配置和數據庫對象的變化；這些變化可能影響系統和數據庫性能
使用戶能夠把變化的出現和數據庫活動關聯一起，用于識別影響系統性能的變化
包括選擇常見輸出格式的報表，計劃和變化種類過濾器，變化種類過濾器能使用戶能夠重新定義在任一個給定時間周期中顯示一系列的變化。
IT是怎樣工作的
Performance Analysis Change Tacking沒有試圖審計系統變化，而是集中于那些以后可能影響系統性能的變化。例如，如果在日常變化跟蹤斷點之間創建和刪除索引，表或數據庫對象，這時這些對象的變化將記錄在日常變化跟蹤報表中。因此從日常的觀點看它們對于性能將沒有什么影響，只有間隔幾天去看才能看出影響。但如果在開始變化跟蹤時存在索引，并且在下個變化跟蹤事件發生之前被刪除了，那么索引刪除將被記錄在變化跟蹤系統中，因為它以后可能影響性能。
事例1－Microsoft SQL Server數據庫上的Index Drop
在下面的例子中，由于不小心把索引從數據庫系統中刪除了。讓我們回顧一下Performance Analysis將如何發現，診斷問題，并且是如何使DBA采取措施解決這些問題的。
但首先讓我們快速地看看Performance Analysis監測產品，這樣能幫助你更好地理解例子中用到的截圖。如果你已經熟悉Quest Central Performance Analysis，那可以跳過下面的例子。
1. 歷史區域以流行的類型（USER，PROGRAM，SQL，和其它）提供性能數據片斷。其它區域是RECENT和REPORTS。
2. 由Performance Analysis跟蹤的工作量等待事件類型。
3. 簡單易用的滾動條和向下鉆取的能力使用戶能夠在任何時候都可以快速地分析。
4. Wait event餅圖使用戶能夠下鉆到等待事件種類和回顧詳細的資源使用情況。
5. 通過點擊列名對改列的性能數據進行排序。
在這個例子中，對于所選擇的事件段，已經發生了一些變化，正如下圖中顏色指示器所指出的。使用Performance Analysis，DBA能夠快速地確定圖中提到的最近IO和Latch活動頻繁是否由最近的變化引起的。
這個揭示了Ron Barret運行一個新腳本，這個腳本刪除了不需要的索引。Ron使用User-Defined變化機制輸入變化到Performance Analysis Change Tracking系統。正如這篇文章前面顯示的，User-Defined變化跟蹤使公司能夠跟蹤發生在它們系統中的重要任務和項目。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
