作為一名合格的Oracle數據庫管理員密切關注有可能會對他們所管理的每個系統可用性或是性能具有不良影響的Oracle數據庫的一些相關問題。在一般的情況下，我們就可以把數據庫管理員監視、維護系統的方式分為兩種，分別為反應性監視與前瞻性監視。
如上圖所示，反應性監視是指在已經出現一個性能或者管理問題後再對數據庫進行監視。例如有員工向Oracle數據庫管理員反應應用系統的速度比較慢。數據庫管員跟其他技術人員共同會診後發現是由於數據庫的原因所造成的。
此時數據庫管理員就需要使用相關的工具來收集數據庫的運行數據，以查明問題發生的原因。雖然這最終也可以順利把問題解決，但是這畢竟與優秀數據庫管理員心中的期望還有一點距離。因此反應性監視有點像放馬後炮的感覺。問題已經出現，即使數據庫管理員能夠在最短時間內查明原因、解決問題，但是畢竟對於用戶產生了一些不利的影響。
故數據庫管理員希望能夠在故障發生之前就能夠了解導致這個故障發生的原因，並及時采取有效措施預防這種故障的最終發生。這就使數據庫管理員所期待的前瞻性監視。
前瞻性監視可以讓數據庫管理員在問題出現之前、期間或者之後查處並響應Oracle數據庫常見的性能與管理問題。簡單的說，在某一個數據庫故障發生之前，都會有一些征兆。這就好像一些自然災害發生時，像螞蟻、燕子等等都會有一些異常的反應。數據庫管理員有必要了解這些征兆。如此的話，我們才能夠把這些問題消除來萌芽狀態，防止問題的擴大。
Oracle數據庫設計者們也一直在往這個方向努力。如在10G以後的數據庫版本中，就有了一個自動工作負荷儲存庫的功能，來幫助數據庫管理員收集在數據庫運行中的異常數據。通過這些數據的幫助，數據庫管理員可以搶在Oracle數據庫故障發生之前把問題解決了。
自動工作負荷存儲庫的特點
自動工作負荷存儲庫主要是通過兩個回退進程實現的，分別為內存監視器與內存監視燈。這兩個進程是一對雙胞胎數據，他們可以給數據庫管理員帶來很大的幫助。如這兩個進程會相互合作，從數據庫系統全局區中直接收集性能統計數據。如數據庫服務器CPU內存的使用率等等。其中內存監視器在其中擔任主要角色。默認情況下，內存監視器每個小時會啟動一次，並從數據動態性能視圖、數據庫目錄視圖和數據庫優化器中收集性能等相關的統計信息，然後會把這些信息存儲在Oracle數據庫的表中。這個表就叫做自動工作負荷存儲庫表。通常情況下，這個表被Sysman用戶所擁有，並被存儲在Sysaux表空間中。
啟用自動工作負荷存儲庫並進行相關的配置
如果數據庫管理員需要啟用這個自動工作負荷存儲庫功能，則需要手工對此啟動。默認情況下數據庫是不會啟動這項功能的。筆者的意見是，在數據庫設計或者測試的時候，不用啟動這項功能。畢竟其本身需要耗用服務器一定的資源。但是在生產服務器(即企業已經在使用的Oracle數據庫)系統中，最好啟用這項功能。
以幫助數據庫管理員自動收集數據庫的運行性能信息，以實現前瞻性監視的目標。
如果想要啟用自動工作負荷存儲庫功能，則需要配置數據庫中的Statistics_level這個參數。這個參數主要有三個值，用來決定內存監視器進程收集統計數據的深度與頻率等等。如數據庫的規模比較小或者應用時間不長的話，可以把這個參數設置為Basic。
在這個參數下，數據庫雖然已經啟用了自動工作負荷存儲庫，但是會禁用這項功能的大多數爭端監視以及顧問活動。也就是說，此時數據庫管理員啟動數據庫實例時，系統只會收集少量的數據庫運行時的統計數據。當數據庫規模比較大時這些數據往往不能夠幫助Oracle數據庫管理員排查故障發生的原因。
如果數據庫設計比較復雜或者企業對於數據庫的性能要求比較高，則此時數據庫管理員可以把這個參數設置為ALL，這是自動工作負荷存儲庫收集統計數據的最高級別。在這個級別下，內存監視器將會捕獲大部分的統計數據，同時還會收集來自操作系統的執行計劃和定時信息。
如Oracle數據庫的自動備份有時候需要操作系統的任務計劃的幫助下才能夠完成。那麼此時數據庫管理員就需要考慮數據庫性能下降的原因是否跟這個操作系統的任務計劃有關。此時內存監視器收集起來的跟操作系統相關的計劃與定時信息就會非常的有用。不過有時候數據庫管理員可能只需要收集數據庫自深的運行信息，而不需要操作系統的相關信息。
此時就可以把這個參數設置為Typical。這個參數是自動工作負荷存儲庫的標准級別，他會收集跟數據庫自深相關的統計信息。
數據庫管理員可以根據企業對數據庫性能的要求、可以允許數據庫當機的時間、服務器的配置等因素來考慮要選擇的級別。通常情況下，如果在同一個服務器中，除了Oracle數據庫外還部署了其他應用服務的話，那麼筆者建議最好采用All級別。此時Oracle數據庫管理員可以知道盡可能多的信息，幫助管理員及早把問題消除掉。
