衆所周知，資料庫的運維既是個技術活兒也是個苦差事，不僅要有廣闊的知識面，強大的技術能力，對主機、存儲、網絡、作業系統也最好樣樣精通，而且還要會寫sql、shell、最好連java也能拿下…同時，還需要擁有超強的耐心、謹慎的态度以及強健的體魄。
今天鄒德裕老師将告訴你如何讓資料庫運維簡單化，如何減輕dba的工作量及壓力，提升效率，并且可以擁有更多時間去思考。
目錄：
如何簡單化
oraz之路
oraz後續計劃開發或擴充功能
2008年剛進公司轉做專職dba，發現dba竟然比以前幹程式員還苦逼，通宵施工如家常便飯，而且有大量的重複工作。當時每個dba在共享伺服器上都有自己的腳本集，每當應用側有任何異動dba們就找到自己的腳本集檔案，然後替換條件複制粘貼執行，遇到沒找到的就一頓狂敲鍵盤輸sql。特别是在遇到大故障時，身後便會圍着一群人，有各方上司，還有開發商，裡外好幾層。那可真是令人抓狂，因為做過幾年的開發，我便想，為何不做一個shell程式，統一入口，隻要傳入參數即可。于是我開發了第一個簡單的oracle運維工具，當時腳本集就叫ora。這個工具後來在運維團隊不斷被完善、擴散，至今仍在使用。
ora腳本集的優點：
讓日常監控、維護操作等标準化。
減少出錯機會，提高效率。
讓dba從容應對故障應急。
缺點也是明顯的，正是有了這個工具，現在很多dba們到了非駐場的服務現場就不會寫sql了。（怪我喽…）
在運維期間碰到系統常發生hang，當資料庫發生在争奪核心級别的資源時，比如latch等，在11g之前oracle不能自動的檢測并處理這種死鎖。這時候需用hanganalyze工具dump資源持有的互相關系。當二線dba到場時已基本hang死，或無法登陸，即使能做出dump trace也無法反映真實原因。
另外分析trace定位堵塞源也要一定時間。是以分析出結果時往往應用已中斷。既然hang住後要重新開機或終止掉所有前台發起資料庫程序才能解決，何不在hang開始初期就發起自動hang分析，識别引起hang的源頭，記錄相關資訊，終止源頭。
具體過程如下：
1．通過等待事件識别hang症狀
2．根據上一步驟判斷觸發搜集hanganalyze
3. 分析hang的dump資訊，并确認是否存在hang
4. 識别hang的源頭記錄相關資訊并解決hang問題
這是我編寫的第二個程式（由于該程式已申請了專利，代碼在此就不分享了）。
注：在oracle 11g 11.2.0.2版本釋出後，其新特性中才出現了hang 管理器(hang manager)
hm配置參數（開啟後會根據配置終止執行個體或程序，請謹慎使用）：
後面還有長事務、二階段事務（dx鎖）分析、自動生命周期管理、自動優化排程分析、自動巡檢工具、離線巡檢工具等等。如果你能把你日常需求做的工作工具化或自動化了，dba就不是一個苦差活了。你也就有更多時間用來研究更深層次的技術了。
我隻是一個會寫程式卻不安分的“懶”dba。
至此越來越想做一個較為完整，能幫助dba的工具。該工具将運作sql查詢視圖監控資料庫的性能，識别資料庫存在的隐患。
資料庫的運維工作包括部署安裝、性能優化、備份容災、故障恢複、預防性巡檢等工作。這幾個方面都存在不少重複度高、工作量大的任務，有的甚至還可以并行處理，這些都是該工具需解決的目标。
oraz是基于jdbc+ssh的java應用，監測和分析資料庫執行個體活動，系統要求是相當簡單，隻需jdbc能連接配接上資料庫即可，該工具不會安裝任何額外軟體在你的伺服器和終端上。
請注意，由于目前javafx不支援中文目錄，故oraz不能在中文目錄運作。
· 有關資料庫和執行個體的一般資訊。
· 有關資料庫結構和資料存儲的詳細資訊: 表空間，資料庫檔案重做日志、 歸檔的日志等。表空間/資料檔案使用情況和可用空間
· 記憶體資訊: sga/pga 元件和大小，共享的池和緩沖區緩存統計資料。
· 執行個體活動洞察-cpu消耗、 等待事件、 頂級的會話、 頂級sql語句等。
· 會話資訊-活動會話，排在前面的會話等。
· 頂尖的 sql 語句和有關每個語句包括語句活動、 執行統計資訊、 資源消耗、 執行計劃、 版本等詳細的資訊。
· oracle 資料庫全系統統計資訊、 作業系統統計、 名額和時間模型。
規避系統風險運維自動化體系形成之前，我們dba的日常例行工作在總工作量中占比較高，很消耗人力，員工疲于奔命但工作效率不高，也很容易出差錯。自動化平台把我們的員工從繁瑣的正常工作中解放出來，更專注于做架構優化之類的有創造性的工作，效率也有了進一步的改善。
每日檢查是工程師上班的第一件事，通過腳本來進行，腳本輸出僅提示異常部分，檢查内容例如：
等，編寫對應查詢sql，再通過jdbc通路遠端伺服器擷取該值進行判斷：
select owner, constraint_name, table_name, status
from all_constraints
where owner = '&owner' and status = 'disabled' and constraint_type = 'p';
建立如360式的一鍵體檢方式：
通過該體檢功能可快速檢測資料庫問題；目前該巡檢暫不支援自定義，可以考慮建立可通過saas平台分享的自定義巡檢項。
執行個體活動洞察分析功能目前已同步釋出更新，在很多情況下，當資料庫發生性能問題的時候，我們是來不及收集足夠的診斷資訊的。或者收到告警，甚至問題發生的時候dba根本不在場。這給我們診斷問題帶來很大的困難。那麼在這種情況下，我們是否能在事後收集一些資訊來分析問題的原因呢。
oracle重器oem，而top activity功能是使用最為頻繁的功能點：
指定時段内的頂級消耗、會話等一目了然。上圖中負載均以average active sessions（aas）平均活動會話進行計算。
每一個會話執行過程如下：
而每一個語句在執行過程又可以分解為不同活動時間: cpu執行中、等待io或其它資源中，即可分為cpu、io、wait
當有多個會話連接配接到庫，并活動時：
通過時間片段來看同一時刻有多少會話處于活動狀态，該值為aas值。以相同方法以sql語句次元統計該時刻活動，則找出頂級活動sql，同樣可以計算頂級活動program、user、會話等待。
由于db time=某一時段時間總和，故頂級活動sql即為topsql，是以aas=db time / elapsed time (曆時)，之是以該名額叫做黃金名額，是因為通過aas名額可以衡量一個系統的繁忙程度，這裡有個cpu時間片概念，每一個cpu時間由作業系統分成cpu時間片，然後cpu時間片輪詢模式配置設定給線程或程序（視操作新系統而定），在最小機關cpu片段内整個系統允許的最大允許數為cpu個數，故通過比較aas值與cpu可以衡量資料庫繁忙度，與cpu數量關聯分析：
aas/cpu_count~= 0 非常空閑
aas/cpu_count<=0.5沒堵塞
aas /cpu_count < 1 部分程序已達100%，應用開始出現緩慢
aas/cpu_count >或>> 1 出現性能問題或堵死、hang狀态
aas在oracle中oem、ash中的應用：
oem中：
ash中：
從oracle 資料庫 10g開始增加v$active_session_history視圖，通過它可以容易地得知目前instance的活動狀态，主要是知道各個時刻系統都在等待哪些事件，通過對這些等待事件和相應等待次數的統計，就可以清晰地了解系統的曆史工作負載特征和壓力情況。此視圖提供了大量寶貴的資訊，而且不需要繁重的跟蹤活動。
ash資料采集由mmon程序與mmnl程序負責；
快照由mmon和mmnl背景程序自動地每隔固定時間采樣一次。
mmon程序負責：
當某個測量值（metrics）超過了預設的限定值（threshold value）時送出警告
建立新的 mmon 隸屬程序（mmon slave process）來進行快照（snapshot）
捕獲最近修改過的 sql 對象的統計資訊
mmnl程序負責執行輕量級的且頻率較高的背景任務，如捕獲會話曆史資訊，測量值計算等。
awr的采樣工作由mmon程序每個1小時執行一次，ash資訊同樣會被采樣寫出到awr負載庫中。ash buffer根據被設計為保留1小時的資訊，但很多時候這個記憶體是不夠的，當ash buffer寫滿後，另外一個背景程序mmnl将會主動将ash資訊寫出。
ash buffer大小
-按照公式size of ash circular buffer = max [min [ #cpus * 2 mb, 5% of shared pool size, 30mb ], 1mb ]計算，預設1m左右，該參數可以同隐含參數進行調整：
"_ash_size"隐含參數控制ash buffer的大小
ash對應視圖關系為：
通過按分鐘從v$active_session_history視圖采集資料，展示如下：
從上圖可看到選擇時段内topsql為“cvn54b7yz0s8u”，占該時段内的19.5%，主要在等待io資源。
表空間增加讀寫走勢分析、碎片率分析
計劃作業執行詳細資訊和目前正在運作的作業。
閃回去/快速恢複區使用情況和備份資訊。
深度體檢
程序跟蹤（10046、10053）以及trace分析
自動化優化分析等
alert日志查詢圖形化展示
對于資料庫、中間件設計，在系統上線前，針對應用系統的主要業務場景和應用要求，對資料庫、中間件軟硬體配置，系統參數和資料存儲進行優化設計，包括但不限于如下内容：
資料庫适用應用特點的最佳實踐配置
性能及穩定性滿足設計需求
系統與資料庫特性及設定的最佳比對
資料庫版本對已知bug的修複
花5-10分鐘發現系統存在的風險
直接提供來自mos推薦的專業解決方案
如果你所在部門有如運維自動化、标準化、可視化、一體化（集中化）這些需求建設，可以與我聯系，我們有amp（自動化運維平台）和apm（應用性能管理），即使是已部署了ixm的txxxx軟體的企業依然會再使用我們的産品。
q&a精選
q1：oraz在windows 2008 r2下無法運作？
a1：目前與将oraz放中文目錄存在不相容問題，建議放英文目錄，如d:\dbaplus。
q2：此程式是否可以自己定制？
a2：目前暫不支援自定制功能。
q3：是否考慮加上統計資訊方面檢查？
a3：非常好的建議，在下一版本的一鍵體檢中會增加該檢查項。
q4：最新版本oraz在哪裡可以下載下傳？
a4：在dba+社群官網和dba+公衆号的服務中可以下載下傳
q5：hpux、aix支援問題
a5：本人無小型機做測試，暫未無法驗證支援型，oraz是通過java開發，通過jdbc連接配接，理論上是支援的，後續我會尋找該測試環境的進行驗證。
q6：有些系統隻能用telnet23端口，好像工具不能用23端口連接配接？
a6：目前僅支援ssh協定，即22端口。
q7：是否可以考慮把sql_monitor功能也內建進去？
a7：非常好的建議，會納入後續考慮功能清單。
q8：是否支援mysql？
a8：目前版本在一鍵體檢中支援mysql，其它專用工具會根據需求逐漸更新。
作者介紹：鄒德裕
新炬網絡首席專家，dba+社群聯合發起人。
oraz産品作者，輕維軟體産品架構師。
十年以上運維管理經驗，oracle ocm，精通oracle9i、10g和11g資料庫技術和linux/unix技術。
對資料庫系統架構具有深刻的了解，并在資料庫診斷、故障排除、優化、架構設計等方面具有豐富的經驗。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-01-14</b>