DB2數據庫管理最佳實踐（簡體書）

《DB2數據庫管理最佳實踐》內容簡介：IBM DB2作為業界主流的數據庫產品，廣泛應用于金融、通信、煙草等行業。《DB2數據庫管理最佳實踐》側重于DB2數據庫管理，以實戰為主要目標，內容涵蓋軟件安裝配置、數據庫環境搭建、存儲規劃、數據遷移、備份恢復、鎖、性能監控調優和常見的問題診斷等。通過循序漸進、深入淺出的講解，力求讓讀者親自動手實驗，結合實際案例，快速掌握DB2知識，獨立完成日常運維管理工作。《DB2數據庫管理最佳實踐》作者均有IBM原廠的工作經歷，實戰經驗非常豐富，《DB2數據庫管理最佳實踐》將和大家分享他們的DB2數據庫管理的最佳實踐經驗。

徐明偉，網絡ID：飛天。畢業于北京航空航天大學，計算機碩士專業。2004年加入IBM中國軟件開發中心軟件服務部，從事DB2、MDM相關的技術支持和咨詢工作。2010年成為DB2咨詢顧問，并創立北京普遠天成科技有限公司，繼續專注于為客戶提供DB2咨詢、培訓和支持工作。在DB2數據庫管理、性能調優和問題診斷方面，徐明偉具備非常豐富的經驗。曾經幫助云南移動，海南移動、貴州移動、上海移動、安徽聯通、人民銀行、農業銀行、交通銀行、晉商銀行、中央國債、中國銀聯、國家煙草局、南京鋼鐵、寶鋼股份、北京高速路、韓國國稅局、馬來西亞工業部等備類行業客戶進行DB2數據庫和相關產品的性能調優和問題診斷工作，獲得客戶高度認可。積極推動DB2的推廣和使用，組織了多場公開課培訓和企業內訓，培訓的人數超過千人，培訓內容注重理論和實戰相結合，并分享多個實際性能調優和問題診斷案例，深受客戶好評。王濤，網絡ID：wangzhonnew。畢業于加拿大卡爾加里大學，計算機科學專業。于2005年加入JBM加拿大多倫多實驗室，從事DB2二線技術支持。2007年升遷到DB2高級技術支持小組，主要負責北美區域客戶DB2系統宕機等嚴重事故處理與高級性能調優支持。2011年進入DB2三線高級問題診斷小組，主要負責全球各地最為復雜與緊急的客戶DB2數據庫系統故障診斷處理，以及部分模塊的研發與優化工作。王濤在DB2問題診斷和性能優化方面，具有極其豐富的經驗，曾經幫助包括花旗銀行，匯豐銀行、四大投行、可口可樂、波音、美國軍方以及政府等不同行業在內的數百家大型企業在第一時間恢復關鍵數據，為超過近百家企業的關鍵系統進行DB2性能診斷和優化，獲得客戶高度認可和贊譽。王濤是國內幾大知名DB2論壇的超級版主，熱心幫助國內客戶解決生產故障，積極參與社區的問題討論，為推動DB2在國內的傳播做出了突出貢獻。

《DB2數據庫管理最佳實踐》是電子工業出版社出版的。

第一部分 DB2概述第1章 DB2產品介紹11.1 數據模型11.2 DB2歷史21.3 DB2版本31.4 DB29主要功能增強51.5 DB2認證81.6 DBA的任務和職責81.7 IBM信息管理產品概述91.8 小結101.9 判斷題111.10 參考文獻11第2章 DB2體系結構122.1 DB2體系結構簡介122.2 對象層次關系152.3 數據訪問過程162.4 數據庫工具182.5 小結192.6 判斷題192.7 參考文檔20第二部分 DB2部置和規劃第3章 安裝DB2軟件213.1 軟件安裝213.1.1 軟件獲取223.1.2 安裝前檢查223.1.3 安裝233.1.4 補丁升級253.1.5 版本升級283.2 小結303.3 判斷題313.3 參考文檔31第4章 實例管理334.1 什么是實例334.2 創建實例344.2.1 在Windows平臺下創建實例344.2.2 在UNIX/Linux平臺下創建實例354.3 啟動/停止/列出實例374.4 更新實例384.5 刪除實例394.6 實例參數394.7 管理服務器（DatabaseAdministrationServer,DAS）404.8 小結414.9 判斷題41第5章 數據庫創建和存儲管理435.1 數據庫結構435.2 建庫、表空間455.3 表空間維護管理505.3.1 表空間監控505.3.2 表空間更改525.3.3 表空間狀態555.3.4 表空間高水位595.3.5 深入DMS表空間655.4 存儲設計最佳實踐675.5 小結715.6 判斷題71第6章 數據庫連接736.1 遠程連接概述736.2 節點和數據庫編目746.3 常見的數據庫連接問題766.4 小結786.5 判斷題79第7章 數據庫對象807.1 模式817.2 表817.2.1 表約束847.2.2 表狀態857.2.3 表壓縮867.2.4 表分區877.3 索引887.4 視圖947.5 昵稱947.6 序列（Sequence）947.7 自增字段967.8 大對象（LOB）987.9 函數1017.10 觸發器1027.11 存儲過程1037.12 小結1097.13 判斷題109第三部分 DB2運維管理第8章 數據遷移1108.1 數據遷移概述1118.2 文件格式1118.2.1 DEL格式1118.2.2 ASC格式1128.2.3 PC/IXF1128.2.4 Cursor1128.3 export1128.4 import1138.5 load1158.5.1 load步驟及原理1158.5.2 load表狀態1188.5.3 load的copy選項1198.5.4 setintegrity完整性檢查1258.6 12個怎么辦1298.6.1 出現了loadpending了怎么辦1298.6.2 在客戶端load問題1308.6.3 要加載的數據是Excel格式怎么辦1318.6.4 要導出/加載的數據不是逗號/雙引號分隔怎么辦1318.6.5 文件中的列比要導入的表中的字段多怎么辦1338.6.6 文件中的列比要導入的表中的字段少怎么辦1338.6.7 要導入/導出大字段（LOB）怎么辦1348.6.8 sequence數據怎么辦1358.6.9 導入identity數據怎么辦1368.6.10 要加載的數據有換行符怎么辦1398.6.11 遷移出現亂碼怎么辦1418.6.12 表數據從一個表空間遷移到另外一個表空間怎么辦1438.7 db2look/db2move1468.7.1 db2move工具介紹1468.7.2 db2look工具介紹1468.7.3 db2look+db2move遷移案例1478.8 db2dart1518.9 小結1538.10 判斷題153第9章 備份恢復1559.1 備份恢復概述1559.2 DB2日志1589.2.1 日志機制和原理1589.2.2 日志參數配置最佳實踐1639.2.3 日志監控和維護管理1689.2.4 其他日志相關的考慮1719.2.5 經常遇到的日志問題1729.3 備份1769.3.1 離線備份1789.3.2 在線備份1789.3.3 表空間備份1799.3.4 增量備份1799.3.5 備份介質檢查1809.3.6 備份監控1839.4 恢復1839.4.1 崩潰恢復1839.4.2 版本恢復1849.4.3 前滾恢復1929.4.4 刪除表恢復（droppedtablerecovery）1969.5 常見備份恢復場景及遇到的問題1999.5.1 宕機後數據庫連接hang的處理1999.5.2 循環日志模式下的離線備份恢復2009.5.3 歸檔日志模式下的備份恢復2019.5.4 歸檔日志模式下前滾恢復的幾個時間戳2039.5.5 同版本不同實例下的數據庫備份恢復（表空間是自動存儲管理）2059.5.6 同版本不同實例下的數據庫備份恢復（表空間是非自動存儲管理）2069.5.7 不同版本不同實例下的數據庫恢復2069.5.8 從生產庫到測試庫恢復的案例分析2079.5.9 歷史文件過大造成數據庫停止響應案例分析2099.5.10 恢復時解壓類包問題2109.5.11 備份失敗問題2119.6 小結2129.7 判斷題212第10章 DB2日常運維21310.1 日常運維工具概述21310.2 Runstats21410.2.1 Runstats原理21410.2.2 Runstats用法21510.3 Reorg21710.3.1 為什么需要Reorg21710.3.2 Reorg用法22110.3.3 Reorg最佳實踐22510.4 Rebind22610.5 獲取數據庫占用空間的大小22710.6 獲取某個表空間占用空間大小22810.7 獲取某個表/索引占用空間的大小22910.8 小結23110.9 判斷題232第11章 鎖和并發23311.1 鎖和隔離級別概述23311.2 鎖的模式和兼容性23511.2.1 表鎖模式23611.2.2 行鎖模式23911.2.3 表鎖和行鎖兼容性24311.3 鎖的各種問題24511.3.1 鎖等24511.3.2 鎖超時24611.3.3 死鎖24611.3.4 鎖升級24811.3.5 鎖轉換24911.4 鎖監控和診斷24911.4.1 鎖的分析思路和方法24911.4.2 鎖升級（lockescalation）的診斷分析25011.4.3 鎖等（lockwait）的捕獲與診斷分析25011.4.4 鎖超時（locktimeout）的捕獲與診斷分析25411.4.5 死鎖（deadlock）的捕獲與診斷分析25911.4.6 9.7 鎖事件監控器26311.5 鎖和并發調優26911.6 CurrentlyCommitted機制27011.7 小結27311.8 判斷題273第四部分 DB2監控和調優第12章 DB2進程/線程模型27412.1 提要27412.2 從操作系統看進程和線程27512.3 DB2V8/V9.1 進程模型27812.3.1 代理進程27912.3.2 分區內并行28012.3.3 分區間并行（DPF）28112.3.4 預取進程（prefetcher）28212.3.5 頁面清理進程（PageCleaner）28412.3.6 其他進程28512.3.7 實例/數據庫啟動步驟28712.4 DB29.5 /9.7 線程模型28912.5 小結29112.6 判斷題291第13章 DB2內存模型29213.1 從操作系統看內存29213.2 DB28/9.1 內存模型29413.2.1 實例共享內存段29513.2.2 數據庫共享內存29613.2.3 應用程序組共享內存29913.2.4 私有內存30013.3 DB29.5 /9.7 內存模型30113.3.1 實例內存30213.3.2 應用程序內存30213.3.3 自動內存調節（SelfTuningMemoryManagement，STMM）30313.4 內存監控30513.4.1 db2mtrk30513.4.2 db2pd-dbptnmem30613.4.3 db2pd-memset/db2pd-mempool30713.5 小結31013.6 判斷題310第14章 DB2監控工具31214.1 snapshot命令行監控31314.2 snapshot管理視圖31414.3 db2pd31514.4 db2top32814.4.1 實時監測32914.4.2 歷史信息收集33014.4.3 子窗口33114.5 DB2事件監控器34014.6 小結34114.7 判斷題341第15章 性能監控和分析方法34315.1 收集數據34315.1.1 操作系統級別性能監控34415.1.2 數據庫級別性能監控35415.1.3 數據收集的頻度38715.1.4 小結38915.2 分析數據38915.2.1 瓶頸分類與原理介紹38915.2.2 性能分析思路39715.2.3 性能分析案例40315.2.4 小結43715.3 判斷題437第16章 優化器與性能調優43816.1 優化器簡介43816.2 性能調優簡介45016.2.1 索引45716.2.2 排序46316.3 KPI47716.3.1 緩沖池命中率（bufferpoolhitratio）47716.3.2 有效索引讀47916.3.3 包緩存命中率（packagecachehitratio）48016.3.4 平均結果集大小48116.3.5 同步讀取比例48216.3.6 數據、索引頁清除48316.3.7 臟頁偷取（dirtypagesteal）48316.3.8 緩沖區讀寫I/O響應時間48416.3.9 DirectI/O時間48516.3.1 0直接I/O讀取（寫入）的次數48516.3.1 1編目緩沖區插入比例48616.3.1 2排序指標48616.3.1 3基于事務的指標度量48716.3.1 4檢測索引頁掃描49016.3.1 5日志寫入速度49116.3.1 6查詢執行速度49116.3.1 7實例級性能指標49216.3.1 8操作系統級指標49216.4 小結49416.5 判斷題494第五部分 DB2問題診斷第17章 問題診斷49517.1 概述49517.2 日志信息錯誤49617.3 宕機49817.4 掛起50317.5 錯誤信息50617.5.1 SQLCODE50717.5.2 db2trc51317.5.3 strace51917.6 分析數據收集工具52217.7 IBM服務支持體系52817.8 小結52817.9 判斷題529第18章 數據庫安全53018.1 安全概述53018.2 認證機制53118.3 權限控制53218.3.1 管理權限53218.3.2 對象特權53518.3.3 權限設計案例53718.4 審計機制54018.5 DB2安全最佳實踐54518.6 其他安全技術增強54518.7 小結54518.8 判斷題54518.9 參考文獻546

剛才我們所做的就是將一個服務器系統性能問題細化為數據庫服務器或者應用程序服務器的性能問題。如果能夠在3個系統中（應用程序服務器、數據庫服務器和存儲服務器）中至少排除掉一個，都能夠為我們性能分析帶來很大方便。但是有時候，很難排除以上任何一種。如果在上周四的數據中，發現上周四大概6個LIOW Executing，每秒15個查詢，CPU占用率5％，那么我們不能夠簡單地說這個是應用程序服務器的問題。一般來說，正常的系統，性能下降意味著單位時間內的吞吐量減少。可是該例中，正常吞吐量為每秒15個查詢，而性能不好的系統中為每秒50個查詢，這一點明顯有悖于正常行為。讓我們繼續分析。通過對CPU使用率的理解，當前CP[J使用率僅有10％，由此可以推斷CPU不應該成為瓶頸。那么問題可能出在哪呢？可能是應用層，比如修改了業務邏輯（需要更多的SQL語句），也可能發生在數據庫層，比如由于業務量的突然提高，導致更多鎖等待，產生系統懶惰。細化問題有一個前提，就是一定要小心不要走上錯誤的岔口。在每次回答一個小問題之前，都不要過度依賴某一類的數據。除了CPU使用率、并發數、吞吐量等指標，還包含更多的數據。我們一定要結合關鍵數據分析現象，千萬不要被某幾條現象所迷惑。每一次回答小問題的時候，都要仔細思考一下，有沒有其他任何數據能夠證明該答案是錯誤的。注意，“錯誤”并不是筆誤。每次回答問題之前，都要去假設心中的答案是一個錯誤的答案，然後嘗試去找數據證明這一點。如果沒有任何數據或者邏輯能夠反證你的推論，這個推導才算是合格可用的。在細化的過程中，有時候我們找不到一個完美的對比數據。比如有的時候當DBA被交予一個陌生的系統時，領導可能拍著桌子吼“這個系統跑了兩年都是好好的，可是性能上周突然下降得很厲害，你給我把它搞定”。這個時候，用戶可能并沒有該系統的歷史數據來對比，那么KPI（KeyPer- formance Indicator，關鍵性能指標）就是我們最好的朋友。KPI并不是憑空產生的，而是國內外無數專家在幾十年的性能分析中總結出的一套相對適用于大部分系統的性能指標。除非一個系統被設計得相當詭異，一般來說大部分系統都可以用KPI指標進行評估。當然，如果系統怪異到連最通常的KPI都不適用的情況下，那么這個系統的設計者估計也可以離職了。最通常的KPI可以說是緩沖池命中率。相信大部分DB2DBA都聽說過，就是說有百分之多少的機會，一個邏輯讀會發現數據已經存在緩沖池內部。這里我們先不給出具體數值，在下一章中，我們會列舉很多常用的KPL以及它們的用法和意義。數據收集頻率很重要，每一次數據收集前，我們都要弄清楚“從這次的收集中我們需要研究什么方向”，以及“為什么在前一次的收集中我們沒有收集到相關數據”。我們的目標是盡量減少無效的數據收集次數，但是由于性能問題的特殊性，人們不可能通過一次收集，就把所有可能發生性能問題的相關數據全部拿到。