 |
-- 會員 / 註冊 --
|
 |
|
|
|
收獲，不止Oracle ( 簡體 字) |
| 作者：梁敬彬,梁敬弘 | 類別：1. -> 資料庫 -> Oracle |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 35355
詢問書籍請說出此書號！【缺書】
【不接受訂購】 |
| 出版日：5/1/2013 |
| 頁數：480 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
【不接受訂購】 | | ISBN：9787121200700 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：隨著IT技術的蓬勃發展，相關技術書籍也大量涌現，這是令許多從事IT 行業的人士十分高興的事。但是，大多書籍都是就技術領域來談技術，讀起來難免有些枯燥或感到深奧。而我讀這本書的內容時，禁不住有一種沖動，一個聲音從心里喊出：原來技術書籍也可以這樣讓讀者喜愛！
從來沒有為哪一本書寫過序，也從沒有想過可以為一本書寫序，因為心中明白自己沒有這樣的能力。但是，當我們公司年輕的數據庫專家梁敬彬將他的書稿發給我參閱時，我被這本書深深吸引住了，更被他的一句肺腑之言感動了：“我寫完這本書，有一種如釋重負的感覺，因為我把自己認為對廣大技術人員最有價值的東西分享給大家了，我知道很多人可以因此不再為技術所累！”我為我們公司有這樣一位年輕的、優秀的、行業內知名的數據庫專家感到十分自豪。他是用自己的行動踐行著我們福富公司“敬天愛人、追求卓越”的核心價值觀；他把自己對廣大技術人員的愛通過這本書傳遞出去了。游于技藝，然心與道合，心中甚感愉悅。于是，認真學習為其作序。
《收獲，不止Oracle》這本書從思維方式和做事方式的高度來闡述技術，相信這樣的書對IT從業人員是十分有益的。在這個知識爆炸的年代，技術不僅學不完，而且還在不斷更新。可以說，具體某階段技術知識的學習都是暫時的，而學思想、學做事的方法論才是永恒的。授人以魚不如授人以漁，學會學習，學會總結，學會思考，才是最重要的。這本書將思想、方法、案例、故事完美地融合到技術中，這不僅需要作者具備精湛的知識、豐富的實戰經驗，更需有思想的高度提煉、方法論的總結、實際案例的組織和故事情節的構思。可以說，這本書是浩瀚技術海洋中的一顆璀璨明珠。翻閱過程中，更是驚喜不斷，本書除了站在思想的高度將技術和方法論巧妙結合，彌補了業內技術書籍的遺憾外，其妙趣橫生、新穎別致的風格也超越了我的想象。讀者閱讀全書仿佛置身課堂，別具一格的課堂風格讓人耳目一新，饒有趣味的故事構思讓人拍案叫絕!對于從事和即將從事IT相關工作的工程師們來說，遇到這本書應該是一種幸運、一個善緣！
作為公司層面的技術專家，梁敬彬服務的客戶遍布全國各地，他能在十分忙碌的工作之余，把自己寶貴的工作經驗撰寫成50余萬字的生動有趣的經典技術著作分享給廣大技術人員，這是他的努力不亞于任何人的證明！我很高興、也很欣慰地看到我們的員工有這樣的胸懷和激情！
此外，此書的校驗及補充完善是由擁有多項核心專利的知名專家、清華大學計算機系畢業的梁敬弘博士完成的。感慨兩位專家聯袂奉獻之余，更感受到他們兄弟間默契配合所傳遞的愛的情誼。
豈曰無衣，與子同袍。此書必為IT行業帶來一股清新之風，打造出IT書籍的一段傳奇佳話，成就一部永不過時的經典力作！我相信，此書將為廣大讀者開啟驚喜之心扉，讓讀者飛翔在思想的天空、遨游在方法論的海洋、采摘到技術的累累碩果，相信收獲遠不止Oracle！
福富軟件公司副董事長、總經理：楊林
別出心裁 另出蹊徑
——與梁敬彬先生序
敬彬的新書就要出版，邀我寫一點感受，于是就有了這一段文字。
我和敬彬相識是在2010年，那時我正在編輯《Oracle DBA手記》一書，偶然被他發表在ITPUB論壇上的一篇文章所吸引，那篇文章的題目是《DBA 小故事之SQL診斷》，其內容清晰、行文引人，于是就和他約了那篇稿子加入到書中，期間郵件往來再到北京會面，就此熟識。
從當時的一篇文章到今天的一本書，我能夠清晰地看到作者一以貫之的思考和敘述方式，這種積累與堅持也正是作者成長和成功的要素之一。
當時那篇文章的感受和今天這本書是類似的，作者能夠用曲折的筆觸將自己的經歷真實生動地再現出來，并且帶領讀者一起經歷一次思維的探索，這是屬于他的獨特風格。
作者在書中反復傳達的核心觀點是：Oracle數據庫看似艱深的原理實際上和生活中的基本常識并無二致。理解了這一層意思，就能夠克服對于這門技藝的畏懼之心，此后的學習自然就能夠順風順水。
誠然如此，我也經常和朋友們說，對于Oracle的很多艱深算法，如果由我們去深思熟慮，其結果都必然大致相同。類似HASH原理，布隆過濾等算法，理解了你就只覺得巧妙而不覺艱深。
現在梁老師就為我們尋找了一系列源于生活、循序漸進的學習路線，如果你能夠細心領會，就會覺得這一門技藝實在是趣味橫生。
蓋國強（eygle）
Oracle ACE總監
云和恩墨創始人
ACOUG創始人
名家推薦
敬彬兄這本書有著與市場上其他Oracle書籍與眾不同的特點，他通過一個個精彩的小故事，串起Oracle的核心知識和優化方法論，并時刻強調學習和工作的意識，如何不被技術束縛，如何跳出技術，意識和方法真的很重要。相信讀完本書，你的收獲，絕對不止Oracle！
丁俊（dingjun123）
ITPUB Oracle開發版資深版主
《劍破冰山——Oracle開發藝術》副主編
通讀本書，如醍醐灌頂，豁然開朗，本書從實戰出發，出發于技術，而超脫于意識，回味無窮，作者擁有多年的Oracle應用和體系架構設計的經驗，付出了不亞于任何人的努力，總結出眾多獨到的經驗，不失為一本好書，為學習和使用Oracle的技術人員帶來諸多益處。
傅祥文
福富軟件公司運營總監
由梁敬彬、梁敬弘兄弟合作的《收獲，不止Oracle》一書問世了。這對學習和從事數據庫相關事務的業內人員來說，是一件幸事。讀一本技術方面的書，或修一門課程、聽一個講座，大凡可能有三方面的收獲：掌握相關的知識，提高解決問題的能力，激發學習、探討有關問題的興趣和熱情。這些可能的收獲不在一個層面上，后兩者更為可貴。梁敬彬梁敬弘兄弟的這本書恰恰給讀者提供了這樣的機會。當然，要有真收獲，還要有真努力。
梁敬弘曾是我的學生，不僅學業專精，圍棋也下得很不錯，是一個真誠而聰明的小伙子，跟他的哥哥相比，內向一些。梁敬彬與弟弟相比更善于溝通和表達，是一個數據庫方面的專家，也是一個很好的教師。在此，預祝本書的出版獲得成功，同時也祝兄弟二人在事業上不斷取得新的成就。
黃連生
清華大學計算機系教授
曾經有Oracle的初學者問我，怎么開始學習Oracle？那時候我的答案很簡單：“去下載Oracle的在線文檔，包括Database Concept、Administrator’s Guide，然后開始學著做實驗。”誠然，對學習技術而言，在線文檔是一個不可多得的利器，但是，對于一個剛剛開始接觸Oracle的人來說，要從枯燥的英文文檔中去學習和理解Oracle的技術體系，也許有點勉為其難。 就算是市面上眾多的Oracle技術書籍，多數也是堆砌滿了技術細節，隨時可能嚇跑初學者。
好在，現在梁敬彬先生通過自己在日常工作和培訓中的磨練，把自己對Oracle技術的感悟，通過一個一個的小故事，淺顯而又形象地展現了出來。對于初學者來說，可以慢慢地在一個個小故事中去了解Oracle數據庫。讀完這本書，你也許會恍然大悟：“哦，原來Oracle是這樣子的。”
羅海雄（rollingpig）
ITPUB Oracle管理版資深版主
梁敬彬，網名wabjtam123，任ITPUB版主、ITPUB社區專家、 福建富士通公司數據庫專家。參與編寫過《劍破冰山——Oracle開發藝術》、《DBA手記2》等技術書籍，多年從事電信相關行業工作，負責系統架構設計、優化、培訓等工作，有著豐富的數據庫管理、設計、開發、培訓經驗和電信行業經驗。
梁敬弘，清華大學計算機系博士畢業，在計算機領域和金融領域皆有建樹，擁有多項計算機相關核心專利技術的同時還擁有金融行業的CFP等高級認證。現就職于華夏銀行總行。
前言
0.1 當今時代，既是最好的也是最壞的
近年來，我深刻地體會到，如今這個時代對于絕大部分技術人員而言是幸福的時代，能在這個時代從事IT技術相關工作的技術人員應該很開心。因為比起老一輩技術人員，現今的技術人員幾乎從來就不缺資料。除了可以在各技術平臺的官方網站下載到詳盡且準確的學習資料，他們還可以很容易地在Google、百度上搜索到自己想要的答案，也可以很方便地在各種技術論壇上注冊提問從而獲取別人的幫助，其中最著名的就是ITPUB論壇，我本人也從中受益匪淺。
然而，這個時代對技術人員來說也是痛苦的時代。無論是傳統的電信、金融、證券行業，還是新興的互聯網行業，我們都不難發現運維系統涉及的數據量、訪問量及并發量都在以驚人的速度不斷激增。重壓之下，很多IT系統運行舉步維艱，技術人員壓力巨大，甚是痛苦。除了負載壓力外，系統的復雜度也隨著業務復雜度的增加而成指數級增加，讓開發設計人員頭昏腦脹，讓故障診斷及系統維護的相關技術人員無從下手。
痛苦還不止于此，在這個時代，除了海量負載和高復雜度，還有讓技術人員應接不暇而無所適從的各種新技術。且不討論IT所有技術，僅以數據庫為例，除了以Oracle、DB2等為代表的一系列傳統關系型數據庫外，還有內存數據庫、列式數據庫、以HBase為代表的分布式數據庫等等，讓人眼花繚亂。此外，除了各類紛繁技術的選型外，我們還要適應具體各個版本的不斷更新，以Oracle數據庫為例，從早期的Oracle 5版本到今天即將正式發布的Oracle 12c，Oracle每一次新版本發布都需要我們去學習和適應，投入大量的精力和時間。
這是幸福的時代，也是痛苦的時代。這是最好的時代，也是最壞的時代（如圖0-1所示）。
圖0-1 當今時代
0.2 技術人員，真正差距其實在意識
在這個特點鮮明的時代，我目睹了一大批在IT項目中不能有效適應這個時代而導致摔得鼻青臉腫，碰得一鼻子灰的技術人員，而這些人之中大多還是勤奮上進之人，少數還是技術能手。當然，也有成功的例子，讓我來說說他們的故事吧。
0.2.1 小白的故事
工作兩年多的小白是一個很努力的員工，每天除了用心工作外，還堅持充電學習，兩年來他除了把Oracle 10g和Oracle 11g的官方文檔幾乎讀了個遍，還購買了不少相關的書籍來學習。由于小白的項目組工作強度大，時常需要加班，因此小白工作學習外的時間就只夠吃飯和睡覺了。那他的工作表現很出色嗎，天道是否一定酬勤？實際情況卻是不盡如人意，雖然他了解很多相關知識，可是在實際工作應用中卻不得要領，頻頻出錯，領導經常對其提出批評，他自己也相當苦惱。
其實小白只是因為缺少了一種稱之為“意識”的東西，這個意識就是，該如何學習。在他的學習過程中，他犯了很多錯誤。
1. 忽略了知識的重點
小白讀完了Oracle官方文檔的幾乎所有內容，毅力讓人欽佩！遺憾的是，他忽略了二八現象這個事實：20%的知識，解決80%的問題。小白根本不需要讀完Oracle所有文檔，他所在的項目組是從事數據庫開發相關工作，而他卻花費了大量的時間閱讀完了至今他都尚未開始從事的數據庫管理相關知識，比如備份恢復、RAC、DATAGUARD部署及高級數據同步復制相關的技術，這是完全沒有必要的。
另外語法方面的資料小白也根本無須細讀、記憶，因為平時用得多的語法，自然記得住，遇到偶爾忘記的場合再去官方文檔翻閱即可，現在Google等搜索引擎也非常強大，搜索到相關語法易如反掌。
人的精力是有限的，如果我們做到當前做什么事對應學習什么知識，盡量理解原理而不強記語法，將能省下多少寶貴的時間啊。
2. 從未考慮知識落地
小白曾經對我說過自己的煩惱，向我說明了他有多努力，看過了多少資料。我試探性地問他是否知道Oracle的體系架構是什么？他很自信地做了回答，滔滔不絕，甚至還畫了草圖給我，回答得讓人相當滿意。我又問他是否知道索引的結構和原理是什么？再次得到完美的答復。
接下來我再問他，知道這個體系架構對我們工作有啥幫助呢？他一下子回答不上來了。我繼續問他，那索引的結構和原理對我們工作中的數據庫應用有啥好處呢？再次答不上來。
原來這就是問題的關鍵所在！
知識要落地，要思考應用的場合，這就是我除了要讓他把握學習重點外的第二個建議。他的學習其實就是為了學習而學習，沒有思考應用場景的學習，是沒有任何意義的。
后來我建議小白來聽我在公司開講的Oracle系列講座，讓他明白原來了解體系結構后我們居然可以將一條SQL從42秒調整到不足0.01秒；了解索引結構后，我們居然可以優化我們身邊最為常見的SQL語句，比如COUNT(*)、MAX()等。而在此之前，這些語句根本不會讓他對索引產生聯想。他終于徹底明白了什么叫知識落地，明白了意識有多么重要！
我最后強調，不只是Oracle，其實學習任何技術都是一樣的，沒有思考過你所學的某項技術有什么用，沒有想過如何落地，如何應用到實際工作中去，都是毫無意義的學習，純粹浪費生命。
3. 選擇技術使用場景
近來小白連續犯錯，他學習了并行度這個章節后，知道并行可以有效地利用多個CPU，就將自己的代碼加入了并行度。但他忽略了生產系統不只運行他這一個應用這個事實，結果導致代碼上生產后系統資源大量爭用。直至最后我們定位到問題在他的代碼中，將寫法修正，取消了并行度后，系統終于恢復正常。
他為什么會犯這個錯誤？主要是因為他只專注于技術本身而忽略了應用的場景，如果是凌晨2點的某個大任務操作，他的這個設置就很好，因為那個時刻大多其他應用都已經停止運行了，資源不用白不用。
這就是什么時候選擇什么技術。小白還有一個有趣的故事，就是在我給他提這第三個建議之后的一周，他又使用了并行，這次他不是在代碼中寫死，而是選擇臨時性場合使用，在凌晨2點運行系列特定腳本。結果這次運行的比想象的慢得多，還不如之前未用并行的時候。
大家知道是什么原因嗎？其實還是因為不知道什么時候選擇什么技術。這次他不會影響他人了，因為凌晨靜悄悄。但是他影響了自己。因為他的任務的特點是小而多，平均不到0.01秒可以完成一條SQL執行。他忽略了另外一個細節，并行是需要調度的，調度是需要開銷的，調度的開銷甚至達到0.1秒，那當然是越跑越慢了。所以小任務實際上是不需要考慮并行的。
類似的故事還有很多，在本書中大家還會接觸到什么時候選擇什么技術的各類場景，這里暫且只說并行。
小白的故事說完了，其實要是早些年，他或許不會有這些苦惱，因為學習資料少，他即便不抓重點也不至于學到筋疲力盡；此外他的諸多失誤都和性能有關，而早些年大多IT系統壓力很小，在基本功能滿足后性能問題幾乎可以忽略不計，那小白也就沒錯可犯了。
再次強調，當今的IT建設項目，如果不對海量數據和高并發帶來的性能問題進行有效的架構設計、部署規劃，你的項目基本上就被判了死刑。而Oracle新版本為什么對應大量技術文檔，很大一部分原因是Oracle新版本提供了更多的性能調優產品。為什么現在新技術如此繁多，其實也是源于此，難道內存數據庫和列式數據及分布式數據庫的產生，不是為了讓系統跑的更快一些嗎？只是這里要注意，它們不可能替代傳統關系型數據庫，因為它們都有各自適合的應用場合。小白的故事如圖0-2所示。
圖0-2 小白的故事
0.2.2 小劉的故事
1. 該如何請教他人
工作近5年的小劉特別勤學好問，工作中一遇到不明白的技術問題就問，有時問周圍的同事，有時發帖子在論壇上提問。可是最近他非常郁悶，因為總是沒人愿意回答他。是不是大家不夠團結友愛？非也！問題出在他自己身上，你們知道為什么嗎？
讓我們來看看他是怎么問的吧。
“請問，對表的某列建索引如何建？”
“請問，分區表中刪除分區后，索引會不會失效？”
“哦，您說我問過同樣的問題了，我怎么記不起來了？”
前兩個提問有問題嗎？不少人都覺得應該一點問題都沒有，其實是很有問題的。因為很顯然第一個問題可以Google搜索到，而第二個問題除了Google可以搜索外，你完全可以通過做一個試驗來得出結論。
網上可以很方便搜索到的東西去問別人無異于浪費別人的時間，當今這個時代，搜索能力成為了最重要的能力之一。知道關鍵字的比不知道關鍵字的搜索能力更強；英文好的比英文糟糕的搜索能力更強。為什么不去鍛煉提升自己這方面的能力呢？顯然可以動手試驗證明結論而不去試驗，會讓你白白失去了一個寶貴的試驗和總結的機會。
第三句對話暗示該同學經常問同樣的問題卻不自知，這說明了什么？別人告訴你答案時，你思考過嗎，記錄過嗎，總結過嗎？
2. 問題該怎樣描述
某次我在外地出差，下飛機后打開電腦，收到了小劉的一封求救郵件，內容是這樣寫的：今天早上上班發現寧夏的數據庫很慢，請幫忙診斷分析一下，萬分感謝！
之前我還收過小劉的另外一封求救郵件，內容是這樣寫的：緊急求救，湖北數據庫崩了，請盡快幫忙處理，謝謝！
從這兩封郵件可以看出來，求救者嚴重缺乏經驗，在溝通上存在著巨大的問題，你們知道是什么問題嗎？
先說這個慢的郵件，是某個局部慢還是整個系統都很慢，不同情況的處理方式截然不同。是今天開始忽然變慢還是一直以來都慢，直至今天再也無法忍受，不同情況的處理方式顯然是截然不同的。再說這個慢字，有一次我對求助者說，這個語句1秒就出來了，你怎么會覺得慢得受不了了？他的回答是，原先只需要0.1秒左右，這語句一天可是會跑上千萬次啊。哦，原來1秒也讓人覺得超級慢。還有一次有個求助者對我說，這個語句現在要跑2個多小時啊，原先超級快，只需要5分鐘左右。哦，原來5分鐘也有人覺得超級快。因此，你準確地告訴我現在要執行多長時間，希望執行多長時間，不是很準確嗎？
再看第二封郵件，崩了？什么叫崩了，是數據庫忽然關閉無法啟動，還是系統運行太緩慢，還是數據文件丟失？哦，我來公布答案吧，后來知道這個崩了原來是指系統資源負載太高，系統運行緩慢。原來這就是崩了，為什么要說這么模糊的字眼呢？
還有，這兩封郵件都有個共同的特點，就是既沒有提供接口人的聯系電話，也沒有提供所需要處理的機器的IP地址、登錄用戶名和密碼。
毫無疑問，接下來我要再確認好多次，才能最終幫上他。
3. 失誤不只是粗心
小劉最近非常苦惱，因為近期系統經常遇到并行相關的等待事件，導致系統運行緩慢，后來查出來是諸多表和索引都有默認的并行度，這是因為系統很多大表通過并行的方式完成了創建，小劉創建完畢后忘記將并行度取消了。因為此事影響了生產系統正常運行，小劉被領導批評了，他也承認了自己過于粗心的毛病。
其實我們仔細分析就知道，這種問題絕對不只是因為粗心。顯然有個更重要、更本質的東西沒有揪出來，這就是流程和規范。
如果小劉在操作前事先準備好操作步驟，而不是即興發揮現場操作，取消并行度的步驟應該就不會忘記。
即便他忘記了這個步驟，連腳本都沒有體現，也沒有關系。如果有規范，要求生產的操作準備了腳本，并且必須要他人審核通過方可操作，那也就不會出錯了。
即便審核的人也犯錯了，如果有個完善的流程，在生產中完成操作后必須檢查哪些項目，那這個例行檢查也必然會讓錯誤再次避免。
人不是機器，都會失誤，即便有的人素質非常高，不容易犯錯，你也不能指望所有的人都這樣，因此流程和規范才是最重要的。本書中大家會發現我們都有哪些流程和規范是來避免誤操作的。小劉的故事如圖0-3所示。
圖0-3 小劉的故事
0.2.3 自己的故事
1. 湖北神秘調優之旅
某日湖北某工程點向我求救，需要優化他們的生產系統，瓶頸正出在數據庫上，為此公司讓我去湖北現場進行調優。去之前我心中很沒有底，因為據說這個性能問題已經困擾該工程點半年多了，期間該工程點已經請過好幾波人馬來調優過了，而且請來的人員中還不乏精通數據庫的知名高手，這么多人這么長時間都無法把系統性能提升，我可以嗎？
結果呢，我趕赴湖北現場忙碌一周后，該工程點生產系統性能最終得以大幅度提升，該工程點興奮之余還發了一封表揚信到我公司，以此來肯定我的貢獻。事后不少同事問我為什么那么多人長時間沒解決的問題，而你一個人一周就搞定了，用了什么Oracle的高深技巧搞定這事。實際情況是，我并沒有用任何Oracle技巧，甚至我根本就沒有利用到和數據庫有關的任何知識，但是我卻解決了性能問題，圓滿完成了任務。這是千真萬確的事。
我到底做了什么事，讓我來公布一下答案吧。我到了湖北，和現場技術支持人員以及相關人員對當前業務深入交流了一周，精簡改寫了大量邏輯被人為復雜化的SQL，刪除了部分多余的SQL，對大表的保留記錄情況根據業務特點進行了合理的規劃，讓不少大表變成了小表。
然后呢，然后就沒有然后了，系統運行飛快，我勝利歸來。這是一個很簡單的道理，原先不少難以優化的運行緩慢的語句被我直接給?嚓掉，從系統中消失了，此外不少大表變成了小表，系統變快不是自然而然的事情嗎？
2. 三句話恢復的故障
某日早上10點，我接到項目組的緊急求救電話，被告知當天早上8點，某平臺的生產系統運行極其緩慢，已經有相關人員在現場進行調查分析了，可惜兩個小時過去了，直至現在依然沒有解決問題，客戶投訴不斷，情況非常緊急。恰逢我在外地出差，且不說我在外地有重要事情要處理，即便是立即飛回來也需要一天的時間，該如何解決這個問題呢？
結果呢？10分鐘后，在我的幫助下，問題解決了，故障恢復了。我做了什么事，這么神奇？
其實，我只在電話里和求助者交流了短短的三句話，求助者心領神會而去，然后問題就解決了。我是讓他們調整什么神秘的參數嗎？不！其實我用的方法和數據庫的知識一點關系都沒有，他們要是早點給我打電話就好了，免得相關技術人員折騰了兩個小時，卻無法消除故障，實際上這個技術人員的水平并不低，甚至可以說是Oracle方面的行家。
到底是哪三句話這么神奇呢？
“系統是從什么時候開始慢的，是一直就慢還是突然變慢？”回答是今早上班忽然感覺緩慢，昨天下班以前都是正常的。
“那昨天你做了什么嗎？”回答是昨天晚上升級了補丁。
“補丁允許回退嗎，如果允許，你就回退補丁吧。”回答是系統都不能用了，如果回退可以解決問題，當然可以回退。
接下來十分鐘后，電話告知我，回退后系統正常了，問題解決了。
現在不影響生產系統的應用了，剩下來的事情就是開發人員自己慢慢去檢查代碼有什么問題，最終問題在于代碼有死循環和笛卡兒積，后續更改后投放生產就沒問題了。
這其實就是生活，好比你去醫院看病，肚子疼醫生肯定會問你從什么時候開始疼，如果就是今天早上疼，那接下來必定會問你昨天晚上吃了什么……
3. 數據遷移有那么難嗎
某日，某生產環境要做數據遷移，方法是通過EXPDP的方式將舊環境的數據庫導出，然后通過IMPDP的方式導入到新環境，要求在凌晨2點開始導出，6點前完成導入，因為之后需要測試，必須保證上班時間8點后，新系統可以正常運行。
這里涉及的技能是掌握Oracle的EXPDP/IMPDP命令，如果今天讓我來上課描述這個工具的使用，大致45分鐘時間可以完成課程的講述，還包含了動手試驗的時間。因此這顯然不是一件很復雜的工作，當時現場的操作人員是一位工作多年的，擁有OCM證書的技術人員，大家也都覺得很放心。
然而實際情況是，從凌晨2點開始操作，直至下午6點，才完成了導入工作，整整比預計推遲了12個小時！這期間雖然臨時做了不少應急補救措施，但是還是嚴重影響了生產的正常運營。
為什么會這么糟，中間出了什么問題？其實這里的故事太耐人尋味了，需要改進考慮的細節也太多太多了。
接下來揭曉謎底吧，還是通過一段對話展開。
“請問你要導出的庫有多大？”答曰不知道。
“請問你要導出的庫最大的對象有多大，能否列舉前20名的大對象？” 答曰沒統計。
“請問是否是所有的對象都需要導出？”答曰應該是，沒確認。
“請問你知道導出和導入機器的CPU、內存配置情況嗎？” 答曰沒注意。
OK，這就是原因了，讓我來告訴大家我調查的結果吧，全庫有1TB這么大，其中某記錄操作日志的表T1就達到400GB，連同索引，大小合計500GB左右，近乎一半的量。而和業務人員確認的結果是，T1表可以暫且不導出，只需在新環境中建表結構即可。前20名的大對象除了巨無霸T1表外，還有不少也很龐大，其中有一張單表即有120GB，只需保留最近三個月即可……經過我的確認，1T的數據最終只需要導出300GB左右。
接下來的調查還發現了更加驚人之處，導出和導入的機器CPU個數居然都達到64個，強勁得讓人驚嘆！而我觀察操作的腳本，也有寫并行度，只是隨便寫了PARALLEL=8。當時是凌晨，我們完全可以將導出導入的PARALLEL設置為更大，比如60個都不為過，這里又將會有5倍以上的提速。
后面我告訴他們，其實這次導出導入只需要合計2小時就足夠了，不需要4小時，更不會操作了整整16個小時！
4. 充分準備是要領
某次我應邀去安徽某工程點進行數據庫調優，周二晚上接到通知，要求周三下班前趕到現場，周四一天之內要把系統性能顯著提升，從而應對周五集團組巡的檢查工作，當時公司領導也在現場，情況相當緊急。
這是相當讓人頭疼的一件事，因為系統調優是一項相對復雜和艱巨的任務，要求在一天時間內立竿見影，可能性很小。雖說沒有把握，但是也只好硬著頭皮去試試看，我在出發前做了充足的準備，這些準備方法大多來自平時的積累，這種積累非常寶貴非常重要。有了這些重要的準備，我在出發前通過工程點現場同事的配合，獲取了大量我想了解的重要信息，在路上和飛機上做了充分的分析和研究，等下午6點到工程點現場，我已經對這里的情況了如指掌了。
然后，晚上調優到凌晨2點，第二天再奮戰一天，第三天，系統終于運行平穩了，IDLE從原先的0∼1%變為40%∼50%，系統性能顯著提升了。
這個小故事說明了一個道理，積極的準備是很重要的，我準備了一個非常詳細的處理及定位問題的流程和思路，從動態到靜態，從整體到局部，非常詳盡和實用，將會在后續分享給大家。讀者可以從中體會到我是如何解決定位以及分析探索問題的，此外還可以學習到我所總結的優化思想和方法論。我自己的故事如圖0-4所示。
圖0-4 自己的故事
0.2.4 故事的總結
至此我講完了小白、小劉和我自己的故事。別小看這三個人的故事，其實是非常典型的，這其中小白的故事告訴了我們學習是很有技巧的，是一門技術活。而小劉的故事告訴我們如何提問、求助以及制定規范是非常重要的。最后我本人的故事告訴大家，很多時候，解決問題不一定完全依靠技術本身，我的4個故事中的制勝法寶全部是非技術，這說明技術雖然重要，但是不能僅僅依賴技術。技術人員的故事如圖0-5所示。
圖0-5 技術人員的故事
0.3 收獲Oracle，更收獲“少做事”
包括我在內的幾位技術人員的故事表面上說明的重點各不相同，實際上有一點上是相同的，那就是一個非常重要的意識：準確地把握需求，盡可能少做事! 不要小看了這句話，這是永不過時的一句話，生活難道不是如此么？
精簡起來可以用三個字概括：少做事。
就只是少做事？
別驚訝，讓我們一起分析一下。
小白是一位數據庫開發人員，數據庫開發就是他的工作職責，很顯然他的學習任務就是了解數據庫開發相關知識。他這時就應該選擇性地學習，盡量拋棄和工作任務無關的知識，例如數據庫的遷移備份部署等相關知識與他工作無關，就暫且不學，這就是少做事。
暫時在工作中應用不到的內容先不學，何樂而不為？接下來我們還要保證精簡學習的內容，要掌握得最快，別拖拖拉拉地學了三五年，不符合這個時代的要求。這時最大的技巧就是將學習和工作結合在一起，帶著知識點該如何落地應用以及什么時候該選擇什么技術的想法去學習，這樣目的性極強的探索性質的學習，往往學習一遍就夠了，那些為了學習而學習的傳統方法，學了多遍往往也無法有效地應用到工作中去。這又是少做事。
小劉為了能更好地提升自己的技術水平，經常請教他人，希望快速獲取別人的幫助，節省時間，本質是想少做事，這個出發點是對的。但是他問的問題是很方便可以搜到的，這樣的提問對被提問者來說，就是讓被提問者多做無意義的事，浪費生命，所以能搜索到的問題盡量不要去請教他人。同樣道理，問過的問題也盡量不要再問。此外自己動手做試驗來證明結論，這事表面上看不如直接問或者查資料來得快，不過試驗可以讓你在動手動腦的鍛煉中加深印象從而過目不忘，和那些由于從不動手進行試驗而導致學習過于浮躁、停留表面，最終反復學習多次都無法很好掌握相關知識的人相比，顯然也是少做事了。
小劉的兩封郵件表達得過于糟糕，導致我一頭霧水無從下手，最終必然要再次聯系反復交流。為什么不養成好的習慣，一次性說清楚，讓大家都快速投入到故障處理工作中去？這也是少做事。
接下來說小劉的工作失誤，文檔規范、評審等看似是多做事了，其實也是典型的少做事，因為公司、部門的工作大多都有通用性，有了這些準備資料，交接的工作者可以直接拿來使用，既準確又省心，就是少做事。
最后點評自己的故事了。湖北之行是一次精簡程序和瘦身表的旅程，顯然是一次少做事的經典之旅，三句話解決故障顯然是一次最精簡的故障定位案例。接下來說數據遷移案例，從1TB到300GB導出，是否很有技術含量，可以說沒有，也可以說有。說沒有是因為這真的沒什么技術可言，說有是因為有意識的人比起沒意識的人，差別是非常大的。最后說說安徽之行我準備的文檔和腳本，且不說提前準備后讓我一到現場就開始解決問題，少做了定位問題的事（提前在路上完成了），節省了寶貴的時間，就說這份文檔和腳本的分享，足以讓后人少做不少事，節省不少時間。
點評完三個技術人員的故事，我的書要怎么寫呢？前面說了這么久，其實主要在談如何少做事的意識，現在這本書的主基調就明確下來了，就是主要和大家分享如何少做事解決問題的思路和方法。
分享這個主題首先要選擇一個場景或者道具來和大家講述，選擇什么道具呢？考慮到現在IT行業中開發、設計、測試、維護等幾乎所有IT相關技術員，或多或少都需要接觸到關系型數據庫，而Oracle又在當前關系型數據庫的市場份額中遙遙領先，因此學習Oracle會讓絕大多數人更容易找到合適的工作，從而在就業上多一些選擇，少一些奔波。于是本著盡量少做事的原則，我們的道具確定是Oracle。
圍繞著Oracle課程我們將會驚奇地發現，其實Oracle技術的本身細節中，四處滲透著少做事的思想，從體系結構到物理結構，從表到索引的設計，無一例外。例如SQL執行第二次就會比第一次更快，顯然是因為第一次執行保存了共享池的解析動作，CACHE了磁盤中的數據，第二次無須再解析，無須再去物理磁盤讀取數據，從而提升了性能，這就是少做事。又如索引的體積一般比表小得多，如果能只訪問索引完成需求一定比在表中更快，這也是少做事。再比如分區表，如果沒有設置分區表，則需要全表掃描，如果設置了，或許只需要在某個分區中查找即可，訪問的路徑少多了，這也是少做事……這些例子不勝枚舉，多得可以寫成一本書。哦，不對，就是可以寫成一本書，這本書不就主要寫這個嗎？
本書不會將Oracle的所有知識都描述完，其中只涉及體系結構和物理結構，表、索引與表連接這幾個章節，雖然涉及的內容不多，但是卻是非常核心和重要的，所有不同角色的人員都離不開這幾個章節的學習，這是共性的部分，只有把這幾個章節學好了，后面的學習才有意義，這是為了避免大家像小白一樣一頭霧水地漫無目的地學習，少做和自己任務無關的事。另外最重要的是我講述的學習的路線圖和思路以及方法，這就是少做事的體現。
此外我特別強調知識的落地，探討最多的話題就是，學習這些知識有什么用，和不知道這些知識的人相比，在工作中有什么差別，從而保證大家不浪費時間。在這些章節中，大家將會和我一起體會，原來理解體系結構后，我們可以把一條常見的SQL從原先的42秒完成提升到0.01秒左右完成，實現了一次從單車到飛船的飛躍；原來理解了索引后，立即就可以著手優化身邊最常見的SQL語句。
接下來書中有另外一個重點部分，就是我的方法論、工作習慣、實用的準備工作腳本以及各個經典案例，這些章節再次強調了理解業務，盡量少做事不做事的思想有多么重要。
這就是本書的全部內容，學完這本書后，大家還會發現，原來用少做事的思想去學習數據庫是那么的親切，那么的容易理解和記憶。用盡可能將知識落地在工作中的意識去學習，學完后應用在工作中的那種感覺，是多么讓人興奮。
最后就是寫書風格的確認了，這是一本風格非常有趣的書，靈感來源于我平時大量的授課。很多學員告訴我他們特別喜歡上我這樣風格的課程，非常容易理解也非常實用。對此我很開心，猛然有一天有了這樣的一個想法，將我的視頻變成文字，這個想法得到我弟梁敬弘博士的大力支持，并答應幫我一起完成此書。于是全書就變成了“老師講課、學生聽課，老師提問、學生回答，學生提問、老師解答”這樣的輕松對話方式。我終于實現了將視頻變成文字。這本書成了一本輕松的書，讀者很容易身臨其境產生共鳴。而我講述知識的方式也變得非常靈活了，有時故意不說的重點知識，在學生們的思考中被引發出來，而讀者也一同經歷了這個難忘之旅。本書還有一個顯著的特點，就是所有的知識點推論都有試驗證明，而這些試驗讀者完全可以自己進行，再現老師的結果。這在保證課程準確性的同時，能讓讀者進一步加深印象。不過全書最有趣的特點還是我構造的小余一家的故事。
學完本書后，大家就會發現，雖然當前時代數據壓力比較大，但是并不可怕。其實調優如同生活一般，一點都不神秘。在老師的故事中，平均每處理10個成功案例中，就有5個不是依賴技術來解決的，真是一個有趣的數字。牢牢抓住需求，在設計和開發中巧妙地應用“少做事，不做事”的思想，產品就能高效，就很少存在性能問題，基本上就很少需要調優。
學完此書后相信大家會有一種強烈的感覺，原來學習技術可以如此輕松，原來學習要落地才有意義，原來少做事的意識這么重要。如果大家真有這個感覺，那我的所有努力——苦心積慮的書寫風格、精心構造的試驗腳本、精彩有趣的經典案例就沒有白費了。我對于如何寫此書的規劃如圖0-6所示。
最后我希望讀者收獲，不止Oracle！
圖0-6 書該如何寫
致 謝
我首先要感謝福富軟件公司，因為公司文化所營造出來的這樣一種氛圍讓我特別開心：各團
隊成員無論員工還是領導，都樂于分享、鼓勵分享且勇于承擔責任。
我至今忘不了當初姚建藝、鄭清泉在我新融入團隊時給予我的耐心指點和幫助，忘不了鄭超
群總監在我分享自己心得體會后發出的讓我倍受激勵的公開表揚郵件，也忘不了吳夢晟經理在我
解決故障問題失利時只鼓勵、不責怪、共同并肩戰斗到天亮的場景。
正是在這種氛圍的渲染下，才有了此書！
關于本書，我特別要感謝黃興勝總助和傅祥文總監對我想法的鼓勵、支持，以及對本書的關
注、推進。尤其是要感謝我們的楊總，她在百忙之中讀完我的全書手稿，提出寶貴意見并為本書
寫下熱情洋溢的《序》，讓我感動不已！
我很慶幸我有一個好弟弟梁敬弘，他從本書的最初策劃、構思到中途的不斷完善、補充，直
至最終的反復審校，傾注了大量的精力。可以說，沒有兩兄弟的傾力合作，就不會有此書！
此外我要感謝蘇旭暉、盧濤、丁俊、羅海雄、李丙洋這幾位業內知名數據庫專家對本書的審
核校驗，感謝博文視點在出版方面的專業性指導意見。感謝大家的幫助！
最后我要感謝我的爸、媽、妻、寶寶、弟、弟妹。謝謝你們的支持，我親愛的家人！ |
內容簡介：在這本書里讀者將會跟隨作者一同對Oracle數據庫的相關知識進行梳理，最終共同提煉出必須最先掌握的那部分知識，無論你是數據庫開發、管理、優化、設計人員，還是從事Java、C的開發人員。接下來作者再將這部分知識中最實用的內容進一步提煉，濃縮出最精華的部分，分享給大家。這是二八現象的一次經典應用。
這部分知識就是Oracle的物理體系結構、邏輯體系結構、表、索引以及表連接五大部分。通過閱讀這些章節，讀者將會在最短時間內以一種有史以來最輕松的方式，完成對Oracle數據庫的整體認識，不僅能在工作中解決常規問題，還能具備一定的設計和調優能力。相信通過這些章節的學習，會給讀者的Oracle學習帶來極大的收獲。
然而，作者最希望看到的是：讓讀者的收獲，不止Oracle。
為達到此目的，作者精心將全書分成了上下兩篇，剛才所描述的具體知識點體現在全書的上篇，而在下篇中，讀者將通過各種精彩故事、生動案例，體會到該如何學習和如何思考，在意識的天空拋開束縛，無拘無束、盡情飛翔。
在這里，讀者也許會有疑問，前面說的有史以來最輕松的方式是一種什么樣的方式呢？
還請親愛的讀者自己去揭曉謎底吧。 |
目錄：上篇 開啟驚喜之門——帶意識地學Oracle
第1章 意識，少做事從學習開始 2
1.1 選擇先學什么頗有學問 2
1.1.1 梁老師課堂爆笑開場 2
1.1.2 看似跑題的手機分類 4
1.1.3 學什么先了解做什么 5
1.2 善于規劃分類才有效果 7
1.2.1 分類與角色密切相關 7
1.2.2 角色自我認識有講究 9
1.3 明白學以致用方有意義 11
第2章 震驚，體驗物理體系之旅 13
2.1 必須提及的系列知識 13
2.2 物理體系從老余開店慢慢鋪開 16
2.2.1 老余的三個小故事 16
2.2.1.1 顧客的尺寸 16
2.2.1.2 有效的調整 17
2.2.1.3 記錄的習慣 18
2.2.2 體系結構原理初探 20
2.2.2.1 從一普通查詢SQL說起 20
2.2.2.2 老余故事終現用心良苦 23
2.2.2.3 一起體會Oracle代價 27
2.2.3 體系結構原理再探 30
2.2.3.1 從一普通更新語句說起 30
2.2.3.2 體系結構中提交的探討 34
2.2.3.3 勞模的評選 38
2.2.3.4 回滾的研究 40
2.2.3.5 一致的查詢 43
2.2.3.6 一致讀的原理 46
2.2.3.7 實踐的體會 49
2.3 體系學習讓SQL性能提升千倍 65
2.3.1 一起探索體系學習的意義 65
2.3.1.1 同學們不知所學何用 66
2.3.1.2 實際上大有用武之地 67
2.3.2 單車到飛船的經典之旅 70
2.3.2.1 未優化前，單車速度 70
2.3.2.2 綁定變量，摩托速度 72
2.3.2.3 靜態改寫，汽車速度 74
2.3.2.4 批量提交，動車速度 75
2.3.2.5 集合寫法，飛機速度 77
2.3.2.6 直接路徑，火箭速度 78
2.3.2.7 并行設置，飛船速度 79
2.3.3 精彩的總結與課程展望 80
2.3.3.1 最大的收獲應該是思想 80
2.3.3.2 老師的課程展望與規劃 81
第3章 神奇，走進邏輯體系世界 84
3.1 長幼有序的邏輯體系 84
3.2 邏輯體系從老余養殖細細說起 85
3.2.1 農場之體系邏輯結構 85
3.2.2 農場之 BLOCK 漫談 89
3.2.3 農場之區與段 91
3.2.4 農場之表空間的分類 93
3.2.4.1 表空間與系統農場 93
3.2.4.2 表空間與臨時農場 93
3.2.4.3 表空間與回滾農場 94
3.2.5 邏輯結構之初次體會 94
3.2.5.1 邏輯結構之 BLOCK 94
3.2.5.2 邏輯結構之 TABLESPACE 95
3.2.5.3 邏輯結構之 USER 97
3.2.5.4 邏輯結構之 EXTENT 97
3.2.5.5 邏輯結構之 SEGMENT 98
3.2.6 邏輯結構之二次體會 100
3.2.6.1 BLOCK的大小與調整 100
3.2.6.2 PCTFREE參數與調整 101
3.2.6.3 PCTFREE與生效范圍 102
3.2.6.4 EXTENT 尺寸與調整 103
3.2.7 邏輯結構之三次體會 104
3.2.7.1 已用與未用表空間情況 104
3.2.7.2 表空間大小與自動擴展 105
3.2.7.3 回滾表空間新建與切換 109
3.2.7.4 臨時表空間新建與切換 111
3.2.7.5 臨時表空間組及其妙用 114
3.3 課程結束你給程序安上了翅膀 117
3.3.1 過度擴展與性能 117
3.3.2 PCTFREE與性能 120
3.3.3 行遷移與優化 123
3.3.4 塊的大小與應用 124
第4章 祝賀，表的設計成就英雄 131
4.1 表的設計之五朵金花 131
4.2 表的特性從老余一家展開描述 132
4.2.1 老余一家各施所長 132
4.2.2 普通堆表不足之處 132
4.2.2.1 表更新日志開銷較大 133
4.2.2.2 delete無法釋放空間 136
4.2.2.3 表記錄太大檢索較慢 139
4.2.2.4 索引回表讀開銷很大 140
4.2.2.5 有序插入卻難有序讀出 143
4.2.3 奇特的全局臨時表 146
4.2.3.1 分析全局臨時表的類型 146
4.2.3.2 觀察各類DML的REDO量 147
4.2.3.3 全局臨時表兩大重要特性 149
4.2.4 神通廣大的分區表 153
4.2.4.1 分區表類型及原理 155
4.2.4.2 分區表最實用的特性 165
4.2.4.3 分區索引類型簡述 176
4.2.4.4 分區表之相關陷阱 177
4.2.5 有趣的索引組織表 184
4.2.6 簇表的介紹及應用 187
4.3 理解表設計的你成為項目組英雄 189
第5章 驚嘆，索引天地妙不可言 191
5.1 看似簡單無趣的索引知識 191
5.2 索引探秘從小余緝兇拉開帷幕 192
5.2.1 BTREE索引的精彩世界 192
5.2.1.1 BTREE索引結構圖展現 192
5.2.1.2 到底是物理還是邏輯結構 194
5.2.1.3 索引結構三大重要特點 198
5.2.1.4 插播小余緝兇精彩故事 201
5.2.1.5 妙用三特征之高度較低 203
5.2.1.6 巧用三特征之存儲列值 219
5.2.1.7 活用三特征之索引有序 248
5.2.1.8 不可不說的主外鍵設計 265
5.2.1.9 組合索引高效設計要領 272
5.2.1.10 變換角度看索引的危害 289
5.2.1.11 如何合理控制索引數量 295
5.2.2 位圖索引的玫瑰花之刺 297
5.2.2.1 統計條數奮勇奪冠 297
5.2.2.2 即席查詢一騎絕塵 302
5.2.2.3 遭遇更新苦不堪言 306
5.2.2.4 重復度低一敗涂地 309
5.2.2.5 了解結構真相大白 311
5.2.3 小心函數索引步步陷阱 315
5.2.3.1 列運算讓索引失去作用 315
5.2.3.2 函數索引是這樣應用的 317
5.2.3.3 避免列運算的經典案例 319
5.3 索引讓一系列最熟悉的SQL飛起來了 325
第6章 經典，表的連接學以致用 327
6.1 表的連接之江南三劍客 327
6.2 三大類型從小余跳舞一一道來 328
6.2.1 跳舞也能跳出連接類型 328
6.2.1.1 感覺怪異的嵌套循環 328
6.2.1.2 排序合并及哈希連接 329
6.2.2 各類連接訪問次數差異 330
6.2.2.1 嵌套循環的表訪問次數 330
6.2.2.2 哈希連接的表訪問次數 337
6.2.2.3 排序合并的表訪問次數 340
6.2.3 各類連接驅動順序區別 341
6.2.3.1 嵌套循環的表驅動順序 341
6.2.3.2 哈希連接的表驅動順序 343
6.2.3.3 排序合并的表驅動順序 345
6.2.4 各類連接排序情況分析 347
6.2.4.1 除嵌套循環都需排序 347
6.2.4.2 排序只需取部分字段 347
6.2.4.3 關于排序的經典案例 349
6.2.5 各類連接限制場景對比 350
6.2.5.1 哈希連接的限制 350
6.2.5.2 排序合并的限制 353
6.2.5.3 嵌套循環無限制 355
6.3 你動手裝備的表連接威震三軍 355
6.3.1 嵌套循環與索引 356
6.3.2 哈希連接與索引 362
6.3.3 排序合并與索引 363
下篇 飛翔意識天空——思想與案例的分享
第7章 搞定！不靠技術靠菜刀 368
7.1 SQL被一刀剁了 369
7.2 整個模塊丟棄了 370
7.3 調用次數減少了 371
7.4 排序不再需要了 372
7.5 大表砍成小表了 373
7.6 排重操作消失了 373
7.7 插入阻礙小多了 374
7.8 遷移事情不做了 375
第8章 升級！靠技術改隱形刀 377
8.1 大表等同小表了 378
8.2 大表切成小表了 379
8.3 索引變身小表了 380
8.4 刪除動作不做了 380
8.5 清表角度變換了 381
8.6 提交次數縮減了 382
8.7 遷移越來越快了 384
8.8 SQL語句精簡了 385
第9章 提問，也是智慧的體現 391
9.1 描述要考慮周全 392
9.2 用詞要盡量準確 393
9.3 說明要力求簡潔 394
9.4 問過的避免再問 396
9.5 能搜能試不急問 396
第10章 買魚，居然買出方法論 398
10.1 小余買魚系列故事 398
10.1.1 診斷與改進 398
10.1.2 需求與設計 401
10.1.3 資源的利用 403
10.1.4 真正的需求 404
10.2 買魚買出了方法論 405
10.2.1 一套流程 405
10.2.2 兩大法寶 407
10.3 方法論的應用案例 408
10.3.1 從我們的這一套流程說起 408
10.3.1.1 診斷 408
10.3.1.2 改進優化（首次優化） 409
10.3.1.3 需求與設計（再次優化） 410
10.3.1.4 資源利用（花絮） 412
10.3.2 案例映襯了經典兩大法寶 412
第11章 寶典，規范讓你少做事 414
11.1 抓狂，為何事總忙不完 415
11.1.1 技術能力不足的新人們 415
11.1.2 不懂提問智慧的求助者 415
11.1.3 產生各種失誤的粗心者 416
11.1.3.1 啊，小黃的DDL惹禍 416
11.1.3.2 慘，老師登錯環境了 417
11.1.3.3 糟，小羅忘操作…… 417
11.1.4 解決問題緩慢的技術員 419
11.1.4.1 優化效率低下的小高 419
11.1.4.2 為何老師能快速解決 420
11.1.5 陷入種種困境的開發者 422
11.1.5.1 超長SQL使小鄭煩惱 422
11.1.5.2 缺少注釋讓小葉沮喪 422
11.1.6 總是考慮不全的設計者 423
11.1.6.1 未提前規劃的王工 423
11.1.6.2 不了解特性的劉工 424
11.2 淡定，規范少做無謂事 425
11.2.1 學習規范——促成新人快速成長 426
11.2.2 求助規范——引導求助不再迷糊 427
11.2.3 操作規范——協助粗心者不犯錯 428
11.2.4 流程規范——保障問題快速解決 429
11.2.4.1 動態整體 429
11.2.4.2 動態局部 432
11.2.4.3 靜態整體 439
11.2.4.4 靜態局部 448
11.2.5 開發規范——讓開發者駕輕就熟 451
11.2.5.1 SQL編寫規范 452
11.2.5.2 PL/SQL編寫規范 455
11.2.6 設計規范——助設計者運籌帷幄 457
11.2.6.1 表規范 458
11.2.6.2 索引規范 461
11.2.6.3 環境參數規范 467
11.2.6.4 命名規范 469 |
| 序： |
|
