藍的成長記——追逐DBA（2）：安裝！安裝！久違的記憶，引起我對DBA的重新認知，dba久違

藍的成長記——追逐DBA（2）：安裝！安裝！久違的記憶，引起我對DBA的重新認知，dba久違
藍的成長記——追逐DBA（2）：安裝！安裝！久違的記憶，引起我對DBA的重新認知

***************************************聲明***************************************

        個人在oracle路上的成長記錄，其中以藍自喻，分享成長中的情感、眼界與技術的變化與成長。敏感資訊均以英文形式代替，不會泄露任何企業機密，純為技術分享。

        創作靈感源於對自己的自省和記錄。若能對剛剛起步的庫友起到些許的協助或共鳴，欣慰不已。

        歡迎拍磚，如有關技術細節表述有錯誤之處，請您留言或郵件（hyldba@163.com）指明，不勝感激。

***********************************************************************************

謙遜的心，低調的生活，需要學習的地方還有太多、太多。

                                                                                                              ——深藍

***************************************前言***************************************

        這是一部個人記錄的成長雜記，既然步入到oracle的這片藍海，免不了一路的奔波與不斷的考驗。藉由此雜記與庫友們分享藍的成長曆程。

        不知何時起對藍有了一種說不出來的癡迷，癡迷其廣博，癡迷其深邃，癡迷於近在咫尺卻又遙不可及。

        而又說不清從何時起，注視於oracle的紅色耀眼，照亮出眼前的一道光，未知與迷惑在自己的腳下開始初露些許人生的充實與青春的回饋。

        在追逐於DBA夢想的道路上步步前行。

***********************************************************************************

8月3日 威海

        時光荏苒間，已經想不起正兒八經看著文檔裝資料庫是什麼時候了，感覺過了好久。尤其單一實例的DB，即使做實驗也習慣了直接導個鏡像拿來就用。而迴歸到實際工作的時候，有些之前不再意的事情，就是擺在眼前的“飯票來源”。還記得之前看過一本書上說的，作為DBA，安裝這檔子事是很少碰見的，碰見的話也會交給什麼第三方、什麼經驗人士去設計之類云云。。。當初我的看法也是如此，雖然是裝過，但那都可以說的上是塵封的記憶了，但擺在眼前的情況是需要用最快的時間把這一切再想起來，這就是眼下的工作，刻不容緩。

        糾結於報錯，問題原因竟如此可笑。

        問題出現在安裝oracle軟體的過程中，進度條到86%時報錯了，如：

        通過報錯現象，我第一直覺的反應就是某個包沒有打上。巧合的是就在昨天練習RAC時，出現了同樣的問題，當時我也判斷為包安裝不全，但也沒查到是哪個包沒有裝上。在單一實例下也出現了這種情況。我開始感覺到似乎是我的思路跑偏了。

這才猛的想起，這個報錯現象在今年年初的時候似乎在哪裡看到過。突然想起來了，這很有可能是因為oracle與作業系統版本不匹配造成的。

        因為這次使用的是CentOS5.6，為64位的作業系統，而之前習慣於用32位的資料庫版本做實驗。這才想到就在昨天RAC安裝時記錄的過程文檔時查了一遍又一遍也沒找到實質性的錯誤，沒想到由單一實例給了靈感，錯誤就是這麼的簡單。資料庫與系統版本不匹配。於是經過些周折在OTN上download了一個64位的Linux版本資料庫軟體。而這次單一實例報錯，嘗試驗擊continue，讓其繼續安裝。之後又彈出幾個類似報錯，均點擊continue讓其繼續。這次全當是實驗一把在系統版本與資料庫版本不匹配的情況下安裝會出現什麼情況（64位作業系統安裝32位的oracle軟體）。但讓我沒想到的是，接連的幾個報錯之後，點擊繼續後，軟體竟然成功裝上了，而且dbca建庫、建監聽完全正常。看來需要時間的考驗了，相容性可能會在不久之後由某個問題而暴漏。測試環境下測試著玩了。

        下載完64位的oracle軟體後，重新對其安裝，果然不出所料，順利的安裝，完全沒有報錯。這次小不順，問題就是出在細節上，這裡引以為戒，切記，系統與資料庫版本、位元要匹配。

        讓安裝摺騰了好一會兒，突然間想談談什麼是DBA了，雖然眼下的安裝只是DBA的一小小的要求之一（甚至可以說很不重要，但還是想說說）。

        一提到這，就免不了對未來走向重新梳理，擺正態度。而且對於當今DBA的需求，又勾起了我的話嘮，想多說些什麼，說給自己，也說給剛剛選擇資料庫這行的人吧。

        聽來眾多5、6年前8i、9i的時代裡，DBA一詞在外界看來還是個比較神秘，比較高大上的職位。那時候對於DBA的瞭解與認知遠沒有當今被眾多的人們所瞭解更談不上是熟知，可以說那個時候的DBA是個待遇與地位相當不錯的職位。當初的ocp、ocm認證也遠比今天含金量更高更能體現價值。好在oracle也發現了這一點，提升了11gocp的認證難度，我想甲骨文也不想看到ocp認證爛大街的尷尬局面。但凡事都有兩面性，當初對DBA的要求雖沒有像當今這樣要求更加龐雜的知識儲配，但那時的壓力在我看來可以說是更大的。這是為什麼呢？隨著oracle的不斷髮展、版本不斷的革新和升級，使得操作化更加智能、功能性更加強大、目標工具的選擇性也更加多元化。舉個例子就能明顯的體會到，在當時，對於一個DBA來說，編寫SHELL指令碼是必須具備的能力，即使搭建rac都需要自己來編寫指令碼。看看現在，無論是網路還是書籍材料，資源都太多了。甚至於有些DBA已經習慣於“拿來主義”，找到差不多的指令碼，稍作修改，就成為自己的勞動成果了。這可能也更加說明當今含金量降低的原因。但曆史總是拿來明鑒的，我們還是更多的是要立足於當今，更多的看向未來。畢竟時代和科技需要不斷的發展、進化和提升，正才是人類IT發展的趨勢。這樣人類文明才能進步。想想看，倘若有一天DBA全都失業了，科技智能將會是達到了什麼的樣的高度，我們抽離出去，是不是應該有更多的喜悅才對呢。

        扯的遠了，再把話題扯回來吧。看看在當今雲時代被炒得沸沸揚揚的時代裡，DBA應該怎麼定位。對於漫天飛來的雲資料、大資料概念，很多時候都有些無可奈何。我最早瞭解到這個概念的時候應該是在07、08年的時候吧，那時候還在上學，當時覺得這門技術是個高大上、含金量超高，是個非常牛x的行業，所以最後還是決定走硬體的專業道路，對資料庫的行業不敢奢望。之後瞭解一些才發現，媒體的噓頭炒作下，更多的跟隨著國外有關“雲概念”理論性的發展，這之後，國內才開始效仿甚至於愈演愈熱的理論炒作、抄襲浪潮。轉眼6、7年過去了，好像這個“大資料”終於有些起步的表現了。資源重新分配，虛擬化的快速發展同時也很大程度上推動了大資料的進步，Vmware公司成為2013年全球前十大軟體公司，就可見一斑，再來看hadoop、nosql資料庫被捧得極熱。甲骨文當然也不甘人後，在收購SUN之後就可以遇見拉裡的野心有多大，12C的問世，可以說的上是正式開始邁進大資料的第一步。眾多諸強開始秣兵厲馬，蓄勢待發的要強佔“雲端”這塊看似“輕飄飄”卻“肥的流油”的“未來”。而對於DBA呢，在這個時代裡，想引用梁敬斌的一句話：“這是最壞的時代，同時也是最好的時代”。面對各行、各業對於資料的重新認識和應用，資料庫相關人員的角色或是更加明確或是更加模糊。

        分開幾方面來表述的話：

1、作為資料庫開發，在未來市場需求將會爆髮式增長，側重於邏輯與業務，加班加點，作為開發人員應該是最習以為常的事了；

2、作為管理型DBA，抗壓能力將是必備的能力，作為DBA應了那句話，“養兵千日用兵一時”，風平浪靜下體現不出真正的價值，而往往是在重大災難面前，這就是DBA需要挺身而出的時候，為企業扭轉乾坤由死轉生。這也是為什麼，在很多公司裡，老闆把DBA當成超人的原因。在它們看來，DBA是個什麼都會做的神，出了問題第一個想到就是DBA。而實際中，往往因素要比預見的更加複雜；

3、作為最佳化方向，正是在行業裡誰都講不清屢不清的一種情結。在我看來，判別一個DBA的標準正是要看最佳化的能力。一個不能做最佳化的DBA就稱不上是DBA。同時還有一個比較尷尬的局面，就是智能化、自動化的最佳化軟體大力開發，對於資料庫的最佳化可能會在一段時間之後，由軟體所取代，Oracle的EM這是這種趨勢（注釋：圖形化佔用資源大，往往老的應用系統都不允許使用圖形化介面，這也在一定程度上限定了EM的普及），人們只需要學會使用工具軟體就好，而底層產生的原因或許即使你不知道也沒關係。但這隻是設想，都期望可以這樣，但同時同不願看到這一幕。換個角度去看，如果真到了那一天，如果我們可以找到其它的增長點或新的技術領域，就可以消除所有DBA的擔憂，畢竟還要混口飯吃。

4、資料庫設計，這是個要求最高的水平，是要建立在之前幾個水平的情況下發展而來的。但同時這要深刻的理解業務需求、資料庫原理、模型的建立、設計出所需要的索引、對象。這是以後技術水平發展的根基。

        這些要是引開說還有太多了，在此對於初學者我推薦一本書，可以讀讀看：梁敬斌的《收穫，不止oracle》，這是我當時購買的第一本有關oracle的書籍，從中，無論是知識還是思維方式，收益匪淺。

        話題再轉吧，談談我對於當今DBA技能的認識，我喜歡用兩個詞來形容：

1、DNS：Database+Network+Storage；（注意這裡的DNS可不是網域名稱解析系統噢，親！）

2、SPSM：SQL+PL/SQL+System+Middleware；（同樣，這裡SPSM不是物理中的概念）

        不言自明了，當今對於DBA的技能要求越來越多源化，如果你想成為一個管理型DBA就需要掌握資料庫的原理、知識其中涵蓋有備份、恢複、調優、RAC、DG、GG等等諸多方面。而且對於網路和儲存知識也需要掌握一些，這在前期實施搭建、後期排除故障都是很有助益的。

        另外，我剛剛進到行業內時間不長，以我的視角看來，對於DBA而言，熟練掌握SQL是基本，這個在工作中不斷的使用的話，便會加強記憶，或者有意的背些指令我覺得也是很需要的。再就是PL/SQL的編寫，很多人認為作為DBA無需掌握指令碼的編寫能力，我對此並不贊同，雖然目前個人能力很有限，對於指令碼編寫很吃力，畢竟並不是寫代碼出身，對於很多邏輯的理解或是調用什麼的還覺得很吃力。但我堅持認為這項能力將對一個DBA來說有著莫大的助益，當掌握了PL/SQL以後對預存程序、包、函數理解和使用會完全不同，再者在調優的工作中，SQL調優會佔據相當大的比重，有甚者有些調優項目針對的就只有SQL語句。還有管理資料庫時，對某些功能的監控也是我們工作中需要做的，這裡就要用到寫SHELL能力了，如果所在的公司想要最大化的削減成本來達到監控的效果，由DBA來編寫一些監控指令碼是很尋常的事。即使使用一些監視軟體，如果你懂PL/SQL，你也會發現理解程度是不一樣的。所以，我說這麼多，就是想強調，擁有PL/SQL的能力，會為職業生涯和穩定度帶來不小的助力。有這麼一個觀點：“在很多方面，要求DBA會修改指令碼來完成自己的目的就行”，這個確實是被認可的。然而這種觀點一定程度上誤導了很多人，以為作為DBA只需會修改指令碼就OK了，這往往是一個誤區，見到過很多DBA最初都是自己寫些簡單的指令碼，基礎紮實後才在業務層面修改指令碼為己所有，最後達到遊刃有餘的地步。而那些從最初就只秉持著修改就好觀點的人，到最後很少有能修改指令碼為己所用的，這裡分享出來，供大家參考吧。

        再來說說系統吧，當今資料庫主流的運行平台都是在Linux或Unix下的，所以說想要玩好DB對於系統的操作就需要不斷練習，熟練是會給解決DB問題帶來很多的便利。我這裡接觸過幾個作業系統，其中就有如Solaris、紅帽Linux、CentOS、Suse、Ubuntu還有小機的AIX、HPUNIX等等，最初接觸的時候感覺很費力，時間久了，常用的命令就是那些而且不同的unix和linux系統之間都有著很多相近的地方，雖說目前對於指令的掌握很多還需要查查手冊才能確定，但對其理解看來，作業系統就如同我們平時玩遊戲的windows平台一樣，要慢慢的學著熟悉它、掌握它、精通它。而且不只是對於系統，協調在應用程式層面的中介軟體也是需要掌握的技能之一，關於中介軟體本人知知甚少，還在慢慢學習中，此處就不過多發表個人意見了。

 

***************************************未完待續***************************************

歡迎訪問：深藍的Blog：http://blog.csdn.net/huangyanlong

*****************************************************************************************