--Author:Leshami
shell
--Blog :http://blog.csdn.ne/leshami
數據庫
提及DBA,全稱是Database Administrator,不是Doctor of Business Administration,千萬不要誤解,那但是天壤之別!儘管如此,不少人依然認爲有着神祕的面紗,高深莫測,花環簇擁,是收入豐厚的一族人。實則否則,DBA說白了就一修理工。修理啥呢,不是車牀機牀,也不是修理啥精密儀器,修理的是數據庫,僅此而已。DBA這個行業一樣也經歷了由萌芽,發展到鼎盛的過程。尤爲是近2年海量數據的井噴以及新數據庫時代,雲數據時代,DBA 2.0時代的興起。以及最近所謂後DBA時代的說法。說到DBA的工做,咱們先得搞清當前幾類經常使用的數據庫。主要有兩大陣營,一類是SQL,學過計算機的人應該都知道,傳統數據庫,諸如Oracle,DB2,MySQL,SQL serer等主流數據庫。面對的是那些傳統行業,好比證券,銀行,電信等使用的居多。另外一類是NoSQL,諸如Hadoop,MongoDB,CouchDB等,主要用於互聯網行業,如在線社交系統,Amazon 的Dynamo等。對於當前這兩大陣營,貌似有劃江而治之勢。讓人難免眼花繚亂。究竟何去何從,應當更多或更深的思考,這是一個比較大的話題,暫且不表。本文主要描述一下傳統DBA的那些事,也就是DBA的工做範圍與職責,更多的圍繞Oracle展開。本文主要從六個方面來簡要描述DBA的工做。安全
1、數據庫的總體設計與規劃
有如建造一座豪華的宮殿同樣,宮殿還沒有動工以前,其選址,結構佈局,空間利用,方位設計等必須先有一套完整的方案。數據庫的規劃與設計一樣如此。良好的數據庫架構設計直接影響到基於該數據庫業務系統的總體性能。而這個架構設計又來源於對業務有詳盡的需求分析,從而對現實需求進行綜合、概括與抽象並造成完整的E-R圖,再由E-R圖轉換爲相應的邏輯模式(表、視圖定義等,考慮範式要求)。同時也根據業務的初期、中期及後期考慮合理的數據庫存儲規劃以及根據數據庫負載、重要程度考慮使用單實例數據庫、集羣、複製、鏡像等等高可用策略。固然,對於數據庫運行平臺環境等也是一個比較重要的選擇。大多數狀況下,數據庫的總體設計對大多數DBA而言沒有機會來接觸或實戰,尤爲是設計E-R圖以及表、視圖定義等,這部分一般都是由專業數據庫設計人員或開發人員來完成。所以本文對此也是初步描述。若是有機會參與,不要放過。性能優化
2、安裝升級、遷移部署
一、安裝數據庫。這個是最起碼的要求了。就比如那些個developer,最開始的代碼,第一句是"hello world"同樣。這個是你必須會的,要掌握的。若是是SQL server安裝部署就相對簡單,所有圖形化界面搞定,並且美觀賴看,功能也很強大,電信移動也有在用。這類數據庫容易上手,這也是Microsoft的強項之一。惟一的缺憾就是不能垮平臺。與之相比的複雜的安裝部署那就是Oracle,DB2,MySQL等這幾類數據庫了。先得把整個環境搭建好,諸如內核參數,環境變量,rmp package之類的搞定,沒得一個安裝參考手冊,有得你整。尤爲是部署生產環境,每個參數都得結合其數據環境考量規劃。這個須要必定的經驗。缺省值有時候不必定能知足現狀。儘管如此,跨平臺特性則成爲這幾類數據庫被普遍使用的重要緣由之一。管得你Windows,Linux,仍是Unix,都有對你胃口的。網絡
二、升級數據,更新patch等等也是司空見慣之事。那個Bug多的是難以數計。有道是,白天監控數據庫,夜晚挑燈戰bug。這個部分比較重要的是須要考慮更新patch等以後產生的影響以及作好回退措施。誰都難以絕對保證實地球明天照樣轉。因此得靠本身把握。架構
三、數據庫遷移。這種情形也是常見之事。隨着業務的增長,對性能要求的提升,以及更新換代,須要升級不得不實施數據庫遷移。老牛拉破車老是入不敷出,影響業務。遷移也是一個比較耗大的工程,尤爲是大型數據庫,上TB級的。好比使用導入導出,儘管操做命令同樣,但大型數據庫你得考慮的更多。諸如考慮使用並行,如何優化這個過程的性能,整一steps徹底有必要。數據庫設計
3、監控數據庫
除了合理的部署數據庫以外,透過對數據庫不一樣部分、組件的實時監控,咱們能夠及時採起補救措施以及防患於未然的策略來保障數據庫持續、穩定、健康平穩運行。所以系統監控對於DBA而言,一樣重要。下面先描述數據庫級別的監控,後描述系統級別監控。這些部分一般包括如下內容:
數據庫告警日誌的實時監控,絕大部分Oracle錯誤信息都會記錄於此。所以監控告警日誌顯得尤其重要。
數據庫實例狀態監控
數據庫監聽器的實時監控
表空間的使用率實時監控
閃回區或歸檔日誌監控(若是有使用到閃回區,歸檔主要是針對歸檔空間空間問題,如不足,如用hang住)
數據庫備份或恢復監控
無效對象的監控與處理
操做系統CPU/IO/Memory監控
對於監控工具的選擇Oracle OEM提供了完美的圖形化界面以及設定閥值來實現自動預警。固然也能夠本身編寫shell腳原本定時完成。對於SQL server一樣能夠基於GUI來完成。比較好的工具你們能夠藉助於Toad,Spotlight,Myora等優秀工具得到包括sga,pga,top SQL,instance等等更爲詳細的信息。除了實時監控以外,按期巡檢也是有必要的。這就比如機器或汽車,得進行按期的保養。這樣子能夠發現隱性的或未決的問題,以及如何改善當前數據庫。工具
4、保證數據庫完整性
不求有功,但求無過。這個對於DBA來講是最起碼的一點。不少時候咱們無心中不當心的rm,drop等等有時候會帶來災難性的後果。永遠不要有機會給上司開國際玩笑,那就是你不當心的整壞了生產數據庫,並且尚未備份,這就丟大了。所以DBA的細心,數據庫的按期備份是相當重要的。尤爲是對於那些數據庫是企業核心命脈的企業,每一步操做都儘量思前想後。對於數據庫的備份方式有多種多樣,並且有諸多第三方備份方式。即使如此,每種數據庫自帶的備份方式是必需要掌握的。對於SQL server而言,自帶的圖形化備份設計基本上能夠知足絕大多數需求。須要搞清數據庫的恢復模式以及全備,增量等方式,固然掌握bcp命令也是頗有必要的。對於Oracle,datapump,冷備,熱備,rman備份幾種最好都所有掌握,多多益善。數據庫的備份策略主要依賴於對數據丟失的容忍度來決定。也就是說合理的備份策略基於數據庫恢復所須要的全部相關的東東。所以備份策略應具體情形具體分析。按期的監控數據庫的備份以及作災備測試等來確保數據庫的備份與恢復是完整無誤的。oop
5、性能優化與調整
業務運行緩慢,客戶抱怨不斷。這是DBA們常常頭疼的問題。儘管總體性能並不徹底取決於數據庫,但數據庫仍然是相當重要的一環。並且性能的問題從整個業務需求分析,數據庫架構設計的那一刻起直至數據庫生命週期的終結。尤爲是隨着業務量的不斷增長致使的性能問題日漸顯現並表現的異常突出。正所以,對於一個優秀的DBA來說,僅僅從數據庫層面來把控性能是遠遠不夠的;對存儲,操做系統,網絡,業務的瞭解與掌握才能對性能調整作到有的放矢,應用自如。深圳有句展示特區精神的口號,時間就是金錢,效率就是生命。一樣適用於在線交易數據庫系統。下面僅僅從數據庫層面來談談性能調整與優化涉及到的方面。
操做系統內核參數優化與調整
基於不一樣的特性使用raid部署不一樣類型文件
分開存儲數據和索引文件以及均衡I/O
調整數據庫以及實例級別初始化參數
使用分區表處理海量數據以及滑動窗口歸檔
消除行連接與行遷移
使用索引、提示或物化視圖調整SQL訪問負載
調整優化器統計信息
經過調整PL/SQL以提供性能
使用並行技術提升性能佈局
6、Troubleshooting
天有不測風雲,人有旦夕禍福。數據庫運行的過程當中總不免出現這樣或那樣的問題。一是因爲數據庫軟件及運行環境等產生的各類bug或隱性問題,二是人爲的問題一般也不在少數。所以,如何快速定位並解決這些問題也是衡量一個DBA水平的重要指標。處理這些棘手的問題,須要DBA有大量的知識和經驗的積累。尤爲是對數據庫理論以及數據庫體系結構應該有較深入的認識,把握其本體,何愁不能應用自如呢?在這裏只說明Troubleshooting是DBA常常面對的問題,並未描述如何Troubleshooting。下面列出幾類較爲較爲常見的須要Troubleshooting的問題。
告警日誌中的異常處理
監聽器相關的異常處理
數據庫備份恢復期間的異常處理
Oracle job運行異常的處理
數據庫突發的異常處理,如數據庫hang,某個時間段性能低下
集羣管理中的異常處理
DataGuard數據庫日誌傳送,恢復等異常處理
用戶報告的異常處理
數據庫安全的異常處理
上面主要從6個方面簡要的描述了DBA的工做及其職責範圍,固然還有更多的細小的問題在此再也不贅述。 總之DBA的工做也很繁瑣,須要沉着冷靜應對,三思然後行,儘量地從總體出發,從全局出發來考慮問題。