《全程回放：100T核心數(shù)據(jù)庫(kù)升級(jí)歷險(xiǎn)記》要點(diǎn)：
本文介紹了全程回放：100T核心數(shù)據(jù)庫(kù)升級(jí)歷險(xiǎn)記，希望對(duì)您有用。如果有疑問(wèn)，可以聯(lián)系我們。

本文根據(jù)汪洋老師在〖2016 Gdevops全球敏捷運(yùn)維峰會(huì)廣州站〗現(xiàn)場(chǎng)演講內(nèi)容整理而成.

講師介紹

汪洋,從事Oracle相關(guān)開(kāi)發(fā)運(yùn)維工作20年.現(xiàn)任平安科技數(shù)據(jù)庫(kù)技術(shù)部總監(jiān),負(fù)責(zé)數(shù)據(jù)庫(kù)技術(shù)引入,數(shù)據(jù)庫(kù)產(chǎn)品選型、架構(gòu)設(shè)計(jì)、規(guī)范制定,開(kāi)發(fā)、測(cè)試、生產(chǎn)環(huán)境運(yùn)維等工作.近年,對(duì)開(kāi)源數(shù)據(jù)庫(kù)技術(shù)以及DBaaS產(chǎn)生濃厚興趣,一直致力于相關(guān)的研究和引入工作.

本次分享大綱：

• 我們的困境和挑戰(zhàn)
• 選擇比努力更重要
• 十月磨一劍
• 最終的決戰(zhàn)時(shí)刻今天給大家?guī)?lái)的分享為《平安產(chǎn)險(xiǎn)核心DB升級(jí)記》,為什么選擇“數(shù)據(jù)庫(kù)升級(jí)”這個(gè)主題來(lái)分享呢?首先,一方面我是做數(shù)據(jù)庫(kù)出身的,另一方面,我認(rèn)為數(shù)據(jù)庫(kù)的升級(jí)是一個(gè)相對(duì)復(fù)雜的系統(tǒng)化工程.在這中間,它幾乎要運(yùn)用到數(shù)據(jù)庫(kù)領(lǐng)域的所有知識(shí),包括管理、備份恢復(fù)、容災(zāi)、監(jiān)控等,而且這個(gè)過(guò)程中,該怎么做升級(jí)的準(zhǔn)備,如何保證真正的實(shí)施方案的順利進(jìn)行,實(shí)施之后如何對(duì)它進(jìn)行監(jiān)控,以及萬(wàn)一有預(yù)想不到的風(fēng)險(xiǎn),怎么去順利回退等等.不單單這樣,它還包括主機(jī)的一些存儲(chǔ)、配置,整個(gè)流程的東西都需要考慮.這是我選擇這個(gè)主題的第一個(gè)原因.第二個(gè)原因,為什么是“平安產(chǎn)險(xiǎn)”這個(gè)數(shù)據(jù)庫(kù)?因?yàn)檫@個(gè)9i版本的數(shù)據(jù)庫(kù)在當(dāng)時(shí)可以說(shuō)是全世界最大的,它有達(dá)100多TB的數(shù)據(jù)容量.它不光是產(chǎn)險(xiǎn)最核心的數(shù)據(jù)庫(kù),并且?guī)缀醍a(chǎn)險(xiǎn)之外的所有子系統(tǒng)也都在這個(gè)數(shù)據(jù)庫(kù)里面.綜合以上這些因素,構(gòu)成了這個(gè)系統(tǒng)的復(fù)雜性.第三個(gè)原因,就是五年前我們?cè)?jīng)失敗過(guò)一次,所以這個(gè)數(shù)據(jù)庫(kù)一直是我們心中的一根刺,心口上永遠(yuǎn)的痛,我們一直想把它拔掉.最后,它是從9i升級(jí)到11g,可能大家會(huì)覺(jué)得這是個(gè)老生常談的問(wèn)題,都談了很多年了,而且它也不是升級(jí)到最新的版本12c.但它是我從業(yè)以來(lái)最復(fù)雜的一次數(shù)據(jù)庫(kù)升級(jí),里面用到的一些思想和方法能夠提煉出來(lái),用到不光是Oracle數(shù)據(jù)庫(kù),也可以用到其他數(shù)據(jù)庫(kù),甚至不單是數(shù)據(jù)庫(kù)里面的,也可以運(yùn)用到其他領(lǐng)域.所以借此機(jī)會(huì)分享出來(lái),希望能夠給大家一些借鑒.

一、我們的困境和挑戰(zhàn)

1、業(yè)務(wù)系統(tǒng)特點(diǎn)介紹

 

正如前面提到的,它是全球最大的Oracle 9i OLTP數(shù)據(jù)庫(kù),甚至連原廠的工程師都不敢碰它,覺(jué)得這個(gè)任務(wù)似乎不可能完成.剛剛也說(shuō)了,五年前我們?cè)?jīng)失敗過(guò)一次,那時(shí)它才只有10個(gè)TB,五年之后,業(yè)務(wù)數(shù)據(jù)量變成了110個(gè)TB,現(xiàn)在每個(gè)月仍在以3TB的速度往上增長(zhǎng),而且是9i版本.眾所周知,9i是個(gè)非常老的產(chǎn)品,它可能在設(shè)計(jì)的時(shí)候就沒(méi)想過(guò)去運(yùn)行這么大的一個(gè)在線數(shù)據(jù)庫(kù).

我們看到,它的業(yè)務(wù)數(shù)據(jù)量有110TB+,每秒的事務(wù)量是2000+,大家可能覺(jué)得這事務(wù)量不是很高,因?yàn)楝F(xiàn)在都是一萬(wàn)或十幾萬(wàn)事務(wù)量,但我想告訴大家的是,保險(xiǎn)不同于其他行業(yè),它的每個(gè)事務(wù)都需要涉及到非常復(fù)雜的計(jì)算后才能提交,所以不同系統(tǒng)的TPS事務(wù)量代表的意義是不一樣的.對(duì)于產(chǎn)險(xiǎn)數(shù)據(jù)庫(kù)來(lái)說(shuō),它已有的數(shù)據(jù)量已經(jīng)是非常高的了,五年前只是現(xiàn)在的1/7,五年后翻了7倍.此外,它每天處理的SQL量有50多萬(wàn),基本上支撐著平安產(chǎn)險(xiǎn)95%以上的業(yè)務(wù).如果萬(wàn)一發(fā)生問(wèn)題,造成的影響與損失可想而知.

2、當(dāng)前面臨的問(wèn)題??

• 獲得Oracle產(chǎn)品的Premier Support支持

首先,Oracle 9i版本的延展服務(wù)在2011年的7月已經(jīng)到期了,所以出了問(wèn)題會(huì)怎樣?如果大家用Oracle的話,出了問(wèn)題,還是可以通過(guò)請(qǐng)求GCS (Oracle 全球技術(shù)支持)來(lái)幫你解決,但如果是新Bug的話,它是不會(huì)讓O染成了研發(fā)介入開(kāi)發(fā)新patch的,它只能有一些Workaround去幫你規(guī)避.如果連Workaround都沒(méi)有,那你就只能像踩著鋼絲一樣,天天擔(dān)心自己會(huì)不會(huì)遇到這些新的Bug.假如真的遇到了,也得自己想辦法如何去規(guī)避.其實(shí)運(yùn)行這么多年,我們也通過(guò)一些已知的辦法去規(guī)避,但這始終不是長(zhǎng)久之計(jì).基于這些原因,必須要去升級(jí).

• 解決硬件擴(kuò)展的瓶頸

第二個(gè)是硬件擴(kuò)展的瓶頸.它不光是數(shù)據(jù)庫(kù)本身廠商的不支持, 更是強(qiáng)調(diào)一個(gè)生產(chǎn)圈的不支持,包括它的主機(jī)、操作系統(tǒng)都不再服務(wù)支持.如現(xiàn)在我們這個(gè)新購(gòu)的主機(jī)上只能運(yùn)行Solaris 11,而Solaris 11 又只認(rèn)證Oralce 11g以后版本的數(shù)據(jù)庫(kù),所以不及時(shí)升級(jí)的話,新采購(gòu)回來(lái)的硬件只能認(rèn)證比它高的版本,你仍繼續(xù)用9i,發(fā)生問(wèn)題時(shí),廠商是沒(méi)有辦法解決的,甚至你要冒風(fēng)險(xiǎn)去運(yùn)行在一個(gè)不被認(rèn)證的操作系統(tǒng)上.還有就是剛才提到的硬件的存儲(chǔ),我們的數(shù)據(jù)庫(kù)有110TB,而數(shù)據(jù)量每個(gè)月仍在以3T的速度往上增長(zhǎng),而舊的整個(gè)存儲(chǔ)最大的容量也就130TB,很快就會(huì)達(dá)到它的瓶頸.

• 緩解DB性能不穩(wěn)定的風(fēng)險(xiǎn)

我們?cè)?013-2014年出現(xiàn)了三次UIOC(ugency incident office center),相當(dāng)于一個(gè)作戰(zhàn)史,一共發(fā)生了三次,而且每次都與latch: cache buffers chains等待事件相關(guān).其實(shí)在9i里面我們感覺(jué)已經(jīng)沒(méi)有一個(gè)很有效的辦法可以解決這個(gè)問(wèn)題了,而在更早之前,從2009-2014年間更出現(xiàn)了12次重大事件,其中5次與執(zhí)行計(jì)劃突變有關(guān),這些都是我們用9i時(shí)遇到過(guò)的問(wèn)題,急需把它升級(jí)為11g.

• 提升技術(shù)人力的價(jià)值投入

維護(hù)9i所投入的人力成本是非常大的.為什么這么說(shuō)呢?因?yàn)?i是一個(gè)比較舊的技術(shù),很多時(shí)候我們的解決手段都必須在更高的版本上去實(shí)現(xiàn),而在9i上做一個(gè)技術(shù)的變更非常復(fù)雜,你要考慮得非常細(xì)致,很多變更不能通過(guò)在線操作.如果升級(jí)到11g,不光可以釋放一部分的人力,還能把這部分的人力投入到更有價(jià)值的事情上去.

3、系統(tǒng)變更要求

我們平時(shí)數(shù)據(jù)庫(kù)升級(jí)一般遵循的都是一次只做一個(gè)變更,但這次情況不同,就像前面提到的受限于硬件、存儲(chǔ)等多個(gè)瓶頸,我們一次做了四個(gè)變動(dòng),這也是為什么這次升級(jí)如此復(fù)雜的原因之一.其中,操作系統(tǒng)是從Solaris 10升級(jí)到了Solaris 11,DB版本從9.2.0.5升級(jí)到了11.2.0.4,主機(jī)硬件從M9000升級(jí)到T5-4,存儲(chǔ)硬件是從高端SAN變更成了閃存.現(xiàn)在閃存是未來(lái)存儲(chǔ)的趨勢(shì).

以上這些都是我們?cè)谧龇桨笗r(shí)提出的挑戰(zhàn)和要求.

二、選擇比努力更重要

如果一開(kāi)始的選擇就是錯(cuò)的,即使后面你do things right,最后的結(jié)果也不一定是對(duì)的.因此在升級(jí)之前,我們要做出正確的選擇.

1、實(shí)施過(guò)程設(shè)計(jì)

這是方案大致的流程.首先要走基礎(chǔ)的硬件上架和基準(zhǔn)的測(cè)試,比如說(shuō),存儲(chǔ)的IO能力能不能達(dá)到我的要求,雖然理論上閃存是要比以前高端SAN要強(qiáng)很多,但沒(méi)有經(jīng)過(guò)實(shí)際測(cè)試過(guò),也是無(wú)法確定的,所以需要自己做一遍測(cè)試.主機(jī)呢,我們也是把真正的生產(chǎn)系統(tǒng)切換到新的主機(jī)上進(jìn)行試運(yùn)行一次,看T5-4到底是不是要比M9000要好,避免發(fā)生我們預(yù)期不到的事情.經(jīng)過(guò)這樣一輪測(cè)試,我們才有信心、鄭重地做硬件架構(gòu)升級(jí)后的生產(chǎn)運(yùn)行平臺(tái).接下來(lái),一方面是做性能測(cè)試,一方面是要做功能方面的回歸測(cè)試,最后還要聯(lián)調(diào)再做一次終極的性能驗(yàn)證.做完之后,用戶接受、開(kāi)發(fā)接受,然后再做系統(tǒng)真實(shí)的投產(chǎn)上線和運(yùn)行.

首先我們碰到的第一個(gè)難題就是DB Replay,用過(guò)Oracle的都知道,它是RAT (Oracle Real Application Testing)的一個(gè)組件,它可以把一個(gè)數(shù)據(jù)庫(kù)的負(fù)載在做一些變更之后,在另外一個(gè)的數(shù)據(jù)庫(kù)或平臺(tái)上去負(fù)載重演,看這負(fù)載在你升級(jí)前后或者硬件更換前后有什么差別.在這里,第一個(gè)難題就是DB Replay是11g的一個(gè)新特性,而目前我們的庫(kù)版本為9i的,所以需要打上一個(gè)patch,因此我們要求Oracle全球研發(fā)幫我們出一個(gè)9i版本的patch,經(jīng)分析這個(gè)patch跟我們目前數(shù)據(jù)庫(kù)補(bǔ)丁有沖突,所以我們花了很長(zhǎng)時(shí)間去做這種補(bǔ)丁沖突的分析,一層層的抽絲剝繭,最終找到那些產(chǎn)生沖突的patch,把這些不重要的沖突patch拿走.

2、軟件補(bǔ)丁方案設(shè)計(jì)

第二個(gè)難題就是我們要在新的11g版本上去安裝patch,這又是另一套原則.大家可以看到,我們先是做了一個(gè)補(bǔ)丁列表的篩選,是Oracle發(fā)布的Patch Set Update(PSU),還有一些Critical Patch Update(CPU),都作為我們的待選.待選patch的會(huì)和已有的、已打的patch做一些補(bǔ)丁沖突分析,如果有沖突的話,那就看它是否關(guān)鍵.兩個(gè)相比較,看到底哪一個(gè)更關(guān)鍵一些,我們會(huì)留下更為關(guān)鍵的一個(gè).如果沒(méi)有沖突,直接加入到我們的補(bǔ)丁列表,做成一整套補(bǔ)丁實(shí)施方案,這樣我們就能知道未來(lái)的系統(tǒng)是什么樣的數(shù)據(jù)庫(kù)版本以及需要打上什么樣的補(bǔ)丁集信息.

3、功能測(cè)試方案設(shè)計(jì)

第二個(gè)選擇比努力更重要的是功能測(cè)試.系統(tǒng)每一次的功能版本變更都有一個(gè)定型期,因?yàn)槲覀冞@個(gè)事情差不多進(jìn)行了半年,定型期里面,每發(fā)一次版本變更都要同時(shí)在9i和11g的平臺(tái)上功能驗(yàn)證通過(guò),我們才能去發(fā)布,這是為了保證整個(gè)升級(jí)運(yùn)行期軟件版本的一致性,也是為了讓它升級(jí)以后不會(huì)出問(wèn)題.

4、性能測(cè)試方案設(shè)計(jì)

第三個(gè)就是性能測(cè)試,這是最復(fù)雜的地方.我們利用DB Replay抓取9i的負(fù)載在11g的環(huán)境去重現(xiàn),那性能的好壞怎么判斷呢?我們先在11g的環(huán)境里面去回放這個(gè)負(fù)載,看它的性能是否下降,如果沒(méi)有下降,我們就會(huì)把這些Top SQL抓起來(lái),用11g的另外一個(gè)新特性,叫SQL plan management(簡(jiǎn)稱SPM),去把它的執(zhí)行計(jì)劃固化下來(lái).

固化之后,我們會(huì)將這些SQL的執(zhí)行計(jì)劃導(dǎo)入到11g的生產(chǎn)環(huán)境中,保證在系統(tǒng)升級(jí)前后生產(chǎn)計(jì)劃是沒(méi)有改變的.如果是性能下降,假如不需要通過(guò)代碼改變就可以進(jìn)行優(yōu)化的,我們會(huì)通過(guò)DBA、開(kāi)發(fā)人員等人工優(yōu)化,把它也用SPM固化下來(lái),同樣導(dǎo)入到生產(chǎn)環(huán)境.對(duì)于那些沒(méi)有辦法簡(jiǎn)單地加Hint或通過(guò)改變關(guān)鍵字次序等進(jìn)行調(diào)優(yōu)的代碼,就需要開(kāi)發(fā)參與進(jìn)行代碼的改造.當(dāng)開(kāi)發(fā)修改代碼時(shí),也是要兩邊調(diào)度,同時(shí)在9i和11g的版本上進(jìn)行性能驗(yàn)證,兩邊都驗(yàn)證通過(guò)之后才能導(dǎo)入生產(chǎn).

5、投產(chǎn)上線架構(gòu)設(shè)計(jì)

這是整個(gè)投產(chǎn)方案的架構(gòu)設(shè)計(jì),看起來(lái)比較復(fù)雜.我們提用了兩套完全一樣的架構(gòu),9i里面有同城的DG,也有遠(yuǎn)程的DG,因?yàn)檫@個(gè)數(shù)據(jù)庫(kù)太核心,太重要了.同樣的,在升級(jí)過(guò)程中,我們不允許出一點(diǎn)差錯(cuò),所以在11g的投產(chǎn)環(huán)境中也有完整的一套11g的預(yù)投產(chǎn)、預(yù)生產(chǎn)環(huán)境,它的同城DG、遠(yuǎn)程DG是完全一樣的.

這里面用了三種不同的存儲(chǔ)技術(shù).第一種存儲(chǔ)技術(shù)就是11g新生產(chǎn)環(huán)境是和原來(lái)9i的同城容災(zāi)是做存儲(chǔ)層面的同步,即存儲(chǔ)LUN級(jí)別的同步；第二種存儲(chǔ)技術(shù)是利用HDS的一種GAD存儲(chǔ)同步技術(shù),使11g新生產(chǎn)和11g新同城容災(zāi)不斷地在做數(shù)據(jù)同步,第三種存儲(chǔ)技術(shù)是9i遠(yuǎn)程容災(zāi)與11g新同城容災(zāi)之間通過(guò)SVC實(shí)現(xiàn)存儲(chǔ)同步,而這11g新同城容災(zāi)也就是用于將來(lái)的11g的遠(yuǎn)程容災(zāi)環(huán)境.

我們還有MIS COW以及DEP COW的補(bǔ)充,用于獲取一些數(shù)據(jù)采集產(chǎn)生一些報(bào)表,所以這里面用了很多種技術(shù),目的就是不去在一個(gè)完整的環(huán)境中去做升級(jí),也就是說(shuō)我們不會(huì)先去升生產(chǎn)再去搭建一套同城容災(zāi)、遠(yuǎn)程容災(zāi),因?yàn)檫@樣的過(guò)程中產(chǎn)生的一些RPO、RTO和風(fēng)險(xiǎn)是無(wú)法規(guī)避的.

6、投產(chǎn)實(shí)現(xiàn)方案設(shè)計(jì)

我們剛開(kāi)始就已經(jīng)在做存儲(chǔ)全量同步,然后也用了HDS GAD在做存儲(chǔ)同步,遠(yuǎn)程容災(zāi)用了SVC存儲(chǔ)同步,升級(jí)中我們會(huì)把它進(jìn)行一個(gè)存儲(chǔ)的分離,然后本地升級(jí),把剛才提到的一些SPM去導(dǎo)入,然后遠(yuǎn)程容災(zāi)是通過(guò)級(jí)聯(lián)升級(jí),這樣我就會(huì)在升級(jí)以后出來(lái)兩套,一套是9i的環(huán)境,一套是11g的環(huán)境.升級(jí)后我們會(huì)把11g產(chǎn)生的數(shù)據(jù)改變通過(guò)OGG同步到9i,所以在任何情況下都可以去回退,而且是完整環(huán)境的回退.

三、十月磨一劍

1、性能分析迭代

這個(gè)過(guò)程中,我們用了半年,在這半年的時(shí)間里,我們首先要構(gòu)造分析基線,也就是剛才提到的——用DB Replay去回放生產(chǎn)壓力.第一步,我們是在11g的環(huán)境里把它的優(yōu)化器參數(shù)和統(tǒng)計(jì)信息仍然保留9i的,那么SQL相當(dāng)于在運(yùn)行在9i的環(huán)境中產(chǎn)生執(zhí)行計(jì)劃及執(zhí)行情況(因?yàn)檫@是跟當(dāng)前運(yùn)行9i的生產(chǎn)環(huán)境最接近的),我們會(huì)抓取一個(gè)基線,并會(huì)把它的Top SQL拿下來(lái).

接下來(lái),我們會(huì)把11g環(huán)境里面的優(yōu)化器參數(shù)和統(tǒng)計(jì)信息修改成11g的,再去回放一次負(fù)載,比較兩方面的差異,也把它的Top SQL抓取下來(lái),我們這時(shí)候也用到SPA,即Oracle RAT中的一個(gè)組件SPA(sql performance analyze),DB Replay在整個(gè)過(guò)程中的作用是回放整個(gè)負(fù)載,可以觀察數(shù)據(jù)庫(kù)有沒(méi)有異常的等待事件,有沒(méi)異常消耗高的SQL等,讓你從整體上去判斷.而SPA,是幫你逐條分析SQL,執(zhí)行計(jì)劃有沒(méi)有改變,如果有改變,它的buffer gets是升高還是降低,CPU TIMES是升高還是降低等.如果它的性能下降了,是由于什么原因,這些就需要你做進(jìn)一步深入分析,也就是說(shuō)Oracle RAT的兩個(gè)組件SPA和DB Replay在這期間發(fā)揮著不一樣的功能.

在抓取了這些SQL之后,我們就要逐條、逐條地去看,包括一些去重,因?yàn)閿?shù)據(jù)量太大了,最初抓取過(guò)來(lái)的有50多萬(wàn)條SQL,去重后還有14萬(wàn)條,后面我們把這14萬(wàn)條再去分類,該給開(kāi)發(fā)的就給開(kāi)發(fā),該給DBA的就給DBA去優(yōu)化,一層一層的優(yōu)化,才能保證最后上線投產(chǎn)的順利進(jìn)行.當(dāng)我們非常有把握或者性能非常穩(wěn)定的時(shí)候,才會(huì)去投產(chǎn).也就是說(shuō),我們總共分析了14萬(wàn)條.

2、綁定變量改造

關(guān)于SQL語(yǔ)句呢,我不細(xì)講,這里提幾個(gè)點(diǎn)和例子.首先是綁定變量,就像剛剛提到的固化執(zhí)行計(jì)劃是需要已使用綁定變量的,否則它每條SQL語(yǔ)句都不一樣,這些SQL也就無(wú)法共用固化過(guò)執(zhí)行計(jì)劃,在這過(guò)程中我們發(fā)現(xiàn)很多這類的SQL語(yǔ)句.尤其在in里面非常多,要么就是跟個(gè)數(shù)不一樣,要么就是值輸入不一樣,兩種情況都可能導(dǎo)致固化過(guò)的執(zhí)行計(jì)劃發(fā)揮不了作用,而這類SQL無(wú)法簡(jiǎn)單地改造成綁定變量,所以我們進(jìn)行了改寫(xiě),以保證我們通過(guò)SPM固化執(zhí)行計(jì)劃達(dá)到固化的效果,第一是改寫(xiě)成綁定變量,第二是將IN寫(xiě)法改寫(xiě)成union all這種寫(xiě)法.通過(guò)這兩種手段,去優(yōu)化它的SQL語(yǔ)句.

3、隱式轉(zhuǎn)換改造

第二個(gè)例子是隱式轉(zhuǎn)換.這是因?yàn)閕batis有個(gè)類型Timestamp與數(shù)據(jù)庫(kù)中的字段類型不一樣導(dǎo)致的,我們也是進(jìn)行了一些優(yōu)化.通過(guò)在應(yīng)用代碼中增加cast函數(shù)來(lái)降低數(shù)據(jù)精度,并在長(zhǎng)期方案中,針對(duì)date類型,應(yīng)用必須傳入string格式,并在XML中使用to_date()函數(shù)進(jìn)行轉(zhuǎn)換.

4、復(fù)雜視圖改造

第三個(gè)例子是復(fù)雜視圖.在9i的時(shí)候, filter條件可以先在VIEW上過(guò)濾再和其他表關(guān)聯(lián),但11g必須先實(shí)例化VIEW,再進(jìn)行filter條件過(guò)濾,對(duì)此,我們?cè)趘$sql中查詢VIEW相關(guān)的代碼,同時(shí)將VIEW拆開(kāi),分別和VIEW之外的表進(jìn)行關(guān)聯(lián)查詢,最后再合并結(jié)果集.

這是幾個(gè)比較典型的案例.

四、最終的決戰(zhàn)時(shí)刻

1、投產(chǎn)組織工作

做了這么多,耗時(shí)6個(gè)月,最終的決戰(zhàn)時(shí)刻終于到來(lái)!這中間涉及到很嚴(yán)密的組織架構(gòu).有總指揮,然后運(yùn)營(yíng)團(tuán)隊(duì)和業(yè)務(wù)團(tuán)隊(duì)怎么去配合,運(yùn)營(yíng)團(tuán)隊(duì)怎么做好深度監(jiān)控、怎么通知業(yè)務(wù)團(tuán)隊(duì)準(zhǔn)備好升級(jí)后的驗(yàn)證,如果發(fā)生問(wèn)題,應(yīng)該怎樣去做回退決策,都有哪些人員當(dāng)時(shí)投產(chǎn)、包括投產(chǎn)后要到場(chǎng)值守,這些都要做好.還有要事先做好升級(jí)的序列和決策點(diǎn),哪些點(diǎn)是必須要決策回退,以及性能監(jiān)控的指標(biāo)和頻率的提前制定.

2、投產(chǎn)人員架

本次升級(jí)變更的總指揮就是我,當(dāng)時(shí)從最早的解決問(wèn)題到最終的投產(chǎn)成功,我有60個(gè)小時(shí)沒(méi)有睡覺(jué).基礎(chǔ)架構(gòu)團(tuán)隊(duì),像剛才提到的,有主機(jī)和存儲(chǔ)的配合.還有DBA團(tuán)隊(duì)、開(kāi)發(fā)測(cè)試團(tuán)隊(duì)、運(yùn)營(yíng)團(tuán)隊(duì)、業(yè)務(wù)驗(yàn)證團(tuán)隊(duì),大家都是“擰住一股繩,心往一處使”,才能讓這個(gè)“只許成功,不許失敗”的項(xiàng)目務(wù)必成功.我們只能接受一次失敗,不能接受第二次失敗.

3、投產(chǎn)前小插曲

然而,即便我們考慮得非常周密,在投產(chǎn)前還是出了小小的插曲.在投產(chǎn)前的72小時(shí),本來(lái)我們是想跟生產(chǎn)環(huán)境做存儲(chǔ)同步的,即11g新環(huán)境是跟9i生產(chǎn)環(huán)境同步的,并且存儲(chǔ)技術(shù)已跟廠商確認(rèn)過(guò)沒(méi)有問(wèn)題,而且我們還怕影響白天的業(yè)務(wù),專門(mén)計(jì)劃存儲(chǔ)層數(shù)據(jù)同步在第一天先做一半,等到第二天過(guò)了白天業(yè)務(wù)的高峰后,晚上再拉起來(lái),用兩個(gè)晚上完成存儲(chǔ)同步,這也和廠商確認(rèn)過(guò),他們也覺(jué)得沒(méi)問(wèn)題,但還是發(fā)生了問(wèn)題.后來(lái)臨時(shí)改變方案,我覺(jué)得這也是敏捷運(yùn)維的一個(gè)思想,改為從同城容災(zāi)進(jìn)行存儲(chǔ)全量數(shù)據(jù)同步,這樣就對(duì)生產(chǎn)環(huán)境沒(méi)有影響,但我們的方案就變得更加復(fù)雜.這是第一個(gè)小插曲.

另外一個(gè)是在投產(chǎn)前的32小時(shí),發(fā)生了一個(gè)大的事務(wù)在運(yùn)行.沒(méi)有人能評(píng)估出這個(gè)事務(wù)還有多少時(shí)間可以結(jié)束,那怎么辦?只能當(dāng)機(jī)立斷去kill這個(gè)事務(wù).這個(gè)事務(wù)當(dāng)時(shí)產(chǎn)生了很多的回滾,回滾是需要時(shí)間的,根據(jù)當(dāng)時(shí)的速度需要98個(gè)小時(shí),但離升級(jí)還只有32小時(shí),根本來(lái)不及.我們整個(gè)準(zhǔn)備了半年的升級(jí)一年就只有這么一次,如果錯(cuò)過(guò)了,就相當(dāng)于今年的升級(jí)就要告吹了,而以后也仍按照3T的速度來(lái)增長(zhǎng),也不太可能再做這個(gè)升級(jí).這也是我為什么60個(gè)小時(shí)不睡覺(jué)的原因.升級(jí)部門(mén)到了總部,告訴我,必須等到事務(wù)回滾完才能升級(jí),因?yàn)椴捎玫氖潜镜厣?jí).他沒(méi)給出什么方法,我這邊無(wú)論是調(diào)回滾的定期發(fā)布,還是調(diào)一次回滾的安全數(shù),在別的數(shù)據(jù)庫(kù)里面都是有效的,但對(duì)這個(gè)數(shù)據(jù)庫(kù)完全沒(méi)效.

最后我發(fā)現(xiàn)它主要的問(wèn)題出在db file sequential read上,怎么辦?發(fā)現(xiàn)它在回滾的過(guò)程中有一個(gè)materialized view log,而這個(gè)materialized view log所有數(shù)據(jù)文件只在一個(gè)存儲(chǔ)卷里.在這一個(gè)卷上我想到用FLASH閃存去替換這一個(gè)存儲(chǔ)卷,但這需要冒很大風(fēng)險(xiǎn),和第一個(gè)我剛剛提到的存儲(chǔ)同步故障是有關(guān)聯(lián)的,第一個(gè)已引發(fā)了生產(chǎn)故障,然后這個(gè)又要在這個(gè)生產(chǎn)環(huán)境上去做存儲(chǔ)同步,這甚至是冒著被炒魷魚(yú)的風(fēng)險(xiǎn),我沒(méi)有告訴其他人,自己做的這個(gè)決策.我覺(jué)得做領(lǐng)導(dǎo)就該這樣,你只要勇敢做,并敢于承擔(dān).

所以,將物化視圖所在的文件卷替換成Flash閃存,加快db file sequential read的效率后,最終發(fā)現(xiàn)回滾速率提升了5倍.同時(shí)連夜把一些存儲(chǔ)的同事從凌晨三點(diǎn)鐘叫到公司,啟用存儲(chǔ)Cache預(yù)熱功能,將物化視圖和物化視圖log緩存到內(nèi)存中,發(fā)現(xiàn)回滾速率又提升了3倍.終于趕在升級(jí)前的6個(gè)小時(shí),回滾完畢,來(lái)得及去做升級(jí)這個(gè)動(dòng)作.

4、投產(chǎn)運(yùn)行分析

 

最終在投產(chǎn)后,所幸實(shí)施過(guò)程是非常順利的.在投產(chǎn)后,高峰期業(yè)務(wù)吞吐量整整提升了大概25%,批量作業(yè)效率提升了5-25倍不等,系統(tǒng)前端響應(yīng)時(shí)間平均提升30%以上,單個(gè)SQL效率提升5-9000倍不等.主機(jī)的CPU運(yùn)行從升級(jí)前的60%,有時(shí)業(yè)務(wù)高峰甚至達(dá)到70-80% ,現(xiàn)在升級(jí)后CPU運(yùn)行在20-30%左右.整個(gè)效果看起來(lái)還是非常好的.

小結(jié)

通過(guò)本次升級(jí)我想說(shuō)的是,這里面用到的一些思想和方法,其中包括一些敏捷運(yùn)維的思想,是可以借鑒到以后同類數(shù)據(jù)庫(kù)產(chǎn)品的升級(jí),也可以用到其他的如主機(jī)、存儲(chǔ)等領(lǐng)域的變更或更新?lián)Q代.這就是我全部的分享,希望能對(duì)大家有所啟發(fā).

文章來(lái)自微信公眾號(hào)：DBAplus社群

轉(zhuǎn)載請(qǐng)注明本頁(yè)網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4243.html