-- 會員 / 註冊 --  
 帳號:
 密碼:
  | 註冊 | 忘記密碼
3/26 新書到! 3/19 新書到! 3/14 新書到! 12/12 新書到!
購書流程Q & A站務留言版客服信箱
3ds MaxMayaRhinoAfter EffectsSketchUpZBrushPainterUnity
PhotoShopAutoCadMasterCamSolidWorksCreoUGRevitNuke
C#CC++Java遊戲程式Linux嵌入式PLCFPGAMatlab
駭客資料庫搜索引擎影像處理FluentVR+ARANSYS深度學習
單晶片AVROpenGLArduinoRaspberry Pi電路設計CadenceProtel
HadoopPythonStm32CortexLabview手機程式AndroidiPhone
可查書名,作者,ISBN,3dwoo書號
詳細書籍分類

DB2設計、管理與性能優化藝術

( 簡體 字)
作者:王飛鵬、李玉明、朱志輝、王富國類別:1. -> 資料庫 -> DB2
譯者:
出版社:清華大學出版社DB2設計、管理與性能優化藝術 3dWoo書號: 36702
詢問書籍請說出此書號!

缺書
NT售價: 395

出版日:8/19/2013
頁數:492
光碟數:0
站長推薦:
印刷:黑白印刷語系: ( 簡體 版 )
加入購物車 加到我的最愛
(請先登入會員)
ISBN:9787302326618
作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證)
作者序:

譯者序:

前言:

序一



DB2數據庫是IBM公司數據管理產品線上最知名也是最成功的產品,不僅在大型主機市場處于絕對領導地位,而且在開放式平臺的影響力更是與日俱增,不斷地有客戶從Oracle遷移到DB2。
說起DB2的悠久歷史,實際上它起源于一篇具有劃時代意義的論文。1970年,IBM公司的研究員埃德加 考特(Edgar F. Codd)發表了名為“大型共享數據庫的關系模型”(A Relational Model of Data for Large Shared Data Banks)的論文,從而正式拉開了關系型數據庫的大幕。從那時起,IBM公司就一直在數據庫這個領域深耕細作,持續創新,通過不斷研發優秀的產品屹立于強手如林的科技界,表現在DB2研發上更是不斷的推陳出新。下面是DB2發展史上具有重要里程碑意義的版本,它們一經推出就獲得了業界的廣泛好評。
1983年,DB2正式問世,被IBM大型機所專用,之所以命名為DB2,是由于以前已經有了一個著名的層次型數據庫產品Information Management System(IMS)。
1992年,IBM將DB2帶向了多種開放式平臺,包括Linux、Unix以及Windows服務器,也簡稱為DB2 LUW。
2002年,IBM發布了DB2 V8,這個版本開始支持數據庫分區特性(Data Partitioning Feature, DPF),從而通過非分享(Share Nothing)的MPP架構為數據倉庫提供更強的伸縮性。
2006年,IBM發布了DB2 V9,這個全新的DB2是第一款“天然”存儲XML的關系型數據庫。
2008年,IBM發布了DB2 V9.7,提供了Oracle兼容特性,這個版本完全支持Oracle語法,從而大大方便了應用和數據庫遷移。
2009年,IBM發布了DB2 V9.8,增加了DB2 pureScale特性,該特性利用了z/OS大型機上經過驗證的DB2數據庫集群技術,在開放平臺上實現了共享磁盤(Share Disk)架構,以滿足高吞吐量OLTP應用對高可用性、擴展性和負載均衡的需要。
2012年4月,IBM發布了DB2 V10,該版本提供了多時態表、多表星型連接、行列訪問控制(RCAC)、多溫度存儲、自適應壓縮等特性。在這個版本中,DB2 pureScale技術得到了進一步完善,從而獲得了很多行業客戶的高度認可,目前DB2 pureScale已經在中國金融、航空、煙草等行業的生產庫上得到了成功實施。
2012年10月,IBM正式推出了數據庫一體機PureData。該產品不同于競爭對手的支持混合負載一體機,而是針對交易處理、分析和操作分析這三種應用場合分別提供不同的軟硬件預配置解決方案。
時光荏苒,我加入IBM中國開發中心已經快20年了,在這里非常榮幸見證了中國工程師DB2研發實力的快速提高。從剛開始接一些簡單的開發工作,到現在參與DB2最新的核心技術開發;從剛開始國外團隊對中國工程師工作能力的半信半疑,到現在獲得國外DB2團隊的信任和認可,這說明中國開發中心在IBM全球的研發地位變得越來越重要了。當然,除了研發最新的DB2核心技術外,中國開發中心還作為培養中國DB2人才的“黃埔軍校”,培養了一大批技術支持和服務客戶的優秀工程師。
成績是非常突出的,但是存在的一些問題也毋庸諱言。在數據庫用戶中,精通Oracle的人非常多,但是精通DB2開發、維護和優化的人就相對比較少了,這在一定程度上影響了DB2產品的使用。其實,說到底這是DB2生態系統的問題。作為原廠來說,IBM公司是非常愿意通過各種方式和途徑推廣DB2產品技術的,例如通過和db2china社區的緊密合作,定期由來自中國研發中心的資深工程師在db2china社區上輪值來解答用戶的棘手問題,中國開發中心也會和db2china社區定期舉辦DB2沙龍以更有效地傳播DB2新技術,這些努力都取得了非常好的效果。
近幾年來,我們還逐漸加大了對IBM客戶和合作伙伴的支持力度。針對DB2客戶,我們于2011年在大中華區成立了DB2客戶顧問委員會,簡稱DB2 CAC,目前來自銀行、電信、保險、制造等不同行業的多個客戶已經加入了這個委員會。這種方式加強了DB2實驗室和客戶之間的雙向交流與合作,我們為客戶安排了實驗室顧問(Lab Advocate),向他們介紹DB2最新的技術發展,客戶也可以把他們對DB2產品的需求提供給DB2開發團隊,這種方式收到了非常顯著的效果。另外,針對合作伙伴,我們今年成立了一個合作伙伴委員會(Business Partner Council)以幫助IBM重要合作伙伴在他們的業務系統中使用好DB2。
實際上,除了IBM官方的積極推動外,類似《DB2設計、管理與性能優化藝術》這樣的DB2書籍也是一種非常有效的技術推廣方式。這本書由來自IBM中國開發中心的DB2資深工程師編寫,具備科學的性能優化知識體系,以大量實戰案例為載體,不僅展示了DB2經典設計和優化方法學,還涵蓋了DB2高級設計和優化技術,例如DB2 HADR、DB2 pureScale集群、數據倉庫等。這對奮戰在數據庫應用開發與優化一線的DB2用戶來說,可以說是找到了一把進入DB2技術圣殿的金鑰匙,希望廣大讀者能從中獲益。

IBM中國開發中心 DB2開發與客戶支持總監
干毅民
2013年7月1日


序二



去國離家十四載后,2009年,當我再次從IBM多倫多實驗室歸來凝視上海這座不夜城時,不由地感慨世界真的變小了、變平了,中國作為地球村的一員,正以驚人的速度發展變化著,而我的工作也一樣在發展變化著。從加拿大回國后于2010年正式加入IBM中國軟件開發實驗室,由之前的DB2數據管理工作,轉而開始從事數據治理(Data Governance)方面的工作。
過去的十年是企業的IT系統數據量高速膨脹的時期,“大數據”時代已悄然來臨:每天,遍布世界各個角落的傳感器、移動設備、在線交易和社交網絡生成上百萬兆字節的數據;每個月,人類發布 10 億條 Twitter 信息和300 億條 Facebook 信息。據統計,全球 90% 的數據都是在過去兩年中生成的。
“大數據”時代必然會產生新的“大數據”問題。哪些數據是可信的?哪些數據需要進行清洗?如何從海量數據中獲得業務洞察力,從而指導商業決策?如何確保新錄入的信息不會產生冗余?如何以可復用的方式發布可信任的信息?如何使如此龐大的數據真正變成對企業有價值的信息?這些海量的、分散在不同角落的數據帶來了資源利用的復雜和管理的困難等問題。
以上所述各種問題,最終的解決辦法就是要靠數據治理。(在很多時候我們用一個更為精確的概念——信息治理)數據治理是專注于將數據作為企業的商業資產進行應用和管理的一套管理機制。良好的數據治理能夠消除數據的不一致性,提高組織數據質量,建立規范的數據應用標準,實現數據廣泛共享,并能夠將數據作為企業的寶貴資產應用于業務、管理、戰略決策中,發揮數據資產的最大商業價值。
這幾年,數據治理在國內的研究和應用都取得了一定進展,但是也面臨觀念上和實踐上的雙重挑戰。從觀念上看,國內很多人認為數據治理只是IT部門的責任,只把數據治理當成軟件,并未真正意識到業務、數據和軟件之間的關系,也就不能從整體上將數據作為企業資產來看待。從實踐上看,很多企業做了數據質量檢查,做了數據歸檔,做了數據安全,但缺乏一個完整的體系來將各個部分串聯起來,也就是說,缺乏將這些領域組織起來的方法論。
為了幫助企業更好地管理數據資產,應用大數據時代信息治理的挑戰,IBM 推出了全新的信息管理和業務分析產品,并提供技術資源,致力于為企業及機構提供大數據分析、信息整合、主數據管理等數據治理解決方案。以下都是基于IBM數據治理方案的優秀軟件。
IBM InfoSphere BigInsights是IBM大數據平臺的核心產品之一,它是一款以Hadoop為基礎的、對海量數據進行存儲、管理和分析的企業級平臺。可以在 30 分鐘內安裝完畢并投入運行,可用來管理企業各種數據,比如大量來自社交網絡、移動設備和傳感器等不同來源的非結構化數據,并對這些數據進行深度挖掘和分析。
IBM InfoSphere Information Server 系列軟件支持將大數據作為來源和目標進行整合,并憑借其成熟可靠的性能和并行引擎,提供大數據所需的強大可擴展性,包括元數據管理、數據清洗、數據質量治理及分析、數據自動化分析、數據抽取轉換加載、數據集成、監控與報告等一整套軟件組成的企業級信息平臺。通過它可分析、清洗和整合異構源中的數據信息,并且把經過分析、清理后的可信任信息以可復用的方式提供給用戶,同時也對新錄入的信息進行實時的數據清洗操作,保證新錄入信息的正確性。
IBM InfoSphere Master Data Management軟件,其最核心的任務是導出企業的關鍵業務數據,也是絕對真實的數據。主數據管理旨在從企業的多個業務系統中整合最核心的需要共享的數據,集中進行數據清洗,并以服務的方式把統一、完整、準確的主數據分發給企業內的操作型應用和分析型應用,包括業務系統、業務流程和決策支持系統等。使用戶更深入地理解生產鏈條上的各個要素——客戶、產品、供應商、員工等之間的關系,為進一步分析和決策做重要支撐。
IBM InfoSphere Stream 是IBM大數據平臺中專門針對快速產生的如流水般不間斷的海量數據流的處理平臺。它是一個支持開發和部署的應用程序平臺。能夠持續快速地分析實時產生的各種各樣的海量流數據。具有低延遲、實時響應、跨多個數據流進行分析的特點,尤其適用于對響應時間有較高要求的應用,例如欺詐檢測、網絡管理,能很好地解決企業處理數據量大、存儲成本高的問題。通過直接對數據進行分析,無須存儲,從而實現對有價值數據進行深入分析的可能。能夠在大規模的集群環境中并行、高性能地處理流數據,并具有近似于線性的可擴展性,是幫助企業處理實時化的海量流數據分析的好幫手。
談了不少數據治理,那么它和DB2數據管理有什么不同?我想分享一下我的觀點。如果說從事數據質量管理、主數據管理等數據治理工作的人是數據巨輪的船長,他們平時的工作就是站在艦橋上,穿著帶金色肩章的白制服,用雙筒望遠鏡了望遠方以把握方向,那么從事DB2相關工作的DBA就是在輪機艙工作的船員,船長和船員雙方共同為數據巨輪的穩定運行發揮重要作用。但是,在實際工作中,我經常發現這樣的事情:當艦橋上傳來船長焦急的指令,命令DBA加快數據流動的速度時,DBA由于缺乏駕馭DB2的優化技巧,只能回答說,“DB2引擎遇到性能瓶頸了,船長!”。雖然船長的指令很及時,但遇到這樣的船員,數據巨輪恐怕也運轉不佳了。
DB2船員的實際水平制約了船長對數據巨輪的駕馭能力。本書就是一本供DB2船員行駛的實戰手冊,希望廣大船員能真正理解和掌握書中講述的DB2設計與性能優化藝術,當收到船長要求加速數據流動的命令時,可以讓DB2引擎運行得更好,這樣數據巨輪就能暢通無阻得行駛下去。

IBM中國開發中心信息管理產品開發部
洪樺 資深主管經理
2013年6月8日


序三



IBM百年華誕,在2011年奪目九界,璀璨全球。創新,這是IBM能屹立于強手如林的科技界的關鍵,使得她能夠適應科技時代發展的需要,不斷創新求變,從而把握時代的脈搏,解決今天以及未來企業遇到或可能遇到的重大挑戰。
進入21世紀,IBM與其眾多對手們不約而同地投入到了信息時代的競爭。隨著信息技術的迅猛發展,作為其核心組成部分的數據之戰已成為了21世紀“競爭”的新內涵,而作為承載、處理和加工這些數據的數據庫軟件行業就不可避免地成為了主戰場。
為了滿足客戶各種需求,大家競爭的對象是極富生命力的數據。在數據的整個生命歷程中,它會經歷設計、開發、部署、運營、優化和治理的不同階段,并且這不是一次性的過程,而是通過周期性的迭代方式,來發揮數據更大的價值。任何一家企業擁有了對數據強大的管控和支配,它就會在21世紀數據之戰中立于不敗地位,甚至引領信息時代的發展。
IBM 正在著手于實現一個戰略計劃,提供一個集成的模塊化數據管理環境,幫助企業更高效準確地管理整個數據生命周期(從需求到報廢)。我們將這個過程稱為“集成數據管理”,管理數據生命周期的每個環節,并能夠支持各種主流廠商提供的數據管理技術,這包括DB2、Informix、Oracle等。
本文中提到的IBM Optim Tools,就是應運而生的這樣一個工具集,它除了提供對數據庫基本的管理和開發功能外,還提供了強大的DB2監控和優化功能。IBM Optim Tools最大的優勢就在于對DB2數據庫全面的支持,能夠及時地反映并緊跟上DB2數據庫的發展和更新,例如對DB2數據倉庫和DB2 pureScale的支持。
本書的作者都有非常豐富的數據庫管理和優化經驗,使得本書具有極佳的實踐性和可操作性,相信能為廣大的數據庫用戶提供前所未有的幫助。

IBM中國開發中心信息管理產品開發部
資深經理 孫冰江
2013年6月28日寫于北京


序四



我和飛鵬在幾年前的一次InfoSphere培訓中結識,基于對DB2的共同愛好,我們經常探討關于DB2的各種技術,受益頗豐。如今飛鵬的舞動DB2系列專著已經陸續出版上市,作為已經閱讀過舞動DB2系列書籍的讀者,我想說,這套專著的理論水平毋庸置疑,實際案例更是經驗和智慧的結晶,對于使用DB2的各個層次的讀者都會有很大幫助。
這次,新書《DB2設計與性能優化藝術》即將上市了,我受飛鵬之邀為本書作序,感到十分榮幸。
先講講我和數據庫的故事。我從1992年開始使用數據庫,最初是用FOXBASE開發了一個工資管理系統。1995年開始基于DB2 for AS400的銀行應用開發。1997年開始基于SYBASE的證券應用開發。1998年開始從一名開發者轉向系統工程師,開始了中間件和數據庫方面的技術支持。1999年獲得DB2 V5 DBA認證。1999年~2006年,先后做過SYBASE、DB2、Oracle數據庫的規劃設計、系統管理、故障排除、性能優化、開發指導等工作。2007年開始主要關注和研究IBM軟件,提供主流數據庫、數據倉庫、數據遷移、災難備份的咨詢及培訓服務。到目前為止,我擁有DB2從版本5到版本10的DBA認證、DB2 版本9的高級DBA認證、Oracle 11G DBA OCP認證、Informix 10和11的DBA認證以及IBM的InfoSphere及Tivoli的各種認證40余個。目前擔任IBM官方認證講師,負責十多項產品的培訓工作。
雖然我做過各種類型的數據庫工作,但是數據庫的設計與優化無疑是一項很重要且關鍵的工作。說起數據庫優化,先給大家講一個故事。華佗兄弟三人都精通醫術,有一天一個人問華佗,你們家里兄弟三人誰的醫術最高,這時華佗說:我們家大哥的醫術最高明,其次是我的二哥,醫術最差的就是我了。提問者十分不解地問:所有人都知道你是天下最有名、醫術最高的人了,怎么還有比你醫術更高明的人?于是華佗說了一段非常耐人尋味的話:“我大哥治病是在人們尚未察覺身體有病的時候為人們醫治的,人們對他醫術不甚了解。我二哥治病是在人們開始發病的時候通過望聞問切,開處方醫治病人的,人們只是對他有所了解。我看病是在病人的病情非常嚴重的時候,才給病人下藥,所以人們認為我能夠讓人起死回生,因此我最有名氣,但是論醫術水平我與我的兄長差距很大呀!”其實DBA就像是數據庫的醫生,數據庫的性能優化也有三個階段:第一個階段是,數據庫性能出現嚴重問題時去診斷分析、提出整改方案,即使能起死回生,但由于之前的規劃設計缺陷很難達到持續穩定健康的運行;第二階段是,在數據庫運維過程及時發現問題解決問題,但同樣也受限于之前的規劃設計;第三個階段是,在數據庫規劃設計階段就開始考慮性能問題,這是性能優化的最高境界。所以設計與性能優化是分不開的,這也是本書所關注和闡述的。
通過十多年的數據庫經驗,強烈地感覺到數據庫設計與性能優化需要了解數據庫之外的很多相關知識,比如:操作系統、存儲、網絡、中間件,這些知識是相互關聯和影響的,既而成為一個既獨立又統一的系統,理解和掌握的越多,在性能優化時考慮得越全面。DBA如同一個劍客,借用電影《英雄》的臺詞:“劍法有三種境界:第一種,手中有劍、心中卻無劍,主要練就的是一招一式;第二,手中有劍、心中有劍,所謂人劍合一,練就的是劍氣;第三,手中無劍、心中也無劍,是一種至大則空的平和。第三種被稱為劍法的最高境界。” 第一種,手中有劍、心中卻無劍:這種境界的DBA知道很多DB2的命令及用法,但對這些命令及用法的使用場景是否匹配合適則無所適從。第二種,手中有劍,心中有劍:知道很多命令及用法,也知道這些命令及用法的適用場景,也能做到活學活用。第三種,手中無劍、心中也無劍:不再使用現成的某某高手寫的安裝指南、運維指南等,不再僅關注于數據庫,而更多地是利用DB2的信息中心,通過全面地系統感悟,做到IT系統為我服務,我來規劃設計IT系統。到了這個境界,就不會糾結于要學習DB2還是Oracle,因為兩者的很多東西都是相通的。希望本書能引導讀者走向DBA的最高境界。

北京富通東方科技有限公司技術服務中心副總經理
張東煥
2013年7月15日寫于北京


前 言



“三方演義”與性能優化
性能優化為什么這么難?
一個IT系統建設的過程,其實就是“三方演義”的過程。這里的三方,就是客戶方、開發商和IBM原廠,通常是客戶提需求,開發商負責應用設計和開發,IBM提供軟硬件產品,系統完成開發后,由客戶或者第三方公司運行維護。一個IT系統的好壞,取決于這三方能否緊密合作,能否發揮各自獨特的優勢,從而實現1+1+1>3的效果。
類似于IT系統建設,一個上規模的性能優化項目,也是“三方演義”的互動過程。我經歷過一些爛尾項目,這種項目在啟動的時候,大家坐在一起指點江山,高談政治,拍腦袋做決定,當出現性能問題的時候非常浮躁,不能冷靜客觀地分析問題和解決問題,而是叫喊著用更高檔的硬件,缺乏嚴謹、務實、執著和求真的精神,缺乏對性能優化項目最起碼的敬畏感。
首先是客戶方。錢是客戶出的,客戶是真正的甲方,所以客戶總是最強勢,客戶領導經常在會議上發號施令,當遇到問題的時候把開發商罵得一塌糊涂:“看看你們寫的垃圾代碼,還想讓我們購買更好的硬件?”或者罵原廠:“你們說過DB2提供的自動維護特性不需要DBA過多干預,但為啥根本不是那么回事呢?”罵歸罵,出了問題其實客戶也是有責任的,你為啥不彎下身段,真正參與到系統的設計、開發和維護的整個過程呢?這樣即使出了問題,心里也有底了呀。但是,現實中又很難,因為這和客戶內部的體制有關,通常在一個項目的不同階段,各個部門就像“鐵路警察,各管一段”,開發部門只管開發,運維部門只負責上線維護,運維部門和開發部門是各自為戰,當出了問題后,相互踢皮球,協調起來非常困難。例如,金融業的客戶,一般擁有自己專門的開發部門和運維部門,兩個部門獨立,不存在上下級隸屬關系,遇到困難后很容易相互扯皮。至于電信業和政府部門,出了系統性問題更難協調:電信業的客戶,通常只負責系統維護工作,應用開發通常由第三方的開發商負責;政府客戶,只負責需求、系統規劃和管理工作,開發和維護都是由第三方公司承擔的。針對客戶方,我想強調的是,沒有專業分工的局面是可怕的,但太過于精細的分工同樣效率低下,更可怕的是很多企業采用政治掛帥的方式啟動和管理項目,這是導致爛尾的重要根源之一。
接下來談談開發商。開發商是挨客戶罵最多的了,但并不妨礙他們喜歡拍胸脯,啥都敢承諾,啥都敢做,畢竟有其獨特優勢。開發商有人力資源的優勢,手中有大量的開發人員可供使用;開發商還有對業務理解的優勢,畢竟開發商長期和行業客戶在一起,積累了很多業務經驗和知識;通常開發商還有關系的優勢,畢竟從客戶那拿項目,是要和客戶關系融洽、有信譽才行。但是,開發商也有技術硬傷,那就是對系統軟件,包括硬件、數據庫、中間件等的使用水平還停留在安裝配置的層面,缺乏對其內部機制的了解,所以在架構規劃、數據庫優化、高可用性測試、可擴展性測試等方面技術上做不到甚至沒有這方面的意識,更不可能實施了。
最后談談原廠。原廠的人員也會挨罵,也會被開發商拿來當擋箭牌,這不新鮮。原廠有自己的核心優勢,那就是對自身產品的深入理解,以及跨金融、電信、政府等各行業應用所積累的實施優勢,這必將在架構規劃、數據庫優化、擴展性測試等需要技術深度和經驗的領域發揮重要作用,也可以為客戶和開發人員在設計、開發和運維等工作上提供至關重要的技術支持。但是,原廠也有做的不夠好的地方,其實也是體制上的原因,那就是以圍繞產品的技術支持為主,如果在推動最新的技術和產品給客戶的同時能愿意多傾聽客戶的真正需求,如果能積極主動參與到項目規劃、設計、開發、測試和運維的整個階段,那將對IT系統質量的提升發揮重要作用。
在這樣一個“三方演義”的架構下,要想完成性能優化工作有時候超越了技術本身,它更多地需要設計開發人員和運維人員的緊密配合。比如,當我發現SQL語句的問題,需要開發人員支持和配合的時候,卻被告知項目已經被開發商交付給客戶了,沒有辦法找到開發人員了。有時候我即使找到了開發人員,他們卻對SQL語句的最終運行環境一點都不關注,他們只是強調SQL語句是業務邏輯的需要。于是,我不得不找運維人員尋求支持,但是運維人員讓我更吃驚,他們只關注主機、操作系統和數據庫本身,對上層應用缺乏了解,也不關注上層SQL語句是怎么寫的。
這可能是國內IT系統建設的一個縮影吧,所以在此我僅提出一條呼吁性質的建議:在客戶的推動下,設計開發人員和運維人員定期舉行技術交流,多交流硬件、數據庫、中間件以及應用開發中遇到的性能痛點,拿出一套行之有效的辦法在當前項目中試點并在其他項目中加以推廣。
某銀行性能優化的真實案例
2012年12月15日,星期六,早上8點鐘,本人衣冠楚楚,匆匆出門,打算去參加一個老同學的婚禮。剛上出租車,就接到了公司銷售的電話,說是國內某銀行客戶的DB2數據庫上線試運行后出現了非常嚴重的性能問題,希望我趕赴浙江寧波現場做一下性能調優工作。前幾年如果周末接到這種電話,我內心肯定會抱怨一番的,周末了都不讓人好好休息,不過經歷的多了也就適應了,也慢慢練就了亂云飛渡仍從容的氣度。老同學的婚禮該參加還是繼續參加,該喝酒還是繼續喝酒,該定去寧波的機票還是繼續定。
我是12月16日晚上抵達寧波的,到了之后和客戶領導鄭總約了第二天也就是12月17日早上9點在現場召開會議。
第二天也就是星期一上午8點50分,我剛到了客戶會議室門口,就聽見一個人在滿腔怒火地訓斥,從聲音可以聽出來這個訓人者就是昨天和我通電話的客戶領導鄭總。等我剛踏入會議室,發現場面非常隆重,里面坐了很多人,除了客戶領導外,還有客戶方DBA小李、第三方顧問公司的架構師老張、以及來自幾家應用開發商的大隊開發人員,可謂各路英豪齊聚一堂啊。作為原廠的唯一代表,本人孤獨地坐在了角落里。會議幾乎在爭吵中度過,下面是我對大家發言概要的整理。
鄭總發言:“這個項目是銀監會重點督導的項目,具有重要的政治意義,如果這個項目在寧波試點成功了,那么可以推廣到華東甚至是全國。但是,開發商在開發階段就屢次拖延工期,這次上線試運行后,又暴露了嚴重的性能問題,業務人員沒法使用,對此我是非常不滿意的,需要拿出徹底的整改辦法來。”
開發商代表發言:“首先,接受領導的批判。但是,這個項目的業務需求改動了好幾次,另外我們的隊伍對Weblogic應用服務器和Oracle數據庫非常熟悉,但是對DB2數據庫開發和優化的技術積累非常薄弱啊,沒有原廠的支持是不行的。”
鄭總發言:“原廠的工程師已經到了,王工,你終于出山了,昨天從北京過來的吧,你可是DB2領域的領軍人物了,解決這個性能問題可以說是舉手之勞啊……”
我發言:“多謝大家的信任,初來乍到,我先了解一下情況再發表建議吧。”
客戶方DBA小李發言(發言非常激烈):“這個應用上線試運行后,正常情況下還好,但是一旦達到了1000并發用戶時,系統的平均響應時間從1s一下急劇增加到4s左右,業務人員根本就沒法用,要知道現在的硬件可是16內核的雙機Power 740了!”
開發商代表接著發言(已經快哭了):“現在雙機Power 740配置太低了,難以滿足性能需要,請按業務最高峰值配置硬件資源,使用最高檔Power 780,另外存儲設備也要升級,用IBM V7000!”
鄭總發言:“這算什么回事?不是國慶節前后剛從x3850升級到Power 740嗎,當時你們可是告訴我,Power 740肯定夠用了,現在又要到Power 780,你們真好意思說出口!”
開發商代表小聲說:“這個不會是DB2的Bug導致的吧……”
第三方顧問公司的架構師老張發言:“現在是雙機Power 740,一臺運行Weblogic應用服務器,一臺運行DB2,使用HACMP來實現HA,當出現故障時,一臺機器接管另外一臺。現在DB2有新的技術了,可以用DB2 pureScale試試,如果還不行的話,可以考慮DB2一體機方案pureData,應用跑上去肯定快幾倍!”
我尋思著,首先感謝這個架構師對IBM新技術新產品的信任,不過他也有點太著急了,目前是響應時間慢的問題,不是事務吞吐量遇到瓶頸的問題,在沒有真正分析客戶的性能瓶頸之前,這樣去硬推銷DB2 pureScale或者pureData一體機,不僅不會給客戶留下好感,有時候反而讓客戶對這些新技術或者新產品產生強烈的逆反心理。
會開到這個份上,其實已經陷入了僵局,我坐在角落里,大腦里反復出現鄭總的話,經驗告訴我,當客戶遇到危難猛夸我的時候,其實已經把我推到了風口上了,因為終于有了可以堵槍眼的人了。當然,我也在考慮解決辦法,內心也發出這樣的感慨:相當一部分客戶和開發商,什么都敢用,但是都用的不夠專業,不夠精細,這樣一旦出現性能問題時,他們就只能高談政治意義,隨后習慣性地拍腦袋做決定,很難冷靜客觀地分析問題和解決問題。
快到中午了,鄭總下午還有其他日常安排,開發商提出的用最高檔Power 780的建議即將被一錘定音的時候,我趕緊發言,把我想說的用最快的速度說了出去:“首先,我認為這個系統目前不應使用Power 780和IBM V7000存儲,那是一種對資源的浪費,Power 740跑這樣的負載綽綽有余;其次,我認為DB2還有優化空間,我有辦法調整一些參數讓DB2把硬件的能力發揮出來;最后,也是最重要的,應用軟件還有很大優化空間,至少在1000并發用戶的情況下,響應速度急劇變慢,就和應用有關。”
我說出上面的話后,整個會議室突然寧靜了下來,開發商的人員面面相覷,客戶領導這時反而笑了,笑的我有點發毛,他和藹的問我:“王工,你有幾成把握?這個項目可是非常緊急的,不能意氣用事啊”,我內心其實也虛不過還是表面非常鎮定地回答:“立足于現有的硬件環境,請給我5天時間吧,當我優化數據庫和改造應用的時候,請DBA和開發人員配合我,謝謝!”
可能是外來的和尚會念經吧,另外我估計鄭總以前就被那些勸他升級高檔硬件Power 780的人嚇怕了。非常出人意料,喜歡張嘴罵人的鄭總竟然采納了我的建議,也對我提出的讓DBA和開發人員配合這樣的要求全部滿足。不過,最后他走出會議室的時候,丟下了一句狠話給我:“我現在罵人都罵累了,如果沒有搞定,就走人吧。”
星期一:應用自下而上方法學,制定優化計劃
立下了軍令狀,優化工作也就正式開始了。
下午的時候,我和小李以及來自開發商的幾個開發人員在會議室進行了深入討論,確定優化方法和實施計劃。開發人員剛要開始給我詳細介紹應用邏輯的時候,我立刻拒絕了,現在沒有時間聽這個。
其實,他們都想知道我葫蘆里賣的什么藥,想看看我有什么辦法解決這個燃眉之急。我內心其實也是有點忐忑的,不過還是先給他們上了一課:“性能優化的方法有兩種:自上而下方法學和自下而上方法學。自上而下的思路是早發現早解決,越到后面發現,優化的成本就越高,因為它是貫穿設計、開發和維護的所有階段的,不過目前已經處于試運行階段,自上而下顯然是不可行了,所以只能采用自下而上方法學。”
我看他們似懂非懂,滿臉迷茫的樣子,隨后接著解釋自下而上方法學:“它是一種應急的辦法,分別從硬件和應用入手,硬件上通過合理配置讓DB2發揮硬件最大能力,這個不難,我用一天時間就能解決好。比較費勁的是應用優化,第一,我沒有時間了解應用邏輯的細節,當務之急是需要花時間把最影響性能的模塊找出來,再從這個模塊里面找出前10位執行時間最長、執行次數最多的SQL語句,分析它們的訪問計劃,隨后運用索引、表連接、分區等技術有效解決它們;第二,在開發應用的時候,開發人員對DB2的鎖機制估計考慮的不周,上午小李提到的有1000并發用戶時,系統響應時間急劇增加,這個很可能和鎖有關,但本質上牽涉到應用代碼。”
于是,大家一起制定了優化計劃:星期二,調整參數,發揮硬件的處理能力;星期三,優化執行時間最長、執行次數最多的SQL語句;星期四和星期五,從應用角度解決鎖問題。
星期二:調整參數,發揮硬件處理能力
我和小李來到了客戶機房,一進到機房,讓我大吃一驚。作為一名常年在客戶現場服務的DB2工程師,我去過北上廣很多大客戶的機房,包括最大電信運營商的和最大銀行的,這個客戶在寧波,我原以為硬件投入上比不上北上廣那些客戶,但是沒想到進去后,全是清一色的IBM服務器、HP服務器,還有EMC存儲服務器,足有100多臺。我忍不住一聲嘆息,都這么多硬件了,還想忽悠客戶繼續升級硬件,這也太浮躁了。
言歸正傳,考慮到業務系統的性能不僅僅由數據庫決定,它涉及存儲、主機、DB2數據庫和Weblogic應用服務器,所以,對這些內容都要進行性能監控。
首先監控了Weblogic應用服務器的運行情況。主機的CPU和內存利用率一切正常,這個也是開發商的強項,他們對Weblogic非常熟悉,所以沒有問題也是意料之中的事。
其次是存儲規劃。這塊是小李搭建的,一共16塊盤,每塊盤300GB左右,劃分為4個RAID組,每個RAID組是3D+1P,其中兩個RAID組存放數據,一個RAID組存放索引,最后一個RAID組存放事務日志,這是一種教科書式的規劃。我通過SSH命令登錄到DB2服務器上,使用dd命令對每個RAID組的I/O吞吐能力進行了測速,可以達到200 M/s以上,暫時沒有調整的必要。
dd if=/dev/zero of=/data1/test.file bs=8192 count=5000000
5000000+0 records in
5000000+0 records out
40960000000 bytes (41 GB) copied, 179.411 seconds, 228 MB/s
接著是CPU利用率。在1000并發用戶的情況下,擁有16個內核的Power 740的CPU利用率也就是20%左右,顯然是足夠了。
最后是監控內存。使用get snapshot命令抓取了數據庫快照和應用快照,發現緩沖池的命中率竟然只有60%,而且有大量的排序溢出和編目緩存溢出。我仔細檢查了一下,發現服務器總的物理內存為64GB,平時可用內存大約48GB左右,但是發現DB2僅僅申請了2G內存,用于緩沖池、排序堆、包緩存、編目緩存、鎖列表等!把這么多內存空余下來想干啥?這是最大的浪費啊,而且緩沖池命中率這么低。想想也覺得這沒有什么奇怪的,很多DBA只知道DB2提供的STMM內存自調優,但并不了解STMM對并發訪問量非常大的交易系統的自調整有一定的滯后,而且它本身也有一定的開銷。
憑借我的技術和經驗,我對下面的參數進行了手工調整。其實真正調整的就是下面幾條語句,但就是這幾條語句,客戶、開發商和第三方顧問公司要求我寫書面的調整建議書,隨后反復評估了整個下午,先在測試環境驗證,最后我和小李在晚上負載低的時候進行了正式實施。
調整緩沖池大小,將DataBuf設置為102400個頁面,由于頁面大小為16K,所以總大小為16GB,IndexBuf設置為512000,即8GB,再次監控,緩沖池命中率達到了99%!
--pagesize為16K
ALTER BUFFERPOOL DataBuf IMMEDIATE size 1024000
ALTER BUFFERPOOL IndexBuf IMMEDIATE size 512000
增加sortheap大小直到不出現排序溢出為止,最終調整為819200。
update dbm cfg using SHEAPTHRES 0
update db cfg using sheapthres_shr 1638400
update db cfg using sortheap 819200
同樣的辦法,增大CATALOGCACHE_SZ直到編目緩存不出現溢出為止,最終調整為102400。
update db cfg using CATALOGCACHE_SZ 102400
同樣的辦法,增大PCKCACHESZ直到包緩存不出現溢出為止,最終調整為102400。
update db cfg using PCKCACHESZ 102400
星期三:優化前10位執行時間最長、執行次數最多的SQL語句
這一天是我過的最開心的一天,也是最順利的一天。早上剛到機房,小李就把昨晚的對比結果發出來了:經過參數調整后,在1000并發用戶的情況下,系統的響應時間從4s減少到了2s。
接下來按照計劃開始了優化SQL語句。本來以為能抓住什么能裝滿好幾頁的SQL語句,假如我自己解決不了的話,可以請教加拿大多倫多實驗室的SQL專家,但沒想到我從snapdyn_sql管理視圖里面抓出的前10位執行時間最長的SQL語句竟然都非常簡單,但是執行次數非常多,達到了上億次!
select TOTAL_EXEC_TIME, NUM_EXECUTIONS,STMT_TEXT from sysibmadm.snapdyn_sql order by TOTAL_EXEC_TIME desc fetch first 10 rows only
NUM_EXECUTIONS TOTAL_EXEC_TIME STMT_TEXT
3292321 293118181
SELECT ORDERID, ORDERTIME FROM BANK.ORDER WHERE ORDERNumber = ? AND ORDERTIME > ? AND ORDERTIME <= ? ORDER BY ORDERTIME DESC
... ... ...
首先來看第1條執行時間最長的SQL語句。這個SQL語句很簡單,就是對表ORDER上的一個動態查詢,ORDER這個表有3億多條記錄,它竟然執行了3292321秒,執行了293118181次!
解決辦法是什么?其實很簡單,為這條語句創建如下索引,這樣不用再對ORDER表進行表掃描,可以通過索引掃描取得結果:
CREATE INDEX "BANK"."IQUERY" ON "BANK"." ORDER"
("ORDERNumber" ASC,
"ORDERTIME" ASC)
MINPCTUSED 10
ALLOW REVERSE SCANS
創建完畢后,運行runstats命令,重新收集統計信息,這樣優化器在生成訪問計劃的時候就可以用上索引了。
其他9條執行時間最長的SQL語句,也是通過索引技術進行了優化。隨后,我整理了報告發給了客戶、開發商和第三方顧問公司供他們評估使用。很快,他們就做了答復,同意先在測試環境驗證。完成驗證后,已經夜深人靜了,最后我喝著咖啡指導小李在生產庫上進行了成功實施。
星期四:解決鎖問題
早上來的時候,路上堵車,晚到了20分鐘。當我剛到機房門口就聽見鄭總在用非常洪亮的聲音給小李和開發商的開發人員講話。他剛看到我就說:“王工,這幾天工作成果很顯著嘛,聽小李說,現在平均響應時間已經優化到1s左右了,看樣子大功告成了,晚上請你吃寧波菜!”
看樣子鄭總的心情不錯,但是,我知道還有優化空間,因為星期二調整參數的時候發現了大量的鎖等待。憑借我的經驗,鎖問題的產生通常是由于表的不合理設計或者事務對表的不合理訪問導致的,這才是影響并發的關鍵所在。我告訴鄭總,革命尚未成功,宜將余勇追窮寇,我再加把勁,看看能否再提升一下。
于是,在小李的配合下,我多次使用db2pd工具分析鎖,發現在高并發的情況下,應用會千萬次的執行同一事務邏輯,即查詢熱表SALESDATA中的某一行,隨后再修改這個熱表中的同樣的行,這樣當多個事務爭搶同一行時,就會出現大量的鎖等待。
通過抓取應用快照,發現這些同一事務的業務邏輯也不復雜,就是兩條SQL語句,都是對表SALESDATA操作的,這個表有8000萬左右的記錄數。
--開始事務
業務邏輯代碼...
--對表SALESDATA進行查詢
SELECT ARRIVALATTENDED, ARRIVALFIRCODE, ARRIVALHOLIDAYSURCHARGE, NIGHTARRIVAL,
VICINITYAPPROACHCOUNTVFR, VICINITYDEPARTURECOUNTVFR, WORKSTATIONIDENTIFIER FROM BANK.SALESDATA WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ?
業務邏輯代碼...
--對表SALESDATA進行更新
UPDATE BANK.SALESDATA SET ARRIVALATTENDED = ?, ARRIVALFIRCODE = ?, ARRIVALHOLIDAYSURCHARGE = ?, NIGHTARRIVAL = ?, VICINITYAPPROACHCOUNTVFR = ?, VICINITYDEPARTURECOUNTVFR = ?, WORKSTATIONIDENTIFIER = ? WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ?
--結束事務
遇到這種情況,只能和開發人員溝通一下了。開發人員告訴我,這是業務邏輯的要求,沒有辦法修改代碼的,所以他們建議調整一下鎖有關的參數而不是修改代碼。我知道這么做,只是治標不治本,不過調整也能取得一定的效果,也就答應了。
最終將LOCKTIMEOUT從90調整為30,這里的單位是秒,90秒的時間太長了,設置為30秒比較合理,這樣鎖等待超過30秒后,就會回滾事務并報鎖超時,從而提升事務吞吐量。
update db cfg using LOCKTIMEOUT 30
將LOCKLIST調大為40960,MAXLOCK調大為60,這樣為鎖分配更多的內存資源。
update db cfg using LOCKLIST 40960
update db cfg using MAXLOCKS 60
這個事務的頻繁執行,會寫大量的日志到磁盤上,分別增大了日志緩沖區(LOGBUFSZ)、日志文件大小(LOGFILSIZ)、主日志文件個數(LOGPRIMARY)和輔助日志文件個數(LOGSECOND)。
update db cfg using LOGBUFSZ 10240;
update db cfg using LOGFILSIZ 102400;
update db cfg using LOGPRIMARY 50;
update db cfg using LOGSECOND 30;
晚上,鄭總開車過來,帶著我、小李和幾個開發人員一起去了一家著名的寧波菜館。由于1s的平均響應時間已經達到了,所以大家也比較放松,吃的不錯,也喝了酒。我借著酒勁,告訴鄭總,越到后面,調優的成本越高,但我還要再猛攻一下,看看能否達到0.9s左右,至少要把鎖等待消滅一批才行。
星期五:應用改造
早上來到機房,小李告訴我,昨天對鎖參數的調整效果不大,但是預定的目標已經達到了,這個時候停下來客戶方鄭總是可以接受的,不過我可不能這樣就草率放棄。
Oracle的DBA一般遇到問題,第一時間想到的是Metalink網站,對DB2來說就是信息中心了。我到DB2信息中心網站上檢索了一下,原來這兩條語句是這樣加鎖的,在當前CS隔離級下,第一條SELECT語句根據where條件獲取某一行上的NS鎖,這條語句可以立即獲得NS鎖,不會出現鎖等待;但是,第二條update語句會試圖將該行上的NS鎖升級為X鎖,這個時候就有可能發生鎖等待。
--開始事務
業務邏輯代碼...
--對表SALESDATA進行查詢
--這條select語句會根據where字句的條件獲取指定行的NS鎖
SELECT ARRIVALATTENDED, ARRIVALFIRCODE, ARRIVALHOLIDAYSURCHARGE, NIGHTARRIVAL,
VICINITYAPPROACHCOUNTVFR, VICINITYDEPARTURECOUNTVFR, WORKSTATIONIDENTIFIER FROM BANK.SALESDATA WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ?
業務邏輯代碼...
--對表SALESDATA進行更新
--這條update語句會將該行上的NS鎖試圖升級為X鎖
UPDATE BANK.SALESDATA SET ARRIVALATTENDED = ?, ARRIVALFIRCODE = ?, ARRIVALHOLIDAYSURCHARGE = ?, NIGHTARRIVAL = ?, VICINITYAPPROACHCOUNTVFR = ?, VICINITYDEPARTURECOUNTVFR = ?, WORKSTATIONIDENTIFIER = ? WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ?
--結束事務
那么有什么變通的辦法呢?根據DB2信息中心的提示,我做了下面的改動,第一條SELECT語句后面加入“with RS USE AND KEEP EXCLUSIVE LOCKS”子句,這樣可以直接獲取指定行上的X鎖,當然這個時候也會出現一定數量的鎖等待;等到update語句執行的時候,無需從NS鎖到X鎖的轉換了,也就不會再出現鎖等待了。
--開始事務
業務邏輯代碼...
--對表SALESDATA進行查詢
--這條select語句會根據where字句的條件直接獲取指定行的X鎖
SELECT ARRIVALATTENDED, ARRIVALFIRCODE, ARRIVALHOLIDAYSURCHARGE, NIGHTARRIVAL,
VICINITYAPPROACHCOUNTVFR, VICINITYDEPARTURECOUNTVFR, WORKSTATIONIDENTIFIER FROM BANK.SALESDATA WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ? with RS USE AND KEEP EXCLUSIVE LOCKS
業務邏輯代碼...
--對表SALESDATA進行更新
--該行上已經是X鎖了,不需要從NS到X的鎖轉換了
UPDATE BANK.SALESDATA SET ARRIVALATTENDED = ?, ARRIVALFIRCODE = ?, ARRIVALHOLIDAYSURCHARGE = ?, NIGHTARRIVAL = ?, VICINITYAPPROACHCOUNTVFR = ?, VICINITYDEPARTURECOUNTVFR = ?, WORKSTATIONIDENTIFIER = ? WHERE FLIGHTIDENTIFIER = ? AND RECORDTYPE = ?
--結束事務
新的方案是否對性能有幫助,只有經過測試才知道。上午的時候,我把報告發給了客戶和開發商供他們評估。盡管改動很小,由于目標已經達到,所以開發商的態度還是十分消極的,不太愿意修改應用代碼。不過還好,客戶方的鄭總盡管不懂技術細節,但他認可這個辦法,至少是可以試試的。
開發商花了30分鐘就改好了代碼,重新部署到Weblogic應用服務器上,隨后在測試環境進行了驗證,取得了不錯的效果。最終,星期五的晚上,我、小李和開發人員一起在生產庫上進行了正式實施。
實施完畢后,已經晚上8點多了,我踏上了從寧波飛往北京的最后一班飛機,心中安慰自己說,至少效果不會更壞吧。到了星期天,小李打電話告訴我效果:鎖等待數量從原來的幾十萬個減少到了幾千個,平均響應時間達到了0.9s!
DBA要失業了嗎?
本書介紹的DB2設計與性能優化方法,基本上都需要DBA調整系統參數,調整邏輯設計和物理設計,解決鎖問題,定位SQL語句,分析其訪問計劃,在測試環境驗證,在生產環境實施,最后評估結果。這是一種手工優化方式,對DBA和開發人員有一定的技術要求。
從V9.1開始,DB2提供了很多自調整特性,例如自動存儲管理( Automatic Storage)、自動內存調優(Sefl Tuning Memory Management)、自適應壓縮等,另外還提供了自動監控工具OPM(Optim Performance Manager),自動SQL語句調優工具(Optim Query Tuner)、自動查詢負載調優工具(Optim Query Workload Tuner),也就是說要從傳統的手工優化時代進入自動優化時代!
本人在2010年參與過一個電信行業的數據倉庫項目,當時客戶方的DBA要求在項目中使用圖形化工具。一名來自開發商的DB2高手站起來大聲抗議:“圖形化工具沒用,DB2中的每條命令我都是順手敲來!”大家都知道,他的確是技術精湛的高手,對他來說敲命令是沒有任何難度的。當然,他說的也未必全是錯的,他可以在一些對安全管理非常規范的客戶那發揮關鍵作用。例如金融證券業客戶,一般不允許你使用自己的筆記本,你只能使用客戶提供的客戶端軟件。但是這個客戶端可能什么工具都沒有給你裝,你只能在上面敲入字符。這種情況下,你就必須放棄圖形界面這個拐杖了,離開拐杖,你也要會走路啊。
但是,對于剛接觸DB2的新手來說,全部敲命令是不現實的,而且DB2的功能越來越多,在使用上只靠敲命令很難保證工作效率和項目進度的要求。所以,在為允許使用圖形化工具的客戶服務時,可以盡量使用工具以提高工作效率。
言歸正傳,那么從手工優化進入到自動優化時代,DBA真的要失業了嗎?我認為,在自動優化時代,DB2提供的自調整特性以及一些SQL自動優化工具仍然無法代替設計人員、開發人員和DBA更富有創造力的工作。DB2提供的自調整工具是需要人去運用的,SQL語句的優化和業務邏輯是強關聯的,是需要和設計開發人員認真溝通的,自動化工具不可能知道廣大設計開發人員如何考慮的。
筆者認為,在自動優化時代,DBA的作用將更加重要。這些自動化特性或者工具的目的只是幫助DBA從瑣碎的事務性工作中解脫出來,這樣DBA可以集中精力放在數據庫架構、數據模型設計、應用開發指導、運維規范、優化指南等更需要智慧的地方。
本書內容
本書內容嚴謹精細、生動活潑,從內容來看,共分為四大部分,11章。第一部分包括第1章和第2章,提出了兩種性能優化方法學,包括理想化的自上而下方法學和救急專用的自下而上方法學,隨后通過一個真實的實戰案例,闡述了如何靈活運用方法學。第二部分是設計部分,包括第3章~第5章,分別談到了物理設計、基礎邏輯設計和高級邏輯設計,這是設計一個高質量的數據庫系統所必須掌握的內容。第三部分是性能優化部分,包括第6章~第9章,講述了如何對DB2進行性能監控,如何調整參數和優化維護工具,如何調整鎖和日志來優化高并發系統,如何來優化最耗資源的SQL語句。第四部分是有關高級設計與優化內容,包括第10章和第11章,講述了如何設計和優化大容量數據倉庫,講述了如何設計和優化DB2 pureScale集群。
為了方便讀者,我們在書中加入了“注意”、“小技巧”和“比較”這樣的提示性文字。其中“注意”的內容是需要DBA在工作中重點留意的;“小技巧”的內容是我們重點向讀者分享的實戰技巧;“比較”的內容是一些容易混淆的概念,是向廣大DBA和開發人員解釋和澄清的。
最后,我們在文中的一些腳本片段,采用灰底形式,這樣就非常明顯的和正文區別開了,同時加黑處理了腳本中的一些重點內容以示強調。
本書讀者
本書目標讀者群主要針對數據庫管理員和應用設計開發人員:
(1)數據庫管理員:中國的數據庫管理員非常勤奮,非常能吃苦,對AIX、Linux等操作系統掌握的很不錯,對DB2的安裝配置也都沒問題,這是他們的強項。但是到了運維階段遇到性能問題就只能苦苦摸索了,完全靠“野路子”打游擊戰:從網上搜點沒有經過驗證的性能優化秘籍,就敢在生產系統上直接實施,成功了是運氣好,失敗了算自己倒霉。另外,我也見過很多數據庫管理員,不了解應用的設計和開發,絲毫不關注SQL語句背后的業務邏輯,這說明還缺乏自上而下方法學的熏陶。因此,這本IBM原廠的性能優化專著將會幫助您們掌握原廠“正規軍”的戰略戰術。
(2)設計開發人員:目前設計開發人員的主力都是80后和90后了,盡管非常年輕,他們中的很多人已經開始承擔核心應用的開發了,我非常理解由于用戶需求的頻繁變更,讓開發人員苦不堪言,所以沒有時間或者不屑去關注SQL語句的數據庫運行環境,可能認為只要掌握好Select、Insert、Update和Delete這4條SQL語句就可以打遍天下無敵手了,但是我想說的是,DB2是IBM公司數以千計的工程師歷經幾十年打造的關系數據庫精品,里面的技術含量很高,不是為了僅僅支持那4條SQL語句的!我建議設計開發人員在繁忙的設計開發工作之余,閱讀一下本書,這本書將會從應用的角度幫助您真正掌握DB2設計與性能優化技術,讀后一定會豁然開朗,收益頗豐。
致謝
感謝我在IBM公司的同事侯戰友,很多性能優化思路我都和他討論過,他的真知灼見讓我受益匪淺。本書側重于DB2設計和性能優化,但也參考過《運籌帷幄DB2》一書中的有關DB2運維內容,這里我想特別感謝我在IBM公司的同事孫岳,本書參考了他在備份恢復以及日志機制方面的一些技術寫作成果;感謝我在IBM公司的同事劉旭,本書參考了他在數據移動方面的一些技術寫作成果;感謝我在IBM公司的同事張廣舟,他在DB2性能監控和鎖并發機制方面具有非常深入的造詣,本書參考了他在這方面的一些技術寫作成果。我還要感謝我在IBM公司的同事楊小華、孔再華和毛青,他們是DB2 pureScale方面的專家,我向他們學習了很多DB2 pureScale方面的技術。另外,我還要感謝IBM公司的存儲專家張曉巍,他在存儲設計上給予了我們大力指導。最后,我還要感謝itpub、db2china、中國DB2技術交流群(QQ群,186465431)等社區上的朋友們,我從和他們的技術探討中獲得了很多寫作靈感。

王飛鵬2013年7月寫于北京
內容簡介:

本書內容嚴謹精細、生動活潑,從內容來看,共分為四大部分,共11章。第一部分包括第1章和第2章,提出了兩種性能優化方法學,包括理想化的自上而下方法學和救急專用的自下而上方法學,隨后通過一個真實的實戰案例,闡述了如何靈活運用方法學。第二部分是設計部分,包括第3章、第4章和第5章,分別談到了物理設計、基礎邏輯設計和高級邏輯設計,這是設計一個高質量的數據庫系統所必須掌握的內容。第三部分是性能優化部分,包括第6章、第7章、第8章和第9章,講述了如何對DB2進行性能監控,如何調整參數和優化維護工具,如何調整鎖和日志來優化高并發系統,如何來優化最耗資源的SQL語句。第四部分是有關高級設計與優化內容,包括第10章和第11章,講述了如何設計和優化大容量數據倉庫,講述了如何設計和優化DB2 pureScale集群。

目錄:

第1章 性能優化方法學
1.1 什么是性能問題 2
1.1.1 如何發現性能問題 2
1.1.2 衡量性能的關鍵指標 2
1.1.3 性能基準測試 3
1.1.4 制定優化目標 3
1.2 性能優化方法學 3
1.2.1 幾種常見誤區 4
1.2.2 自上而下(From Top To Down)方法學 4
1.2.3 自下而上(From Down To Top)方法學 5
1.2.4 自上而下和自下而上,如何選擇? 5
1.3 高質量數據庫設計 5
1.3.1 充分了解需求 6
1.3.2 設計概念模型 7
1.3.3 設計邏輯結構 8
1.3.4 設計物理結構 10
1.3.5 應用開發階段 10
1.3.6 運行維護階段 11
1.4 性能調整與優化 11
1.4.1 磁盤瓶頸 12
1.4.2 CPU瓶頸 14
1.4.3 內存瓶頸 16
1.4.4 網絡瓶頸 17
1.4.5 懶惰系統 17
1.4.6 關鍵SQL語句優化 18
1.5 性能優化基本準則 18
1.6 小結 19
第2章 實戰案例研究與分享
2.1 性能問題的提出 21
2.1.1 系統現狀:從Oracle RAC談起 21
2.1.2 性能優化解決方案:“分庫”架構 22
2.1.3 高可用解決方案:DB2 HADR 24
2.2 實施:經營分析庫 26
2.2.1 DB2數據庫安裝 26
2.2.2 操作系統參數配置 27
2.2.3 實例創建與配置 29
2.2.4 存儲規劃與文件系統創建 30
2.2.5 數據庫創建 32
2.2.6 DB2參數配置 35
2.3 實施:DB2 HADR 38
2.3.1 準備工作 38
2.3.2 復制數據庫 38
2.3.3 配置HADR 43
2.3.4 啟動主從數據庫 44
2.3.5 HADR切換演練 45
2.3.6 為JAVA應用配置ACR 47
2.4 性能分析 48
2.4.1 業務分析 49
2.4.2 系統分析 49
2.4.3 優化方法學與計劃 50
2.5 性能優化 51
2.5.1 全局調整和優化 51
2.5.2 人力資源模塊優化 64
2.5.3 查詢分析模塊優化 69
2.5.4 報表應用優化 72
2.5.5 性能優化總結 74
2.6 小結 75
第3章 高質量物理設計
3.1 從數據庫硬件選型談起 77
3.1.1 對主機的考慮 77
3.1.2 對存儲的考慮 77
3.1.3 對網絡環境的考慮 78
3.1.4 電信公司選型結果 78
3.2 存儲設計 79
3.2.1 磁盤與磁盤陣列技術 80
3.2.2 條帶化 83
3.2.3 存儲設計 84
3.2.4 為電信公司規劃存儲 87
3.2.5 為電信公司創建數據庫 87
3.3 表空間設計 88
3.3.1 表空間管理方式 88
3.3.2 表空間類型 91
3.3.3 表空間參數設置 92
3.3.4 為電信公司設計表空間 93
3.4 內存的設置管理 94
3.4.1 解密DB2內存 95
3.4.2 緩沖池設計 99
3.4.3 緩沖池命中率 101
3.4.4 STMM自動管理內存 102
3.4.5 為電信公司設計緩沖池 102
3.5 高質量物理設計最佳實踐 103
3.5.1 硬件配置 103
3.5.2 存儲的設計配置 103
3.5.3 數據庫參數初始化選擇 104
3.5.4 內存設置管理 104
3.5.5 表空間設計管理 104
3.6 小結 105
第4章 經典邏輯設計
4.1 數據庫設計不僅是一種藝術 107
4.1.1 業務需求 107
4.1.2 性能需求 107
4.2 常規表設計體現真功夫 108
4.2.1 規范化決定成敗 108
4.2.2 用戶與模式 109
4.2.3 字段與類型 111
4.2.4 建表的講究 114
4.2.5 鍵與約束 118
4.2.6 序列、標識列和生成列 120
4.2.7 處理大對象的智慧 122
4.3 撲朔迷離的臨時表 125
4.3.1 聲明全局臨時表(DGTT) 125
4.3.2 創建全局臨時表(CGTT) 127
4.3.3 臨時表小結 128
4.4 無處不在的時態表 129
4.4.1 無處不在的時間 129
4.4.2 系統時態表 130
4.4.3 應用時態表 134
4.4.4 雙時態表 138
4.4.5 將普通表轉換為時態表 139
4.5 索引設計是一招鮮,吃遍天 140
4.5.1 DB2索引長什么樣 140
4.5.2 為了性能設計索引 142
4.5.3 吃透組合索引 148
4.5.4 創建索引 150
4.5.5 索引的常見誤區 150
4.6 觸發器設計一瞥 155
4.7 小結 156
第5章 高級邏輯設計
5.1 如何處理TB級的數據 158
5.1.1 方法學指導 158
5.1.2 合理運用高級設計技術 158
5.2 DB2 DPF設計 159
5.2.1 DB2 DPF技術內幕 160
5.2.2 DB2 DPF設計最佳實踐 161
5.3 表分區設計 162
5.3.1 表分區技術內幕 163
5.3.2 全局索引vs分區索引 166
5.3.3 轉入轉出 168
5.3.4 分區排除技術 169
5.3.5 分區維護 172
5.3.6 V10新特性:多溫度存儲 173
5.4 MDC表設計 175
5.4.1 MDC技術內幕 175
5.4.2 MDC表設計最佳實踐 177
5.4.3 案例:“吃磁盤”的MDC表 178
5.5 分區技術對比:DB2 vs Oracle 179
5.6 MQT設計 184
5.6.1 MQT的能力 184
5.6.2 創建MQT必須掌握的要點 187
5.6.3 深入討論MQT的刷新機制 188
5.6.4 MQT設計最佳實踐 190
5.7 強大的數據壓縮 192
5.7.1 行壓縮深度剖析 192
5.7.2 V10新特性:自適應壓縮 194
5.7.3 數據壓縮實踐與探索 195
5.8 小結 198
第6章 系統監控
6.1 由一則新聞想到的 200
6.2 操作系統監控 200
6.2.1 CPU監控 201
6.2.2 I/O監控 203
6.2.3 內存監控 204
6.2.4 網絡監控 206
6.3 數據庫監控 207
6.3.1 快照監視器 207
6.3.2 事件監視器 211
6.3.3 監視器表函數 214
6.3.4 管理視圖 218
6.3.5 db2pd 219
6.3.6 db2top 222
6.4 關鍵SQL語句監控 223
6.4.1 監控最耗費用戶CPU時間的動態SQL 223
6.4.2 監控訪問熱點對象執行次數最多的SQL 224
6.4.3 監控運行時間最長的SQL 224
6.4.4 監控執行次數最多的SQL 224
6.4.5 監控排序次數最多的SQL 225
6.5 關鍵性能指標(KPI) 225
6.5.1 緩沖區命中率 225
6.5.2 包緩沖區命中率 226
6.5.3 編目緩沖區命中率 226
6.5.4 緩沖區讀寫平均響應時間 226
6.5.5 日志寫入速度 227
6.5.6 鎖升級及死鎖 227
6.5.7 排序溢出率 227
6.5.8 數據、索引頁異步清除比例 228
6.5.9 臟頁偷取次數 228
6.6 融會貫通——監控的最佳實踐 229
6.6.1 CPU瓶頸問題的監控與診斷 229
6.6.2 I/O瓶頸的監控與診斷 231
6.6.3 內存瓶頸的監控與診斷 234
6.6.4 懶惰系統的監控與診斷 236
6.7 圖形化性能管理器 237
6.8 小結 238
第7章 配置參數與運維工具優化
7.1 配置參數優化 240
7.1.1 操作系統參數優化 240
7.1.2 DBM參數優化 242
7.1.3 DB參數優化 244
7.1.4 注冊變量優化 249
7.1.5 常見問題總結 250
7.2 日常運維工具的使用與優化 250
7.2.1 知已知彼——統計信息收集 250
7.2.2 集中兵力——碎片整理工具 251
7.2.3 隨機應變——重新綁定 253
7.3 數據移動工具 254
7.3.1 導出數據(EXPORT) 255
7.3.2 導入數據(IMPORT) 256
7.3.3 LOAD——導入大數據的核武器 259
7.3.4 LOAD FROM CURSOR輕松移動數據 269
7.3.5 INGEST——性能和可用性間平衡的使者 270
7.3.6 使用db2move在數據庫間移動數據 274
7.3.7 db2relocatedb——DB2移形換位 276
7.3.8 存儲過程——內部數據挪移的利器 278
7.3.9 特殊對象的移動方式 283
7.4 備份恢復工具優化 286
7.4.1 備份的基本原理與優化 286
7.4.2 DB2崩潰恢復、版本恢復和前滾恢復與優化 290
7.5 運維工具的調速策略 294
7.6 小結 296
第8章 鎖和日志優化
8.1 DB2鎖機制解析 299
8.1.1 沒有鎖會發生什么 299
8.1.2 鎖的類型和兼容性 301
8.2 DB2隔離級 305
8.2.1 DB2提供的四種隔離級 305
8.2.2 如何設定隔離級 307
8.3 實戰案例:鎖問題分析和解決 308
8.3.1 什么是鎖問題 308
8.3.2 從監控開始 309
8.3.3 鎖等待分析和解決 311
8.3.4 鎖超時分析和解決 314
8.3.5 鎖升級分析和解決 315
8.3.6 死鎖分析和解決 316
8.4 深入淺出——DB2日志的秘密 320
8.4.1 DB2日志的原理 320
8.4.2 DB2日志的模式 323
8.4.3 日志優化的最佳實踐 325
8.5 并發機制比較:DB2 vs Oracle 326
8.5.1 鎖與隔離級別:DB2 vs Oracle 326
8.5.2 日志:DB2 vs Oracle 327
8.6 并發性能優化 328
8.6.1 應用開發 328
8.6.2 數據庫調優 329
8.7 小結 330
第9章 SQL語句優化實戰
9.1 SQL優化基礎,理解DB2優化器 332
9.1.1 SQL語句的編譯過程 332
9.1.2 DB2優化器的核心作用 333
9.1.3 SQL語句優化過程 334
9.2 SQL優化關鍵:分析訪問計劃 334
9.2.1 解釋(Explain)工具 334
9.2.2 解讀訪問計劃 338
9.2.3 表掃描與索引掃描 345
9.2.4 嵌套循環連接、歸并連接和哈希連接 348
9.2.5 基數估計和統計信息 353
9.2.6 用優化概要定制訪問計劃 362
9.3 實戰案例集錦 366
9.3.1 案例1:不可思議的物理讀次數 367
9.3.2 案例2:理想的索引沒用上 370
9.3.3 案例3:標記位(Flag)數據上的runstats時機 374
9.3.4 案例4:NLJOIN vs HSJOIN大比拼 377
9.3.5 案例5:不是壓縮惹的禍 381
9.3.6 案例6:居高不下的CPU占用率 385
9.4 高級SQL語句應用 390
9.4.1 Merge語句 390
9.4.2 層次查詢和SQL遞歸 392
9.4.3 報表開發中的GROUP BY擴展 398
9.5 編寫高效SQL語句 401
9.5.1 不要檢索多余的數據 401
9.5.2 避免在連接謂詞中使用復雜表達式 402
9.5.3 將復雜表達式放在常量上 402
9.5.4 使用DB2提供的日期類型 403
9.5.5 謹慎對待隱式類型轉換 404
9.5.6 外連接的順序 404
9.5.7 IN和EXISTS子查詢 405
9.5.8 OFNR和FFNR子句 410
9.5.9 動態SQL vs靜態SQL 410
9.5.10 分組拼接字符串:LISTAGG 412
9.5.11 事務結束后及時COMMIT 412
9.6 小結 413
第10章 DB2數據倉庫設計與優化
10.1 數據倉庫是什么 415
10.1.1 數據倉庫的誤區 415
10.1.2 數據倉庫的體系結構 417
10.2 支撐數據倉庫的DB2特性 417
10.2.1 分區數據庫 417
10.2.2 靈活的數據分區 419
10.2.3 多分區環境下的連接(Join)策略 422
10.2.4 物化查詢表 424
10.3 DB2數據倉庫設計 424
10.3.1 BCU/BPU的設計原則 424
10.3.2 數據BPU上存儲劃分 427
10.3.3 數據庫的文件系統劃分 427
10.3.4 倉庫中誕生的數據庫 428
10.3.5 數據庫分區組的設計 428
10.3.6 緩沖池的設計 429
10.3.7 數據庫日志的設計 429
10.3.8 表空間的設計 430
10.3.9 表的存放技巧 430
10.3.10 數據壓縮 431
10.4 數據倉庫實戰 431
10.4.1 硬件環境 431
10.4.2 實例的規劃與實施 432
10.4.3 數據庫的規劃與實施 436
10.4.4 參數設置 439
10.4.5 其他操作 440
10.5 工作負載管理(WLM) 442
10.5.1 管理已知的工作負載 442
10.5.2 管理不可預見的工作負載 443
10.5.3 管理并行的LOAD工作負載 446
10.5.4 監控工作負載 446
10.6 數據倉庫優化總結 448
10.6.1 與OLTP系統的區別 448
10.6.2 設定優化目標 449
10.6.3 物理優化 449
10.6.4 邏輯優化 450
10.7 與Oracle數據倉庫比較 450
10.8 小結 451
第11章 DB2 pureScale集群數據庫
11.1 深入淺出DB2 pureScale架構 453
11.1.1 DB2 pureScale架構 453
11.1.2 DB2 pureScale的特點 454
11.1.3 DB2 pureScale與DB2 DPF的區別 455
11.2 從細節入手:與Oracle RAC對比 455
11.3 某銀行DB2 pureScale實戰案例 457
11.3.1 從硬件配置開始 457
11.3.2 突破難點:網絡規劃 458
11.3.3 抓住重點:存儲與文件系統 465
11.3.4 檢查與配置 467
11.3.5 正式安裝 471
11.3.6 數據庫部署 473
11.3.7 應用端配置 473
11.4 DBA必須掌握的: DB2 pureScale實用運維命令 476
11.4.1 日常管理命令 477
11.4.2 節點維護命令 479
11.4.3 GPFS文件系統管理命令 480
11.4.4 監控命令 481
11.5 DB2 pureScale規劃總結 484
11.6 小結 485
后記 信念的奇跡
縮略語
參考文獻

序: