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