品悟性能優(yōu)化

目錄
第1章  從兩個案例開始\\1
1.1  關于案例的說明\\2
1.2  體驗日本人工作風格\\2
1.2.1  問題現(xiàn)象及解決過程\\2
1.2.2  日本人嚴謹、細致的工作風格\\3
1.2.3  日本人的IT投入觀\\3
1.2.4  該系統(tǒng)的總體感覺\\4
1.2.5  在日本企業(yè)暖意洋洋的一幕\\4
1.2.6  也談強國夢\\5
1.3  國內某大型銀行故障的解決\\5
1.3.1  天塌下來一樣的故障\\5
1.3.2  故障原因其實很簡單\\6
1.3.3  故障的啟示\\7
1.3.4  2010年銀行案例的進一步感悟\\8
第2章  Oracle數(shù)據(jù)庫性能優(yōu)化方法論\\9
2.1  關于性能優(yōu)化的誤區(qū)\\10
2.1.1 “你調了哪些參數(shù)”\\10
2.1.2 “性能優(yōu)化主要是DBA和系統(tǒng)管理員的工作”\\10
2.1.3 “開發(fā)階段無須太多考慮性能問題”\\11
2.1.4 “優(yōu)化SQL，就是如何編寫SQL”\\11
2.1.5 “多表連接性能太差”\\11
2.1.6 “CPU利用率越低越好”\\12
2.1.7 “大內存能解決性能問題”\\12
2.1.8 “性能分析就是分析低層細節(jié)”\\13
2.2  性能優(yōu)化過程——自頂向下\\13
2.2.1  為時已晚\\13
2.2.2  什么叫自頂向下方法論\\13
2.2.3  體驗方法論\\15
2.3  高質量IT系統(tǒng)的正確認識\\15
2.3.1  高質量IT系統(tǒng)的目標\\15
2.3.2  目標的綜合平衡\\16
2.3.3  你只管進，不管出啊\\16
2.4  20/80規(guī)則\\17
2.4.1  性能優(yōu)化中也有20/80規(guī)則\\17
2.4.2  用數(shù)據(jù)詮釋20/80規(guī)則\\18
2.5  性能優(yōu)化過程——自底向上\\19
2.5.1  什么叫自底向上方法論？\\19
2.5.2  客戶要給我上課\\20
2.6  性能優(yōu)化中的角色分工\\20
2.6.1  老外的角色分工\\20
2.6.2  國內的角色分工\\21
2.7  應用開發(fā)指導思想\\22
2.7.1  管理重于技術\\22
2.7.2  我聽后，開心死了\\22
2.8  合理運用技術的重要性\\22
2.8.1  聯(lián)機事務處理系統(tǒng)（OLTP）和決策
支持系統(tǒng)（OLAP）\\22
2.8.2 “你們Oracle給我們出一個開發(fā)規(guī)范和指南吧”\\23
2.8.3  4分鐘如何優(yōu)化到1秒鐘\\24
第3章  性能優(yōu)化分析基本工具的使用\\29
3.1  性能優(yōu)化中的量化分析\\30
3.1.1  隔靴抓癢\\30
3.1.2  SQL語句到底是怎么執(zhí)行的\\30
3.1.3  性能分析都分析哪些量化指標\\32
3.2  工欲善其事，必先利其器\\32
3.2.1  SQL量化分析和優(yōu)化工具\\32
3.2.2  Oracle有大量實用的小工具和命令\\33
3.3  SQL語句到底是怎么被執(zhí)行的\\34
3.3.1  最經(jīng)典的執(zhí)行計劃分析工具\\34
3.3.2  這種老掉牙的東西，還用啊\\34
3.3.3  10g新功能：DBMS_XPLAN\\34
3.4  如何配套使用SQL*Trace和TKPROF\\35
3.4.1  又一對老古董\\35
3.4.2  其實功能非常強\\35
3.4.3  報告分析比如何產(chǎn)生報告更重要\\37
3.5  最常用的工具：Autotrace\\37
3.6  一個洋“忽悠”的?事\\42
3.6.1  洋和尚到中國來念梵文了\\42
3.6.2  洋大“忽悠”啊\\43
3.7  性能優(yōu)化與“三個代表”\\43
3.7.1  重溫“三個代表”\\43
3.7.2  案例背景\\43
3.7.3  自底向上方法論的運用\\44
3.7.4  關鍵應用問題的解決\\45
3.7.5  詮釋“三個代表”\\47
第4章  基本索引的使用\\49
4.1  索引既簡單又復雜\\50
4.1.1  關于索引的需求\\50
4.1.2  索引其實好簡單\\50
4.1.3  索引其實好難\\50
4.1.4  想做個懂Oracle索引的專家，難上加難\\51
4.2  索引設計基本建議\\52
4.2.1  Oracle索引長什么樣\\52
4.2.2  B*樹單字段索引設計建議\\53
4.2.3  一招鮮，吃遍天\\53
4.3  如何避免索引被抑制\\56
4.3.1  無從下手，郁悶至極！\\56
4.3.2  幸虧父母都是數(shù)學老師\\57
4.3.3  慎用自定義函數(shù)\\58
4.3.4  關于函數(shù)索引使用的建議\\58
4.3.5  其實是數(shù)據(jù)庫設計問題\\59
4.4  一把雙刃劍：復合索引\\59
4.4.1  復合索引的重要性\\59
4.4.2  我如何“戲弄”客戶\\60
4.4.3  復合索引原理和設計建議\\61
4.4.4  IT系統(tǒng)是面向客戶的，不是給領導看的\\63
4.5  一個既簡單又復雜的故事\\64
4.5.1  女兒說我吹牛了\\64
4.5.2  故事上集\\65
4.5.3  故事中集\\66
4.5.4  故事下集\\66
4.6  如何進行索引監(jiān)控分析和優(yōu)化\\68
4.6.1  為什么索引I/O那么高\\68
4.6.2  別亂建索引\\68
4.6.3  如何發(fā)現(xiàn)多余的索引\\69
4.6.4  如何進行索引碎片分析和整理\\70
第5章  為應用軟件設計更好的性能和可擴展性\\71
5.1  基本概念和原理\\72
5.1.1  本章標題有點大吧\\72
5.1.2  一個屢見不鮮的錯誤\\72
5.1.3  解剖SQL語句執(zhí)行過程\\73
5.2  語句共享性原理\\74
5.2.1  再說聯(lián)機事務處理系統(tǒng)（OLTP）
和決策支持系統(tǒng)（OLAP）\\74
5.2.2  如何實現(xiàn)語句共享化\\74
5.2.3  開發(fā)人員永遠比Oracle聰明\\75
5.2.4  技術服務工作，越做膽子越小\\75
5.2.5  如何量化評估語句共享性\\76
5.3  回到日本企業(yè)案例\\77
5.3.1  深入分析技術原因\\77
5.3.2  被日本人較真的滋味其實不好受\\79
5.4  語句共享性的深入分析\\79
5.4.1  語句共享性和查詢統(tǒng)計系統(tǒng)的關系\\79
5.4.2  語句共享性與擴展性的關系\\80
第6章  如何提高排序、表連接性能\\81
6.1  如何提高排序性能\\82
6.1.1  能不排序就不排序——廢話一句\\82
6.1.2  查詢欠費最高的前100名手機客戶\\83
6.1.3  痛心疾首的一?\\84
6.1.4  IBM和Oracle：亦敵亦友\\88
6.2  Oracle表連接技術和應用\\89
6.2.1  數(shù)據(jù)庫精髓之一：表連接\\89
6.2.2  最經(jīng)典、最常用的表連接技術——嵌套循環(huán)\\90
6.2.3  嵌套循環(huán)連接與索引\\91
6.2.4  嵌套循環(huán)連接的應用場景及效率\\93
6.2.5  適合于大批量數(shù)據(jù)處理的連接技術\\94
6.3  多表連接優(yōu)化的基本思路\\96
6.3.1  總體思路\\96
6.3.2  OLTP應用的表連接優(yōu)化\\96
6.4  如何使用子查詢\\96
6.4.1  使用子查詢好不好\\96
6.4.2  到底是使用in還是exists\\97
6.5  回到20/80規(guī)則\\99
6.5.1  優(yōu)化詳細過程\\100
6.5.2  技術方面總結\\106
6.5.3  每項工作做到最好都不容易\\107
第7章  應用綜合優(yōu)化及總結\\108
7.1更多的優(yōu)化案例\\109
7.1.1數(shù)據(jù)類型不一致導致的問題\\109
7.1.2  多此一舉的操作\\111
7.1.3  錯誤使用HINT\\113
7.1.4  Oracle和IBM又一次成功合作\\117
7.2  可怕的笛卡兒乘積\\118
7.2.1  問題的發(fā)生和初步解決\\119
7.2.2  其實是設計和開發(fā)中更深層次問題\\120
7.3  說說全表掃描\\122
7.3.1  導致數(shù)據(jù)庫性能問題的常見原因\\122
7.3.2  何謂全表掃描\\122
7.3.3  數(shù)據(jù)增長與全表掃描的關系\\123
7.3.4  硬件太多了\\124
7.3.5  導致技術運用復雜化的其他問題\\124
7.3.6  更多的類比和感慨\\125
7.4  導致性能問題的其他原因\\125
7.5  一個應用軟件的綜合優(yōu)化\\126
7.5.1  優(yōu)化前的狀況\\126
7.5.2  優(yōu)化策略及分工合作\\127
7.5.3  優(yōu)化效果及原因分析\\127
7.5.4  主管部門的反應\\128
7.5.5  美妙的三降預言同時實現(xiàn)\\129
7.5.6  優(yōu)化工作的艱巨性和長期性\\129
7.6  一個樸實無華的好系統(tǒng)\\130
7.6.1  國人也能做出精良的好系統(tǒng)\\130
7.6.2  巨大升值空間\\131
7.6.3  瑕不掩瑜\\131
第8章  Oracle分區(qū)技術及應用\\133
8.1  硅谷之行\(zhòng)\134
8.1.1  IT人的圣地：硅谷\\134
8.1.2  我在Oracle總部中邪了\\135
8.2  我對Oracle分區(qū)技術的認知過程\\135
8.2.1  初嘗分區(qū)甜頭\\135
8.2.2  分區(qū)給我的痛苦體驗\\137
8.2.3  全面理解分區(qū)技術\\138
8.3  分區(qū)表技術\\138
8.3.1  分區(qū)技術原理：分而治之\\138
8.3.2  分區(qū)表技術概述\\140
8.3.3  11g的分區(qū)新技術\\144
8.4  分區(qū)索引技術\\146
8.4.1  分區(qū)索引技術好難哦\\146
8.4.2  10分鐘讓你理解最難的分區(qū)索引\\149
8.4.3  分區(qū)索引設計指南\\151
8.5  更多的分區(qū)技術\\153
8.5.1  一個神奇的分區(qū)技術\\153
8.5.2  Oracle分區(qū)技術發(fā)展史\\154
8.6  如何實施和評估分區(qū)\\155
8.6.1  分區(qū)設計建議\\155
8.6.2  分區(qū)效果評估\\156
8.6.3  如何在生產(chǎn)系統(tǒng)實施分區(qū)\\156
8.7  某行業(yè)分區(qū)方案設計的曲折過程\\159
8.7.1  第一階段：出師不利\\159
8.7.2  第二階段：經(jīng)驗主義錯誤\\160
8.7.3  第三階段：初見成效\\160
8.7.4  第四階段：日臻完善\\160
8.8  分區(qū)方案中常見問題探討\\161
8.8.1  問題1：目標方面的誤區(qū)\\161
8.8.2  問題2：分區(qū)表設計方面的誤區(qū)\\162
8.8.3  問題3：沒有充分考慮應用設計和開發(fā)的誤區(qū)\\162
8.8.4  問題4：分區(qū)表空間設計方面的誤區(qū)\\163
8.8.5  問題5：分區(qū)在大批量數(shù)據(jù)處理中的誤區(qū)\\164
8.8.6  問題6：分區(qū)索引設計方面的誤區(qū)\\164
8.8.7  無止境的分區(qū)技術\\165
第9章  架構與性能優(yōu)化\\166
9.1  該談談架構了\\167
9.1.1  架構與性能的關系\\167
9.1.2  Oracle高端架構產(chǎn)品與性?的關系\\167
9.1.3  Oracle架構的重要性\\168
9.2  基本概念很重要\\169
9.2.1  什么是Oracle數(shù)據(jù)庫\\169
9.2.2  服務器、實例和數(shù)據(jù)庫的關系\\170
9.2.3  關于架構方面的誤區(qū)\\172
9.3  IT系統(tǒng)架構現(xiàn)狀分析\\173
9.3.1  一副并不美妙的大蜘蛛網(wǎng)\\173
9.3.2  現(xiàn)有體系結構特點分析\\174
9.3.3  現(xiàn)有體系結構評估\\174
9.4  Oracle網(wǎng)格計算\\176
9.4.1  Oracle 10g = 網(wǎng)格計算\\176
9.4.2  按網(wǎng)格計算設計數(shù)據(jù)庫架構\\176
9.4.3  烏托邦式架構就是好\\178
9.4.4  初級階段的設計建議\\179
9.4.5  關于真正大集中的疑慮\\179
9.5  云計算與性能優(yōu)化\\182
9.5.1  滿天翻滾的云\\182
9.5.2  Oracle的紅云\\182
9.5.3  客戶關注的云計算話題\\183
9.6  Oracle數(shù)據(jù)庫分布式架構\\184
9.6.1  數(shù)據(jù)復制技術\\184
9.6.2  Data Guard技術簡介\\186
9.6.3  Streams技術簡介\\187
9.6.4  其他數(shù)據(jù)同步技術\\188
9.6.5  數(shù)據(jù)同步技術的定位和比較\\188
9.7  我看分布式架構\\190
9.7.1  我不喜歡分布式架構\\190
9.7.2  數(shù)據(jù)大集中與分布式架構\\191
9.7.3  分布式架構的用武之地\\192
9.7.4  真正的返璞歸真\\192
9.8  誓做抗拒拆遷的刁民\\193
9.8.1  拆遷大錘已高高舉起\\193
9.8.2  統(tǒng)一戰(zhàn)線發(fā)揮重要作用\\193
9.8.3  人民戰(zhàn)爭的汪洋大海\\195
9.9  一個本來平淡的日子\\195
9.9.1  什么專家，拿了錢就跑？\\195
9.9.2  艱難的問題診斷過程\\196
9.9.3  一根救命稻草\\197
9.9.4  技術方面的教訓和感悟\\197
9.9.5  猶豫半天的話語\\198
第10章  RAC與性能優(yōu)化\\200
10.1  關于RAC的一些誤解和疑慮\\201
10.2  RAC技術原理\\203
10.2.1  系統(tǒng)介紹RAC架構和原理\\203
10.2.2  RAC到底有什么好處\\204
10.2.3  10g RAC架構新特性\\205
10.2.4  我害怕Oracle什么技術工作\\206
10.3  RAC架構的優(yōu)勢\\207
10.3.1  為什么RAC架構比HA架構好\\207
10.3.2  客戶的方案不一定是最優(yōu)的\\209
10.4  RAC實施方法論\\210
10.4.1  還是方法論重要\\210
10.4.2 “你打個補丁要三天啊？”\\211
10.4.3  如何降低RAC實施和運行風險\\212
10.4.4  RAC其實背了好多黑鍋\\212
10.5  RAC性能優(yōu)化原理\\213
10.5.1  RAC性能優(yōu)化等同于單事例\\213
10.5.2  RAC性能問題與應用關系\\214
10.5.3  應用在RAC環(huán)境下部署的最佳方式\\216
10.6  RAC環(huán)境下的性能分析\\217
10.6.1  RAC性能分析基本策略\\217
10.6.2  AWR報告中的RAC性能分析\\217
10.6.3  ADDM報告中的RAC問題原因分析\\218
10.6.4  GCS性能分析\\219
10.6.5  GES性能分析\\221
10.6.6  下得去，還要上得來\\222
10.7  RAC高可用性\\222
10.7.1  RAC高可用性技術其實很復雜\\222
10.7.2  RAC高可用性實施思路\\223
10.7.3  RAC高可用性測試案例和測試過程\\223
10.8  RAC可擴展性\\225
10.8.1  RAC不能超過4個節(jié)點？\\225
10.8.2  Oracle總部RAC?家的觀點\\225
10.8.3  某大型交易系統(tǒng)的擴展性測試\\226
10.8.4  如何實施RAC擴展性\\227
10.9  RAC運行維護和故障診斷\\228
10.9.1  RAC運行維護建議\\228
10.9.2  RAC故障診斷經(jīng)驗談\\228
10.9.3  瞎貓碰上死耗子\\229
第11章  數(shù)據(jù)倉庫中的性能優(yōu)化\\231
11.1  我看數(shù)據(jù)倉庫\\232
11.1.1  數(shù)據(jù)倉庫不是倉庫管理軟件\\232
11.1.2  數(shù)據(jù)倉庫鼻祖的精確定義\\232
11.1.3  數(shù)據(jù)倉庫的應用特點\\233
11.1.4  我所?解的數(shù)據(jù)倉庫\\233
11.1.5  本書講述的數(shù)據(jù)倉庫\\234
11.2  數(shù)據(jù)倉庫應用開發(fā)指導思想\\235
11.2.1  數(shù)據(jù)倉庫應用開發(fā)指導思想建議\\235
11.2.2  案例為證\\235
11.2.3  如何貫徹大批量、并行處理？\\238
11.3  并行處理技術的應用\\238
11.3.1  Oracle并行處理技術無處不在\\238
11.3.2  并行處理舉例\\239
11.3.3  并行技術的幾個層面\\240
11.3.4  并行處理經(jīng)驗\\242
11.3.5  榨干所有硬件資源\\243
11.4  Oracle是個大計算器\\244
11.4.1  告別農(nóng)耕時代\\244
11.4.2  Oracle不僅是一個存數(shù)據(jù)的大容器\\244
11.5  大批量數(shù)據(jù)ETL案例\\245
11.5.1  VIP客戶判斷標準\\245
11.5.2  外部表\\246
11.5.3  MERGE語句\\247
11.5.4  VIP計算總體流程圖\\248
11.5.5  簡述一個流程\\249
11.5.6  方案評估\\250
11.6 “非典”期間的一個典型性問題\\250
11.6.1  一個應用開發(fā)中的典型性問題\\250
11.6.2  Oracle系統(tǒng)級臨時表\\253
11.7  一種快速高效的數(shù)據(jù)倉庫加載方案\\253
11.7.1  讓洋鬼子激動地蹦到桌子上去\\253
11.7.2  快速高效的數(shù)據(jù)倉庫加載方案\\255
11.8  報表優(yōu)化技術\\259
11.8.1  我的第一次軟件開發(fā)經(jīng)歷\\259
11.8.2  現(xiàn)在的報表處理狀況\\260
11.8.3  報表優(yōu)化核心技術：物化視圖和語句重寫\\261
11.8.4  為什么不要自己編寫匯總表\\263
11.8.5  報表優(yōu)化的基本思路及示例\\263
11.8.6  報表優(yōu)化示例\\264
11.8.7  為什么沒有實現(xiàn)語句重寫\\268
11.8.8  IT行業(yè)到底是買方市場還是賣方市場\\269
第12章  統(tǒng)計信息采集與性能優(yōu)化\\272
12.1  我闖大禍了\\273
12.1.1  常在河邊走，哪有不濕鞋的\\273
12.1.2  太急于表現(xiàn)了\\273
12.1.3  建一個索引，搞死一個系統(tǒng)\\274
12.1.4  我被罵得滿地找地縫\\274
12.1.5  初識問題原因\\275
12.1.6  問題根本原因\\275
12.2  優(yōu)化器原理和統(tǒng)計信息采集作用\\276
12.2.1  SQL語句執(zhí)行過程\\276
12.2.2  基于規(guī)則優(yōu)化器（RBO）簡介\\277
12.2.3  基于成本優(yōu)化器（CBO）簡介\\278
12.2.4  如何將葫蘆和瓢都按下\\278
12.2.5  為什么要進行統(tǒng)計信息采集\\279
12.3  自動采集統(tǒng)計信息\\279
12.3.1  自動采集統(tǒng)計信息的特點\\279
12.3.2  自動還是手工\\280
12.3.3  超長的自動統(tǒng)計信息采集\\280
12.3.4  一次變味的數(shù)據(jù)庫升級技術研討會\\282
12.4  定制采集統(tǒng)計信息\\282
12.4.1  統(tǒng)計信息采集基本策略\\282
12.4.2  統(tǒng)計信息采集實施策略\\283
12.4.3  統(tǒng)計信息采集具體方法\\283
12.4.4  Oracle 10g鬼精鬼精的\\285
12.5  若干最佳實踐經(jīng)驗\\286
12.5.1  自動和手工結合進行統(tǒng)計信息采集\\286
12.5.2  鎖住統(tǒng)計信息采集\\286
12.5.3  數(shù)據(jù)分布統(tǒng)計（Histogram）建議\\286
12.5.4  批處理中的統(tǒng)計信息采集\\287
12.5.5  鐵路警察，各管一段\\288
第13章  感悟性能優(yōu)化分析的高級工具\\290
13.1  Oracle 10g = Oracle 10a\\291
13.1.1  外部手工管理變內部自動管理\\291
13.1.2  Oracle 10g都有哪些自動的東西\\292
13.2  AWR是個好東西\\292
13.2.1  AWR原理\\292
13.2.2  AWR基本操作\\293
13.2.3  把AWR功能用個夠\\295
13.3  ADDM：Oracle能自動診斷監(jiān)控嗎\\298
13.3.1  ADDM能干啥\\298
13.3.2  DBA要失業(yè)了嗎\\300
13.4  SQL優(yōu)化進入工業(yè)化時代\\301
13.4.1  傳統(tǒng)模式到工業(yè)化\\301
13.4.2  SQL Tuning Advisor能做哪些優(yōu)化\\302
13.4.3  SQL Access Advisor能做哪些優(yōu)化\\304
13.4.4  SQL Tuning Advisor和SQL Access Advisor的差異\\304
13.4.5  OEM中的每條命令我都會敲\\304
13.4.6  IT工業(yè)化時代的初級階段\\305
第14章  參數(shù)配置與性能優(yōu)化\\307
14.1  神奇的“魔術師”\\308
14.1.1  不調系統(tǒng)參數(shù)\\308
14.1.2  調錯系統(tǒng)參數(shù)\\308
14.2  漫談初始化參數(shù)\\309
14.2.1  神奇的初始化參數(shù)\\309
14.2.2  參數(shù)設置基本思路和經(jīng)驗\\310
14.2.3  將Log Buffer設它個幾百兆\\311
14.3  自動?存管理\\311
14.3.1  DBA真地快沒活干了\\311
14.3.2  自動內存管理技術管用嗎\\314
14.4  Buffer Cache優(yōu)化\\315
14.4.1  Buffer Cache參數(shù)設置思路\\315
14.4.2  Buffer Cache優(yōu)化技術\\316
14.4.3  Buffer Cache的其他優(yōu)化技術\\318
14.5  Shared Pool優(yōu)化\\319
14.5.1  Shared Pool參數(shù)設置思路\\319
14.5.2  Shared Pool優(yōu)化技術\\320
14.5.3  再撞一次墻\\321
14.6  PGA優(yōu)化\\321
14.6.1  PGA參數(shù)設置思路\\321
14.6.2  匪夷所思的做法\\323
14.7  奇妙的Oracle內部參數(shù)\\325
14.7.1  Oracle有神奇的內部參數(shù)嗎？\\325
14.7.2  內部參數(shù)的一次神奇作用\\325
14.7.3  不要濫用內部參數(shù)\\327
14.7.4  令人眼花繚亂的內部參數(shù)和event\\327
第15章  存儲技術與性能優(yōu)化\\330
15.1  什么時候才考慮I/O優(yōu)化\\331
15.2  裸設備？文件系統(tǒng)？ASM？\\331
15.2.1  裸設備有那么神奇嗎？\\331
15.2.2  客戶期望值太高了\\332
15.2.3  文件系統(tǒng)和裸設備的原理分析\\332
15.2.4  文件系統(tǒng)同樣好\\333
15.3  RAID與性能優(yōu)化\\334
15.3.1  也說RAID\\334
15.3.2  IBM太慷慨了\\334
15.4  Oracle管存儲了\\336
15.4.1  關于ASM的疑慮\\336
15.4.2  ASM是什么？\\336
15.4.3  ASM有什么技術優(yōu)勢？\\337
15.4.4  Oracle即將不支持裸設備了\\338
15.5  ASM優(yōu)化策略\\338
15.5.1  裸設備與ASM的性能對比\\338
15.5.2  如何保證ASM實施的高性能\\340
15.5.3  ASM事例的參數(shù)設置建議\\341
15.6  ASM實施案例\\343
15.6.1  我所見過的真正海量數(shù)據(jù)庫\\343
15.6.2  裸設備還是ASM文件系統(tǒng)？\\344
15.6.3  ASM、OMF、大表空間技術的完美結合\\344
15.6.4  年輕教授被ASM氣得直跳腳\\345
15.6.5  寬容平和的心態(tài)\\346
第16章  數(shù)據(jù)保護中的性能優(yōu)化\\348
16.1  Oracle豐富的數(shù)據(jù)保護技術\\349
16.1.1  Oracle高可用性解決方案全景圖\\349
16.1.2  相關技術和產(chǎn)品的定位\\349
16.2  RMAN實施現(xiàn)狀分析\\350
16.2.1  備份恢復只是磁帶庫廠商的事情？\\350
16.2.2  RMAN實施中常見問題分析\\351
16.3  RMAN備份的優(yōu)化\\353
16.3.1  RMAN備份優(yōu)化的基本策略\\353
16.3.2  RMAN備份優(yōu)化的傳統(tǒng)技術\\353
16.3.3  在表空間級進行RMAN備份\\354
16.3.4  10g的快速增量備份技術\\356
16.3.5  備份壓縮技術\\358
16.4  RMAN恢復的優(yōu)化\\358
16.4.1  頭疼醫(yī)頭，腳疼醫(yī)腳\\358
16.4.2  降低日志恢復量\\360
16.4.3  增量更新備份\\361
16.5  快速恢復數(shù)據(jù)的新技術：Flashback\\361
16.5.1  人為邏輯錯誤是最大的單一因素\\361
16.5.2  傳統(tǒng)的數(shù)據(jù)恢復技術及缺陷\\362
16.5.3  Flashback技術概述\\363
16.5.4  Flashback技術綜合對比\\364
16.5.5  Flashback技術與傳統(tǒng)數(shù)據(jù)恢復技術綜合運用\\365
16.6  Data Guard實施中的優(yōu)化\\365
16.6.1  容災系統(tǒng)與生產(chǎn)系統(tǒng)是緊密相關的\\365
16.6.2  還是原理最重要\\366
16.6.3  日志傳輸?shù)膬?yōu)化\\366
16.6.4  日志恢復的優(yōu)化\\371
16.6.5  容災系統(tǒng)與生產(chǎn)系統(tǒng)的配置關系\\372
16.6.6  也談Data Guard與硬件存儲鏡像技術\\372
16.6.7  Data Guard和存儲鏡像技術的綜合\\374
第17章  故障診斷與性能優(yōu)化\\375
17.1  故障診斷與性能優(yōu)化的區(qū)別\\376
17.1.1  故障診斷與性能優(yōu)化不完全是一回事\\376
17.1.2  故障診斷需要一個偉大的心臟\\376
17.2  大汗淋漓的故障診斷\\377
17.2.1  一個“Ctrl + C”幾乎搞死一個系統(tǒng)\\377
17.2.2  啼笑皆非的故障處理過程\\378
17.2.3  脅從犯的自責\\379
17.3  可別小看數(shù)據(jù)壞塊處理\\379
17.3.1 “關于Oracle腐敗問題的處理”\\379
17.3.2  飛機落地了，資料還未看完\\380
17.3.3  收集信息、制定處理方案最重要\\380
17.3.4  數(shù)據(jù)壞塊處理的八卦圖\\381
17.3.5  別亂用DUL\\383
17.3.6  如何防范數(shù)據(jù)壞塊\\384
17.4  堪比好來塢大片的情節(jié)\\385
17.4.1  我的女同事被嚇壞了\\385
17.4.2  驚心動魄的時刻！\\385
17.4.3  事件遠沒有結束\\386
17.4.4  其實原因很簡單\\387
17.5  Oracle Buuuuuuuuuuuuuug\\388
17.5.1 我看Oracle Bug\\388
17.5.2  手工作坊與大工廠的差別\\389
17.5.3  一個展板都畫不下的流程圖\\389
17.6  軟件版本管理和補丁實施\\390
17.6.1  相關術語和概念\\390
17.6.2  未雨綢繆的補丁實施計劃\\391
17.6.3  打補丁那點事\\392
17.6.4  補丁沖突分析像偵探推理\\393
第18章  DBA職責及性能管理\\395
18.1  我的專職DBA經(jīng)歷\\396
18.1.1  不太安心的“DBA”\\396
18.1.2  無所事事的“DBA”\\396
18.1.3  手忙腳亂的“DBA”\\397
18.1.4  無所事事的DBA\\397
18.2  DBA職責建議\\398
18.2.1  DBA的十大任務\\398
18.2.2  DBA的工作比例\\400
18.2.3  不太懂SQL的DBA\\400
18.2.4  一位技術實力超強的DBA\\401
18.3  DBA在性能方面的工作\\402
18.3.1  每日的工作\\402
18.3.2  每周的工作\\403
18.3.3  每月的工作\\403
18.3.4  其他的工作\\403
18.4  性能管理更重要\\404
18.4.1  性能問題其實是管理問題\\404
18.4.2  開發(fā)人員永遠都長不大？\\404
18.4.3  Oracle核心技術開發(fā)團隊的故事\\405
18.5  開發(fā)與運行維護的脫節(jié)\\405
18.5.1  開發(fā)與運行維護部門的獨立性\\406
18.5.2  開發(fā)與運行維護工作的脫節(jié)\\406
18.6  客戶/開發(fā)商/Oracle的分工合作\\407
18.6.1  目前的分工和定位\\407
18.6.2  客戶在IT系統(tǒng)中的作用\\408
18.6.3  建議的分工和定位\\409
18.6.4  包含3種角色的項目組\\411
18.7  分工合作的成功案例\\412
18.7.1  系統(tǒng)運行情況\\412
18.7.2  系統(tǒng)主要技術特點\\412
18.7.3  項目成功因素分析\\413
18.7.4  Oracle公司的服務經(jīng)驗\\413
18.7.5  項目的不足\\414
第19章  軟件就是服務\\415
19.1  Oracle服務體系概述\\416
19.1.1  Oracle公司組織結構一瞥\\416
19.1.2  Oracle豐富的服務產(chǎn)品\\417
19.2  我看Oracle標準服務\\419
19.2.1  標準服務不僅僅是法律條款\\419
19.2.2  標準服務的益處\\419
19.3  愛不釋手的Metalink\\420
19.3.1  幸虧有Metalink\\420
19.3.2  初嘗Oracle服務甜頭\\420
19.3.3  Metalink是個大寶藏\\421
19.3.4  Metalink是個自助式的知識庫\\422
19.3.5  在Metalink中提交SR的經(jīng)驗\\423
19.3.6  把Metalink當成學習工具\\425
19.4  Oracle高級客戶服務\\426
19.4.1  ACS服務概述\\426
19.4.2  基于ITIL理念的ACS服務\\427
19.4.3  我們不是鐘點工\\430
19.4.4  ACS的運行維護服務\\430
19.4.5  IT系統(tǒng)挑戰(zhàn)和ACS解決方案服務\\432
19.4.6  幾種ACS解決方案服務\\432
19.5  又一次救火之后的感慨\\435
19.5.1  又著火了\\435
19.5.2  再次感謝Metalink\\435
19.5.3  客戶把系統(tǒng)重新安裝了\\436
19.5.4  其實還是服務問題\\436
第20章  一個更全面的案例\\438
20.1  為升級而來\\439
20.1.1  初識客戶\\439
20.1.2  升級方案遇到阻力\\439
20.2  以性能優(yōu)化開路\\440
20.2.1  性能是升級的第一大風險\\440
20.2.2  調整服務思路\\440
20.3  性能整體評估\\441
20.3.1  先看操作系統(tǒng)數(shù)據(jù)\\441
20.3.2  數(shù)據(jù)庫基準指標的采集\\441
20.3.3  性能分析策略和原則\\442
20.4  若干典型問題\\443
20.4.1  還是索引這樣基礎的問題\\443
20.4.2  發(fā)現(xiàn)了最大的性能瓶頸\\445
20.4.3  我把開發(fā)人員嚇住了\\449
20.4.4  參?可調的余地太小\\450
20.5  難以解決的問題：中間表\\451
20.5.1  又一類典型問題\\451
20.5.2  9i沒有合適的招\(zhòng)\451
20.5.3  10g的有效解決辦法\\452
20.6  又說分區(qū)方案設計\\453
20.6.1  分區(qū)表太多了\\453
20.6.2  分區(qū)設計的其他問題\\453
20.6.3  綜合平衡考慮問題不簡單\\454
20.7  再說升級\\454
20.7.1  對升級的兩種極端看法\\454
20.7.2  為什么要升級\\455
20.7.3  常見的升級方法\\456
20.7.4  Oracle升級服務包\\457
20.7.5  如何降低性能風險\\458
第21章  綜合類\\460
21.1  Oracle出硬件了\\461
21.1.1  我快變成硬件工程師了\\461
21.1.2  我看Exadata\\461
21.1.3  ACS在Exadata方面的服務\\464
21.2  Oracle全文檢索技術\\465
21.2.1  Oracle能做搜索引擎\\465
21.2.2  茅塞頓開的解決方案\\467
21.2.3  林子大了，什么鳥都有\(zhòng)\469
21.3  什么是IT系統(tǒng)最寶貴的財富\\470
21.3.1  IT系統(tǒng)最寶貴?財富是信息本身\\470
21.3.2  也談信息中心的作用\\470
21.4  如何閱讀Oracle聯(lián)機文檔\\471
21.4.1  Oracle聯(lián)機文檔的確是個寶藏\\471
21.4.2  合理分類閱讀和利用\\471
21.4.3  按工作角色和任務去閱讀\\473
21.5  IT行業(yè)中的“偽”科學\\474
21.5.1  什么叫IT“偽”科學\\474
21.5.2  費力不討好的事情\\474
21.5.3  我也是“偽”IT科學的吹鼓手\\475
21.6  性能優(yōu)化與橋牌\\477
21.6.1  大局觀的重要\\477
21.6.2  實施計劃的重要性\\478
21.6.3  應善于捕捉、利用信息\\478
21.6.4  合作、溝通的重要性\\479
21.6.5  簡簡單單，平平淡淡就是真\\479
21.7  IT業(yè)其實還是個孩子\\480
21.8  大話南游記\\481
結束語\\484
參考文獻\\486
推薦語\\489
推薦語1\\489
推薦語2\\489
推薦語3\\490