年底了很多客戶(hù)都在借著銀監(jiān)的窗口進(jìn)行容災(zāi)切換演練驳规。這兩年有一個(gè)明顯的趨勢(shì)，就是監(jiān)管對(duì)容災(zāi)的要求越來(lái)越高署海。早些年的容災(zāi)通常是擺設(shè)吗购，只需要解決有的問(wèn)題，至于能不能切過(guò)去砸狞，切過(guò)去能不能頂?shù)米∧砻悖瑳](méi)有考慮太多。如今不僅要確保能切過(guò)去刀森，并且還需要切過(guò)去運(yùn)行一天甚至是一周的時(shí)間踱启，對(duì)于切換時(shí)間同樣也有很高的要求。

雖然 DataGuard 是非常成熟的容災(zāi)技術(shù)，但是受各種運(yùn)行環(huán)境的影響埠偿，仍然可能在切換過(guò)程中出現(xiàn)各種意外透罢，導(dǎo)致切換時(shí)間超時(shí)。今天我們就來(lái)梳理一下切換過(guò)程中的各種坑胚想，幫你理清楚整個(gè)的切換流程琐凭。

切換過(guò)程梳理

首先我們簡(jiǎn)單列舉出常規(guī)的災(zāi)備切換流程芽隆，便于更好的理解整個(gè)過(guò)程浊服。

1.停止業(yè)務(wù)系統(tǒng)的運(yùn)行

2.完成數(shù)據(jù)庫(kù)主備切換

3.修改數(shù)據(jù)庫(kù)DNS解析 (或者應(yīng)用修改連接串)

4.啟動(dòng)業(yè)務(wù)系統(tǒng)，確認(rèn)連接到新主庫(kù)

上述的步驟中胚吁，1/3/4主要是網(wǎng)絡(luò)和業(yè)務(wù)系統(tǒng)的調(diào)整牙躺，不在這次討論的范圍。今天我們重點(diǎn)要討論的是第二步腕扶。

接著孽拷，我們從數(shù)據(jù)庫(kù)內(nèi)部對(duì)主備切換過(guò)程進(jìn)行一個(gè)細(xì)粒度的分解。

12c之前的切換過(guò)程是這樣的半抱，

a. 主庫(kù)發(fā)出切換備庫(kù)的命令后脓恕，發(fā)起一次日志切換(，這個(gè)日志中會(huì)包含日志結(jié)束的標(biāo)記)窿侈，如果命令中帶有with session shutdown炼幔，還會(huì)殺掉數(shù)據(jù)庫(kù)中的活動(dòng)會(huì)話

b. 備庫(kù)接收到歸檔日志后進(jìn)行Media Recovery，應(yīng)用到日志結(jié)束標(biāo)記后史简，完成日志同步

c. 主庫(kù)接收到備庫(kù)完成日志應(yīng)用后乃秀，將控制文件中的角色修改為Standby Database，然后以abort的方式關(guān)閉主庫(kù)

d. 備庫(kù)上發(fā)起切換主庫(kù)的命令圆兵，關(guān)閉MRP進(jìn)程跺讯，清理在線日志文件，將控制文件中的角色修改為Primary Database

e. 新的主庫(kù)上執(zhí)行open命令殉农，打開(kāi)數(shù)據(jù)庫(kù)對(duì)外提供服務(wù)

f. 后續(xù)再啟動(dòng)新的備庫(kù)刀脏，開(kāi)啟MRP日志應(yīng)用 (這個(gè)時(shí)候已經(jīng)不影響業(yè)務(wù)系統(tǒng)的使用)

在這個(gè)過(guò)程中，容易出意外的 a 和 e 兩步超凳，一個(gè)是原主庫(kù)的關(guān)閉愈污，一個(gè)是新主庫(kù)的啟動(dòng)。

影響原主庫(kù)關(guān)閉速度的原因

影響原主庫(kù)關(guān)閉速度主要有兩個(gè)原因聪建，

1.帶業(yè)務(wù)切換的場(chǎng)景中钙畔，數(shù)據(jù)庫(kù)中有大量的會(huì)話， 關(guān)閉數(shù)據(jù)庫(kù)時(shí)需要?dú)⒌暨@些會(huì)話金麸，這個(gè)過(guò)程消耗了很多的時(shí)間擎析。

? 為了規(guī)避這個(gè)問(wèn)題，我們可以先關(guān)閉或者部分關(guān)閉應(yīng)用；

2.關(guān)閉過(guò)程中遇到Bug

? 在12c的環(huán)境下進(jìn)行 DG 切換時(shí)揍魂，可能會(huì)遇到 SCM0 進(jìn)程長(zhǎng)時(shí)間無(wú)法關(guān)閉的問(wèn)題桨醋，解決方法是禁用 DLM 統(tǒng)計(jì)信息收集。

Active process 8968 user 'oracle' program 'oracle@db24pr02 (SCM0)', not in a wait

Active process 8968 user 'oracle' program 'oracle@db24pr02 (SCM0)', not in a wait

alter system set "_dlm_stats_collect" = 0 scope = spfile sid = '*’;

SCM0 (Slave DLM(Distributed Lock Management) Statistics Collection and Management)后臺(tái)進(jìn)程負(fù)責(zé)收集和管理全局入隊(duì)服務(wù)（GES）和全局緩存服務(wù)（GCS）的統(tǒng)計(jì)信息现斋；只有在數(shù)據(jù)庫(kù)中啟用了DLM統(tǒng)計(jì)信息收集 SCM0 才會(huì)存在喜最， 根據(jù)官方文檔描述，在12.2版本中即使收集了 DLM 統(tǒng)計(jì)信息庄蹋，use these stats service based affinity and cache warmup功能也是禁用的瞬内，只是為了后續(xù)版本準(zhǔn)備，所以在禁用該進(jìn)程不會(huì)對(duì)12CR2版本產(chǎn)生負(fù)面影響限书。

影響新主庫(kù)open速度的原因

不論備庫(kù)是 mount 狀態(tài)還是 open read only 狀態(tài)虫蝶，切換成主庫(kù)角色后，都會(huì)變成 mount 狀態(tài)倦西，需要執(zhí)行 open 命令打開(kāi)能真。

在 12C 的環(huán)境下打開(kāi)主庫(kù)時(shí)，可能會(huì)遇到長(zhǎng)時(shí)間等待 "clear SRLs" 的問(wèn)題扰柠，導(dǎo)致主庫(kù)遲遲不能正常對(duì)外提供服務(wù)粉铐。

Sleep 80 seconds and then try to clear SRLs in 17 time(s)

......

Successfully onlined Undo Tablespace 2.

Undo initialization finished serial:0 start:363400623 end:363952914 diff:552291 ms (552.3 seconds)

這個(gè)問(wèn)題是因?yàn)橛|發(fā)Bug 23263748，因此建議在 12C 的環(huán)境中打上這個(gè)補(bǔ)丁卤档。

關(guān)于切換流程的優(yōu)化

12C 之前的切換步驟是這樣的蝙泼，

## 主庫(kù)切換成備庫(kù)

alter database commit to switchover to physical standby with session shutdown;

## 備庫(kù)切換成主庫(kù)

alter database commit to switchover to primary;

alter database open;

核心的步驟其實(shí)就兩條，但這里存在幾個(gè)問(wèn)題：

1.對(duì)于能夠正常切換成功裆装，沒(méi)有明確的判斷條件踱承。官方提供了 v$database.switchover_status字段，分別用Allow哨免、NotAllow和SessionActive來(lái)表示允許或者不允許切換茎活，以及是否還有活動(dòng)會(huì)話存在。但即使是Allow狀態(tài)琢唾，也仍然存在很多切換失敗的案例载荔；

2.切換命令需要分別連接到主備庫(kù)執(zhí)行，這也造成了一些不便采桃，尤其是現(xiàn)在很多客戶(hù)都用自動(dòng)化切換懒熙，會(huì)多出一次主機(jī)登錄的動(dòng)作；

3.主庫(kù)執(zhí)行切備庫(kù)的命令后普办，什么時(shí)候執(zhí)行備切主的命令工扎，需要自行判斷。尤其是自動(dòng)化場(chǎng)景中衔蹲，也會(huì)造成一定的麻煩肢娘。

所以12c之后對(duì)DG切換進(jìn)行了增強(qiáng)，增加一個(gè)verify命令，驗(yàn)證成功則說(shuō)明具備主備切換條件橱健，驗(yàn)證失敗則需要進(jìn)一步分析失敗的原因而钞。正式切換的命令也只有一條，在主庫(kù)上執(zhí)行這條命令后拘荡，會(huì)自動(dòng)完成一系列的切換動(dòng)作臼节，不需要過(guò)多的干預(yù)。

## 校驗(yàn)ADG切換

alter database switchover to coredg verify;

## 正式切換

alter database switchover to coredg;

關(guān)于異常切換

以上我們所討論的都是正常的例行切換珊皿，災(zāi)備庫(kù)還有一個(gè)更重要的功能就是為了應(yīng)對(duì)異常情況或者極端場(chǎng)景网缝，比如主庫(kù)數(shù)據(jù)庫(kù)損壞或者主生產(chǎn)中心地震、火災(zāi)等亮隙，這時(shí)候需要在沒(méi)有主庫(kù)的情況下拉起備庫(kù)途凫，繼續(xù)對(duì)外提供服務(wù)垢夹。在這些場(chǎng)景下會(huì)面臨數(shù)據(jù)丟失的風(fēng)險(xiǎn)溢吻。

為了說(shuō)清楚這個(gè)問(wèn)題，我們簡(jiǎn)單介紹一下 DG 支持的三種保護(hù)模式果元。

雖然提供了3種保護(hù)模式促王，但絕大多數(shù)環(huán)境中為了不影響主庫(kù)的可用性和性能，DG 庫(kù)均配置為最大性能模式而晒，存在著理論上丟失數(shù)據(jù)的可能蝇狼。因此一旦涉及到有損切換，就不得不掂量下到底會(huì)丟多少數(shù)據(jù)倡怎。尤其是像金融行業(yè)迅耘，對(duì)于 RTO 和 RPO 都有著嚴(yán)格的要求，核心系統(tǒng)的 RPO 要求甚至是 0 监署。

為了滿(mǎn)足業(yè)務(wù)系統(tǒng) RPO 的要求颤专，同時(shí)又盡量減少對(duì)性能的影響，12C 引入了一個(gè)新的組件 Far Sync钠乏。相比于普通的 DG 庫(kù)栖秕，F(xiàn)ar Sync 實(shí)例有兩個(gè)特點(diǎn)：

1.只有實(shí)例和控制文件，沒(méi)有數(shù)據(jù)文件晓避，節(jié)省了保存數(shù)據(jù)文件所需要的存儲(chǔ)開(kāi)銷(xiāo)簇捍；

2.輕量級(jí)的架構(gòu)，可以將 Far Sync 實(shí)例部署在生產(chǎn)本地機(jī)房俏拱，配置為實(shí)時(shí)同步模式接收主庫(kù)的歸檔日志文件暑塑，異步分發(fā)到遠(yuǎn)程災(zāi)備節(jié)點(diǎn)。

部署了 Far Sync 的災(zāi)備環(huán)境中锅必，最大的好處是可以進(jìn)行無(wú)損的 Failover 切換事格。因?yàn)橹鲙?kù)的日志是實(shí)時(shí)同步到 Far Sync 實(shí)例的，所以在做 Failover 的時(shí)候并沒(méi)有數(shù)據(jù)損失，只是 RTO 的時(shí)間會(huì)增加一些分蓖。在一個(gè)正常傳輸?shù)木W(wǎng)絡(luò)環(huán)境中尔艇，這點(diǎn)時(shí)間幾乎可以忽略不計(jì)。

總結(jié)

這篇文檔中主要介紹了 DG 切換過(guò)程中可能遭遇的問(wèn)題么鹤，影響 DG 切換時(shí)效终娃；也對(duì)比了 12C 版本前后切換過(guò)程的差異，總體的趨勢(shì)是切換過(guò)程更加簡(jiǎn)便和智能蒸甜，不少的客戶(hù)已經(jīng)能夠在1分鐘內(nèi)完成例行的主備切換棠耕，對(duì)于強(qiáng)一致性要求的 Oracle 數(shù)據(jù)庫(kù)盅藻，能做到這個(gè)水平粮呢，已經(jīng)是非常的難能可貴羽氮；對(duì)于災(zāi)難切換溅固，給大家介紹了新的 Far Sync 架構(gòu)阳惹，能夠在對(duì)數(shù)據(jù)庫(kù)性能影響最小的情況下撼港，做到數(shù)據(jù)零丟失茫蛹，對(duì)于 RPO 要求為零的業(yè)務(wù)猖吴，是一個(gè)不錯(cuò)選擇憔恳。

最后瓤荔，大家在容災(zāi)切換過(guò)程中遇到哪些坑，也歡迎留言一起討論钥组。