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