《Oracle10g性能分析與最佳化思路》是2010年出版的圖書，作者是譚懷遠。
基本介紹
- 書名：Oracle 10g性能分析與最佳化思路
- 作者：譚懷遠
- ISBN：978-7-121-11325-3
- 頁數：456頁
- 定價：59.00元
- 出版時間：2010年8月
- 開本：16開
宣傳語,內 容 簡 介,作 者 簡 介,序,前 言,目 錄,
宣傳語
國內第一本真正意義上從工作經驗出發，
以作者的心得體會全面論述Oracle資料庫性能最佳化的書籍。
編寫風格流暢 注重實效 學習Oracle，可以從這裡開始 ..
內 容 簡 介
在這本書里讀者將會學到作者在性能最佳化方面的一些思路和思考，一些故障處理的方法和原則，這些東西是作者在實踐中長期積累的心得體會，當讀者掌握了一些處理問題的基本思路之後，成為一名合格的DBA就是一件輕而易舉的事情了。
作 者 簡 介
譚懷遠，副總工，DBA團隊負責人，在國內屬於較早進入專職DBA崗位的人。是國內著名資料庫論壇ITPUB的資深版主，論壇id alantany。有10年的Oracle DBA工作經驗，從Oracle 8開始進入資料庫領域，從Oracle 8到Oracle 8i,Oracle 9i,Oracle 10g，見證了中國DBA職業的發展歷程。作者對資料庫的性能最佳化有獨到的見解，頗擅長於海量數據資料庫的設計管理及最佳化工作。
序
性能最佳化是資料庫套用的核心問題。目前的商業或開源的資料庫產品，發展已日臻成熟，很少有經常發生崩潰急需修復的情形。故DBA除了日常的常規維護任務外，大多把精力花在最佳化資料庫上。在2005年的時候，ITPUB也曾出過一本《Oracle資料庫性能最佳化》（蓋國強、馮春培、葉梁、馮大輝主編）的技術書，頗受Oracle DBA們的歡迎。現在很高興地看到在ITPUB技術叢書里又增加了一本關於資料庫最佳化知識的書籍。
ITPUB於2001年9月26日成立的，已發展為國內最大的資料庫技術討論社區。本書作者譚懷遠先生則是在2001年9月28日加入了ITPUB，相交至今將近九年時間。他在這么長久的時間，長期工作在資料庫業務的第一線，積累了大量豐富的經驗，也形成自己獨到的見解。而這些見解，又大部分體現在本書的文字里，本書既是知識的歸納總結，同時又是個人技術感情（恕我在這裡使用了一個創新的辭彙，大多數長期從事技術工作的人，都有一種有墨在胸，不得不發的感覺）的抒發。縱觀全書，我個人對作者所說的“最難的東西不是技術本身，而是什麼時候該用什麼技術”深表認同。當DBA從煩瑣的日常工作脫身出來，舉目遠望的時候，再往前的一片田野便是架構問題，最好的最徹底的，能一勞永逸的最佳化，往往從架構設計開始。期待懷遠君將來的新作，可以在這片更廣闊的天地里馳騁。
我感到本書最大的一個特點在於，作者通過自己的一種情緒化的東西在寫作，也可以說是對於技術的一種感情告白，所以是真摯的，這種真摯將影響到讀者閱讀時的情緒，讓你在一種頗為感性化和人性化的氛圍里閱讀，輕鬆而又有趣，而不是冷冰凍的枯燥的技術討論，這是本書區別於其他技術類書籍的一個顯著特點。
本書里，涵蓋了幾乎所有最佳化相關的知識點，以及一些很新的內容，比如bind peeking、並行執行、執行計畫、Cardinality（基數）、10053事件等，這些內容對於那些渴望深度了解性能最佳化的讀者來說，是非常有用的。
ITPUB前身是在smiling上的Oracle電子小組，剛剛開始的時候ITPUB的板塊不多，只有Oracle資料庫管理、Oracle開發、OCP、Cisco、網路集成、海闊天空這幾個板塊，會員數只有一萬多人，今年過9年的發展，ITPUB已擁有技術板塊100多個，註冊會員數量超過230萬人。每天更新的討論帖數以萬計。ITPUB的發展與像懷遠君這樣的專家、第一線技術工作者的長期支持是分不開的，在此也向懷遠君表示感謝，沒有你們就不會有今天的ITPUB。
ITPUB創始人 tigerfish
2010年6月8日
很多年前就在itpub看到作者的身影，也了解到作者管理著大量的資料庫。多年的不斷錘鍊讓作者在Oracle資料庫領域有了豐富的經驗。在資料庫最佳化領域，國內的書籍相對比較少，不論哪種資料庫，比較多的都是類似工具手冊一樣。寫書是一件很不容易的事情，對作者的知識體系有著極高的要求，所以市面上流傳的很多都是簡單地將英文的文檔翻譯為中文的手冊類的書籍。作者將自己多年的經驗用自己的語言和通俗的比喻給我們展示出來，帶給人的是另一種體驗，更親切和容易理解。除了常規的最佳化所涉及的範疇及Oracle 10g開始推出的AWR和ASH之外，作者還引出了10053這樣的CBO相關的事件及不少的Hint方法，這些都將幫助我們非常深入地研究資料庫的 SQL最佳化問題。相信作者將親身經歷的體驗深入淺出地展示給我們，能給Oracle資料庫愛好者很好的幫助。
——馮春培（biti）
當我們在2004年開始編輯出版Oracle技術書籍時，國內原創的作品還十分有限，現在，這種情況完全改變了，越來越多的技術愛好者開始總結、寫作和分享，Oracle技術出版物開始豐富起來。在這個歷程中，ITPUB論壇一直推動著Oracle資料庫技術的探討和套用，作者alantany正是來自於ITPUB的一位技術專家，他將自己多年的實踐與經驗不斷總結出來，和我們大家分享，這種精神與堅持值得我們尊敬，我樂於見到這樣的作品問世，也期待作者能夠堅持不懈，不斷同我們分享他的知識與經驗。
——蓋國強（eygle）恩墨科技創始人，Oracle ACE總監
很欣喜地看到這幾年來國內Oracle資料庫技術原創書籍的蓬勃發展，對每一位能夠坐下來並且將自己的經驗寫出來的作者我都報以深深的敬意。對於Oracle資料庫而言，也許在現在隨著安裝的日漸簡易和默認性能的不斷最佳化，一份默認的資料庫安裝，甚至是保證資料庫可以正常運行都不再需要太多的專業知識，然而資料庫最佳化仍然是非常專業的部分，這需要多年的實際工作經驗積累。 可以說這本書的作者擁有得天獨厚的工作環境，據我所知，他所參與管理的資料庫無論是數量還是大小還是性能要求上在國內都可以排入前列，因此這是一本融合了真知灼見、可以指導實際工作的Oracle資料庫性能最佳化書籍。 實際上我更希望讀者們可以從後記開始讀起，作者在後記中提及的所有觀點都與我不謀而合，我同樣相信無論是後記中這些觀點還是全書中記錄的技術知識，對於所有從業人員都有極大幫助。
——業內資深Oracle技術專家，Oracle ACE張樂奕（Kamus）
據我所知作者是中國獨立撰寫Oracle性能最佳化書籍的第一人，該書幾乎涵概了Oracle性能最佳化的所有主題，在國內資料庫性能最佳化領域的書籍中實屬罕見。
——謝永生（warehouse) 資深Oracle培訓講師
The fast and easy way to understanding the fundamentals of database performance tunning. If you’re tired of wading through huge technical manuals that drown you in jargon, making it difficult to decipher database performance issues, help has finally arrived. Simple enough for a beginner, but challenging enough for an advanced user, this book is your shortcut to mastering database perfperformance tunning.
本書提供了一種理解Oracle性能最佳化的簡單快捷的方法。如果你已經被成堆的關於性能最佳化的技術手冊淹沒，身心疲憊，無從下手，那么，這本書將幫你走出困境。無論你是初學者，或是經驗豐富的技術人員，你都將從這本書中獲得一個掌握資料庫性能最佳化的捷徑。
——Mike ITG (Investment technology group) 資深軟體工程師
前 言
筆者在寫這本書的時候，翻看了很多當前國內資料庫方面的書籍，發現寫性能最佳化的書並不多，特別是從工作經驗和思路上來討論性能方面的書，更是少之又少，這些因素讓筆者思考要寫這樣一本書，這也算是這本書的一個定位。
在這本書里，你將會學到筆者在性能最佳化方面的一些思路和思考，一些故障處理的方法和原則，這些東西是筆者在實踐中長期積累的心得體會，在筆者看來，掌握處理問題的方法和分析問題的思路在日常工作中顯得更為重要，當你掌握了一些處理問題的基本思路之後，剩下的工作就是去Google或者閱讀參考書了。
本書的一個特點是，凡是作者提到的觀點，都儘可能地使用一些例子來證明它，這樣看起來更有說服力一些。
為什麼會出現資料庫的性能問題
性能問題是最近幾年來DBA們越來越關注的一個資料庫技術領域，歸根結底，造成它的原因是最近幾年信息化進程的飛速發展，導致了很多系統的用戶數量猛增，資料庫中存儲的數據量亦成幾何級數激增，資料庫作為數據處理和存儲的最終受體，將必然直接承擔這種變化導致的性能下降。因此在人們對信息的依賴性越來越強的時候，對信息使用的效率也變得越來越關注，這樣資料庫的性能最佳化問題就日益嚴重地壓在DBA的身上。
什麼時候需要對性能進行干預
itpub是國內最早的一個專業討論Oracle資料庫技術的論壇，目前在國內資料庫方面已經相當有知名度，筆者是2001年註冊的，算是最早的會員之一。目前仍然會經常上去看看，由於工作內容的關係，我比較關注性能方面的帖子，發現以下一類的帖子經常有很多，比如：
1. 我是一個DBA，我現在手頭有一個資料庫，我該從哪裡進行性能最佳化呢？
2. 這是我的資料庫的一個Statspack，我該如何最佳化？
通常對於第一個問題，我是很少回答的，並不是不屑於回答，實在是沒有辦法回答，如果我回答說，“你怎么知道你的資料庫需要最佳化？”又擔心這種沒有實際意義的回答帶有說教意味，打擊別人的積極性，所以通常看看而已。實際上我是想說，對於一個DBA來講，當你拿到一個資料庫的時候，你首先需要做的是用最短的時間來了解一下跑在這個庫上的是一個什麼系統，比如是線上事務（OLTP）系統還是線上分析（OLAP）系統，這對於你做出性能上的判斷至關重要，如果連繫統都不了解，真不知道該如何去最佳化它，這就好比說，要設計一輛汽車，如果連用戶對汽車的喜好都弄不清楚，如何能設計出一個取悅於用戶的車呢？
對於第二個問題，像是比第一個具體一些，因為帖子作者已經提供了一個性能數據報告，但我仍然覺得通過這些數據沒有辦法準確地判斷資料庫是否有性能問題。比如你是一個醫生，我讓一個人站在你的面前測心率，結果是50次/分鐘，你是不是可以斷定他有問題，需要安裝心臟起搏器呢？實際上是不需要，因為我知道他是一個運動員，這樣的心率是正常的，而醫生不知道，所以他在做出診斷之前需要詳細了解站在自己面前的應診者的所有詳細信息，來作為他做出判斷的依據。
下面貼出一個來自於我使用過的資料庫性能報告中的一部分：
Buffer Nowait %: 100.00 Redo NoWait %: 99.99
Buffer Hit %: 66.35 In-memory Sort %: 100.00
Library Hit %: 99.63 Soft Parse %: 96.87
Execute to Parse %: 83.99 Latch Hit %: 99.87
Parse CPU to Parse Elapsd %: % Non-Parse CPU: 100.00
許多人看到這個數據一定會大聲說：
“嘿，你的資料庫性能好差，buffer hit只有66%，不知道是誰設計的這個系統，趕緊加大data buffer的尺寸!”
誠然，這個數據的確顯示資料庫的記憶體命中率低得可憐，但是我想告訴你的是，這是一個線上分析（OLAP）系統的資料庫，運行著很多非常大的查詢，每個查詢搜尋的範圍都在上億條記錄以上，那這個結果不是很正常嗎？我們需要把幾億條數據快取到記憶體里提供給這種每天可能只運行幾次的查詢嗎？你可以同意，但是你的老闆是不會同意的，這樣做的成本太高了，而且完全沒有必要，因為它只是一個報表系統，對資料庫的回響時間要求不高，所以我們當然可以讓這個查詢直接到磁碟上去搜尋數據，這也就是為什麼在這樣的系統里，buffer hit比例很低，但卻是一個完全可以接受的值的原因。
筆者認為，只有資料庫的性能已經影響到業務的正常工作或者用戶已經無法滿意於這種性能時，我們才應該考慮來最佳化它，對於絕大多數系統，資料庫的安全和穩定才是最重要的。
FAST=TRUE？
這是很多人追求的目標，它的意思是，在Oracle資料庫中，通過調整性能參數的值，就可以讓資料庫運轉得飛快。
實際上這不過是句玩笑，它本身是一句反話，卻讓很多人誤入歧途。我看到很多人，包括一些DBA，凡涉及性能最佳化，必定談及性能參數的修改，這實在是一個誤區，他把性能參數值的修改對資料庫性能的正面影響人為地放大了很多倍，實際上恰恰相反，很多時候修改這些參數產生的卻是副作用，原因很簡單，Oracle給一個參數一個默認值是讓它最大限度地適用於每個資料庫，所以它幾乎是最優的，當然，絕對有個別資料庫需要適當調整，但我認為那是個例，並且，很多時候，修改這些參數的人，他們修改的理由並不是非常充分，不過是想修改一下看看運氣而已。
本書的內容
以下是本書各個章節的內容簡介。
第1章 引起資料庫性能問題的因素
這一章主要討論一些引起資料庫性能問題的因素，包含了系統架構、軟體代碼、資料庫設計、存儲設計等話題。
第2章 鎖和阻塞
在這一章里，將介紹Oracle資料庫中鎖的起因及由鎖引起的性能問題—阻塞，並將討論常見的幾種阻塞的起因。
第3章 Latch和等待
這一章討論Latch，它是Oracle中比鎖更輕量級的一種串列機制。熱塊或是SQL未綁定變數是最常見的導致Latch等待的原因，這一章將對這些成因及解決方法進行論述。
第4章 最佳化器
最佳化器是SQL執行中最核心的部分，如果要分析SQL的性能，就不能不了解Oracle最佳化器的機制，這一章，我們就帶你走進Oracle最佳化器—CBO的世界。
第5章 執行計畫
當我們分析一條SQL語句的性能時，最先做的事情大概就是分析它的執行計畫了。
所以，如果連執行計畫都看不懂，那SQL調優根本無從談起。在這一章，我們將討論CBO（基於成本的最佳化器）執行計畫相關的內容。
第6章 Hint
Hint指通過人為的方式來約束SQL的執行計畫，讓它按照我們希望的方式來執行，以達到我們需要的目的—改善性能或者僅僅是試驗以對比SQL的執行性能。
這一章將討論Oracle資料庫中的大多數Hint。
第7章 分析及動態採樣
對象採樣分析是CBO（基於成本的最佳化器）的靈魂和核心，CBO如果沒有了對象的分析數據，就好像一個醫生不使用病人的病歷來確定病人的病一樣危險—那是一種沒有依據的、盲目的行為。
在這一章里，我們將詳細討論Oracle中和對象分析相關的內容。
第8章 並行執行
這一章討論一個和性能關係極大的技術—並行執行。
在OLAP（線上分析系統）或者是數據倉庫系統中，並行技術使用得非常普遍，在合適的條件下，並行執行將會使SQL的執行效率大幅度提升。
第9章 變數綁定
這一章將詳細討論一個在性能最佳化領域經常被談到的話題—變數綁定。
那么，是不是在任何時候變數綁定都是必需的呢？答案是否定的，在這一章中將給出答案。
第10章 SQL_TRACE事件
SQL_TRACE和事件是會話級非常有用的兩個工具，它們可以捕獲會話當中SQL執行的詳細信息，其中事件還可以獲得SQL綁定變數的信息及發生的等待事件。
這一章將詳細討論這兩個工具。
第11章 10053事件
這一章將詳細討論10053事件，它是一個很有用處的工具，當你發現一條SQL總是選擇錯誤的執行計畫，而你又百思不得其解的時候，也許你應該去生成一個10053事件的trace檔案，看看CBO究竟是如何做出這樣的執行計畫的。
第12章 性能視圖和性能參數
本章討論一些Oracle資料庫的性能視圖和性能參數。
性能視圖相對於SQL_TRACE來說，可以讓我們更直接地獲取一些性能數據，幫助我們判斷資料庫是否出現了性能問題。
而性能參數則讓我們能夠有機會選擇一種最適合自己系統的某個參數值，以最大程度地滿足當前系統的需要。
第13章 性能報告
本章介紹了常用的幾個性能分析工具及性能報告，包括AWR，STATSPACK和ASH，其中以AWR性能報告作為重點介紹的對象。
本章以一個來自於現實生產資料庫的AWR報告為題材，來討論AWR報告的閱讀方式，並最終判斷出系統的性能所在；STATSPACK介紹了它的安裝方法和如何生成報告；ASH也是以一個來自實際生產資料庫的性能報告進行性能分析。
附錄A 常見的等待事件
這部分會列出一些常見的等待事件、引起它們的原因及一些內部的機制，可以作為大家在處理性能問題時的一個參考部分。
後記 關於資料庫的學習方法
這一部分是作者對如何學習Oracle的一個心得分享，對於Oracle初學者來說，正確的學習方法非常重要，它可以使你少走很多彎路。
如果初學者對於Oracle資料庫的學習方法有興趣，這部分可以作為本書的第一部分來閱讀。
本書的讀者對象
1. 本書適合Oracle DBA或者和Oracle相關的開發人員。
2. 本書的讀者需要有一定的Oracle基礎，比如你應該知道什麼叫做表，什麼叫做索引等。
約定
1. 本書示例使用的Oracle版本是10gr2。
2. 本書自創了一個術語—段對象。
這個詞大家可能看著有那么一點陌生。作者的意思是，在Oracle資料庫中，凡是分配了存儲空間的，都稱為段，所以段並不一定指的是表，也可能是表的一個分區，還可能是索引、大對象（LOB），或是IOT（索引表），物化視圖等。在書中有時候需要描述這些對象時，單獨說某個表，或者一個索引，都不能完全概括，所以就統稱為段對象。
3. 幾個未作翻譯的術語Extent，Latch和Bind peeking。
Extent：我看有些書翻譯為“分區”，說實話，在Oracle裡面，一提到分區，可能99%以上的人會認為是partition，還有的書翻譯為“範圍”，這個就更讓人匪夷所思，所以在書中這個單詞就沒有翻譯，相信大家也懂。
Latch：有的書翻譯成“閂”，有的翻譯成“鎖存”，我總覺得還是不翻譯好，只要大家知道它是Oracle里一種類似於鎖的保證一些操作串列化的技術就好了。
Bind peeking：翻譯成“變數窺視”或是“變數窺探”都非常不對頭，所以乾脆也不翻譯。
本書的目的
筆者從事Oracle DBA的工作已經超過10年，對資料庫的理解也一直在改變，就目前來看，我覺得最難的東西不是技術本身，而是什麼時候該用什麼技術。比如說要使用變數綁定，這非常容易，如果你不會，Google一下，差不多幾分鐘時間你就會了。可是，這個系統究竟該不該使用變數綁定，我想你Google一天或者一個星期也不一定有答案。原因是每個系統都是獨立的，都有自己的業務特點，這需要技術人員根據自己系統的業務特點來度身定做符合自己系統的技術特性。
讓讀者在每一個技術面前先停下來思考一下，這個技術究竟在什麼時候應該用，什麼時候不應該用，這是筆者寫本書的最終目的。
致 謝
感謝itpubt網站的創始人Tigerfish為本書寫序，我一直對他懷有敬意，他在推動中國Oracle資料庫的發展 上功不可沒。
感謝biti（馮春培），eygle（蓋國強），kamus（張樂奕）和warehouse（謝永生），他們都是國內頂尖的Oracle專家，感謝他們為本書寫的精彩點評。
還有來自ITG的Mike，感謝他的熱心幫助和鼓勵。
感謝ITPUB的王蓓小姐（貝貝），在本書的出版過程中，她做了大量的協調工作，才保證這本書的順利出版。
感謝電子工業出版社的張月萍策劃和高洪霞編輯，是她們的努力讓本書更具可讀性和完整性。
最後要感謝我的妻子tracy和兒子思墨，是他們讓我一直努力工作，最終使本書得以問世。
後 記
關於資料庫的學習方法
我想在這裡聊一些資料庫方面的學習方法，算是對自己這些年學習的一個總結，也可以給那些才進入Oracle領域的朋友們提供一些借鑑。如果能夠使你有所收穫的話，我將非常高興。
1、英語和技術的關係
從2005年開始到現在，我只看過三本關於資料庫方面的印刷書籍，都是由一個人寫的，他叫Tom Kyte，業內都叫他Tom，這三本書分別是：
● 《Expert One-on-One Oracle》—《Oracle專家高級編程》
● 《Expert_Oracle_Database_Architecture》—《Oracle 9i&10g編程藝術深入資料庫體系結構 》
● 《Effective Oracle by Design》—《Oracle高效設計》
在買這三本書時，多少帶有些許盲目性，因為崇拜書的作者，所以愛屋及烏地買了他寫的所有的書，實際上我用在看這三本書上的時間並不多，更多的時候我都泡在這個網站上，就是這個網站，改變了我對問題的思考方式和學習方法。
對於大多數中國人來說，特別是做技術的人，英語成為很多人的軟肋，這是一個無奈的局面。我甚至聽到很多人在說，為什麼非要學習英語，自己國家的話說好就行了，言辭之間頗鄙視那些學英語的“崇洋派們”。本身這句話也還不錯，作為自己國家的公民，學好自己國家的語言，自然是再好不過的事情。但是很遺憾的是，我們說著自己的語言，卻在用著別人的東西。用別人的東西，卻拒絕學習別人的語言，這看起來不免有些矛盾。如果有一天世界上所有的商業軟體都來自於中國，那么我們再自豪地鄙視那些學習英語的人也不遲。
所以我必須要說的是，如果你想把計算機的技術學深一些，請你務必要學好英語，至少要做到能夠熟練閱讀英文文檔的啞巴英語，如果再進一步，你能夠使用英語和別人做書面的溝通（比如在論壇中或者E-mail中提出問題），那會更好一些。
在Asktom中有來自世界上很多國家的Oracle DBA或者開發人員在提出問題，我最初的時候只是瀏覽，後來嘗試著用自己蹩腳的英語向Tom提出了一個問題，當收到Tom給出的回覆後，當時心情真是無比的激動，可喜之餘不免又甚感悲哀，為什麼一個簡單的提問，卻讓我歡喜至此呢？原因大概是，我們和他們之間溝通太少了，一個小小的問答，對我來說就像跨過一個巨大的鴻溝。
之後的日子裡，就慢慢習慣了這種學習方式，當我有一個問題，在找遍了所有的Oracle官方文檔，Google和Metalink（一個Oracle公司的線上技術支持平台）未果之後，總是能夠在這裡得到一個確切的回答，它已經變成了我在技術上最後的依靠了。
我們不得不承認和接受一個現實，由於語言的溝壑，使我們學習起這些西方人發明的東西時，比他們自己的人要困難得多，比如對於一個軟體，他們已經習慣於隨手看一下軟體的Manual（在線上幫助手冊）來了解這個軟體的用法，而我們卻還在傻傻地等待著軟體的漢化或者翻譯過來的軟體使用教程呢（市面上有很多書都是簡單地將某個軟體的manual翻譯過來，然後出版），這種語言上的障礙使我們和他們在技術上有相當大的差距，這就是我在Asktom論壇上得到的最切身的感受，我們不僅在技術本身上，而且在一些思維方式上和他們也有明顯的不同，這不是妄自菲薄，是我們中國IT從業人員的現狀，我們只是封閉在自己的圈子裡面做研究，卻並不知道外面已經是個什麼樣子了。
我希望大家能夠把英語學好（我本人也在努力地學習中），Oracle的官方文檔全都是英文的，metalink也全都是英文的，asktom網站也都是英文的，如果我們能夠熟練地使用這三個資源，那么我們的技術水平必將上一個新的台階。
2. 如何使用Oracle的官方文檔
如果你到現在為止，依然沒有習慣於使用Oracle的官方文檔的話（比如你懼怕英語閱讀或者其他的原因），那么你可能要考慮改變一下你的學習方式了，因為Oracle官方文檔是Oracle公司提供的最權威的技術資料，它基本上包含了Oracle所有的技術，你在這裡可以找到大多數你想找的東西。
也許那些看起來無比長的英文文檔讓你望而卻步，至少我最初也是如此的。但是隨著自己嘗試著去閱讀了幾篇之後，感覺情況並沒有想像中的那么壞，我居然讀懂了一大半。因此建議大家也要樹立信心，要鼓起勇氣來閱讀英文文檔，當你經常閱讀時，你會發現其實它並沒有你想的那么難，你使用它的次數也多，你就越能接受和使用它。
這裡簡要地介紹幾個使用頻率比較高的官方文檔，希望大家能夠經常使用它們：
《New Features Guide》
一般稱為新特性，當我們要使用一個新版本資料庫的時候，我們應該先閱讀這篇文檔。可以通過目錄來瀏覽自己感興趣的部分。這篇文檔主要介紹的就是當前這個版本的資料庫較從前的版本有了哪些新的技術，這篇文檔可以幫助你快速地了解一個新版本資料庫的新特性，這比閱讀那些具體的文檔要省力得多。
《Concepts》
當我們需要了解一個概念或者技術的具體含義或機制時，我們需要參考這篇文檔，這裡面基本上包含了所有Oracle相關的概念和技術。
比如什麼是表，什麼是索引，什麼是段等。
或者什麼是SGA，PGA等。
或者什麼是並發，事務等。
這是Oracle最重要的一篇文檔，希望大家能夠經常使用它。
《Reference》
這裡面主要包含了四部分內容：
●初始化參數
●視圖
●等待事件
●統計信息
這是我使用頻率最高的文檔之一，基本上每天都要打開幾次，主要是查詢一些視圖及其欄位的解釋及等待事件的解釋，初始化參數的解釋也會經常用到它，另外它還包含了一些統計項目，比如v$sesstat中的統計項目的解釋就可以從這篇文檔中找到。
《SQL Reference》
這篇文檔大家應該再熟悉不過了，當你記不住某條SQL的命令或者搞不清楚某條SQL的選項時，就需要從這篇文檔中獲取答案，它包含了Oracle所有的SQL語法。
《Administrator's Guide》
這可以看做一本Oracle的實戰手冊，很多Oracle的技術和特性在這篇文檔里都能夠找到相應的示例，所以建議大家也經常使用它。
《PL/SQL Packages and Types Reference》
如果你是一個喜歡使用Oracle提供的PL/SQL包工作的人，這篇文檔你就應該經常使用到，它包含了Oracle提供的所有PL/SQL包，比如我們經常使用到的DBMS_STATS，它是用來做分析用的包，包裡面每個存儲過程及參數在這篇文檔中都有詳細的說明。
《Performance Tuning Guide》
如果你要學習Oracle資料庫性能最佳化的話，這篇文檔應該要好好讀幾遍，這裡面包含了所有和性能最佳化相關的技術和方法。
3、學會思考
我們不能機械地去學一些技術，那樣只能讓自己陷入一個由自己打造的萬劫不復的技術深淵，無法自拔，因為技術是無止境的，而人的精力是有限的，這樣只能使自己整天生活在一種壓抑和苦悶當中。
我們要學會在技術面前理性的思考，比如對於一個新技術，流複製（Streams Replication），當我看到這個概念的時候，我告訴自己，這不過又是Oracle為用戶提供的另外一種數據同步的機制而已，如果我們有這方面的需求，我會帶著我們的需求去看相關的文檔，以便確定這種技術是否適合我們的系統，否則，我可能只是做一些粗淺的了解，僅此而已，切勿把自己陷入到技術的泥潭當中去。
有目的地學習技術，做到學以致用，你就會過得很快樂，相反，你就會非常痛苦，儘管你每天都在學習，可是你是否想過，你一個人學習，Oracle卻有成千上萬的開發人員在開發新版本的資料庫和新的技術，你能學完嗎？
理性地學習，心平氣和地學習，是做技術的人的一種生活態度，希望本書對大家在學習技術上會有所幫助。
目 錄
第1章 引起資料庫性能問題的因素 1
1.1 軟體設計對資料庫的影響 1
1.1.1 軟體架構設計對資料庫性能的影響 1
1.1.2 軟體代碼的編寫對資料庫性能的影響 2
1.2 資料庫的設計 8
1.2.1 OLTP資料庫 9
1.2.2 OLAP資料庫 10
1.3 資料庫的硬體設計 14
1.3.1 存儲容量 15
1.3.2 存儲的物理設計 16
1.3.3 數據的安全 17
1.4 小結 19
第2章 鎖和阻塞 20
2.1 關於鎖 20
2.2 鎖和阻塞 22
2.3 引起阻塞的其他情況 30
2.3.1 select for update 30
2.3.2 外鍵和索引 36
第3章 Latch和等待 44
3.1 共享池中的Latch爭用 45
3.2 數據緩衝池Latch爭用 54
3.2.1 表數據塊 54
3.2.2 索引數據塊 59
3.2.3 索引根數據塊 62
3.2.4 段頭數據塊 65
第4章 最佳化器 66
4.1 RBO基於規則的最佳化器 66
4.2 CBO基於成本的最佳化器 69
第5章 執行計畫 85
5.1 Cardinality （基數） 85
5.2 SQL的執行計畫 94
第6章 Hint 109
6.1 和最佳化器相關的Hint 115
6.1.1 all_rows和first_rows（CBO） 115
6.1.2 RULE Hint 117
6.2 訪問路徑相關的Hint 117
6.2.1 FULL Hint 118
6.2.2 INDEX Hint 118
6.2.3 NO_INDEX Hint 118
6.2.4 INDEX_DESC Hint 119
6.2.5 INDEX_COMBINE Hint 119
6.2.6 INDEX_FFS 119
6.2.7 INDEX_JOIN 120
6.2.8 INDEX_SS Hint 120
6.3 表關聯順序的Hint 125
6.3.1 LEADING Hint 125
6.3.2 ORDERED Hint 126
6.4 表關聯操作的Hint 127
6.4.1 USE_HASH，USE_NL和USE_MERGE Hint 127
6.4.2 NO_USE_HASH Hint 132
6.4.3 NO_USE_MERGE Hint 133
6.4.4 NO_USE_NL Hint 133
6.5 並行執行相關的Hint 134
6.5.1 PARALLEL Hint 134
6.5.2 NO_PARALLEL Hint 134
6.6 其他方面的一些Hint 135
6.6.1 APPEND Hint 135
6.6.2 DYNAMIC_SAMPLING Hint 135
6.6.3 DRIVING_SITE Hint 136
6.6.4 CACHE Hint 136
6.7 小結 136
第7章 分析及動態採樣 138
7.1 直方圖 141
7.2 DBMS_STATS包 147
7.3 動態採樣 176
7.3.1 什麼是動態採樣 176
7.3.2 動態採樣的級別 182
7.3.3 什麼時候使用動態採樣？ 185
7.4 小結 185
第8章 並行執行 186
8.1 並行和OLAP系統 187
8.2 並行處理的機制 189
8.3 讀懂一個並行處理的執行計畫 191
8.4 一個很常見的並行執行等待事件 192
8.5 並行執行的適用範圍 194
8.5.1 並行查詢 194
8.5.2 並行DDL操作 195
8.5.3 並行DML操作 203
8.6 並行執行的設定 210
8.6.1 並行相關的初始化參數 210
8.6.2 並行度的設定 211
8.7 直接載入 213
8.7.1 直接載入和REDO 216
8.7.2 直接載入和索引 219
8.7.3 直接載入和並行 221
8.7.4 直接載入和SQL*LOADER 226
第9章 變數綁定 232
9.1 什麼是變數綁定，為什麼要做變數綁定 232
9.2 為什麼說OLTP必須要求變數綁定而OLAP不應該綁定變數 241
9.3 bind peaking 248
第10章 SQL_TRACE和事件 254
10.1 SQL_TRACE 254
10.2 TKPROF工具 256
10.3 事件 268
第11章 10053事件 276
第12章 性能視圖和性能參數 294
12.1 性能視圖 294
12.1.1 V$SQL 295
12.1.2 V$SQL_SHARED_CURSOR 300
12.1.3 v$session 305
12.1.4 V$sessstat 309
12.1.5 V$session_wait 310
12.2 性能參數 312
12.2.1 Cursor_sharing 313
12.2.2 DB_FILE_MULTIBLOCK_READ_COUNT 328
12.2.3 PGA_AGGREGATE_TARGET和SGA_TARGET 334
12.2.4 OPTIMIZER_DYNAMIC_SAMPLING 334
第13章 性能報告 335
13.1 AWR性能報告 335
13.1.1 生成AWR性能報告 337
13.1.2 AWR性能報告分析 342
13.2 Statspack性能報告 386
13.2.1 Statspack的安裝 386
13.2.2 Statspack性能採集 391
13.3 ASH性能報告 394
13.3.1 生成ASH性能報告 395
13.3.2 ASH性能報告分析 405
13.4 小結 416
附錄A 常見的等待事件 417
後記 關於資料庫的學習方法 434
