【挨踢人物傳】Vage：高級DBA的突破之路（第13期）

原文首發原創與51CTO技術論壇：http://bbs.51cto.com/thread-1085647-1.html

【編者有話】
本期的嘉賓呂海波是Oracle技術方面的資深專家，也是我所見到的少數的有人文氣息的IT人。爲了突破高級DBA的瓶頸，他毅然離開了深有感情的阿里。離職是爲了更好的突破？來看看海波老師的突破歷程吧——

【本期人物檔案】

個人信息：

51CTO賬號：Vage

姓名：呂海波

性別：男

所在地：北京

教育信息：職專

關鍵詞：調試 Oracle 倡導者 DTrace/mdb/gdb調試 Oracle 技術推廣者

職業信息：
從業時間：十七年

行業：電商
關注技術：Oracle數據庫/調試技術/雲存儲技術

【Vage的聯繫方式】

51CTO家園：http://home.51cto.com/index.php?s=/space/1001806

新浪微博：文本時代_VAGE

博客地址：http://winda.blog.51cto.com/

郵箱地址:mythdata#hotmail.com

【Vage是這樣的人】

Vage：高級DBA的突破之路

有一個笑話，創世第一天，上帝創造了驢。上帝對驢說：“今天我創造了你！作爲一頭驢，你必須跟終日拉磨，任勞任願。我給你50年的壽命。”
驢不同意：“什麼？這種苦日子你要我活50年？讓我活20年吧，30年還給你。”
上帝同意了。
第二天，上帝創造了猴子。上帝對猴子說：“你必須帶給人們娛樂。你必須讓他們開懷大笑，耍把戲。我給你20年壽命。”
猴子不幹：“什麼？讓他們開懷大笑？做鬼臉耍把戲？10年就夠了，另外10年還給你。”
上帝同意了。
第三天，上帝創造了狗。上帝對狗說：“你應該終日坐在自家門口，有人進來就叫！我給你則20年壽命。”
狗反對：“什麼？整天坐在門口？絕對不行！我退給你10年壽命！”於是上帝同意了。
第四天，上帝創造了人。
上帝對人說：“你的工作就是吃喝玩樂睡大覺，盡情享受人生。只管享受，什麼都不幹。這種生活，我給你20年壽命。”
人反對說：“什麼？這樣的好日子！除了吃喝玩樂，什麼都不幹。盡情享受，而你讓我只活20年？不行，老兄！我們何不做個交易？既然驢退給你30年，狗還你10年，猴子退回10年，你把這些統統給我！這樣我的壽命就有70年了。行嗎？”
上帝同意了。
這就是爲什麼頭20年，我們吃喝玩樂，盡情享受，無所事事。接下來的30年，我們終日像驢一樣辛苦工作，養家餬口。之後的10年，我們像猴子一樣扮鬼臉耍把戲讓孫輩開心。最後10年，我們像狗一樣呆在家裏，坐在門口，對人大叫。

雖是笑話，但成年後的人生，也的確如此。像驢一樣工作，像猴子一樣被人耍，……。就算是逍遙自在的頭20年，《這個殺手不太冷》中瑪蒂爾達和萊昂的對話，也讓人絕望：
瑪蒂爾達：是不是人生總是如此艱難，還是隻有童年如此？萊昂：總是如此

做人苦，做中國人更苦，做中國的IT人則苦上加苦。前段日了不是有則新聞嗎，一美帝程序員將自己的工作包給幾名中國程序員完成，自己每天就是享受生活。支付幾名中國程序員薪水後，美帝程序員自己的工資還剩一大部分，足夠優哉優哉的過日子。這則消息真是讓國內程序員苦哈哈們淚奔。

反差大的又何止程序員們，DBA也是如此。我經常觀注一美帝DBA的BLOG，他BLOG有一段時間沒更新。後來又開始更新，貼出了一些照片，原來是去愛琴海享受了十來天的陽光、白色沙灘、藍海、……。我們的假期沒有藍海，只有人海。我的生活沒有愛琴海，只有房貸。真是少壯不努力，至今在內地啊。

但其實很多朋友都知道，比起生活上的苦，還有一種苦更難以名狀，就是找不到前進的方向。

我們似乎身處在一片濃濃的霧mai中，雖然想努力“自強不吸”，但遺憾的是我們不知道哪裏是前、哪裏是後。穿越霧mai區的過程，是人生最爲艱辛的過程。你需要在不知道結果的情況下，朝向一個未知的方向前進。前方有可能是掌聲和鮮花，也可能是絕壁斷涯。

做爲在霧mai中行走多年的“行客”，今天和大家分享下Oracle DBA這條艱苦曲折之路，特別現在有很多朋友都被困擾的問題：“高級DBA如何突破”。

DBA的特點，是“入行難、突破難”。

先說入行難。由於直接負責企業最重要的資產：數據，因此，所有公司對DBA的要求都有一條：經驗。沒有公司肯把數據庫交給沒有經驗的DBA。評價初、中、高級DBA的重要一點就是經驗多少。

沒有經驗的DBA想找到工作，是很難的。這間接催進了DBA培訓行業的繁榮。通常從事培訓工作的講師，都是有一定經驗的。通過講師介紹，可以學到一些書本中沒有的經驗類東西。但其實如今網絡如此發達，只要有心，自己在網絡中找，也是能找到很多富含經驗的技術文章。只不過純靠自己找資料、自己學，會慢一些而已。

能跨入了DBA的門檻後，一般成長都會很迅速。因爲Oracle相關知識還是比較簡單的。一般快則一、兩年，慢則兩、三年，差不多就是中級DBA了。是否再往下前進就看個人意願了。如果有意研究技術，靜下心來將Oracle的原理研究一下，再有個兩年左右，差不多就是高級DBA了。這時，很多人的瓶徑就到了。有希望轉管理的人，紛紛轉管理。沒希望轉管理的呢，這時會極度迷茫，因爲已經到頂了。隨着時間累積，經驗越來越豐富，但總是無法突破，無法達到更高層次。這樣再過個幾年，就是經驗更豐富的高級DBA。再過幾年，就是經驗更更豐富的高級DBA。說到底，其實還是普通DBA。

我曾經在這一階段迷茫很久，各種Oracle原理，能分析的都分析了。但Oracle又沒有開源，很多原理，只能霧裏看花的研究一下。大部分時候對調優、排故意義不大。這時，就遇到DBA行業的第二難：“突破難”。

不突破，將一直是普通DBA，即使是“高級”，也還是普通的DBA。很多等待事件，很多資料，無法完全搞清楚其意義。只能被動的等待網絡上幾個國外大牛寫些文章。但我們自己去研究的話，又始終摸不着頭腦。

舉個簡單的例子，比如關於向客戶端發送信息的等待事件有兩個：SQL*Net message to client和SQL*Net more data to client。按照文檔中的解釋，SQL*Net message to client等待事件說明了：The server is performing another send to the client. The previous operation was also a send to the client，翻譯過來就是服務器進程正在完成另外的到客戶端的發送，之前的操作將總是被髮送到客戶端。SQL*Net more data to client的解釋是：The server process is sending more data/messages to the client. The previous operation to the client was also a send。服務器進程正在發送更多的數據/消息到客戶端，之前的操作將總是被髮送到客戶端。

按照這個解釋，SQL*Net more data to client是發送的數據太多了，是這樣不是呢？我做了一個測試。我建了一張小表，只有100行，全表掃描它，觀察SQL*Net message to client和SQL*Net more data to client哪個會出現。結果當然是SQL*Net message to client。表不夠大嗎，當然不會有“More Data”。接下來，我將表的行數擴大到10萬、100萬、1000萬、1億。最後表的大小都上G了，還是沒有“more data”等待。要多大的表，纔會有SQL*Net more data to client等待事件呢？我沒有測試出來。

DBA都知道，10046事件是Oracle提供的研究Oracle的利器，接下來，可以用10046跟蹤一下。我當時作過這樣的跟蹤，但很遺憾，在跟蹤結果中，無法找到SQL*Net message to client、SQL*Net more data to client的進一步思路。

我在網上也瞭解了一下這兩個等待事件，大家的說法都含含呼呼。這也很正常，大家對這兩個等待事件的理解都是來自於文檔，文檔中如此含呼，自然也就造成大家的理解各不相同、不太統一的情況。我在網上好一番查找，終於發現有人不知道根據從哪裏搞來的資料，說“More Data”等待事件和SQL中Select語句的Fetch有關，然後就沒了。根據這點資料猜想一下，應該是抓取的行太多了，就會有這個等待事件吧。在網上又一番查找，也沒找到更進一步的資料，也只能放棄了。

其實很多時候，DBA有點像“考據”學家了。要在網上找各種各樣的資料。

考據學，就是埋首於故紙堆中，查閱各種經、史、子、集，論證著如秦始皇真是呂不韋后人嗎之類的問題。由於大家所參考的史料有不同，因此某些問題常常分成幾派，各執一詞。DBA也是一樣，我在由中級DBA到高級DBA的過程中，查看了大量的英文資料。但有些資料的說法相互矛盾，比如說“檢查點系列問題”。包括增量檢查點什麼時候觸發、日誌切換是什麼檢查點，這類問題吵來吵去，從無定論。

這使我想起一個有關程序員的笑話。程序員請女神吃飯，女神說：“只要你能讓論壇裏大家都吵起來，我就和你去吃飯”。程序員略加思索，說：“這好辦，你等着看。”說着程序員在論壇上發一帖子：“Python好還是Perl好”。一時之間，大家各抒己見，看法各不相同。很快討論就變成爭吵，論壇鬧翻了天。女神一看，說：“不錯，你真行，我們去吃飯吧。”程序員回答：“等等，我要讓他們相信，還是Python更好”。

這個笑話也可以換成Oracle的，“增量檢查點如何被觸發”之類的話題，從來都能引起一番爭論。

和考據學一樣，史料的來源，有正史、野史。Oracle資料的來源，也分等級。通常Oracle內部資料爲上品，非內部資料爲下品。英文資料爲上品，中文資料爲下品。英文的、Oracle內部的資料，絕對是上品中的上品。在爭論問題的時候，能拋出一小段英文，註明這是Oracle內部資料。絕對的權威。

實事上，好奇之心人皆有之。人都有求知慾的，對於自己想不明白的問題，如果有個地方可以告訴自己答案，就算這個答案有時候也比較朦朧，但總比沒有答案好。相信我們都會有過疑問，這個世界、宇宙是從何而來，最早的答案是上帝、盤古他們創造的。這個答案在很長一段時期內，給了很多人以心靈的安慰。當人們仰望無盡的星空時，彷彿看到慈愛的天父在注視我們。當求知慾轉變成信仰，這個時候就不要再挑戰他了。因爲他維護的不是知識本身，而是他的心靈。

言歸正傳，對這兩個等待事件的研究，就到此爲止了，雖然我始終沒有測試出來“More Data”的等待事件，但我也總算找到了答案，原來“More Data”是Fetch階段的等待事件，應該是“抓取”數據太多時，會出現這一等待事件。這應該只能在一些大型企業較大規模的數據庫上才能看到，所以我模擬不出來。我原來在阿里的數據庫中，的確看到不少這個等待事件。看，有時候找到答案就是這麼簡單。

但是，這樣的“考據”，對實際調優、排故有幫助嗎？答案當然是，沒有。

原理的研究，不能停留在“引經據典”，一定要自己驗證、測試。但遺憾的是，Oracle的有些地方，運行的十分迅速，比如Latch、Mutex方面。相關這兩點的測試，非常不容易做，因爲它們的獲得、釋放太快了。

因此，很長一段時期內，我同意一種說法，Oracle內部原理的研究，意義不大。只有一點意義，單純的“考據”沒有意義，通過自己設計實驗，驗證結論，這個過程可以讓我們熟悉Oracle的各個方面，可以讓我們儘快成長爲高級DBA。

高級DBA是如何煉成的，很簡單，考據+驗證，再加上從業5、6年的經驗，基本就是高級DBA了。如果只有5、6年經驗，沒經歷過“考據+驗證”的洗禮，稱不上高級，也就只是經驗豐富的DBA。而且現在隨着DBA的普及，從業5、6年的DBA已經很多了。如果在2005、06哪幾年，如果誰說有5年專職DBA經驗，大家都要敬仰一下。現在，已經很多了。所以只是從業時間長已經越來越沒有優勢了。

我在高級DBA階段，停留了很久。應該說到阿里之前，就已經是高級了。因爲當時我已經可以解析部分Redo文件格式，對內部原理的“考據+驗證”，已經做了很多。到加入阿里的時候，也正好有5年經驗。十分符合“考據+驗證+經驗”，因此阿里也給了我高級數據庫專家的Title。擁有高級專家頭銜的在當年整個集團的技術人員中也就幾十人，這也算是對我之前努力的認可。

但在這之後，我遇到了DBA的另一大難題：突破難。到阿里之後我一直沒有進步。一直停留在高級階段，無法前進。這就是我前面說的“突破難”。如果你不突破，很難在技術職業上到達另一高峯，這時候你面前的路只有一條，做管理。但現階段的我並不適合管理，其實並非每一個人都適合做管理。起碼以我目前的年齡、心態，還不太適合做管理。一旦加入管理團隊，個人技術成長基本宣告停滯。進入管理角色，你能做出多大的成績，很大程度上取決於你之前的技術水平。技術，是管理的地基（除非是很有管理者天賦的管理型人才）。我還不想在地基很薄的時候，就匆匆在薄薄的地基上蓋樓。以後我也會轉去做管理，但不是現在。所以，我要先“突破高級DBA”。

爲什麼DBA達到高級會“突破難”呢？想一想其實是很簡單，就兩個字：認可。IT業內對DBA的評價是有頂的。做程序員，只要牛B，可以做到Linus，開發個Linux造福人類。程序員，是沒頂的行業。或者說有頂，不過這個頂太高了。而DBA不同，DBA不從事創造性行業。運維，而且是運維別人已經開發好的程序。就算你的運維技術登峯造極，在開發Oracle的程序員面前，不還是擡不起頭來嗎。DBA是有頂的，而且頂不高。從事DBA後少則5、6年，一定會到頂。

我一直相信，有些事是看機緣的。佛家所謂“緣起”，就是對小概率、巧和事件的另一種說法。我的突破，就是一件巧合事件。突破之後，我慢慢發現，在高級DBA之後，還有兩個層次。

我的突破，“緣起”就是阿里搞了套GreenPulm系統，這是一種基於PostGre SQL的分佈式數據庫系統。由於是最初是SUN搞的，所以最早GreenPulm是裝在Solaris系統上。公司的GreenPulm需要維護，由於阿里去Oracle運動如火如荼，我也要選擇一個非Oracle方向的技術，我就選擇了GreenPulm。我是從Solaris開始入手的，因爲要先學Solaris的維護，然後才能維護GreenPulm。我買了一本《Solaris紅寶書》開始啃，啃的很無趣。不過，我在Solaris中，發現一個特性，叫“動態跟蹤語言”，也就是DTrace。這玩意非常強大，它基本上能跟蹤一切。而且，在Solaris下的Oracle，和在Linux、AIX下等等其他系統下的Oracle，運行原理是一樣的。如果在Solaris下裝個Oracle，再用DTrace跟蹤，不知道能不能有所突破。

發現這東西之後，我基本上停止接手GreenPulm的維護。一門心思的開始研究用DTrace跟蹤Oracle。果然，收穫很大。我研究了大半年這玩意，比如前面所說的例子：SQL*Net message to client和SQL*Net more data to client的意義。使用DTrace跟蹤，將非常容易發現它們的祕密。

Oracle邏輯讀其實就是調用memcpy函數，將數據從Buffer Cache中拷貝到PGA中。再從PGA中通過網絡傳送到客戶端。用DTrace的PID類探針跟蹤邏輯讀Oracle都調了什麼函數。在跟蹤結果中可以發現，每次SQL*Net message to client事件發生，向客戶端發送數據的量大小，有一個上限。

大概過程是這樣的，先要用DTrace挖掘出Oracle註冊等待事件的函數，這樣不必查詢視圖，在DTrace的跟蹤結果中，就可以知道在哪段代碼之後發生的等待事件是什麼。比如數據到PGA開始用網絡傳輸之後，Oracle就註冊了SQL*Net message to client等待事件。

數據拷貝到PGA中後，一定會佔一塊內存。一次拷貝多少數據，是受set arraysize控制的。我不斷嘗試新的arraysize值，統計memcpy函數拷貝的數據量。發現隨着arraysize增大，Oracle只會在PGA中最分配8K內存，絕對不會超過這個數字。而當arraysize很大，一次邏輯讀的數據量超過8K時，就會出現SQL*Net more data from client等待事件。

比如說，arraysize設爲很高的值，一次邏輯讀要讀10K數據。Oracle先memcpy 8K數據到PGA中，通過網絡發送到客戶端，這時等待事件是SQL*Net more data from client，邏輯讀並沒有結束。然後Oracle再memcpy 2K數據到PGA中，再通過網絡發送到客戶端，這次的等待事件就是SQL*Net message to client，不再是“More Data”，這時一次邏輯讀才結束。

這就是SQL*Net message to client和SQL*Net more data to client的區別。

下面，問題是，明白了這些有什麼用呢？這和普通高級DBA“考據+測試”所得出的結論，雖有不同，但同樣沒有意義。

當然不是的，如果單純只是無意義的“屠龍之術”，只爲了裝裝門面，確實是沒有意義的。但使用“動態跟蹤”DTrace進行的深入研究，並非沒有意義。以這個例子爲例，有兩點實際意義：
1、當發生SQL*Net more data to client時，說明一次邏輯讀的數據量要兩次網絡傳輸。而邏輯讀期間，Oracle會一直持有Buffer Pin鎖。也就是說，Buffer Pin鎖的持有時間要包含一次網絡傳輸。在網絡稍差的環境中，這會導致Buffer Pin鎖持有時間過長，加重系統CPU的負擔。

2、PGA中滿8K就發送一次數據。這個8K是固定的嗎？還是可以調的。如果可以調的大些，不但可以減少Oracle和網絡的交互次數，還可以減少SQL*Net more data from client的次數，這都對減少系統CPU負載有幫助。有了8K這個默認數字，在Oracle官方文檔中搜索，又發現一個含含乎乎的參數，Session Data Unit，簡稱SDU。這個參數可以在sqlnet.ora、tnsnames.ora或監聽配置文件中設置。你可以在文檔中搜索SDU的介紹，保證你可以看懂、但不知道這玩意是幹什麼用的。它就是用來設置邏輯讀在PGA的緩存大小的。

其實簡單點說，當你的數據庫中SQL*Net more data to client等待事件比較多時，調大SDU，可以有效的降低CPU的負載。但這對網絡的要求會更高。

這就是DTrace跟蹤出的結果。我用DTrace跟蹤出的結果有很多，當然，單純的DTrace，有時間會顯得力不從心。這時候調試工具gdb就上場了。後來升級到Oracle 11GR2後，在Solaris下只有64位版本的11GR2，Solaris下64位的gdb我一直沒裝成功，所以後來我改用mdb了。

gdb/mdb的作用，在研究Latch、Mutex時最明顯。gdb/mdb可以在代碼的任意地方設置斷點，讓運行的如脫繮野馬般的Oracle，停在我們想讓它停的地方。

還有，這兩年來我把CPU、彙編方面的知識又補了補。今年春節，我開始閱讀Oracle部分重點代碼的反彙編。比如Mutex的、邏輯讀的。

使用DTrace、gdb/mdb這類調試工具，很多人擔心會對觀察對象有影響。影響肯定是有的，量子物理中人類的一瞥，不是還可以影響量子的行爲嗎，我們去調試Oracle進程，一定會對被調試進程有影響的。不過，優秀的調試工具，能將影響降到最低。Solaris下的DTrace和mdb在這方面做的要好一些，對調試對象基本沒有影響。Linux也正在慢慢趕上，gdb的低層Ptrace對進程影響稍大，不過這是以前了，Linux內核不斷在進步，調試、動態跟蹤技術也不斷在進步。後來又有了PTrace Over Utrace，Utrace對進程的影響已經大大縮小。現在已經是最新的uprobes了，調試跟蹤的性能、對進程的影響，已經非常小了。

我們都知道許多昆蟲都有的一種生長方式：蛹-->成蟲。蛹的階段，是初級階段。從蛹到成蟲，是一種飛越式的進化。蛹只能在泥土中鑽來鑽去，而多數成蟲則能跳、能飛。這種飛越也是有代價的，成語有“破繭成蝶”。扔掉過去、打破自己的天花板，向更高級進化。將近一年的DTrace、gdb/mdb研究，使我在阿里的職業生涯走到了盡頭。幾次季度KPI考評，我都沒有完成要求，GreenPulm維護工作無法勝任。這段時間是痛苦的，一方面我感覺到技術方面自己成長很快，快要實現我的目標：“突破高級DBA”。另一方面，考評如此之差，也讓自己背付了巨大的壓力。我想，是到了要告別的時候，阿里也是這麼想的。於是，很自然的，在2012年初，我離開了阿里。

我很感謝阿里巴巴，進公司前，我是一名普通的高級DBA。出公司後，我覺得我找到了突破高級DBA瓶頸的方法，哪就是Oracle DBA領域中新的方向：調試Oracle。將調試與運維合二爲一的新領域。

馬雲是舞臺感很好的演說家，因此阿里的風格也是開放、高調。雙11民間造節的成功，讓所有人都無法懷疑這點。馬雲又在宣稱要用雙11撬動房價，無論撬動的結果如何，將雙11和中國最具爭議性字彙：“房價”聯繫在一起，無疑會讓雙11影響力進一步擴大。不但“造節”，阿里製造的概念，同樣不乏震動業界的，比如“去IOE”。

和雙11一樣，去IOE已經是一個充滿魔力的詞彙，它神祕、充滿懸念，又極富爭議。和雙11一樣，它也像風暴一樣，席捲了數據庫界。和雙11一樣，它也有偉大的理想。雙11要最終撬動房價、改變中國，去IOE要撬動“核心技術國外論”，要使中國走上自主核心技術的發展之路。有人說2013雙11第一分鐘訂單金額就已經過億了，主要阻塞在銀行，如果銀行也可以去IOE，第一分鐘訂單金額就不只過億了。先不說支付寶的去O情況，單想想去年雙11淘寶的超買現象。如果銀行也來個“超取”，那就真是太刺激了。

不過，經過幾年去IOE的宣傳，Oracle技術圈的確被打壓的萎靡不振，每個Oracle DBA都在考慮自己的未來之路，Oracle已經變成明符其實的夕陽產業。甚至連帶着整個運維的大環境，都大不如前。一些前輩高人紛紛轉管理、出國，新人們在去IOE的影響下，更加關注分佈式、大數據、雲這些新興行業，很少人靜下心來研究運維技術。導致一些奇怪的運維問題，無人可以解答清楚。2011年春、夏之交，有兩套某存儲廠商的中端存儲背板有問題，導致存儲宕機。因爲兩套存儲先、後宕機，我們希望廠商能給個說法，最後的回覆是“因爲前段時間日本福島核泄露，導致空氣中微量元素的輻射超標，造成電子設備運行不穩。”還有一次是另一家存儲設備供應商，在存儲設備出問題後，給出的原因是“太陽黑子爆發，大量中微子等量子穿過設備，造成問題。”看來去IOE之後，運維工程師已經可以閒到研究量子物理了。

我相信，隨着去IOE風瀑的進一步影響，以後這樣的奇怪回答將越來越多。我也相信總有企業不滿足這樣的奇怪答案，一些深入的問題，總要有人去研究。靠在這個新領域的研究成果，我迅速得到了很多Oracle DBA的認可。很多人說我給萎靡不振的Oracle技術圈注入了新的活力，我相信調試與運維的結合，將是DBA新的春天。也歡迎大家一起加入這個新領域，共同重振運維雄風。去年我寫了很多文章，介紹如何使用DTrace、gdb/mdb研究Oracle，年初還寫了一篇如何閱讀Oracle反彙編代碼的文章，今年以來寫文章的進度慢了，因爲我一直在著作《Oracle核心技術揭密》，隨着這本書進入收尾階段，我會更多分享文章，介紹如何“調試Oracle”。

達到可以調試Oracle的級別，你可以解決一切Oracle問題，當然了，前題是只要有時間。因爲一次調試、研究，需要大量時間。理解反彙編代碼，沒有相像中哪麼容易。我的方法是，養兵千日，用在一時。平常多調試、鑽研，如果遇到的問題正好是你以前研究過的，哪不就很快能搞定嗎。

最近我以高管級別的技術人員入職京東，證明了“調試ORACLE”這個方向正逐漸被技術圈接受、認可。但很可惜，由於自身、家庭原因，我只在京東待了兩週。

相比阿里，京東還是比較封閉的。每年各種IT技術大會，總少不了阿里人的身影，但京東鮮有人蔘加。但這兩週在京東的耳聞目染，京東的技術還是很牛的。比如ORACLE數據庫這塊，數據庫可用性，維護水平絕對不在全盛時的阿里之下，只可惜京東規定較嚴，通常不允許對外宣傳，否則，大家又可以聽到一些不錯的技術思想。

很可惜沒能在這樣的團隊中和大家共創輝煌。但離開後也多了一些自由度，可以更多的宣傳“調試ORACLE”的方法，讓更多的人從中受益。

在調試Oracle之後，還有一個最終級別。爲了調試，C語言、數據結構要掌握的不錯，還要有彙編、操作系統和CPU的相關知識。你已經把這些東西掌握的這麼好了，完全可以根據需要開發自己的調試工具。如果不想老是在調試這一塊搞，既然已經調試了Oracle這麼多年，對Oracle機制如此熟悉，完全可以模仿Oracle，寫一些自己的東西。比如，Oracle的內存管理是很優秀的，這已經被無數大型企業所驗證。只是網上所能查到的資料，缺失了很多細節，比如LRU的算法，或者更具體的HASH算法。但現在不一樣了，經過調試Oracle，你會看的比別人更清楚。這時，要吸收Oracle優秀的思想，設計自己程序的架構，也並非難事了。

這是我所希望的最終方向，我目前還只處於調試Oracle階段，希望以後有時間我可以再進一步。

從前有個叫拉里.沃爾的SA（系統管理員），覺得UNIX下處理報表非常不方便，awk、sed等工具都有不足之外，就自己寫了個工具方便處理報表，這個工具就是Perl。拉里.沃爾從些進入世界級IT神人名單，再也不用擔心自己的未來之路。

我並沒有寫個Perl這樣遠大的理想，我只想在運維、調試Oracle之餘，寫個工具可以更好的運維、使用數據庫，讓數據庫跑的更快。這就是我的最終方向了。

【相關閱讀】