天天看點

《品悟性能優化》讀後感

     《品悟性能優化》五一後開始看,昨天剛看完,大約看了1個星期,每天看1個小時吧。作者主要是結合實際案例介紹資料庫性能優化相關的資訊,如果你想從這本書裡學習性能優化知識,那估計找不到,因為裡面沒有告訴你太多的原理與技巧,更多的是通過介紹案例來表達作者對性能優化的認識。書中通過大量案例介紹,也展示了目前國内資訊化建設在性能規劃方面的水準及問題及資訊化工程實施的許多問題。

       從書裡流露出作者很鮮明的觀點:ORACLE博大精深,能稱為精通的人太少,多關注應用比關注ORACLE的内部技術實作細節更有效,把SQL、索引、分區幾個東西搞透了,結合應用來分析性能問題,什麼隐藏參數、latch之類的研究隻是偏方。

--個人對本書讀者的建議--

ORACLE新手:隻能當故事看,千萬别當真,當然,也有可能看完後會激起你學習ORACLE的興趣,因為很多ORACLE愛好者都是嘗到優化的甜頭而深入進來的。

ORACLE進階者:看故事時,檢驗自己是否了解為什麼能優化,争取能把每一個故事的優化原理及場景都模拟出來,最直接的檢驗是如果當時是你來處理,多久能診斷出問題并解決。

ORACLE高手:相信這裡面的每個優化原理都應該很清楚,是以隻能當故事看,了解一些客戶案例,了解ORACLE顧問的優化思路。

以下是連結

http://product.dangdang.com/product.aspx?product_id=21053160#catalog

目錄

《品悟性能優化》

第1章 從兩個案例開始 1

1.1 關于案例的說明 2

1.2 體驗日本人工作風格 2

1.2.1 問題現象及解決過程 2

1.2.2 日本人嚴謹、細緻的工作風格 3

1.2.3 日本人的it投入觀 3

1.2.4 該系統的總體感覺 4

1.2.5 在日本企業暖意洋洋的一幕 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資料庫性能優化方法論 9

2.1 關于性能優化的誤區 10

2.1.1 “你調了哪些參數” 10

2.1.2 “性能優化主要是dba和系統管理者的工作” 10

2.1.3 “開發階段無須太多考慮性能問題” 11

.2.1.4 “優化sql,就是如何編寫sql” 11

2.1.5 “多表連接配接性能太差” 11

2.1.6 “cpu使用率越低越好” 12

2.1.7 “大記憶體能解決性能問題” 12

2.1.8 “性能分析就是分析低層細節” 13

2.2 性能優化過程——自頂向下 13

2.2.1 為時已晚 13

2.2.2 什麼叫自頂向下方法論 13

2.2.3 體驗方法論 15

2.3 高品質it系統的正确認識 15

2.3.1 高品質it系統的目标 15

2.3.2 目标的綜合平衡 16

2.3.3 你隻管進,不管出啊 16

2.4 20/80規則 17

2.4.1 性能優化中也有20/80規則 17

2.4.2 用資料诠釋20/80規則 18

2.5 性能優化過程——自底向上 19

2.5.1 什麼叫自底向上方法論? 19

2.5.2 客戶要給我上課 20

2.6 性能優化中的角色分工 20

2.6.1 老外的角色分工 20

2.6.2 國内的角色分工 21

2.7 應用開發指導思想 22

2.7.1 管理重于技術 22

2.7.2 我聽後,開心死了 22

2.8 合理運用技術的重要性 22

2.8.1 聯機事務處理系統(oltp)和決策支援系統(olap) 22

2.8.2 “你們oracle給我們出一個開發規範和指南吧” 23

2.8.3 4分鐘如何優化到1秒鐘 24

第3章 性能優化分析基本工具的使用 29

3.1 性能優化中的量化分析 30

3.1.1 隔靴抓癢 30

3.1.2 sql語句到底是怎麼執行的 30

3.1.3 性能分析都分析哪些量化名額 32

3.2 工欲善其事,必先利其器 32

3.2.1 sql量化分析和優化工具 32

3.2.2 oracle有大量實用的小工具和指令 33

3.3 sql語句到底是怎麼被執行的 34

3.3.1 最經典的執行計劃分析工具 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 報告分析比如何産生報告更重要 37

3.5 最常用的工具:autotrace 37

3.6 一個洋“忽悠”的故事 42

3.6.1 洋和尚到中國來念梵文了 42

3.6.2 洋大“忽悠”啊 43

3.7 性能優化與“三個代表” 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 幸虧父母都是數學老師 57

4.3.3 慎用自定義函數 58

4.3.4 關于函數索引使用的建議 58

4.3.5 其實是資料庫設計問題 59

4.4 一把雙刃劍:複合索引 59

4.4.1 複合索引的重要性 59

4.4.2 我如何“戲弄”客戶 60

4.4.3 複合索引原理和設計建議 61

4.4.4 it系統是面向客戶的,不是給上司看的 63

4.5 一個既簡單又複雜的故事 64

4.5.1 女兒說我吹牛了 64

4.5.2 故事上集 65

4.5.3 故事中集 66

4.5.4 故事下集 66

4.6 如何進行索引監控分析和優化 68

4.6.1 為什麼索引i/o那麼高 68

4.6.2 别亂建索引 68

4.6.3 如何發現多餘的索引 69

4.6.4 如何進行索引碎片分析和整理 70

第5章 為應用軟體設計更好的性能和可擴充性 71

5.1 基本概念和原理 72

5.1.1 本章标題有點大吧 72

5.1.2 一個屢見不鮮的錯誤 72

5.1.3 解剖sql語句執行過程 73

5.2 語句共享性原理 74

5.2.1 再說聯機事務處理系統(oltp)

和決策支援系統(olap) 74

5.2.2 如何實作語句共享化 74

5.2.3 開發人員永遠比oracle聰明 75

5.2.4 技術服務工作,越做膽子越小 75

5.2.5 如何量化評估語句共享性 76

5.3 回到日本企業案例 77

5.3.1 深入分析技術原因 77

5.3.2 被日本人較真的滋味其實不好受 79

5.4 語句共享性的深入分析 79

5.4.1 語句共享性和查詢統計系統的關系 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 資料庫精髓之一:表連接配接 89

6.2.2 最經典、最常用的表連接配接技術——嵌套循環 90

6.2.3 嵌套循環連接配接與索引 91

6.2.4 嵌套循環連接配接的應用場景及效率 93

6.2.5 适合于大批量資料處理的連接配接技術 94

6.3 多表連接配接優化的基本思路 96

6.3.1 總體思路 96

6.3.2 oltp應用的表連接配接優化 96

6.4 如何使用子查詢 96

6.4.1 使用子查詢好不好 96

6.4.2 到底是使用in還是exists 97

6.5 回到20/80規則 99

6.5.1 優化詳細過程 100

6.5.2 技術方面總結 106

6.5.3 每項工作做到最好都不容易 107

第7章 應用綜合優化及總結 108

7.1更多的優化案例 109

7.1.1資料類型不一緻導緻的問題 109

7.1.2 多此一舉的操作 111

7.1.3 錯誤使用hint 113

7.1.4 oracle和ibm又一次成功合作 117

7.2 可怕的笛卡兒乘積 118

7.2.1 問題的發生和初步解決 119

7.2.2 其實是設計和開發中更深層次問題 120

7.3 說說全表掃描 122

7.3.1 導緻資料庫性能問題的常見原因 122

7.3.2 何謂全表掃描 122

7.3.3 資料增長與全表掃描的關系 123

7.3.4 硬體太多了 124

7.3.5 導緻技術運用複雜化的其他問題 124

7.3.6 更多的類比和感慨 125

7.4 導緻性能問題的其他原因 125

7.5 一個應用軟體的綜合優化 126

7.5.1 優化前的狀況 126

7.5.2 優化政策及分工合作 127

7.5.3 優化效果及原因分析 127

7.5.4 主管部門的反應 128

7.5.5 美妙的三降預言同時實作 129

7.5.6 優化工作的艱巨性和長期性 129

7.6 一個樸實無華的好系統 130

7.6.1 國人也能做出精良的好系統 130

7.6.2 巨大升值空間 131

7.6.3 瑕不掩瑜 131

第8章 oracle分區技術及應用 133

8.1 矽谷之行 134

8.1.1 it人的聖地:矽谷 134

8.1.2 我在oracle總部中邪了 135

8.2 我對oracle分區技術的認知過程 135

8.2.1 初嘗分區甜頭 135

8.2.2 分區給我的痛苦體驗 137

8.2.3 全面了解分區技術 138

8.3 分區表技術 138

8.3.1 分區技術原理:分而治之 138

8.3.2 分區表技術概述 140

8.3.3 11g的分區新技術 144

8.4 分區索引技術 146

8.4.1 分區索引技術好難哦 146

8.4.2 10分鐘讓你了解最難的分區索引 149

8.4.3 分區索引設計指南 151

8.5 更多的分區技術 153

8.5.1 一個神奇的分區技術 153

8.5.2 oracle分區技術發展史 154

8.6 如何實施和評估分區 155

8.6.1 分區設計建議 155

8.6.2 分區效果評估 156

8.6.3 如何在生産系統實施分區 156

8.7 某行業分區方案設計的曲折過程 159

8.7.1 第一階段:出師不利 159

8.7.2 第二階段:經驗主義錯誤 160

8.7.3 第三階段:初見成效 160

8.7.4 第四階段:日臻完善 160

8.8 分區方案中常見問題探讨 161

8.8.1 問題1:目标方面的誤區 161

8.8.2 問題2:分區表設計方面的誤區 162

8.8.3 問題3:沒有充分考慮應用設計和開發的誤區 162

8.8.4 問題4:分區表空間設計方面的誤區 163

8.8.5 問題5:分區在大批量資料進行中的誤區 164

8.8.6 問題6:分區索引設計方面的誤區 164

8.8.7 無止境的分區技術 165

第9章 架構與性能優化 166

9.1 該談談架構了 167

9.1.1 架構與性能的關系 167

9.1.2 oracle高端架構産品與性能的關系 167

9.1.3 oracle架構的重要性 168

9.2 基本概念很重要 169

9.2.1 什麼是oracle資料庫 169

9.2.2 伺服器、執行個體和資料庫的關系 170

9.2.3 關于架構方面的誤區 172

9.3 it系統架構現狀分析 173

9.3.1 一副并不美妙的大蜘蛛網 173

9.3.2 現有體系結構特點分析 174

9.3.3 現有體系結構評估 174

9.4 oracle網格計算 176

9.4.1 oracle 10g = 網格計算 176

9.4.2 按網格計算設計資料庫架構 176

9.4.3 烏托邦式架構就是好 178

9.4.4 初級階段的設計建議 179

9.4.5 關于真正大集中的疑慮 179

9.5 雲計算與性能優化 182

9.5.1 滿天翻滾的雲 182

9.5.2 oracle的紅雲 182

9.5.3 客戶關注的雲計算話題 183

9.6 oracle資料庫分布式架構 184

9.6.1 資料複制技術 184

9.6.2 data guard技術簡介 186

9.6.3 streams技術簡介 187

9.6.4 其他資料同步技術 188

9.6.5 資料同步技術的定位和比較 188

9.7 我看分布式架構 190

9.7.1 我不喜歡分布式架構 190

9.7.2 資料大集中與分布式架構 191

9.7.3 分布式架構的用武之地 192

9.7.4 真正的返璞歸真 192

9.8 誓做抗拒拆遷的刁民 193

9.8.1 拆遷大錘已高高舉起 193

9.8.2 統一戰線發揮重要作用 193

9.8.3 人民戰争的汪洋大海 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與性能優化 200

10.1 關于rac的一些誤解和疑慮 201

10.2 rac技術原理 203

10.2.1 系統介紹rac架構和原理 203

10.2.2 rac到底有什麼好處 204

10.2.3 10g rac架構新特性 205

10.2.4 我害怕oracle什麼技術工作 206

10.3 rac架構的優勢 207

10.3.1 為什麼rac架構比ha架構好 207

10.3.2 客戶的方案不一定是最優的 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性能優化原理 213

10.5.1 rac性能優化等同于單事例 213

10.5.2 rac性能問題與應用關系 214

10.5.3 應用在rac環境下部署的最佳方式 216

10.6 rac環境下的性能分析 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個節點? 225

10.8.2 oracle總部rac專家的觀點 225

10.8.3 某大型交易系統的擴充性測試 226

10.8.4 如何實施rac擴充性 227

10.9 rac運作維護和故障診斷 228

10.9.1 rac運作維護建議 228

10.9.2 rac故障診斷經驗談 228

10.9.3 瞎貓碰上死耗子 229

第11章 資料倉庫中的性能優化 231

11.1 我看資料倉庫 232

11.1.1 資料倉庫不是倉庫管理軟體 232

11.1.2 資料倉庫鼻祖的精确定義 232

11.1.3 資料倉庫的應用特點 233

11.1.4 我所了解的資料倉庫 233

11.1.5 本書講述的資料倉庫 234

11.2 資料倉庫應用開發指導思想 235

11.2.1 資料倉庫應用開發指導思想建議 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 并行處理經驗 242

11.3.5 榨幹所有硬體資源 243

11.4 oracle是個大電腦 244

11.4.1 告别農耕時代 244

11.4.2 oracle不僅是一個存資料的大容器 244

11.5 大批量資料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 一個應用開發中的典型性問題 250

11.6.2 oracle系統級臨時表 253

11.7 一種快速高效的資料倉庫加載方案 253

11.7.1 讓洋鬼子激動地蹦到桌子上去 253

11.7.2 快速高效的資料倉庫加載方案 255

11.8 報表優化技術 259

11.8.1 我的第一次軟體開發經曆 259

11.8.2 現在的報表處理狀況 260

11.8.3 報表優化核心技術:物化視圖和語句重寫 261

11.8.4 為什麼不要自己編寫彙總表 263

11.8.5 報表優化的基本思路及示例 263

11.8.6 報表優化示例 264

11.8.7 為什麼沒有實作語句重寫 268

11.8.8 it行業到底是買方市場還是賣方市場 269

第12章 統計資訊采集與性能優化 272

12.1 我闖大禍了 273

12.1.1 常在河邊走,哪有不濕鞋的 273

12.1.2 太急于表現了 273

12.1.3 建一個索引,搞死一個系統 274

12.1.4 我被罵得滿地找地縫 274

12.1.5 初識問題原因 275

12.1.6 問題根本原因 275

12.2 優化器原理和統計資訊采集作用 276

12.2.1 sql語句執行過程 276

12.2.2 基于規則優化器(rbo)簡介 277

12.2.3 基于成本優化器(cbo)簡介 278

12.2.4 如何将葫蘆和瓢都按下 278

12.2.5 為什麼要進行統計資訊采集 279

12.3 自動采集統計資訊 279

12.3.1 自動采集統計資訊的特點 279

12.3.2 自動還是手工 280

12.3.3 超長的自動統計資訊采集 280

12.3.4 一次變味的資料庫更新技術研讨會 282

12.4 定制采集統計資訊 282

12.4.1 統計資訊采集基本政策 282

12.4.2 統計資訊采集實施政策 283

12.4.3 統計資訊采集具體方法 283

12.4.4 oracle 10g鬼精鬼精的 285

12.5 若幹最佳實踐經驗 286

12.5.1 自動和手工結合進行統計資訊采集 286

12.5.2 鎖住統計資訊采集 286

12.5.3 資料分布統計(histogram)建議 286

12.5.4 批進行中的統計資訊采集 287

12.5.5 鐵路警察,各管一段 288

第13章 感悟性能優化分析的進階工具 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能自動診斷監控嗎 298

13.3.1 addm能幹啥 298

13.3.2 dba要失業了嗎 300

13.4 sql優化進入工業化時代 301

13.4.1 傳統模式到工業化 301

13.4.2 sql tuning advisor能做哪些優化 302

13.4.3 sql access advisor能做哪些優化 304

13.4.4 sql tuning advisor和sql access advisor的差異 304

13.4.5 oem中的每條指令我都會敲 304

13.4.6 it工業化時代的初級階段 305

第14章 參數配置與性能優化 307

14.1 神奇的“魔術師” 308

14.1.1 不調系統參數 308

14.1.2 調錯系統參數 308

14.2 漫談初始化參數 309

14.2.1 神奇的初始化參數 309

14.2.2 參數設定基本思路和經驗 310

14.2.3 将log buffer設它個幾百兆 311

14.3 自動記憶體管理 311

14.3.1 dba真地快沒活幹了 311

14.3.2 自動記憶體管理技術管用嗎 314

14.4 buffer cache優化 315

14.4.1 buffer cache參數設定思路 315

14.4.2 buffer cache優化技術 316

14.4.3 buffer cache的其他優化技術 318

14.5 shared pool優化 319

14.5.1 shared pool參數設定思路 319

14.5.2 shared pool優化技術 320

14.5.3 再撞一次牆 321

14.6 pga優化 321

14.6.1 pga參數設定思路 321

14.6.2 匪夷所思的做法 323

14.7 奇妙的oracle内部參數 325

14.7.1 oracle有神奇的内部參數嗎? 325

14.7.2 内部參數的一次神奇作用 325

14.7.3 不要濫用内部參數 327

14.7.4 令人眼花缭亂的内部參數和event 327

第15章 存儲技術與性能優化 330

15.1 什麼時候才考慮i/o優化 331

15.2 裸裝置?檔案系統?asm? 331

15.2.1 裸裝置有那麼神奇嗎? 331

15.2.2 客戶期望值太高了 332

15.2.3 檔案系統和裸裝置的原理分析 332

15.2.4 檔案系統同樣好 333

15.3 raid與性能優化 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有什麼技術優勢? 337

15.4.4 oracle即将不支援裸裝置了 338

15.5 asm優化政策 338

15.5.1 裸裝置與asm的性能對比 338

15.5.2 如何保證asm實施的高性能 340

15.5.3 asm事例的參數設定建議 341

15.6 asm實施案例 343

15.6.1 我所見過的真正海量資料庫 343

15.6.2 裸裝置還是asm檔案系統? 344

15.6.3 asm、omf、大表空間技術的完美結合 344

15.6.4 年輕教授被asm氣得直跳腳 345

15.6.5 寬容平和的心态 346

第16章 資料保護中的性能優化 348

16.1 oracle豐富的資料保護技術 349

16.1.1 oracle高可用性解決方案全景圖 349

16.1.2 相關技術和産品的定位 349

16.2 rman實施現狀分析 350

16.2.1 備份恢複隻是錄音帶庫廠商的事情? 350

16.2.2 rman實施中常見問題分析 351

16.3 rman備份的優化 353

16.3.1 rman備份優化的基本政策 353

16.3.2 rman備份優化的傳統技術 353

16.3.3 在表空間級進行rman備份 354

16.3.4 10g的快速增量備份技術 356

16.3.5 備份壓縮技術 358

16.4 rman恢複的優化 358

16.4.1 頭疼醫頭,腳疼醫腳 358

16.4.2 降低日志恢複量 360

16.4.3 增量更新備份 361

16.5 快速恢複資料的新技術:flashback 361

16.5.1 人為邏輯錯誤是最大的單一因素 361

16.5.2 傳統的資料恢複技術及缺陷 362

16.5.3 flashback技術概述 363

16.5.4 flashback技術綜合對比 364

16.5.5 flashback技術與傳統資料恢複技術綜合運用 365

16.6 data guard實施中的優化 365

16.6.1 容災系統與生産系統是緊密相關的 365

16.6.2 還是原理最重要 366

16.6.3 日志傳輸的優化 366

16.6.4 日志恢複的優化 371

16.6.5 容災系統與生産系統的配置關系 372

16.6.6 也談data guard與硬體存儲鏡像技術 372

16.6.7 data guard和存儲鏡像技術的綜合 374

第17章 故障診斷與性能優化 375

17.1 故障診斷與性能優化的差別 376

17.1.1 故障診斷與性能優化不完全是一回事 376

17.1.2 故障診斷需要一個偉大的心髒 376

17.2 大汗淋漓的故障診斷 377

17.2.1 一個“ctrl + c”幾乎搞死一個系統 377

17.2.2 啼笑皆非的故障處理過程 378

17.2.3 脅從犯的自責 379

17.3 可别小看資料壞塊處理 379

17.3.1 “關于oracle腐敗問題的處理” 379

17.3.2 飛機落地了,資料還未看完 380

17.3.3 收集資訊、制定處理方案最重要 380

17.3.4 資料壞塊處理的八卦圖 381

17.3.5 别亂用dul 383

17.3.6 如何防範資料壞塊 384

17.4 堪比好來塢大片的情節 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經曆 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 開發人員永遠都長不大? 404

18.4.3 oracle核心技術開發團隊的故事 405

18.5 開發與運作維護的脫節 405

18.5.1 開發與運作維護部門的獨立性 406

18.5.2 開發與運作維護工作的脫節 406

18.6 客戶/開發商/oracle的分工合作 407

18.6.1 目前的分工和定位 407

18.6.2 客戶在it系統中的作用 408

18.6.3 建議的分工和定位 409

18.6.4 包含3種角色的項目組 411

18.7 分工合作的成功案例 412

18.7.1 系統運作情況 412

18.7.2 系統主要技術特點 412

18.7.3 項目成功因素分析 413

18.7.4 oracle公司的服務經驗 413

18.7.5 項目的不足 414

第19章 軟體就是服務 415

19.1 oracle服務體系概述 416

19.1.1 oracle公司組織結構一瞥 416

19.1.2 oracle豐富的服務産品 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的經驗 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系統挑戰和acs解決方案服務 432

19.4.6 幾種acs解決方案服務 432

19.5 又一次救火之後的感慨 435

19.5.1 又着火了 435

19.5.2 再次感謝metalink 435

19.5.3 客戶把系統重新安裝了 436

19.5.4 其實還是服務問題 436

第20章 一個更全面的案例 438

20.1 為更新而來 439

20.1.1 初識客戶 439

20.1.2 更新方案遇到阻力 439

20.2 以性能優化開路 440

20.2.1 性能是更新的第一大風險 440

20.2.2 調整服務思路 440

20.3 性能整體評估 441

20.3.1 先看作業系統資料 441

20.3.2 資料庫基準名額的采集 441

20.3.3 性能分析政策和原則 442

20.4 若幹典型問題 443

20.4.1 還是索引這樣基礎的問題 443

20.4.2 發現了最大的性能瓶頸 445

20.4.3 我把開發人員吓住了 449

20.4.4 參數可調的餘地太小 450

20.5 難以解決的問題:中間表 451

20.5.1 又一類典型問題 451

20.5.2 9i沒有合适的招 451

20.5.3 10g的有效解決辦法 452

20.6 又說分區方案設計 453

20.6.1 分區表太多了 453

20.6.2 分區設計的其他問題 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 林子大了,什麼鳥都有 469

21.3 什麼是it系統最寶貴的财富 470

21.3.1 it系統最寶貴的财富是資訊本身 470

21.3.2 也談資訊中心的作用 470

21.4 如何閱讀oracle聯機文檔 471

21.4.1 oracle聯機文檔的确是個寶藏 471

21.4.2 合理分類閱讀和利用 471

21.4.3 按工作角色和任務去閱讀 473

21.5 it行業中的“僞”科學 474

21.5.1 什麼叫it“僞”科學 474

21.5.2 費力不讨好的事情 474

21.5.3 我也是“僞”it科學的吹鼓手 475

21.6 性能優化與橋牌 477

21.6.1 大局觀的重要 477

21.6.2 實施計劃的重要性 478

21.6.3 應善于捕捉、利用資訊 478

21.6.4 合作、溝通的重要性 479

21.6.5 簡簡單單,平平淡淡就是真 479

21.7 it業其實還是個孩子 480

21.8 大話南遊記 481

結束語 484

參考文獻 486