【徵文】真實的DBA工作

 

【徵文】真實的DBA工作

 

                         作者：高陽

 

以此文獻給一起成長的朋友們！努力不一定成功，但放棄一定失敗！

 

1． 資料庫的可用度，DBA說了“不算”

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

他們要的是速度！

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

這讓你一頭霧水，好像他說的不是你眼前的資料庫！

有時候一個全域性設定良好的庫也存在這樣問題。我們遇到這樣的問題，也只有對老闆當前所用到的表進行重新的設計，也可以建立物化檢視。

 

2． 對於成本，他們很在意！

有時候公司可能為了成本或是開發需要，要求更換作業系統，那原資料庫上的資料匯入新資料庫就是我們經常要做的了。

公司對成本很看重！

對於TB級的資料庫，Exp/imp過於老慢，dpexp/dpimp又對版本有限制，跨平臺表空間遷移也有部分不完美的地方。選擇怎樣的資料遷移方案和是我們要慎重的!

 

3.有計劃的資源分配

公司各部門在使用資料庫資源時可能不太均衡。有時會有很高的時間性和規律性，這需要甚為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，你會永遠記得這樣的錯誤多麼致命對於一個生產庫！

 

 

 

 

 

2008．6．16 北京

 

 

                      

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/13427867/viewspace-351883/，如需轉載，請註明出處，否則將追究法律責任。