前幾天我們討論的關於DBA 2.0的話題，實際上也正是Oracle在後9i時代不斷促進的變革，而變革的主要工具之一就正是全新的OEM（Grid/Database Control）。所以我嘗試將這個話題做一個最後的總結。既然我們開始了DBA 2.0的討論，那麼DBA 2.0是從何開始的，又可以如何界定呢？
普遍的認為，DBA 2.0開始於Oracle Database 10g的時代，由於Oracle 10g引入了大量的新特性，使得DBA的工作發生了質的變化。 比如，ASM的引入使得DBA不得不更加深入的介入存儲的管理和維護；Clusterware的引入，使得DBA不得不深入了解和維護Cluster軟件；如果在加上Oracle的OEL（Oracle Enterprise Linux）和最近推出的Exadata以及HP Oracle Database Machine，那麼現在主機、操作系統、OS都需要一個Oracle DBA深層次的介入和管理。
而在傳統的數據庫層面，數據庫的自動管理與自我維護性則不斷提高。 Grid Control/Database Control可以幫助我們更好的監控和管理數據庫，AWR（自動工作負載信息庫）使得信息的收集實現自動化，ADDM（自動數據庫診斷監控程序）使得數據庫可以根據AWR等信息進行自動的性能分析和診斷，SQL Advisor、SPM（SQL Plan Management）可以幫助我們進行SQL的調整和建議……
總結一下那就是，在傳統的數據庫層面，Oracle不斷在強化自動化管理，提高數據庫的自我管理性，減少用戶的干預和工作量；而在數據庫之外，更後端，DBA需要不斷向系統、存儲甚至網絡領域延伸，在前端，DBA則需要不斷向應用層面進行擴展。
那麼DBA 2.0的使命大致就可以概括為：在不斷完善的數據庫管理工作之外，向更廣闊體系層面延伸，包括應用（Application）、系統（System）、存儲（Storage）、網絡（Network）、架構（Architecture）等方面，為企業提供更深遠的架構與決策支持，促進企業向更全面合理的可持續性IT架構方向發展。
這裡所說的”不斷完善的數據庫管理工作”實際上是對DBA 2.0的一個深入要求，如果要延伸更廣闊的領域，那麼就必然要將數據庫管理工作處理的游刃有餘，我之前提到過的Proactive一詞就是最核心的要求，只有更加主動的、具有預見性的對數據庫進行維護和管理，才能將很多故障消弭於無形，也才能夠達到數據庫管理上的提高。
既然DBA 2.0意味著更廣泛的層面介入，更深入的知識了解，那麼Oracle也不斷在加強自己的產品，來降低DBA工作的複雜度，加強數據庫的穩定性與可靠性等。實際上通過不斷的收購以及長期的佈局，Oracle已經打造了以數據庫為核心的全系列DBA輔助工具與產品。
比如，在最近的一次會議上，我了解到的Real User Experience Insight產品，這是一款用於全方位監視實際用戶活動的軟件，用以確保基於web的應用程序性能能夠達到期望水平；在達不到期望水平時進行分析和通知，並提供用戶應採取相關措施的軟件。下圖是其原理圖，從Page request到請求返回，所有流程的響應都將被記錄用於預警和評估：
這是我第一次了解到Oracle在應用監控方面的軟件，實際上這是在前端、應用層向前邁進，這是Oracle的擴展策略之一。
而我此前曾經提到的Oracle Enterprise Manager產品（也即新版的Grid Control / Database Control）則是在數據庫層面的巨大增強，Oracle一如既往不斷在數據庫層面加強其產品能力。下圖是Oracle在從開發到產品所有階段自頂向下的應用管理示意圖（摘自Oracle官方演示文檔），其中數據庫層面的Diagnostic and Tuning產品，Provisioning，Configuration Management等產品都是來自OEM產品中的增強。
而右側關於應用測試階段，Oracle也有了很多新的產品，這包括Real Application Testing（這是Oracle Database 11g中的功能，也整合在Oracle 10.2.0.4及之後的版本中），而Data Masking也是最新包含進OEM中的組件。
Data Masking我也是剛剛了解，這個組件在進行數據克隆時，可以對於生產數據進行轉換來保護原來的敏感信息，但是仍然能夠保持數據的完整關係用於真實的應用測試。這的確是一個不錯的功能及組件。
在前幾天召開的2008北京甲骨文開發者大會上，我還了解到，現在Timesten居然也打包進了數據庫產品，Oracle In-Memory Database Cache現在可以作為數據庫的一個組件銷售。
那麼回過頭來，DBA 2.0的時代，我們希望不再面臨以前的情況：數據庫忽然變慢，客戶投訴電話不斷，DBA如同消防隊員一樣不斷四處來撲滅冒起的火焰……
DBA 2.0的時代，我們希望能夠預見系統的變化，將問題消弭與無形。這就要求我們能夠全面掌握數據庫運行狀況，作為一個DBA，我在團隊中不斷強調”數據庫的全信息管理”模式，也就是要全面深入掌握數據庫的運行狀況，比如並發數量、負載概要、邏輯讀與物理讀變化等等，全面掌握這些信息並且適時監控，就能夠見微知著的了解數據庫的變化，並及早預測和解決可能出現的性能問題。
在這方面AWR的歷史數據收集和記錄給了我很大的幫助，OEM的診斷和SQL捕獲為系統調優提供了便利，Oracle也在2.0的方向不斷為我們解決難題。
在DBA 2.0的時代，Oracle的變化一如既往的非常快，要不斷學習才能跟上Oracle與時代的要求！
在最初的文章裡，我曾經提到過Grid/Database Control這個工具，這是Oracle Database 10g開始引進的基於瀏覽器的數據庫管理、維護與監控工具，是OEM（Oracle Enterprise Manager）發展的一個新階段。
不知道Oracle是基於怎樣的考慮和討論開始廢除/捨棄了Oracle Database 9i年代的基於JAVA開發的客戶端OEM工具（這個幕後的故事可能會非常有意思），也許是順應B/S的潮流，也許是大勢所趨。但是總之，Grid/Database Control的出現讓人眼前一亮（也讓很多第三方數據庫管理工具廠商大感壓力）。
新的OEM功能越來越強大，涵蓋的範圍也越來越廣，Oracle的意圖是將OEM逐漸演進成為一個全面的系統管理、維護與監控工具，不僅涵蓋數據庫，還要涉及系統、網絡、存儲等方方面面。
最近在使用11g的OEM過程中，發現關於主機方面的信息與監控越來越完善起來，比如關於負載、IO等信息的監控：
而在Grid Control中，更廣泛的信息會被監控和收集，比如應用的響應與處理時間等，通過進一步的下鑽與分析，可以在不同層面對於性能問題進行分析和解讀：
雖然OEM還不能解決我們所有的問題，但是在日常工作方面，已經可以成為我們很好的助手。
我曾經在我的《循序漸進Oracle》一書中用了很大篇幅來介紹新版OEM的使用。 OEM通過全面的監控部署，可以將曾經需要我們進行大量手工處理的工作自動來進行，以前需要很多腳本編寫處理的工作，現在OEM可以內置的自動完成，我要說的是，這部分增強對於DBA具有普遍的價值。
比如在監控方面，我們可以定義各種各樣的度量條件，當特定閾值達到時，觸發報警：
當然還要配置一些SMTP及郵件設置，此後如果數據庫出現相關告警，我們的信箱就可以收到告警郵件，以下是幾個郵件示例，當警告日誌中出現錯誤或者設置的空間使用達到，自動郵件告警信息就會發出。
關於通用功能的增強，是OEM中非常重要的部分，因為這部分增強可以將DBA普遍需要進行的工作進行簡化，實現用戶效率的提升。
當然，OEM對於很多高級DBA的幫助也許有限，但是如果90%的Oracle數據庫應用企業能夠將OEM作為數據庫的管理監控工作，那麼數據庫的管理和維護效率一定能夠大大提高。我這裡所說的90%的企業，也許根本沒有專職的DBA，那麼OEM將會是非常重要的助力。
OEM中很多特性也可以顯著縮減資深DBA的工作量，我覺得OEM眾多的PACK包中，對DBA價值最高的是以下兩個：
1. Diagnostic Pack診斷包通過數據庫內建的自我診斷引擎來定位系統的性能瓶頸所在，並且給出相應的優化建議。
2. Tuning Pack調整包對於指定的SQL自動進行優化，使之符合系統的性能要求。而哪些SQL需要優化，則完全可以通過制定性能目標來由Oracle自動從當前系統中抓取出來。
在OEM中，通過這兩個工具包，DBA可以很容易的捕獲並分析性能問題，並且可以參考數據庫的建議進行改進！使用OEM進行問題SQL的捕獲（注意，不要等待問題出現時才去關注，日常對於數據庫的關注與監控尤為重要，也只有對數據庫進行更全面的跟踪才能使DBA更具有預見性）與診斷變得非常快速與簡便，這些變化甚至可以讓對數據庫僅有初步認識的人在解決數據庫問題時也變得十分專業：
而這些在OEM中可以快速完成的工作，在以前的複雜度可能會讓很多對數據庫了解不多的技術人員望而卻步！我們可以確切的說，正是Oracle OEM的改進也即Grid / Database Control的增強，使得傳統的數據庫管理工作更加簡便，從而進一步促進了數據庫管理的變革！
