 |
-- 會員 / 註冊 --
|
 |
|
|
|
收獲，不止Oracle（第2版） ( 簡體 字) |
| 作者：梁敬彬,梁敬弘 | 類別：1. -> 資料庫 -> Oracle |
| 譯者： |
| 出版社：電子工業出版社 |  3dWoo書號： 50878
詢問書籍請說出此書號！【有庫存】
NT售價： 495 元 |
| 出版日：3/1/2019 |
| 頁數：464 |
| 光碟數：0 |
|
站長推薦：  |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787121360923 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：推薦序一
這是一本非常有趣的技術書，全書以對話穿插故事的形式完成編寫，讓人在輕松愉快中了解各種知識，構思讓人拍案叫絕。也正是由于如此出色的構思設計，本書第1版多次印刷，依然售罄。應業界的強烈要求，結合Oracle 12c的第2版新書終于面世了。
梁敬彬是我們公司的特級專家，他服務的客戶遍布全國各地，并取得了良好的口碑。他能在十分忙碌的工作之余，雷打不動地堅持每天早上4點起床整理技術知識，把自己寶貴的工作經驗撰寫成生動有趣的經典技術著作分享給廣大技術人員，我非常欣賞技術人的這份激情。
不過，我更欣賞的是梁敬彬身上的創新精神。梁敬彬同時也是我們研究院的副理事長，是研究院許多好點子的主要貢獻者之一，比如設置了EX幣、創辦了電子期刊、發布了懸賞令，策劃主持了技術比武等，將研究院運作得風生水起，引發了許多電信內部兄弟公司的興趣，并在電信集團層面進行了分享。
一個歷史悠久的公司能夠永葆青春，需要有優秀的內部創業文化，每個專家都要有創新精神，敢于否定自己的過去。梁敬彬就是我們公司許多有著創新精神員工的一個代表、一個縮影，希望更多員工能為公司多多建言獻策，未來聚焦“兩外兩T”業務，在互聯網化規模發展、機制創新、文化建設等方面進一步加快步伐，
期待公司出現越來越多的創新人才，以給我們帶來更多的驚喜。
吳剛
中電福富公司總經理
推薦序二
經典升級再現，技術傳播孜孜不倦
敬彬兄的經典著作《收獲，不止Oracle》要再版了，邀請我寫一篇推薦序。因為這本書本身寫得很好，推薦序于我而言就不太好寫了，相形見絀反而不美，那我就寫寫與敬彬相識相知的過程吧。俗話說，文如其人，人如其文，真誠的人寫的書也定是真誠的。
跟敬彬是在ITPUB時代的老友，大家在論壇里就各種問題互相回復，純然的技術友誼。第一次見面，應該是九華山會議，ITPUB請了一些版主見面聚會，敬彬給人的感覺就是溫文爾雅，彬彬君子。
第二次見面，是在2013年的DTCC會議上，我當時分享的議題是《大型業務系統Oracle數據庫10g到11g的升級實踐》，而敬彬分享的則是《贏在起點—談數據庫設計規范》。我有幸聆聽敬彬的分享，一個富有經驗的老師，將生活中的故事揉進枯燥的技術里，娓娓道來，引人入勝。之后敬彬的《收獲，不止Oracle》和《收獲，不止SQL優化》兩本書相繼出版，秉承了他的演講風格，內容提綱挈領，文字風趣幽默，講解深入淺出，讓讀者更易于吸收。
dbaplus社群成立后，敬彬在繁忙工作之余，多次參與社群的線上分享和線下峰會，用他獨特的方式持續傳播Oracle技術。如今他又投注精力將Oracle 12c/18c的新特性及這些年工作生活的新積累更新到《收獲，不止Oracle》（第2版）中，實乃讀者之福。
楊志洪
dbaplus社群聯合發起人，Oracle ACE，Oracle10g/12c OCM
推薦序三
別出心裁，另辟蹊徑
敬彬的新書就要出版了，邀我寫一點感受，于是就有了這一段文字。
我和敬彬相識是在2010年，那時我正在編輯《Oracle DBA手記》一書，偶然被他發表在ITPUB論壇上的一篇文章所吸引，那篇文章的題目是《DBA小故事之SQL診斷》，其內容鮮活、行文引人，于是就和他約了那篇稿子加入書中，郵件往來再到北京會面，就此熟識。
從當時的一篇文章到今天的一本書，我能夠清晰地看到作者一以貫之的思考和敘述方式，這種積累與堅持也正是作者成長和成功的要素之一。
當時那篇文章的感受和今天這本書是類似的，作者能夠用細膩的筆觸將自己的經歷真實生動地再現出來，并且帶領讀者一起經歷一次思維的探索，這是屬于他的獨特風格。
作者在書中反復傳達的核心觀點是：Oracle數據庫看似艱深的原理實際上和生活中的基本常識并無二致。理解了這一層意思，就能夠消除一些人對于這項技術的畏懼之心，此后的學習自然就能順風順水。
誠然如此，我也經常和朋友們說，對于Oracle的很多艱深算法，如果由我們去深思熟慮，其結果都必然大致相同。類似HASH原理、布隆過濾等算法，理解了你就只覺得巧妙而不覺艱深。
現在梁老師就為我們尋找了一系列源于生活、循序漸進的學習路線，如果你能夠細心領會，就會覺得這項技術實在是趣味橫生。
蓋國強（eygle）
Oracle ACE總監，云和恩墨創始人，ACOUG創始人
推薦語
梁先生的技術功底和文字功底同樣深厚，更重要的是，他具有作為講師那種縝密、體系化的思維方式，以及對讀者心思的透視力，因此成書脈絡清晰，里面還不斷穿插許多人生哲理、技術前瞻，讓人獲益良多。這本書非常適合入行者和在行業里謀求上升的同仁閱讀，動人的文筆可以讓你一口氣讀完這本書。這是一本值得向行業推介的優秀技術書籍。
黃志洪（tigerfish）
Dataguru創始人
到底是什么后天原因導致人和人之間的學習結果發生重大差異呢？其中有一點就是思維方式。于是我嘗試在思維方式方面去影響身邊的一些人，其中的很多人在各自的工作領域都獲得了成功，而在此之前他們卻是默默無聞的。
敬彬的這本書就是用詼諧幽默的語言生動地引導大家在意識層面發生改變，然后逐步轉化為行動上的改變。按此堅持，幾年下來，相信每個人都能邁上新的臺階，這的確早已超越Oracle的范疇，對我們學習、生活等諸多方面都有益處。
馮春培（biti_rainy）
支付寶平臺數據部資深總監
通讀本書，如醍醐灌頂，豁然開朗，本書從實戰出發，出發于技術，而超脫于意識，回味無窮。作者擁有多年的Oracle應用和體系架構設計經驗，付出了超于常人的努力，總結出眾多獨到的經驗，不失為一本好書，為學習和使用Oracle的技術人員帶來諸多益處。
傅祥文
中電福富公司運營總監
敬彬兄的書筆觸輕松而生動，在內容表現形式上使用了故事和對話場景，讓讀者在閱讀時有很強的代入感；書中展現了大量的腦圖總結，清晰直觀，十分便于知識的理解和記憶。此書無論對于新手還是資深技術專家，都具有極大的借鑒意義。在Oracle技術已然成熟的今天，帶給DBA的挑戰和機遇依然有增無減，希望敬彬的這本書能成為你Oracle學習生涯的起點。
楊建榮
dbaplus社群聯合發起人，Oracle ACE，《Oracle DBA工作筆記》作者
由梁敬彬、梁敬弘兄弟合著的《收獲，不止Oracle》一書出第2版了。第1版取得了很大的成功，成為業界數據庫書籍中的經典，堪稱不易。該書第2版是響應業界的聲音而再次出版的，融入了Oracle的新特性，預祝新書再次獲得成功，同時也祝兄弟二人在事業上不斷取得新的成就。
黃連生
清華大學計算機系教授
看過很多Oracle的書，讓我印象深刻的并不多，梁老師的這本書是我給新員工推薦的必讀書。這本書寓教于樂，將做事做人的道理潛移默化地傳授給讀者，雖然從事的是國產數據庫的事業，此書依然能夠給我們帶來很多啟發，收獲確實不止Oracle，你值得擁有！
黃海明
達夢技術總監
敬彬兄這本書有著與市場上其他Oracle書籍不同的特點，通過一個個精彩的小故事，串起Oracle的核心知識和優化方法論，并時刻強調學習和工作的意識，如何不被技術束縛，如何跳出技術，意識和方法真的很重要。相信讀完本書，你的收獲，絕對不止Oracle！
丁俊（dingjun123）
ITPUB Oracle開發版資深版主，《劍破冰山—Oracle開發藝術》副主編
梁敬彬先生通過自己在日常工作和培訓中的磨煉，把自己對Oracle技術的感悟，通過一個個生動鮮活的小故事，淺顯而又形象地展現了出來。對于初學者來說，可以慢慢地在一個個小故事中去了解Oracle數據庫。讀完這本書，你也許會恍然大悟：“哦，原來Oracle是這樣子的。”
羅海雄（rollingpig）
前言
? ? ?
邁出嶄新一步—
本書特點及存在的意義
0.1 當今時代，既是最好的也是最壞的
近年來，我深刻地體會到，如今這個時代對于絕大部分技術人員而言是幸福的時代，能在這個時代從事IT技術相關工作的技術人員應該很開心。因為比起老一輩技術人員，現今的技術人員幾乎從來就不缺學習參考資料。除了可以在各技術平臺的官方網站下載到詳盡且準確的資料，還可以很容易地在各種搜索引擎中搜索到自己想要的答案，也可以很方便地在各種技術論壇上注冊提問從而獲取別人的幫助。
然而，這個時代對技術人員來說也是痛苦的時代。無論是傳統的電信、金融、證券行業，還是新興的互聯網行業，我們都不難發現運維系統涉及的數據量、訪問量及并發量都在以驚人的速度不斷激增。重壓之下，很多IT系統運行舉步維艱，技術人員壓力巨大，甚是痛苦。除了負載壓力外，系統的復雜度也隨著業務復雜度的增加而呈指數級增加，讓開發設計人員頭昏腦漲，讓故障診斷及系統維護的相關技術人員無從下手。
痛苦還不止于此，在這個時代，除了海量負載和高復雜度，還有讓技術人員應接不暇而無所適從的各種新技術。且不討論IT所有技術，僅以數據庫為例，除了以Oracle、DB2等為代表的一系列傳統關系數據庫外，還有內存數據庫、列式數據庫、以HBase為代表的分布式數據庫等，讓人眼花繚亂。此外，除了各類紛繁技術的選型外，我們還要適應具體各個版本的不斷更新，以Oracle數據庫為例，從早期的Oracle 5版本到今天的Oracle 12c，Oracle每一次發布新版本都需要我們投入大量的精力和時間去學習和適應。
這是幸福的時代，也是痛苦的時代。這是最好的時代，也是最壞的時代。
0.2 技術人員，真正的差距其實在意識
在這個特點鮮明的時代，我目睹了一大批在IT項目中不能有效適應這個時代而導致摔得鼻青臉腫的技術人員，而這些人之中大多還是勤奮上進之人，少數還是技術能手。當然，也有成功的例子，讓我來說說他們的故事吧。
0.2.1 小白的故事
工作兩年多的小白是一個很努力的員工，每天除了用心工作外，還堅持充電學習，兩年來他除了把Oracle的官方文檔幾乎讀了個遍，還購買了不少相關的書籍來學習。由于小白的項目組工作強度大，時常需要加班，因此小白工作、學習外的時間就只夠吃飯和睡覺了。那他的工作表現很出色嗎，天道是否一定酬勤？實際情況卻是不盡如人意，雖然他了解很多相關知識，可是在實際工作應用中卻不得要領，頻頻出錯，領導經常對其提出批評，他自己也相當苦惱。
其實小白只是因為缺少了一種被稱為“意識”的東西，這個意識就是，該如何學習。在他的學習過程中，他犯了很多錯誤。
1. 忽略了知識的重點
小白讀完了Oracle官方文檔的幾乎所有內容，毅力讓人欽佩！遺憾的是，他忽略了“二八現象”這個事實：20%的知識，解決80%的問題。小白根本不需要讀完Oracle的所有文檔，他所在的項目組是從事數據庫開發相關工作的，而他卻花費了大量的時間閱讀完了至今他都尚未開始從事的數據庫管理相關知識，比如備份恢復、RAC、DATAGUARD部署及高級數據同步復制相關的技術，這是完全沒有必要的。
另外，語法方面的資料小白也根本無須細讀、記憶，因為平時用得多的語法，自然記得住，遇到偶爾忘記的場合再去官方文檔翻閱即可，現在各種搜索引擎的功能也非常強大，搜索到相關語法易如反掌。
人的精力是有限的，如果我們做到當前做什么事對應學習什么知識，盡量理解原理而不強記語法，將能省下多少寶貴的時間啊。
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.2 小劉的故事
1. 該如何請教他人
工作近5年的小劉特別勤學好問，工作中一遇到不明白的技術問題就問，有時問周圍的同事，有時發帖子在論壇上提問。可是最近他非常郁悶，因為總是沒人愿意回答他的問題。是不是大家不夠團結友愛？非也！問題出在他自己身上，你們知道為什么嗎？
讓我們來看看他是怎么問的吧。
“請問，對表的某列建索引如何建？”
“請問，分區表中刪除分區后，索引會不會失效？”
“哦，您說我問過同樣的問題了，我怎么記不起來了？”
前兩個提問有問題嗎？不少人都覺得一點問題都沒有，其實是很有問題的。因為很顯然第一個問題可以在搜索引擎中搜索到，而第二個問題除了可以搜索外，完全可以通過做一個試驗來得出結論。
網上可以很方便地搜索到的東西去問別人無異于浪費別人的時間，當今這個時代，搜索能力成為最重要的能力之一。知道關鍵字的比不知道關鍵字的搜索能力更強；英文好的比英文糟糕的搜索能力更強。為什么不去鍛煉自己這方面的能力呢？顯然可以動手試驗證明結論而不去試驗，會讓你白白失去一個寶貴的試驗和總結的機會。
第三句對話暗示該同學經常問同樣的問題卻不自知，這說明了什么？別人告訴你答案時，你思考過嗎，記錄過嗎，總結過嗎？
2. 問題該怎樣描述
某次我在外地出差，下飛機后打開電腦，收到了小劉的一封求救郵件，內容是這樣寫的：今天早上上班發現寧夏的數據庫很慢，請幫忙診斷分析一下，萬分感謝！
之前我還收到過小劉的另外一封求救郵件，內容是這樣寫的：緊急求救，湖北數據庫崩潰了，請盡快幫忙處理，謝謝！
從這兩封郵件可以看出來，求救者嚴重缺乏經驗，在溝通上存在著巨大的問題，你們知道是什么問題嗎？
先說這個“慢”的郵件，是某個局部慢還是整個系統都很慢，不同情況的處理方式截然不同。是今天開始忽然變慢還是一直以來都慢，直至今天再也無法忍受，不同情況的處理方式顯然是截然不同的。再說這個“慢”字，有一次我對求助者說，這個語句1秒就執行完了，你怎么會覺得慢得受不了了？他的回答是，原先只需要0.1秒左右，這個語句一天可是會跑上千萬次啊。哦，原來1秒也讓人覺得超級慢。還有一次有個求助者對我說，這個語句現在要跑2個多小時啊，原先超級快，只需要5分鐘左右。哦，原來5分鐘也有人覺得超級快。因此，你準確地告訴我現在要執行多長時間，希望執行多長時間，不是很準確嗎？
再看第二封郵件，崩潰了？什么叫崩潰了，是數據庫忽然關閉無法啟動，還是系統運行太緩慢，還是數據文件丟失？哦，我來公布答案吧。后來知道這個“崩潰了”原來是指系統資源負載太高，系統運行緩慢。原來這就是崩潰了，為什么要說這么模糊的字眼呢？
還有，這兩封郵件都有一個共同的特點，就是既沒有提供接口人的聯系電話，也沒有提供所需要處理的機器的IP地址、登錄用戶名和密碼。
毫無疑問，接下來我要再確認好多次，才能最終幫上他。
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、內存配置情況嗎？”答曰沒注意。
好了，這就是原因了，讓我來告訴大家我調查的結果吧。全庫有1TB大，其中某記錄操作日志的表T1就達到400GB，連同索引，大小合計500GB左右，近乎占一半的量。而和業務人員確認的結果是，T1表可以暫且不導出，只需在新環境中建表結構即可。前20名的大對象中除了巨無霸T1表外，還有不少也很龐大，其中有一張單表即有120GB，只需保留最近三個月的記錄即可……經過我的確認，1TB的數據最終只需要導出300GB左右。
接下來的調查還發現了更加驚人之處，導出和導入的機器的CPU個數居然都達到64個，強勁得讓人驚嘆！而我觀察操作的腳本，也有寫并行度，但只是隨便寫了PARALLEL=8。當時是凌晨，我們完全可以將導出導入的并行度設置得更大，比如設成60都不為過，這里又將會有5倍以上的提速。
后面我告訴他們，其實這次導出導入只需要合計2小時就足夠了，不需要4小時，更不會操作了整整16個小時！
4. 充分準備是要領
某次我應邀去安徽某工程點進行數據庫調優，周二晚上接到通知，要求周三下班前趕到現場，周四一天之內要把系統性能顯著提升，從而應對周五集團的檢查工作，當時公司領導也在現場，情況相當緊急。
這是一件相當讓人頭疼的事，因為系統調優是一項相對復雜和艱巨的任務，要求在一天時間內立竿見影，可能性很小。雖說沒有把握，但是也只好硬著頭皮去試試看，我在出發前做了充足的準備，這些準備方法大多來自平時的積累，這種積累非常寶貴、非常重要。有了這些重要的準備，我在出發前通過工程點現場同事的配合，獲取了大量我想了解的重要信息，在路上和飛機上做了充分的分析和研究，等下午6點到工程點現場，我已經對這里的情況了如指掌。
然后，晚上調優到凌晨2點，第二天再奮戰一天，第三天，系統終于運行平穩了，IDLE從原先的0∼1%變為40%∼50%，系統性能顯著提升。
這個小故事說明了一個道理，積極的準備是很重要的。我準備了一個非常詳細的處理及定位問題的流程和思路，從動態到靜態，從整體到局部，非常詳盡和實用，將會在后續分享給大家。讀者可以從中體會到我是如何定位以及分析探索問題的，此外，還可以學習到我所總結的優化思想和方法論。
0.2.4 故事的總結
至此我講完了小白、小劉和我自己的故事。別小看這三個人的故事，其實都是非常典型的。這其中小白的故事告訴了我們學習是很有技巧的，是一門技術活。而小劉的故事告訴我們如何提問、求助以及制定規范是非常重要的。最后我本人的故事告訴大家，很多時候，解決問題不一定完全依靠技術本身，我的4個故事中的制勝法寶全部是非技術的，這說明技術雖然重要，但是不能僅僅依賴技術。
0.3 收獲Oracle，更收獲“少做事”
包括我在內的幾位技術人員的故事表面上說明的重點各不相同，實際上有一點是相同的，那就是一個非常重要的意識：準確地把握需求，盡可能少做事！不要小看了這句話，這是永不過時的一句話，生活難道不是如此嗎？
精簡起來可以用三個字概括：少做事。
就只是少做事？
別驚訝，讓我們一起分析一下。
小白是一位數據庫開發人員，數據庫開發就是他的工作職責，很顯然他的學習任務就是了解數據庫開發的相關知識。他這時就應該選擇性地進行學習，盡量拋棄和工作任務無關的知識，例如數據庫的遷移、備份、部署等相關知識與他工作無關，就可暫且不學，這就是少做事。
暫時在工作中應用不到的內容先不學，何樂而不為？接下來我們還要保證精簡學習的內容，要最快地掌握，別拖拖拉拉地學了三五年，這不符合這個時代的要求。這時最大的技巧就是將學習和工作結合在一起，帶著知識點該如何落地應用以及什么時候該選擇什么技術的想法去學習，這樣目的性極強的探索性質的學習，往往學習一遍就夠了，那些為了學習而學習的傳統方法，學了很多遍往往也無法有效地應用到工作中去。這又是少做事。
小劉為了能更好地提升自己的技術水平，經常請教他人，希望快速獲取別人的幫助。節省時間，本質是想少做事，這個出發點是對的，但是他問的問題是可以很方便地搜索到的，這樣的提問對被提問者來說，就是讓被提問者多做無意義的事，浪費生命，所以能搜索到的問題盡量不要去請教他人。同理，問過的問題也盡量不要再問。此外，自己動手做試驗來證明結論，這件事表面上看不如直接問或者查資料來得快，不過試驗可以讓你在動手動腦的鍛煉中加深印象從而過目不忘，和那些由于從不動手進行試驗而導致學習過于浮躁、停留于表面，最終反復學習多次都無法很好掌握相關知識的人相比，顯然也是少做事了。
小劉的兩封郵件表達得過于糟糕，導致我一頭霧水無從下手，最終必然要再次聯系反復交流。為什么不養成好的習慣，一次性說清楚，讓大家都快速投入到故障處理工作中去呢？這也是少做事。
接下來說小劉的工作失誤，文檔規范、評審等看似是多做事了，其實也是典型的少做事，因為公司、部門的工作大多都有通用性，有了這些準備資料，交接的工作者可以直接拿來使用，既準確又省心，就是少做事。
最后點評自己的故事。湖北之行是一次精簡程序和為表瘦身的旅程，顯然是一次少做事的經典之旅，三句話解決故障顯然是一次最精簡的故障定位案例。接下來說數據遷移案例，從導出1TB到導出300GB，是否很有技術含量，可以說沒有，也可以說有。說沒有是因為這真的沒什么技術可言，說有是因為有意識的人比起沒意識的人，差別是非常大的。最后說說安徽之行我準備的文檔和腳本，且不說提前準備后讓我一到現場就開始解決問題，少做了定位問題的事（提前在路上完成了），節省了寶貴的時間，就說這份文檔和腳本的分享，足以讓后人少做不少事，節省不少時間。
點評完三個技術人員的故事，我的書要怎么寫呢？前面說了這么多，其實主要在談如何少做事的意識，現在這本書的主基調就明確下來了，就是主要和大家分享少做事解決問題的思路和方法。
分享這個主題首先要選擇一個場景或者道具來和大家講述，選擇什么道具呢？考慮到現在IT行業中開發、設計、測試、維護等幾乎所有IT相關技術人員，或多或少都需要接觸到關系數據庫，而Oracle又在當前關系數據庫的市場份額中遙遙領先，因此學習Oracle會讓絕大多數人更容易找到合適的工作，從而在就業之路上多一些選擇，少一些奔波。于是本著盡量少做事的原則，我們的道具確定是Oracle。
圍繞Oracle我們將會驚奇地發現，其實在Oracle技術本身的細節中，到處滲透著少做事的思想，從體系結構到物理結構，從表到索引的設計，無一例外。例如，SQL執行第二次就會比第一次更快，顯然是因為第一次執行保存了共享池的解析動作，緩存了磁盤中的數據，第二次無須再解析，無須再去物理磁盤讀取數據，從而提升了性能，這就是少做事。又如索引的體積一般比表小得多，如果能只訪問索引完成需求一定比在表中進行更快，這也是少做事。再比如分區表，如果沒有設置分區表，則需要全表掃描，如果設置了分區表，或許只需要在某個分區中查找即可，訪問的路徑少多了，這也是少做事……這些例子不勝枚舉，多得可以寫成一本書。哦，不對，就是可以寫成一本書，這本書不就主要寫這個嗎？
本書不會將Oracle的所有知識都描述完，其中只涉及體系結構和物理結構，表、索引與表連接這幾個章節，雖然涉及的內容不多，但卻是非常核心和重要的，所有不同角色的人員都離不開這幾個章節的學習，這是共性的部分，只有把這幾個章節學好了，后面的學習才有意義，這是為了避免讓大家像小白一樣一頭霧水、漫無目的地去學習，少做和自己任務無關的事。另外，最重要的是我講述的學習的路線圖和思路以及方法，這就是少做事的體現。
此外，我特別強調知識的落地，探討最多的話題就是，學習這些知識有什么用，和不知道這些知識的人相比，在工作中有什么差別，從而保證大家不浪費時間。在這些章節中，大家將會和我一起體會，原來理解體系結構后，我們可以把一條常見的SQL語句的執行時間從原先的42秒完成提升到0.01秒左右，實現一次從單車到飛船的飛躍；原來理解了索引后，立即就可以著手優化身邊最常見的SQL語句。
接下來書中有另外一個重點部分，就是我的方法論、工作習慣、實用的準備工作腳本以及相應的經典案例，這些章節再次強調了理解業務、盡量少做事或不做事的思想有多么重要。
這就是本書的全部內容，學完本書后，大家還會發現，原來用少做事的思想去學習數據庫是那么親切，那么容易理解和記憶。用盡可能將知識落地在工作中的意識去學習，學完后應用在工作中的那種感覺，是多么讓人興奮。
最后就是寫書風格的確認了，這是一本非常有趣的書，靈感來源于我平時大量的授課。很多學員告訴我他們特別喜歡上我這樣風格的課程，非常容易理解也非常實用。對此我很開心，猛然有一天有了這樣的一個想法，將我的視頻變成文字，這個想法得到我弟弟梁敬弘博士的大力支持，并答應幫我一起完成此書。于是全書就變成了“老師講課、學生聽課，老師提問、學生回答，學生提問、老師解答”這樣輕松的對話方式。我終于實現了將視頻變成文字。這本書成了一本輕松的書，讀者很容易身臨其境產生共鳴。而我講述知識的方式也變得非常靈活了，有時故意不說的重點知識，在學生們的思考中被引發出來，而讀者也一同經歷了這個難忘之旅。本書還有一個顯著的特點，就是所有的知識點推論都有試驗證明，而這些試驗讀者完全可以自己進行，再現老師的結果。這在保證知識準確性的同時，能讓讀者進一步加深印象。不過全書最有趣的特點還是我構造的小余一家的故事。
學完本書后，大家就會發現，雖然當前數據壓力比較大，但是并不可怕。其實調優如同生活一般，一點都不神秘。在老師的故事中，平均每處理10個成功案例中，就有5個不是依賴技術來解決的。牢牢抓住需求，在設計和開發中巧妙地應用“少做事，不做事”的思想，產品就能高效，且很少存在性能問題，因此就很少需要調優。
學完此書后相信大家會有一種強烈的感覺，原來學習技術可以如此輕松，原來學習要落地才有意義，原來少做事的意識這么重要。如果大家真有這個感覺，那我的所有努力—用心良苦的書寫風格、精心構造的試驗腳本、精彩有趣的經典案例就沒有白費。
最后我希望讀者—收獲，不止Oracle！ |
內容簡介：在這本書里，讀者將會跟隨作者一同對Oracle數據庫的相關知識進行梳理，最終共同提煉出必須最先掌握的那部分知識，無論你是數據庫開發、管理、優化、設計人員，還是從事Java、C的開發人員。接下來作者再將這部分知識中最實用的內容進一步提煉，濃縮出最精華的部分，分享給大家。這是“二八現象”的一次經典應用。這部分知識就是Oracle的物理體系結構、邏輯體系結構、表、索引以及表連接五大部分。通過閱讀本書中的這些章節，讀者將會在短時間內以一種有史以來最輕松的方式，完成對Oracle數據庫的整體認識，不僅能解決工作中的常規問題，還能具備一定的設計和調優能力。通過對這些章節的學習，讀者在Oracle的學習中一定會有極大的收獲。然而，作者更希望看到的是：讓讀者的收獲，不止Oracle。為達到此目的，作者精心將全書分成上下兩篇，剛才所描述的具體知識點體現在全書的上篇中。而在下篇中，讀者將通過各種精彩故事、生動案例，體會到該如何學習和如何思考，在意識的天空拋開束縛，無拘無束、盡情飛翔。在這里，讀者也許會有疑問，前面說的有史以來最輕松的方式是一種什么樣的方式呢？還請親愛的讀者自己去揭曉謎底吧。
|
目錄：上篇 開啟驚喜之門——帶意識地學Oracle
第1章 意識，少做事從學習開始 2
1.1 選擇先學什么頗有學問 2
1.1.1 梁老師課堂爆笑開場 2
1.1.2 看似跑題的手機分類 3
1.1.3 學什么先了解要做什么 5
1.2 善于規劃分類才有效果 6
1.2.1 分類與角色密切相關 6
1.2.2 角色自我認識有講究 8
1.3 明白學以致用方有意義 11
第2章 震驚，體驗物理體系之旅 12
2.1 必須提及的系列知識 12
2.2 物理體系從老余開店慢慢鋪開 15
2.2.1 老余的三個小故事 15
2.2.2 體系結構原理初探 18
2.2.3 體系結構原理再探 28
2.3 體系學習讓SQL語句性能提升千倍 59
2.3.1 一起探索體系學習的意義 59
2.3.2 單車到飛船的經典之旅 63
2.3.3 精彩的總結與課程展望 73
2.4 走進12C新特性之多租戶架構 75
2.4.1 大樓里的江湖爭斗 75
2.4.2 強大的多租戶架構 76
2.4.3 多租戶架構的好處 78
第3章 神奇，走進邏輯體系世界 79
3.1 長幼有序的邏輯體系 79
3.2 邏輯體系從老余養殖細細說起 80
3.2.1 農場的體系邏輯結構 80
3.2.2 農場之塊漫談 84
3.2.3 農場之區與段 85
3.2.4 農場之表空間的分類 87
3.2.5 邏輯結構之初次體會 88
3.2.6 邏輯結構之二次體會 93
3.2.7 邏輯結構之三次體會 98
3.3 課程結束你給程序安上了翅膀 109
3.3.1 過度擴展與性能 110
3.3.2 PCTFREE與性能 112
3.3.3 行遷移與優化 115
3.3.4 塊的大小與應用 116
第4章 祝賀，表的設計成就英雄 122
4.1 表的設計之五朵金花 122
4.2 表的特性從老余一家展開描述 123
4.2.1 老余一家各施所長 123
4.2.2 普通堆表的不足之處 123
4.2.3 奇特的全局臨時表 135
4.2.4 神通廣大的分區表 142
4.2.5 有趣的索引組織表 170
4.2.6 簇表的介紹及應用 173
4.3 理解表設計的你將成為項目組英雄 174
4.4 走進12C新特性之分片技術 175
4.4.1 如日中天的E公司 175
4.4.2 神奇的分片分布式技術 176
第5章 驚嘆，索引天地妙不可言 180
5.1 看似簡單無趣的索引知識 180
5.2 索引探秘從小余緝兇拉開帷幕 180
5.2.1 BTREE索引的精彩世界 180
5.2.2 位圖索引的玫瑰花之刺 277
5.2.3 小心函數索引，步步陷阱 293
5.3 索引讓一系列最熟悉的SQL語句飛起來了 302
5.4 走進12C新特性之索引優化 304
第6章 經典，表的連接學以致用 306
6.1 表的連接之江南三劍客 306
6.2 三大類型從小余跳舞一一道來 306
6.2.1 跳舞也能跳出連接類型 306
6.2.2 各類連接被訪問次數的差異 309
6.2.3 各類連接驅動順序的區別 319
6.2.4 各類連接排序情況分析 324
6.2.5 各類連接限制場景對比 327
6.3 你動手裝備的表連接威震三軍 332
6.3.1 嵌套循環連接與索引 332
6.3.2 散列連接與索引 338
6.3.3 排序合并連接與索引 338
下篇 飛翔意識天空——思想與案例的分享
第7章 搞定！不靠技術靠菜刀 342
7.1 SQL語句一刀被剁了 342
7.2 整個模塊丟棄了 343
7.3 調用次數減少了 345
7.4 排序不再需要了 345
7.5 大表砍成小表了 346
7.6 排重操作消失了 347
7.7 插入阻礙小多了 348
7.8 遷移事情不做了 348
第8章 升級！靠技術改隱形刀 350
8.1 大表等同小表了 351
8.2 大表切成小表了 352
8.3 索引變身小表了 353
8.4 刪除動作不做了 353
8.5 清表角度變換了 354
8.6 提交次數縮減了 355
8.7 遷移越來越快了 356
8.8 SQL語句精簡了 357
第9章 提問，也是智慧的體現 363
9.1 描述要考慮周全 364
9.2 用詞要盡量準確 365
9.3 說明要力求簡潔 365
9.4 問過的避免再問 367
9.5 能搜能試不急問 368
第10章 買魚，居然買出方法論 370
10.1 小余買魚系列故事 370
10.1.1 診斷與改進 370
10.1.2 需求與設計 372
10.1.3 資源的利用 375
10.1.4 真正的需求 375
10.2 買魚買出了方法論 376
10.2.1 一套流程 376
10.2.2 兩大法寶 377
10.3 方法論的應用案例 378
10.3.1 從我們的這一套流程說起 378
10.3.2 案例映襯了兩大經典法寶 383
第11章 寶典，規范讓你少做事 384
11.1 抓狂，為何事總忙不完 384
11.1.1 技術能力不足的新人們 385
11.1.2 不懂提問智慧的求助者 385
11.1.3 產生各種失誤的粗心者 386
11.1.4 解決問題緩慢的維護人 388
11.1.5 陷入種種困境的開發者 391
11.1.6 總是考慮不全的設計者 392
11.2 淡定，規范讓你少做無謂事 395
11.2.1 學習成長規范——促成新人快速成長 396
11.2.2 求助規范——引導求助不再迷糊 397
11.2.3 作業操作規范——協助粗心者不犯錯 398
11.2.4 流程規范——保障問題快速解決 399
11.2.5 開發規范——讓開發者駕輕就熟 420
11.2.6 設計規范——助設計者運籌帷幄 425 |
| 序： |
|
