?
?
第二部分物理standby(3)角色轉(zhuǎn)換? 2007.12.11
?
??? 第1節(jié)的時(shí)候我們就提到了角色切換，我們也聽說了其操作簡單但用途廣泛，同時(shí)我們也猜測(cè)其屬于primary與standby 之間的互動(dòng)，那么在primary 和standby 數(shù)據(jù)庫(之一)上都需要有操作，并且切換又分了：switchover和failover，前者是無損切換，不會(huì)丟失數(shù)據(jù)，而后者則有可能會(huì)丟失數(shù)據(jù)，并且切換后原primary 數(shù)據(jù)庫也不再是該data guard 配置的一部分了.針對(duì)不同standby(邏輯或物理)的處理方式也不盡相同。en,內(nèi)容也挺多地。我們還是先大概了解下概念，然后再通過實(shí)戰(zhàn)去印證。
?
??? 角色轉(zhuǎn)換前的準(zhǔn)備工作：
??? ● 檢查各數(shù)據(jù)庫的初始化參數(shù)，主要確認(rèn)對(duì)不同角色相關(guān)的初始化參數(shù)都進(jìn)行了正確的配置。
? ● 確保可能成為primary 數(shù)據(jù)庫的standby 服務(wù)器已經(jīng)處于archivelog 模式。
? ● 確保standby 數(shù)據(jù)庫的臨時(shí)文件存在并匹配primary 數(shù)據(jù)庫的臨時(shí)文件
? ●確保standby 數(shù)據(jù)庫的RAC 實(shí)例只有一個(gè)處于open 狀態(tài)。（對(duì)于rac 結(jié)構(gòu)的standby 數(shù)據(jù)庫，在角色轉(zhuǎn)換時(shí)只能有一個(gè)實(shí)例startup。其它rac 實(shí)例必須統(tǒng)統(tǒng)shutdown，待角色轉(zhuǎn)換結(jié)束后再startup）
?
Switchover
：
??? 無損轉(zhuǎn)換，通常是用戶手動(dòng)觸發(fā)或者有計(jì)劃的讓其自動(dòng)觸發(fā)，比如硬件升級(jí)啦，軟件升級(jí)啦之類的。通常它給你帶來的工作量非常小并且都是可預(yù)計(jì)的。其執(zhí)行分兩個(gè)階段，第一步， primary 數(shù)據(jù)庫轉(zhuǎn)換為standby 角色，第二步，standby 數(shù)據(jù)庫(之一)轉(zhuǎn)換為primary 角色，primary 和standby 只是簡單的角色互換，這也印證了我們前面關(guān)于角色轉(zhuǎn)換是primary/standby 互動(dòng)的猜測(cè)。
?
Failover
：
??? 不可預(yù)知原因?qū)е聀rimary 數(shù)據(jù)庫故障并且短期內(nèi)不能恢復(fù)就需要failover。如果是這種切換那你就要小心點(diǎn)了，有可能只是虛驚一場(chǎng)，甚至連你可能損失的腦細(xì)胞的數(shù)量都能預(yù)估，但如果運(yùn)氣不好又沒有完備的備份恢復(fù)策略而且primary 數(shù)據(jù)并非處于最大數(shù)據(jù)保護(hù)或最高可用性模式地話，黑黑，哭是沒用地，表太傷心了，來，讓三思GG 安慰安慰你，這種情況下呢丟失數(shù)據(jù)有可能是難免的，并且如果其故障未能修復(fù)，那它甚至連快速修復(fù)成為standby 的機(jī)會(huì)也都失去了吶，咦，你腦門怎么好像在往外冒水，難道是強(qiáng)效凈膚液，你的臉也忽然好白皙喲~~~~
?
??? 在執(zhí)行failover 之前，盡可能將原primary 數(shù)據(jù)庫的可用redo 都復(fù)制到standby 數(shù)據(jù)庫。
?
??? 注意，如果要轉(zhuǎn)換角色的standby 處于maximum protection 模式，需要你首先將其切換為maximumperformance 模式（什么什么，你不知道怎么轉(zhuǎn)換模式？oooo,對(duì)對(duì)，我們還沒有操作過，這塊并不復(fù)雜，接下來會(huì)通過專門章節(jié)討論），這里先提供透露一下，轉(zhuǎn)換standby 數(shù)據(jù)庫到MAXIMIZE PERFORMANCE 執(zhí)行下列SQL 即可：
??? SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
??? 等standby 切換為新的primary 之后，你可以再隨意更改數(shù)據(jù)庫的保護(hù)模式。
?
??? 你是不是有疑問關(guān)于為什么待切換角色的standby 不能處于maximum protection 模式呢？這個(gè)其實(shí)很好理解，我們?cè)诘谝还?jié)學(xué)習(xí)三種保護(hù)模式的時(shí)候就介紹過其各自的特點(diǎn)，腦袋瓜好使的同學(xué)應(yīng)該還有印象，maximum protection 模式需要確保絕無數(shù)據(jù)丟失，因此其對(duì)于提交事務(wù)對(duì)應(yīng)的redo 數(shù)據(jù)一致性要求非常高，另外，如果處于maximum protection 模式的primary 數(shù)據(jù)庫仍然與standby 數(shù)據(jù)庫有數(shù)據(jù)傳輸，此時(shí)alterdatabase 語句更改standby 數(shù)據(jù)庫保護(hù)模式會(huì)失敗，這也是由maximum protection 模式特性決定的。
?
??? 下面分別演示switchover 和failover 的過程：
?
?
一、物理standbstandby的Switchover
?
??? 注意操作步驟的先后，很關(guān)鍵的喲。
?
1、檢查是否支持switchover 操作--primary 數(shù)據(jù)庫操作
?
??? 登陸primary 數(shù)據(jù)庫，查詢v$database 視圖的switchover_status 列。
??? E:\ora10g>set oracle_sid=jssweb
??? E:\ora10g>sqlplus "/ as sysdba"
??? SQL*Plus: Release 10.2.0.3.0 - Production on 星期四12 月13 09:41:29 2007
??? Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
???
已連接。
??? SQL> selectswitchover_statusfromv$database;
??? SWITCHOVER_STATUS
??? --------------------
??? TO STANDBY
??? 如果該列值為"TO STANDBY"則表示primary 數(shù)據(jù)庫支持轉(zhuǎn)換為standby 角色，否則的話你就需要重新檢查一下Data Guard 配置，比如看看LOG_ARCHIVE_DEST_n 之類參數(shù)值是否正確有效等等。
?
2、啟動(dòng)switchover --primary 數(shù)據(jù)庫操作
??? 首先將primary 轉(zhuǎn)換為standby 的角色，通過下列語句：
??? SQL> alterdatabasecommittoswitchovertophysicalstandby;
??? 數(shù)據(jù)庫已更改。
?
??? 語句執(zhí)行完畢后，primary 數(shù)據(jù)庫將會(huì)轉(zhuǎn)換為standby 數(shù)據(jù)庫，并自動(dòng)備份控制文件到trace。
?
3、重啟動(dòng)到mount --原primary 數(shù)據(jù)庫操作
?
??? SQL> shutdownimmediate
??? ORA-01507: 未裝載數(shù)據(jù)庫
??? ORACLE 例程已經(jīng)關(guān)閉。
??? SQL> startupmount
??? ORACLE 例程已經(jīng)啟動(dòng)。
??? Total System Global Area 167772160 bytes
??? Fixed Size 1289484 bytes
??? Variable Size 104858356 bytes
??? Database Buffers 54525952 bytes
??? Redo Buffers 7098368 bytes
??? 數(shù)據(jù)庫裝載完畢。
?
4、檢查是否支持switchover 操作--待轉(zhuǎn)換standby 數(shù)據(jù)庫操作
?
??? 待原primary 切換為standby 角色之后，檢查待轉(zhuǎn)換的standby 數(shù)據(jù)庫switchover_status 列，看看是否支持角色轉(zhuǎn)換。
??? E:\ora10g>set oracle_sid=jsspdg
??? E:\ora10g>sqlplus " / as sysdba"
??? SQL*Plus: Release 10.2.0.3.0 - Production on 星期四12 月13 10:08:15 2007
??? Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
??? 已連接。
??? SQL> select switchover_status from v$database;
??? SWITCHOVER_STATUS
??? --------------------
??? TO PRIMARY
??? 此時(shí)待轉(zhuǎn)換standby 數(shù)據(jù)庫switchover_status 列值應(yīng)該是"TO_PRIMARY"，如否則檢查其初始化參數(shù)文件中的設(shè)置，提示一下，比著原primary 數(shù)據(jù)庫的初始化參數(shù)改改。
?
5、轉(zhuǎn)換角色到primary --待轉(zhuǎn)換standby 數(shù)據(jù)庫操作
?
??? 通過下列語句轉(zhuǎn)換standby 到primary 角色：
??? SQL> alter database commit to switchover to primary;
??? 數(shù)據(jù)庫已更改。
?
??? 注意：待轉(zhuǎn)換的物理standby 可以處于mount 模式或open read only 模式，但不能處于open read write模式。
?
6、完成轉(zhuǎn)換，打開新的primary 數(shù)據(jù)庫
?
??? SQL> alter database open;
??? 數(shù)據(jù)庫已更改。
?
??? 注：如果數(shù)據(jù)庫處于open read-only 模式的話，需要先shutdown 然后直接startup 即可。
?
7、驗(yàn)證一下
?
??? 新的primary 數(shù)據(jù)庫
??? SQL> show parameter db_unique
??? NAME???????????????? TYPE??????? VALUE
??? -------------------- ----------- ------------------------------
??? db_unique_name?????? string????? jsspdg
??? SQL> select max(sequence#) from v$archived_log;
??? MAX(SEQUENCE#)
??? --------------
??? 67
??? SQL> altealter system switch logfile;
??? 系統(tǒng)已更改。
??? SQL> select max(sequence#) from v$archived_log;
??? MAX(SEQUENCE#)
??? --------------
??? 68
?
??? 新的standby 數(shù)據(jù)庫
??? SQL> show parameter db_unique
??? NAME???????????????? TYPE??????? VALUE
??? -------------------- ----------- ------------------------------
??? db_unique_name?????? string????? jssweb
??? SQL> select max(sequence#) from v$archived_log;
??? MAX(SEQUENCE#)
??? --------------
??? 68
?
??? 轉(zhuǎn)換成功。
?
二、物理standby的failover
?
??? 注意幾點(diǎn)：
??? ● failover 之后，原primary 數(shù)據(jù)庫默認(rèn)不再是data guard 配置的一部分。
??? ● 多數(shù)情況下，其它邏輯/物理standby 數(shù)據(jù)庫不直接參與failover 的過程，因此這些數(shù)據(jù)庫不需要做任何操作。
??? ● 某些情況下，新的primary 數(shù)據(jù)庫配置之后，需要重新創(chuàng)建其它所有的standby 數(shù)據(jù)庫。
?
??? 另外，如果待轉(zhuǎn)換角色的standby 處于maximum protection 或maximum availability 模式的話，歸檔日志應(yīng)該是連續(xù)存在的，這種情況下你可以直接從第3 步執(zhí)行，否則建議你按照操作步驟從第1 步開始執(zhí)行。
??? 一般情況下failover 都是表示primary 數(shù)據(jù)庫癱瘓，最起碼也是起不來了，因此這種類型的切換基本上不需要primary 數(shù)據(jù)庫做什么操作。所以下列步驟中如果有提到primary 和standby 執(zhí)行的，只是建議你如果primary還可以用，那就執(zhí)行一下，即使它能用你卻不執(zhí)行，也沒關(guān)系，不影響standby 數(shù)據(jù)庫的切換:)
1、檢查歸檔文件是否連續(xù)
??? 查詢待轉(zhuǎn)換standby 數(shù)據(jù)庫的V$ARCHIVE_GAP 視圖，確認(rèn)歸檔文件是否連接：
??? SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
??? 未選定行
?
??? 如果返回的有記錄，按照列出的記錄號(hào)復(fù)制對(duì)應(yīng)的歸檔文件到待轉(zhuǎn)換的standby 服務(wù)器。這一步非常重要，必須確保所有已生成的歸檔文件均已存在于standby 服務(wù)器，不然可能會(huì)數(shù)據(jù)不一致造成轉(zhuǎn)換時(shí)報(bào)錯(cuò)。文件復(fù)制之后，通過下列命令將其加入數(shù)據(jù)字典：
??? SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
?
2、檢查歸檔文件是否完整
?
??? 分別在primary/standby 執(zhí)行下列語句：
??? SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;
?
??? 該語句取得當(dāng)前數(shù)據(jù)庫各線程已歸檔文件最大序號(hào)，如果primary 與standby 最大序號(hào)不相同，必須將多出的序號(hào)對(duì)應(yīng)的歸檔文件復(fù)制到待轉(zhuǎn)換的standby 服務(wù)器。不過既然是failover，有可能primary 數(shù)據(jù)庫此時(shí)已經(jīng)無法打開，甚至無法訪問，那你只好聽天由命嘍，三思在這里替你默念：蒼天啊，大地啊，哪路的神仙大姐能來保佑俺們不丟數(shù)據(jù)呀！
?
3、啟動(dòng)failover
?
??? 執(zhí)行下列語句：
??? SQL> alter database recover managed standby database finish force;
??? 數(shù)據(jù)庫已更改。
?
??? FORCE 關(guān)鍵字將會(huì)停止當(dāng)前活動(dòng)的RFS 進(jìn)程，以便立刻執(zhí)行failover。
?
?
剩下的步驟就與前面switchover 很相似了
?
4、切換物理standby 角色為primary
?
??? SQL> alter database commit to switchover to primary;
??? 數(shù)據(jù)庫已更改。
?
5、啟動(dòng)新的primary 數(shù)據(jù)庫。
?
??? 如果當(dāng)前數(shù)據(jù)庫已mount,直接open 即可，如果處于read-only 模式，需要首先shutdown immediate，然后再直接startup。
??? SQL> alter database open;
??? 數(shù)據(jù)庫已更改。
?
?
?
??? 角色轉(zhuǎn)換工作完成。剩下的是補(bǔ)救措施(針對(duì)原primary 數(shù)據(jù)庫)，由于此時(shí)primary 數(shù)據(jù)庫已經(jīng)不再是data guard 配置的一部分，我們需要做的就是嘗試看看能否恢復(fù)原primary 數(shù)據(jù)庫，將其改造為新的standby服務(wù)器。具體操作方式可以分為二類：1.重建2.備份恢復(fù)。所涉及的技術(shù)前面的系列文章中均有涉及，此處不再贅述。
?
?
?