技術(shù)專題總結(jié)：standby Database （三）
2024-07-21 02:37:54
供稿：網(wǎng)友
四、Opening/Activating a standby database
在通常的情形下，standby database是處于 recovery狀態(tài)的。但是在 opened read-only 或者 activeated 之后可以 access standby database 中的 data。
1. opening standby database read-only:
當(dāng) standby database 被 opened read-only 時，數(shù)據(jù)只能處于讀取狀態(tài)。
因為 standby database被opened 成為 read-only mode之后，還可以恢復(fù)成 recovery/managed recovery mode，所以 opening standby database read-only，可以用來試驗 standby database是否建立成功及 archived log files是否成功 applied到database 中。
在更多的情況下，read-only mode 是用于系統(tǒng) run report。很多擁有很多用戶的系統(tǒng)，需要 on-line data access，同時需要 run report，為了避免系統(tǒng) overheat，單機(jī)狀態(tài)的時候，大的 reports 是在非尖峰期的晚上和周末運行的。假如系統(tǒng)有 standby database，可以 open standby database在 read-only情況下 run reports，不影響 PRimary database的性能。
需要注重的是，在 read-only狀態(tài)下面時，primary database的 archived log files仍然持續(xù)送達(dá) standby database，但是不會 apply到 standby database中去。所以，在 run完 reports之后，要將 standby database 回歸至 managed/manual recovery mode。
有關(guān)命令行如下：
假如 standby database處于shutdown狀態(tài)：
SQL> startup nomount pfile=/path/stinit.ora
SQL> alter database mount standby database;
SQL> alter database open read only;
假如 standby database 處于 manual/managed recovery mode:
SQL> recover cancel/recover managed standby database cancel
(需要另開啟一個 session來做)
SQL> alter database open read only;
將 read-only mode 的 standby database 回歸 manual/managed recovery mode:
SQL> recover standby database;/recover managed standby database time out 15;
檢查 database 所處狀態(tài)的命令：
SQL> select status from v$instance;
STATUS
-------
MOUNTED
2. activating a standby database
當(dāng) primary database 由于某種原因不能正常工作，而修復(fù)時間超過用戶可以接受的范圍時，需要擊活 standby database，使之成為 primary database 運行。這個行為是單向的。被擊活的 standby database 是無法再回到 standby 狀態(tài)下的。下一個部份，我們講討論到 standby database 的重建問題。
完成擊活 standby database 使之成為 primary database 的過程是需要 downtime 的。
過程如下：
(1) 首先要 shutdown primary database. 這種情況出現(xiàn)在 primary database 出了問題，不能正常工作，但 database 仍然處于 open 的狀態(tài)下，但是無法做 online recovery，或者 online recovery 所需要的條件，客戶不能接受(可能部份 data 無法訪問，所需時間視數(shù)據(jù)庫損壞程度而不同)。
這時，假如可能要盡量 archive current online log file:
SQL> alter system archive log current;
(2) 對應(yīng)在 standby database node，activating 之前，要 apply 最后一個 archived log file。
假如 primary database 的錯誤導(dǎo)致 database down，系統(tǒng)丟失的 data 將會是 online log file 中的 data。同樣的，在 activating 之前，要 apply 最后一個 archived log file。
(3) 在 standby database 處于 mount 的狀態(tài)下 activate standby database:
SQL> alter database activate standby database;
(4) shutdown the standby database normal/immediate，之后做一次 cold backup。
在這里需要解釋一下，當(dāng) standby database 被activated 之后成為 primary database，這個過程將自動 resetlogs。因此，在 startup 之前要做一次 cold backup，因為以往的 backup 最多只能 recover 到 standby database 被activated 這一點。
另外，standby database 的 parameter file 中l(wèi)og_archive_start 是 false，系統(tǒng)不能自動 archive log file，在startup 之前要改為 ture。
這樣即可以保證在 重建 primary database 之前的任何狀況發(fā)生，database 可以被 recovered to the point of failure。
(5) open the standby database.
SQL> startup pfile=/path/stinit.ora
注重：假如用戶是通過client/server mode 或其他方式與 primary database 相連的話，在 activate standby database 的同時，需要修改 client side 的 tnsnames.ora 文件中的 database hose name 或者ip 地址。
五、Primary and standby database的重建
當(dāng)原 standby database 因為 primary database的 failure而成為 primary database 之后，一般在僅接下來的第一個非高峰工作時段，就要進(jìn)行 standby database的重建。
怎樣對 Standby database進(jìn)行重建，首先要考慮系統(tǒng)的設(shè)置，以及有多少的時間進(jìn)行重建。
實例一：假如 primary/standby 兩個nodes都是為該數(shù)據(jù)庫專用的，且設(shè)置相同的話，可以保留 standby node上面的數(shù)據(jù)庫做為 primary database，在原來的 primary上面建立一個standby database就可以了。系統(tǒng)不需要 downtime。備份文件可以采用上一部份中，standby database變?yōu)?primary database open 之前的冷備份，再手工 apply 從數(shù)據(jù)庫 open 到目前的所有 archived logs。
注重，這種情形下，要重新設(shè)置當(dāng)前 primary database node的 tnsnames.ora文件，以及當(dāng)前 standby node上面的 listener.ora文件。(具體參見上面部份的 standby database的建立)
這種設(shè)置在 standby database系統(tǒng)中算是最理想的設(shè)置了，甚至在某些情形下面，可以 activing standby database，直接對 primary database進(jìn)行 recovery，再在standby node上重建 standby database。具體的設(shè)置和操作，是要根據(jù)項目的要求設(shè)定的。
實例二：這種情況下，不管怎樣，原來的primary node 要變回 primary database的服務(wù)器， standby node上的database要回歸 standby database 的狀態(tài)。在這種情形下，假如你能得到足夠的系統(tǒng) down time，最輕易的辦法，就是將 standby node上面的database shutown，拷貝所有的 all database file (包括 control files，但不包括 parameter file) 到 primary node 原來的目錄下面，覆蓋住原來的文件，清除掉原來 database的 alter.log/trace files/archived log files等等，直接 open database，同時把 application side的所有 tnsnames.ora文件 host name/IP 改回成 primary node 即可。重建 primary database的時間只比系統(tǒng)拷貝文件的時間多出 10分鐘而已。
在 standby node上面：在 database shutdown之后，拷貝文件去 primary node的過程中，要對整個 database進(jìn)行一次冷備份。之后用原來備份的 standby database的 parameter file取代當(dāng)前的 parameter file，再從已經(jīng) open的 primary database上面建立一個 standby database的 control file拷貝到 standby node上面取代當(dāng)前的 control files。
假如此時，primary database 尚未生成新的 archived log files， standby database 可以直接進(jìn)入 managed recovery mode。
這個實例是我本人比較喜歡采用的一種方法。現(xiàn)給出具體的操作步驟如下：
重建 primary database的過程：
1) 在 standby node上面建一個 standby database 的 control file:
Alter database create standby control file ‘/oradba/DBA/stcrt1si.ctl’;
2) Shutdown database normal/immediate;
3) 對 database進(jìn)行一個冷備份
4) 清除所有 archived log files (原來的 primary node上面的)
5) 拷貝除了 parameter file 之外的所有 data files/control files/online redo log files 到 primary node 原來 Directory下面，覆蓋掉原來的文件。
6) 可以用原來已經(jīng)存在的 instance 直接 open database
重建 standby database的過程：
1) 拷貝剛剛建好的 control file (見重建 primary database過程) standby database parameter file 指定的 directory 下面
2) 清除 standby node上面全部的 archived log files.
3) 核對一下 parameter file是否與原來的 standby database parameter file相同 (應(yīng)該是相同的) 之后，就可以直接 Startup standby database:
Startup nomount pfile=’xxxxxxxxxxxxxxxxxxx’;
Alter database mount standby database;
4) Recover managed standby database timeout 15;
(因為是在非工作繁忙期，所以，primary上面不會有很多 transactions，所以沒有產(chǎn)生新的 archived log file之前，可以直接進(jìn)入 managed recover mode。假如已經(jīng)產(chǎn)生了 archived log files，要先手工 recover。
實例三：在實例二的情況下，假如在 primary node 上面重建 primary database 的時間，用戶不答應(yīng)有足夠多的系統(tǒng)down time，可以采用的方法就是，在 primary node 上面再建目前運行的 database 的standby database，建立好之后，可以在最短時間
