對于oracle運維中的那些事兒，我的最終目的：不是比誰更慘，而是能夠從中吸取經驗和教訓。
從我的了解來看，我會從下面的幾個方面來進行說明dba運維中的一些事兒。
每個部分都是非常關鍵的，缺一不可，而且每一部分都有很多的東西可以細化，我會逐一展開來說。
（一）環境篇
首先來說說環境篇。
dba的角色及分工
對于dba的分工，以前的公司對于dba角色劃分粒度還是很細的。
大體是按照核心和客戶化定制層來劃分的，核心層主要負責産品化，客戶化層面主要負責定制。屬于不同的産品線但又彼此緊密關聯。
physical dba更多負責環境部署，搭建和資料恢複，更新檔更新等，對于系統，存儲網絡等更為拿手。
performance dba一般都是從各個産品線逐漸衍生出來的高手，對于産品了解很深，當然工作重點是在性能調優上。一般都是産品級的優化，全球所有項目都會通用。
dev dba也有一個團隊，負責運維産品的開發，其實内部的很多自動化的工具都是他們做出來的，當然開發功底要求也很了得。
delivery dba主要負責資料傳遞，一般的ut,uat,prod的資料傳遞，有的時候涉及的環境成百套，對于這些資料的傳遞管理非常重要，更新檔管理，資料變更的基線管理，資料的同步，複制，業務環境搭建都會涉及。
application dba 主要和業務相關，一般和開發的聯系較為緊密，一線的資料支援，對于系統的架構，業務情況要很熟悉。
最後是site dba，所有産品，業務的事情都要考慮，最終的方案和實施落地。
然後來說說行業環境，以我為例，我也是從傳統行業到了網際網路行業，當然也需要作出一些改變。
從角色上是從乙方到甲方，很多的事情都需要考慮，對于技術方案和硬體選型，不僅僅是純技術上的考量，需要更多的因素。這是一個全面的過程。
當然和傳統行業來比，傳統行業更為保守，穩定壓倒一切。
以之前的電信客戶為例，測試情況極為苛刻，uat測試做了差不多一年。
對于産品和資料庫的版本搭配，公司也有嚴格的認證制度，哪個産品适用的資料庫子版本（比如11.2.0.2.x）都有要求，因為這些是實實在在做足了測試。
很多客戶對于rac的使用也是保守的active/passive方式，當然自11g的adg之後，也在默默的開始替換bcv的方式。
從資料庫的角度來看，為了保守，很多特性都會禁用。
禁用直方圖
産品化極為徹底，很少有建立索引優化sql的場景
禁用資源回收筒
禁用skip scan
……
（二）監控篇
監控篇中和大家說說一下幾個方面。一個是監控工具。
一般的選擇都會是商業或者開源，或者兩者兼有。
兩者沒有嚴格的優劣之分，這是一種平衡和理性的選擇過程。
gc,em12c本身原生支援oracle,還可以擴充支援其它的資料庫，系統層面也做得不錯。管理功能非常強大。
而在開源領域，zabbix負責系統級，搭配插件orabbix監控資料庫執行個體，其實也不錯。
再說說監控盲點，對于下面的語句：
select ‘oracle is alive’ from dual; 如果監控執行個體是否open，是否合理？
其實dual表比較特殊，在nomount,mount,open階段都可以通路。嚴格來說是不太合理的。
11g中備庫的v$flash_recovery_area_usage的自動歸檔删除政策
11g備庫在mount階段，比較浪費。
1、asm使用空間的監控
硬體監控
當然還有很多，就不展開了。我想多說說硬體監控的重要性。
這是一個故障類型的占比圖。
可以看到硬體故障出現的機率還是非常大的。其實在很多的故障中都是一個很頭疼的問題，對于硬體故障來說，主機闆故障，記憶體故障又占有很高的比例。
這是故障影響累計時長的占比圖：
這裡有幾個地方需要說明一下。
可以看到硬體故障遙遙領先，這個4500分鐘是一個累計的值，不是一次故障的影響時間，比如有1000台機器，一台機器影響1分鐘，1000台就是1000分鐘。
這是積累了好幾年的一個數值，是以會把這個影響放大。
2、硬體故障的反思
監控次元要全
監控粒度要細
不能等待問題降臨，要直面迎擊
100多台伺服器，硬體巡檢12台有磁盤壞塊
沒有條件，不能坐以待斃，要敢于diy
db time抖動的分析，後面會講到
做曆史問題，遺留問題的終結者
我舉一個例子來說明一下監控的重要性，可能對于備庫的監控也是個盲點。
這是一台備庫的cpu使用情況，藍色的部分表示使用情況，在平時負載是很高的。
當然深入分析之後，發現有一些查詢隻在備庫上運作，在做大量的全表掃描，分析之後發現問題其實完全可以避免，建立一個相應的索引即可修複。
修複後的情況如下，可以看到cpu使用率幾乎觸底。
3、運維管理
運維管理的内容很多，我說說日常維護和一些細節問題。
（1）日常維護
使用空格的技巧：這是學到的一種專業态度，對于不熟悉，不确定的環境，黑屏時先敲一下空格，敲了回車很可能會有緻命問題。
空格的慘案：這個慘案也是聽來的，如果使用下面的指令 ifconfig –a6 vs ifconfig –a 6 就因為一個空格就會造成網絡位址瞬間修改，如果是rac,節點瞬間就會倒下。
簡單至極的維護案例：system表空間滿，如果發現表空間滿的情況，不要急于添加資料檔案，倒底是應用不規範存放資料到了system表空間還是審計日志占用了大量空間，可以參考mos得到一些專業指導，在有些版本直接清理審計日志可能會有死鎖。
（2）不可忽略的細節
既然說到這麼細了，我再多提幾個。
外部表使用exp會有奇怪的問題，還是要用expdp來做。
安裝資料庫軟體時silent模式下的參數在10g和11g中竟然有一個細小的差别。
responsefile,responsefile你看出來了嗎？
合理利用新特性
使用sql_monitor，竟然發現一條運作14天的sql語句，當然其它方式也可以做到。
少踩一些坑
drop datafile導緻的備庫bug，在10.2.0.4以前，主庫如果drop datafile，備庫的mrp會直接挂掉，這是一個bug,官方解決方案是重建備庫，當然我比較任性，其實也可以手工修複。
靈活變通，省事省力
5t資料和1m資料的靈活切換。這個我拿一個小案例來說明，生産環境需要緊急複現一個問題，這個工作通過測試生産環境來完成，但是測試生産環境已經資料有5t，而從生産環境抽取的客戶資料隻有1m。
直接導入1m的資料，很可能因為逐漸沖突而導入失敗。這個時候就可以使用閃回資料庫來實作。可以做到5t和1m資料的靈活切換。
（三）優化篇
說到優化。
不定時的性能炸彈sqlprofile：sqlprofile是一個臨時方案。有一個sqlprofile調優的語句在一年後發生了嚴重的性能問題，原因就在于裡面的資料情況發生了很大變化，導緻原油的執行計劃資源消耗太大。
臨時送出的變更4個小時的pl/sql和1分鐘的sql：之前有同僚在更新前緊急送出一個pl/sql腳本是作為資料插入，但是測試不夠充分，結果在生産執行了近4個小時，當然問題期間，我們進行了優化，其實改造成一條sql語句，insert xxxx select xxxx from xx where 一分鐘就可以搞定。
sqlldr加載性能問題的分析：有一個sqlldr加載的性能問題診斷，在各方掐架的情況下，我默默使用scp傳送一個檔案，證明了其實是網絡問題。
優化部分我舉一個案例：資料庫無法登入的診斷。
某一天收到報警說資料庫無法登入,報錯資訊如下：
報錯的原因看起來是audit的問題，其實sysdba登入會自動寫audit，當然audit區域空間占用很小。
但是問題時間段的歸檔頻率可以說明問題，橫軸是每個小時的切換頻率，縱軸是日期：
可以看到歸檔切換很頻繁，想必應用做了調整，但是我還是看了看awr報告分析了一下。發現top1的sql語句是一個update，當然看性能也沒有什麼大的問題。
語句如下：
下面的報告對比可以說明問題的原因，rows per exec有很大的差别，其實這個表隻有1萬條的資料。
是以很容易看出來，這是備援資料的問題導緻了大量的歸檔。
稍後做了對比測試：
運作3分鐘，日志切換14次（存在備援資料）
運作7分鐘，日志切換0次（删除備援資料）
（四）開發,業務篇
開發和業務對于資料庫運維非常重要，可能這個部分大家都會輕視。
定制awr,ash,addm——
這些工具其實可以簡單定制，會極大提高工作效率。
熟練掌握開發技能——
資料庫連接配接滿的原因分析：之前分析的一個資料庫連接配接滿的問題，還是在檢視開發源代碼後發現jdbc沒有正确釋放連接配接導緻，當然還是比較隐蔽的一個小問題。
熟練掌握業務——
通過業務優化sql：通過業務來優化sql其實還是非常中肯的一種方式，改進幅度最大，把技術需求轉化為業務需求。
我來舉一個分區規則，業務和技術的脫鈎的例子，可能看起來比較繞，大家耐心看一下。
之前做資料遷移的時候，有一個分區表特别慢，最後發現分區中繼資料如下：
是以說分區規則可能存在問題。發現分區規則是多鍵值的情況。
我們來看看分區規則的中繼資料情況，似乎和業務需求和吻合的。
那麼實際的資料存放情況呢。以p120_c10分區為例。可以看到資料有些亂。
多鍵值分區需要格外注意，點到為止。
（五）展望篇
對dba更高的要求，更高的挑戰
開發技能
資料架構
一專多能
新技術前沿
全棧dba
展望
自動化運維
精細化運維
這個部分看起來比較虛，但是都是我們目前在做的。比如說精細化運維，一個目前的簡單的zabbix改進就是db time的監控。其實通過這個可以發現很多的潛在問題。
調優之後的情況如下。
是以大家一起努力，辦法總比困難多。有很多人覺得平淡，其實可以再努力一下，堅持一下。借用知乎的一句話。平淡其實是很奢侈的，那意味着有許多愛你的人在為你付出。在dba+社群，在這裡，就是我們可愛的dba們。
作者介紹 楊建榮
【dba+社群】聯合發起人。
oracle ace-a、yep成員，現就職于搜狐暢遊，擁有6年以上的資料庫開發和運維經驗，曾任amdocs dba，負責亞太電信營運商的資料業務支援，擅長電信資料業務，資料庫遷移和性能調優。
擁有oracle 10g ocp，ocm，mysql ocp認證，對shell，ava有一定的功底,曾在2015年資料庫大會進行關于資料遷移和更新的主題分享，現在每天仍在孜孜不倦的進行技術分享，每天通過微信，技術部落格共享，已連續堅持700多天。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-04-01</b>