致Oracle DBA 的一封信 （網上流傳）

標籤：丟失   機房   伺服器   按鈕   線上添加   自己的   相對   簡單   處理   

1． 資料庫的可用度，DBA 說了“不算”   --物化視圖，加快查詢速度

某些時候資料庫的可用性，並不由DBA所設定。因為即使DBA對資料庫有絕對掌控權，但使用者可能從自己的工作和應用角度，與DBA的感受是不一樣的。

他們要的是速度！很簡單的道理，也許你也曾遇見。某天當你正在崗位上忙碌的時候。這時在同一時間，你的老闆正在查看公司的財報，在他的電腦裡有個應用，其中有一個按鈕，只需輕輕一點就能查看當月甚至當年的財報。當他點了一下之後，結果並沒有按他預計的時間返回，於是他拿起電話打給你，問資料庫為什麼“崩潰”了！

這讓你一頭霧水，好像他說的不是你眼前的資料庫！有時候一個全域設定良好的庫也存在這樣問題。我們遇到這樣的問題，也只有對老闆當前所用到的表進行重新的設計，也可以建立物化視圖。  

2． 對於成本，他們很在意！　　　　　　--不得不遷移，謹慎行事

有時候公司可能為了成本或是開發需要，要求更換作業系統，那原資料庫上的資料匯入新資料庫就是我們經常要做的了。公司對成本很看重！對於TB級的資料庫，Exp/imp過於老慢，dpexp/dpimp又對版本有限制，跨平台資料表空間遷移也有部分不完美的地方。選擇怎樣的資料移轉方案和是我們要謹慎的!

3.有計劃的資源分派　　　　　　　　　　--服務也有優先順序，選擇RAC

公司各部門在使用資料庫資源時可能不太均衡。有時會有很高的時間性和規律性，這需要甚為DBA的你做出相應的改變！資源的合理分配！財務年終和月底會做結算，開發測試會不週期性進入等等。這就需要以服務為優先順序，選擇分配工作負載和系統資源。RAC一個是不錯的選擇，可以把服務和RAC結合，不同的服務訪問不同的節點數。對於大業務量來說它是在恨也沒有的了。

4． 宕機和停機

有時候人力不可抗拒的因素也是需要DBA 考慮的。也許正當你在夢中的時候，值班員打來電話，公司機房漏水，伺服器全掛了。這種情況誰聽了腦袋都大。你試著打電話給系統管理員，詢問前一階段淘汰的伺服器是否可用，並且跑回公司產看，異地備份是否完好。也許這不是你的錯，但是解決不了，錯就是你的了。

這一點不用多說，群集和備庫是你最好的選擇。對於7*24這是多麼重要。尤其dg是你免除人力不可抗拒災難的最好方案！

5． 壞塊擋不住你

有時候你會被資料庫告知出現壞塊，這時RMAN 就是你最好的工具，上帝保佑你做了備份。如果你丟失了或是儲存相對地區無法使用，等待從磁帶還原是你唯一的選擇，前提你有這樣的保險機制！但如果只是使用者誤操作，閃回的使用是再好不過的了！

6． 空間不足，作用區的負載平衡

你有一個重要的資料表空間，它無時無刻不在被使用，他很大很大，大到你的儲存對應的lun 無法容納他，這時你如何處理!當然對於記錄檔我們可以去刪除它來實現。但資料檔案呢？Asm我想你會想到，他會自動平衡檔案負載和i/o分布。支援線上添加新磁碟去asm磁碟組！

7． 誤操作 DBA 的夢魘

清晨一個倒黴蛋，睡眼惺忪的坐在DB 前，作這那每日的維護工作，突然當一次不起眼的手指敲擊鍵盤發生後，他再無睡意。一次錯誤的斷行符號，刪掉了一張重要表的部分記錄。這在我們實際工作中是無數次的發生，怎麼辦！清醒地他想到了動用不完全恢複的，來挽回錯誤!但是這一切並無人看見，要是不完全恢複，意味著停機申請，領導的變身。。。。太可怕了！其實FLASHBACK 給你它機會：使用FLASHBACK 實現行級恢複.事情註定是往一起湊，當著倒黴蛋驚魂未定的時候，電話響了。電話是財務部打來的，意思是由於失誤，他對財務軟體的修改把工資表的漲工資一項誤打錯了數字，你發現自己月薪已成百萬（玩笑）。其實大家都是這麼期望的！它需要你挽救一下他的失誤！使用FLASHBACK也可以幫你快速解決問題.

8．做一個良好習慣的 DBA

有時你會發現自己的udump 下的trace檔案暴漲，多數情況他是你的馬虎所造成的，去關閉那些不必要的SQL_trace，你會永遠記得這樣的錯誤多麼致命對於一個生產庫！

致Oracle DBA 的一封信 （網上流傳）