DBA日記第二部 前言部分-老白學(xué)RAC (1) 3
1.1. 單機升級到RAC 7
1.1.1. 4月14日 各懷心思的研討會 7
1.1.1. 5月19日 令人目瞪口呆的方案 10
1.1.1. 6月20日 令人沮喪的實驗 13
1.1.1. 6月21日 好事多磨 17
1.1.1. 7月1日 一身冷汗 20
1.1. 經(jīng)常宕機的RAC系統(tǒng) 26
1.1.1. 3月2日 上海的緊急故障 26
1.1.2. 3月3日 上海第一天 30
1.1.3. 3月4日 決定 39
1.1.4. 3月5日 平安無事了 44
1.1.5. 后記 47
1.1.6. 本章技術(shù)要點講解 48
1.1. EAI系統(tǒng)的性能問題 52
1.1.1. 3月6日 緊急求援 52
1.1.2. 3月7日 典型的RAC性能問題 55
1.1.3. 3月8日 繼續(xù)優(yōu)化 59
1.1.4. 后記 62
1.1. 奇怪的RAC性能問題 63
1.1.1. 8月4日 系統(tǒng)告急 63
1.1.1. 8月5日 分析的方法 68
1.1.1. 8月6日 extent pre-allocation 72
1.1. 好的方法是成功的一半 74
1.1.1. 8月8日 又宕機了 74
1.1.1. 8月9日 求人不如求自己 79
1.1.1. 8月9日夜 定位故障 86
1.1.1. 8月10日 及時雨 90
1.1.1. 后記 94
1.1. 愛刨根問底的客戶 97
1.1.1. 8月15日 奇怪的性能下降 97
1.1.1. 8月16日 系統(tǒng)級的調(diào)整 101
1.1.1. 8月17日 繼續(xù)優(yōu)化 111
1.1. 外來的和尚好念經(jīng) 120
1.1.1. 4月25日 一封郵件引發(fā)的事端 120
1.1.1. 4月27日 突生變故 123
1.1.1. 4月29日 Richard Warham 127
1.1.1. 5月1日 在家聊天 132
1.1.1. 5月8日 危機再現(xiàn) 135
1.1.1. 5月12日 Richard的180度大轉(zhuǎn)彎 139
1.1.1. 5月13日 系統(tǒng)擴容 141
1.1.1. 5月14日 Richard請客 144
1.1.1. 6月1日 新的起點 147
1.1.1. 6月7日 孤獨的唱反調(diào)的人 150
1.1.1. 6月8日 ITL等待引發(fā)的RAC性能問題 152
1.1.2. 6月9日 ORA-8104 154
1.1.1. 6月15日 又陷危機 156
1.1.1. 6月16日 IO負載均衡 158
1.1.1. 6月18日 按下葫蘆浮起了瓢 161
1.1.1. 6月19日 實施優(yōu)化 163
DBA日記第二部 前言部分-老白學(xué)RAC (1)
老白接觸RAC的時候RAC還叫OPS，OPS翻譯成中文就是ORACLE并行服務(wù)器，不過那個時侯DBA還是喜歡把OPS叫做ORACLE CLUSTER。老白對CLUSTER的認識來自于DEC公司���VAX CLUSTER，VAX CLUSTER是一種十分優(yōu)秀的集群系統(tǒng)，在集群里的任何一個資源（文件、磁盤、端口、設(shè)備，等等）只要被設(shè)置為CLUSTER資源，那么這個資源就可以在整個CLUSTER中共享。VAX CLUSTER這種古老但是十分優(yōu)秀的技術(shù)現(xiàn)在已經(jīng)基本上快消亡了，不過VAX CLUSTER技術(shù)給了老白很多誤導(dǎo)，認為CLUSTER就應(yīng)該是這樣的，不過隨著DEC的灰飛煙滅，我們看到20年后的今天，UNIX上的CLUSTER還只能做到VAX CLUSTER的一小部分功能。15年前，老白開始使用ORACLE數(shù)據(jù)庫的時候，絕大多數(shù)客戶對CLUSTER的認識還停留在HA層面上，當時最常用的詞匯是雙機熱備和雙機冷備這個概念，這兩種技術(shù)都被宣傳為CLUSTER技術(shù)，所不同的是雙機熱備就是我們現(xiàn)在所認知的RAC，而雙機冷備就是我們現(xiàn)在常說的HA系統(tǒng)。早期老白接觸CLUSTER系統(tǒng)的時候，實際上客戶對ORACLE CLUSTER���要求只是基于熱備和冷備的需求，而不是來自于性能和可擴展性方面的需求。那時候的數(shù)據(jù)庫往往較小，一般在幾百M到10多個G，而且應(yīng)用系統(tǒng)也比較簡單，因此系統(tǒng)在性能上的問題較少，DBA的主要工作就是幫助客戶安裝ORACLE系統(tǒng)，當然OPS的安裝是這中間技術(shù)含量最高的了。
早期的OPS系統(tǒng)安裝十分復(fù)雜，需要在操作系統(tǒng)上打打大量的補丁，進行復(fù)雜的配置，因此OPS系統(tǒng)的安裝一般會選擇購買原廠的服務(wù)，ORACLE的銷售一般會把OPS的安裝說成是一個和阿波羅登月一樣復(fù)雜的工作，因此敢于不購買原廠安裝服務(wù)的客戶少之又少。說實在的，不要說是OPS系統(tǒng)，早期的ORACLE系統(tǒng)安裝也十分復(fù)雜，老白曾經(jīng)幫客戶安裝過ORACLE 5.1 FOR OPENVMS，介質(zhì)存儲在266M���磁帶上，從磁帶上將安裝介質(zhì)導(dǎo)出來，到編譯鏈接，再到創(chuàng)建數(shù)據(jù)文件和表空間，整個過程確實和火箭發(fā)射沒多大區(qū)別了。不過從ORACLE 6開始，ORACLE的安裝變得簡單起來了，有一次老白給一個客戶安裝一套SCO UNIX 5.0上的ORACLE 7，當客戶看到老白拿出厚厚的兩盒子安裝盤的時候，不禁生出敬畏之心，于是他搬了張椅子坐在老白的身邊，想好好學(xué)習(xí)一下傳說中的復(fù)雜工藝，開始的一些眼花繚亂的字符界面和配置確實讓他感到有些神秘，他不停的問老白每個配置選項的含義，幾分鐘的配置很快就過去了，剩下的就是好像永無止盡的換盤。對于一個幾十M的“大型”軟件來說，1.44M的軟盤似乎容量太小了。等老白換到第十幾張盤的時候，那哥們終于打著哈欠離開了，臨走的時候還說了一句：“老白，原來你們DBA干的就是這種沒有什么技術(shù)含量的活��，下回有客戶安裝ORACLE我去幫你干吧�！�
雖然說ORACLE 的安裝變得簡單了，不過OPS的安裝還是一個在業(yè)界認為是技術(shù)含量最高的活，甚至有些ORACLE的工程師都十分懼怕安裝OPS，我就曾經(jīng)見過一個客戶到了客戶那里拼命的說OPS的壞話，并且建議客戶把系統(tǒng)做成HA模式。最后在客戶的一再堅持下，他硬著頭皮開始安裝OPS，在折騰了2天后，他不得不承認這是自己第一次安裝OPS，估計是搞不定了，等過兩天公司派個高手再過來安裝。
看到傳說中的OPS居然是如此的難纏，于是老白也在工作中盡可能的避開OPS，好在那時候的客戶對系統(tǒng)的高可用性和高可擴展性方面的需求并不明顯，因此在最初的幾年里，老白都能很輕松的說服客戶不要使用OPS。不過該來的事情總是要來的，98年經(jīng)歷了那次8.0.4 OPS大型故障后，雖然老白對OPS更加排斥，但是在一個項目中，老白終于無法躲開OPS了。當時我們承接一個比較大型的軟件項目，這個項目是從國家火炬計劃的經(jīng)費下?lián)艿闹攸c項目，因此該項目在前期方案認證的時候��了一大批清華大學(xué)的專家，于是高可用性、高可擴展性之類的需求就放在了十分重要的位置。再加上數(shù)據(jù)庫選擇了使用ORACLE，那么上OPS就是必然的事情了。更讓老白頭疼的是因為在經(jīng)費預(yù)算上的不足，最終這個項目確定的時候連集成費和購買ORACLE原廠安裝服務(wù)的錢都沒有了，這就意味著從小型機的安裝、村粗的安裝、數(shù)據(jù)庫的安裝到應(yīng)用軟件開發(fā)這一條龍的工作都必須由我們這家專門從事軟件開發(fā)的公司來承擔(dān)了。當甲方的科技處處長一臉壞笑的對老白說“要么你們?nèi)酉聛�，要么我們就另請高明”的時候，老白也只能苦笑著拍胸脯了，這百把萬的單子，夠老白全公司吃一年的了，就是砸鍋賣鐵也必須接下來。
胸脯好拍，事情難做，為了做好這個項目，合同還沒簽訂，老白就已經(jīng)開始了OPS技術(shù)的學(xué)習(xí)。從ORACLE.COM上老白下載了一套oracle 8.1.6的技術(shù)資料，其中一個《Oracle8i Parallel Server Documentation Online Roadmap》的文檔介紹了一個學(xué)習(xí)OPS的路線圖。首先需要學(xué)習(xí)第三方廠商的CLUSTERWARE的相關(guān)技術(shù)，這方面還算好，老白好歹還是在DEC混過段時間的，早就從原廠找了一個ALPHA產(chǎn)品���高手來��助安裝系統(tǒng)，這部分內(nèi)容就先省了吧。第二步就是學(xué)習(xí)《Oracle8i Parallel Server Concepts》，這是一本介紹OPS概念的書，從概念入門，循序漸進對的學(xué)習(xí)方法和老白一貫的學(xué)習(xí)方法是一致的，老白決定先用個把星期時間認真研讀一下這本書。第三步是閱讀《Oracle8i Parallel Server Setup and Configuration Guide》，這是一本介紹安裝配置的書，真正實戰(zhàn)安裝就要靠這本書來指導(dǎo)了，這本書不一定需要面面具到的閱讀，不過主要的脈絡(luò)是一定要認證看看的。第四步是閱讀《Oracle8i Parallel Server Administration, Deployment, and Performance》，這本書和我們今后的應(yīng)用開發(fā)、部署和性能優(yōu)化有關(guān)，是十分重要的，不過在目前階段我們還不會碰到這方面的問題，可以稍微往后放放，不過關(guān)于性能優(yōu)化的內(nèi)容還是要盡早閱讀，最好能在我們數(shù)據(jù)字典設(shè)計完成之前把OPS性能方面要考慮的問題搞清楚。
閱讀《Oracle 8i Parallel Server Concepts》這本書對老白的幫助十分大，在閱讀這本書之前，老白根本不知道OPS是怎么工作的，只是知道OPS可以支持多個實例同時訪問一個數(shù)據(jù)庫。而這本書開場的一段文字給了老白十分深刻的印象，就是這句話為老白認識OPS打開了一扇門：
You can also use Oracle Parallel Server to deliver high performance, throughput, and high availability. Whatever your goal, your challenge is to successfully deploy these technologies to take full advantage of their multiprocessing powers. To do this, you must understand how Oracle Parallel Server works, what resources it requires, and how to effectively use it.
在看到這段文字之前，老白認為OPS可以為開發(fā)人員解決一切問題，開發(fā)人員只需要將應(yīng)用部署在OPS上，就可以自然而然的獲得高可用性、高可擴展性，并且可以隨著OPS中實例的增加獲得更強的處理能力。而這段文字中明確指出了，無論你的目的是怎么樣的，你必須面臨如何成功的部署應(yīng)用的挑戰(zhàn)，要做到這一點，你必須了解OPS是如何工作的，OPS需要獲得什么樣的資源，并且如何有效的使用這些資源。看樣子我必須認真把這本近300頁的書看完，起碼要了解OPS的基本工作原理���并且在��統(tǒng)設(shè)計的時候充分利用OPS的優(yōu)勢，避開OPS的弱點，才能充分發(fā)揮OPS的優(yōu)勢。
|
|
資源大�。�285.07 KB 
