Standby database 的建立
Oracle Standby Database 的建立過程並不複雜，但建立過程的相關設置取決於建立standby database 的目的。例如，如果建立standby database 是爲了 disaster protection，standby database 就不能建立在與 primary database 相同服務器上面。如果是爲了 protection against data corruption，在standby database 接收到 primary database 送來的 archived log files 時，apply 需要晚上一段，比如三個小時，或是六個小時。這樣當 primary database出現錯誤的時候，standby database 不會與primary database 同步。
在這篇文章裏面，我無法面面俱到的分析各種性能，僅做一個具體實例分析。
我們承諾客戶的條件：
24x7 uptime of SIS database
in case of failure on primary:
1.1 1/2 hour to fail over to standby database
1.2 no more than 5 mins data loss
1.3 2 hours scheduled downtime to revert back to primary/standby configuration
我們爲了完成以上各項，必須完成的工作：
1. 在remote site 建立 standby database。我們有半小時的時間 activing standby database，我個人喜歡再做一次 cold backup。
2. 以我們的環境，4組 log groups，每組 2 個members，on-line redo log file size 是 10M，運行高峯期，每分鐘可以多達 10 個archived files 產生。因此非高峯的時候，我們用cron job 做強制 log switch.
3. 因爲我們的standby database server 不是專用的，所以在非高峯期時我們需要重新建立 primary/standby database.
在這裏，我又要說一些多餘的話了。DBA 在申請down time 的時候，應該給自己預留足夠的時間，到底多少合適，自己要掌握好。(如果留的時間太少，老闆和客戶可能會認爲DBA的工作很容易，或不重要，如果一旦出了差錯，自己的壓力方面也夠大。所以一般選擇在用戶可接受的最多的時間，我一般要求需要時間的2-4倍) 。
1. 根據上面的條件，我們做的環境設置
(1) 首先我們必須確認 primary database 處於archived mode:
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oradba/sisi/arch
Oldest online log sequence 4783
Next log sequence to archive 4786
Current log sequence 4786
(2) 我們必須滿足的條件是 high availablity，所以我們採用的是雙機。
採用雙機形式，有很多的好處，除了再安裝與primary node 相同的OS系統及oracle 系統外，其他各種設置都可以與primary node 完全相同，省掉很多修改參數的麻煩之處。
(3) 我們的oracle 版本是8.1.7EE，standby node 通過net8 接收 primary node 的 archived log files。我們專門在 standby node 開通了 port 1512 做爲 standby database 的listener。(Oracle 的缺省是 port 1521) 。
2. standby database的建立過程：
standby database一般是用primary database的cold backup建立的。特殊情況下，可以用RMAN或export dmp file來做。這裏我們是講的正常情況。
(1) 在 standby node上面建立與primary node上面相同的datafile directory。我們用的是/oradba/sisi/
(2) 修改 primary database的 initialize parameter file: (我們的例子，請不要問我爲什麼，很多是 application要求的，不是我制定的)
primary database:
db_name = sisi
instance_name = sisi
service_names = sisi
control_files = (/oradba/sisi/ctrl/stctl1si.ctl, /oradba/sisi/ctrl/stctl2si.ctl)
db_files = 500
compatible = 8.1.7.0.0
rollback_segments = (rbs1, rbs2, rbs3, rbs4, rbs5, rbs6, rbs7, rbs8, rbs9, rbs10, rbs11, rbs12, rbs1
3, rbs14, rbs15)
db_file_multiblock_read_count = 32
optimizer_mode = rule #application required
db_block_size = 8192
db_block_buffers = 83200
shared_pool_size = 52428800
sort_area_size = 1048576
sort_area_retained_size = 64000
log_checkpoint_interval = 10000
sessions = 252
transactions = 280
transactions_per_rollback_segment = 4
processes = 800
open_cursors = 1000
dml_locks = 500
log_buffer = 20971520
log_checkpoint_timeout = 10000
cursor_space_for_time = true
utl_file_dir=/tmp
timed_statistics = false # if you want timed statistics
max_dump_file_size = 2097152 # limit trace file size to 5 Meg each
core_dump_dest = /oradba/sisi/cdump
background_dump_dest= /oradba/sisi/bdump
user_dump_dest = /oradba/sisi/udump
remote_login_passwordfile = none
parallel_max_servers = 0
#The following parameters are the HA parameters needed for Standby Database on primary side
LOG_ARCHIVE_START=TRUE
LOG_ARCHIVE_FORMAT = "sisi%S.arc"
LOG_ARCHIVE_DEST_1='LOCATION=/oradba/sisi/arch MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
STANDBY_ARCHIVE_DEST='/oradba/sisi/arch'
LOG_ARCHIVE_DEST_2='SERVICE=standby_sisi MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MIN_SUCCEED_DEST=2
複製到Standby database side相對的directory下面：
db_name = sisi
instance_name = sisi
service_names = sisi
control_files = (/oradba/sisi/ctrl/stctl1si.ctl, /oradba/sisi/ctrl/stctl2si.ctl)
db_files = 500
compatible = 8.1.7.0.0
rollback_segments = (rbs1, rbs2, rbs3, rbs4, rbs5, rbs6, rbs7, rbs8, rbs9, rbs10, rbs11, rbs12, rbs1
3, rbs14, rbs15)
db_file_multiblock_read_count = 32
optimizer_mode = rule
db_block_size = 8192
db_block_buffers = 83200
shared_pool_size = 52428800
sort_area_size = 1048576 #100M Change to 1M after import.
sort_area_retained_size = 64000
log_checkpoint_interval = 10000
sessions = 252
transactions = 280
transactions_per_rollback_segment = 4
processes = 800
open_cursors = 1000
dml_locks = 500
log_buffer = 20971520
log_checkpoint_timeout = 10000
cursor_space_for_time = true
utl_file_dir=/tmp
timed_statistics = false # if you want timed statistics
max_dump_file_size = 2097152 # limit trace file size to 5 Meg each
core_dump_dest = /oradba/sisi/cdump
background_dump_dest= /oradba/sisi/bdump
user_dump_dest = /oradba/sisi/udump
remote_login_passwordfile = none
parallel_max_servers = 0
#The following parameter are the HA parameters needed for Standby Database on standby side
LOG_ARCHIVE_START=FALSE
LOG_ARCHIVE_FORMAT = "sisi%S.arc"
LOG_ARCHIVE_DEST_1='LOCATION=/oradba/sisi/arch MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
STANDBY_ARCHIVE_DEST='/oradba/sisi/arch'
LOG_ARCHIVE_DEST_2='SERVICE=standby_sisi MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MIN_SUCCEED_DEST=2
(3) shutdown primary database normal/immediate，做一個冷備份，再次 startup primary database時，用 pfile標示到上面改過的 parameter file. 用ftp或其他OS工具，把冷備份的 data
files/online redo log files到在standby node已經建好的對應 directory下面。
(4) 建立 standby database control file.
Alter database create standby controlfile as ‘/oradba/sisi/temp/stctl1si.ctl’;
用 rcp或 ftp到standby node對應的directory，用 cp command複製另一個。
(5) 在primary side編輯 tnsnames.ora文件，增加一條(可以用netasst做)：
STANDBY_SISI =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.19.26.10)(PORT = 1512))
)
(CONNECT_DATA =
(SID = sisi)
)
)
(6) 在 standby node編輯 listener.ora文件，增加一條(可以用netasst做)：
ST_LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = prtltest)(PORT = 1512))
)
SID_LIST_ST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = sisi)
(ORACLE_HOME = /oracle/8.1.7)
(SID_NAME = sisi)
)
)
(7) start standby listener:
lsnrctl start st_listener;
(8) start standby database
$ export ORACLE_SID=sisi
$ sqlplus
SQL*Plus: Release 8.1.7.0.0 - Production on Mon Dec 31 00:54:28 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Enter user-name: internal
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
JServer Release 8.1.7.0.0 - Production
SQL>startup nomount pfile=’/oradba/sisi/pfile/stinitsi.ora’;
SQL>alter database mount standby database;
(9) apply log files.
這裏有兩種情況，覈對已經mount起來的standby database與primary database之間有archived logs上的是否有差距，用下面命令：
SQL> select sequence# from v$log_history;
如果有差距，要手動把差的archived log files copy到standby node，並手動恢復：
SQL> recovery automatic standby database
如果沒有差距，就可以直接進入managed recovery mode:
SQL> recovery managed standby database
二、Standby database的維護與備份
在前面的部份，我們提到過，standby database所處於的狀態。在oracle 8i之前的各版本(指7.3.x – 8.0.x) ，standby database只能處於manual recovery mode以及被actived 成爲 primary database，並且 archived log files的傳送需要靠手動或OS的相關工具完成。
從 oracle8.1.x開始(EE版)，oracle增加了新的功能，在 standby database所處的狀態上面，增加了managed recoveredd mode 和 read only mode，archived log files也可以通過 oracle network自動傳到standby side。
本篇是基於 oracle 8.1.7EE版本在 unix環境下的相關問題進行的討論。
1. standby database的維護
在一般的情況下面，standby database一直是處於 managed recovered mode的情形下。
(1) 如果需要database 處於managed recovered mode 的情況下，必須滿足的條件是：
在 primary database 與 standby database 在建立之後已經手動 recoverd gap log files。因此，如果不是用以前的冷備份及備份的 archived log files 建立的 standby database，兩個database 之間沒有 log 差距的話，即可直接進入 managed mode。
當 primary database 與 standby database 存在 archived log files 差距的時候，需要手動去做 recovery，有關命令是：
SQL> recover standby database;
Or
SQL> recover automatic standby database;
如果這兩個 command 得到 ora-00308, 27037, 01547, 01194, 01110, 01112錯誤的時候，standby database可以直接進入 managed mode:
SQL> recover managed standby database;
(2) 當 standby database是處於 managed recovery mode時，recover managed standby database; command line的 window session要永遠 open， standby database才能一直處於等待狀態，當下一個 archived log file送達 standby node指定位置的時候，會及時被recovery到 standby database中。
如果，受到條件限制，無法永遠 open一個 managed mode session window時，可以採用下面命令。
SQL> recover managed standby database timeout 15;
即爲 managed mode窗口 open並等待 15分鐘，如果 15分鐘之內未收到新的 archived log files，這個session會自己結束。但結束之後，新到的 archived log files將不會被自動 recover到 standby database。這種情形下，可以通過設立 crontab job，在每隔一固定的時間段，運行上述命令，保證 primary database和standby database中的數據差距，最大爲 crontab job的執行頻率。
(3) 在維護方面，我們這裏沒有討論到 primary database數據結構及 data files size等改變對 standby database的影響。這些情況，在一個成熟的 database環境中不是很常見問題，也不是很難解決的。
2. 在使用了 standby database後，database 的備份計劃
在系統尚未使用 standby database之前，大家都知道正常運行在一個node上面的databases的備份計劃非常的重要。從DBA的角度上來講，並不希望因爲系統增加了 standby database，而將全部的全部的備份計劃棄置不用。
以我上面舉例的系統來說，在設立 standby database之前，我們每個星期，有二個小時的 downtime做 cold back，刪除 hard disk上面的所有 archived log files; 每天晚上，有一次 full export和全部 data files的 hotback。
在建立 standby database之後，我們失去了每週二小時的 downtime時間，即意味着，我們沒有辦法每週對 primary database進行 cold backup了，但我們仍然保留了對 primary database每晚上的 full export和全部 data files的 hotback。所有的 archived log files仍然一週清理一次，並轉移到 backup tape上面，保留一年。每一年的 downtime我們仍在與客戶的協商之中。
在這種情形下，對 standby database進行 backup，就變的相對需要考慮，以彌補每週以來，primary database無法進行 cold backup的缺陷。
Standby database可以採用兩種情形進行 backup。一種是處於 shutdown狀態 (必須 shutdown normal/immediate) 。另一種是 standby database處於 read-only狀態。shutdown狀態，相當於 cold backup，缺點是，standby database shutdown以後，database不能處於 managed recovery狀態，有可能再 mount的時候，需要手動 recover primary/standby database的間距 archived log files。而 standby database處於read-only狀態時仍然可以使 database處於 managed recovery mode。
但這種 backup的恢復可能會麻煩一些。
考慮各種情況之後，我們的系統對 standby database每天晚上採用的是 shutdown immediate之後的 cold backup。
三、Opening/Activating a standby database
在通常的情形下，standby database是處於 recovery狀態的。但是在 opened read-only 或者 activeated 之後可以 access standby database 中的 data。
1. opening standby database read-only:
當 standby database 被 opened read-only 時，數據只能處於讀取狀態。
因爲 standby database被opened 成爲 read-only mode之後，還可以恢復成 recovery/managed recovery mode，所以 opening standby database read-only，可以用來試驗 standby database是否建立成功及 archived log files是否成功 applied到database 中。
在更多的情況下，read-only mode 是用於系統 run report。很多擁有很多用戶的系統，需要 on-line data access，同時需要 run report，爲了避免系統 overheat，單機狀態的時候，大的 reports 是在非尖峯期的晚上和週末運行的。如果系統有 standby database，可以 open standby database在 read-only情況下 run reports，不影響 primary database的性能。
需要注意的是，在 read-only狀態下面時，primary database的 archived log files仍然持續送達 standby database，但是不會 apply到 standby database中去。所以，在 run完 reports之後，要將 standby database 迴歸至 managed/manual recovery mode。
有關命令行如下：
如果 standby database處於shutdown狀態：
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 所處狀態的命令：
SQL> select status from v$instance;
STATUS
-------
MOUNTED
2. activating a standby database
當 primary database 由於某種原因不能正常工作，而修復時間超過用戶可以接受的範圍時，需要擊活 standby database，使之成爲 primary database 運行。這個行爲是單向的。被擊活的 standby database 是無法再回到 standby 狀態下的。下一個部份，我們講討論到 standby database 的重建問題。
完成擊活 standby database 使之成爲 primary database 的過程是需要 downtime 的。
過程如下：
(1) 首先要 shutdown primary database. 這種情況出現在 primary database 出了問題，不能正常工作，但 database 仍然處於 open 的狀態下，但是無法做 online recovery，或者 online recovery 所需要的條件，客戶不能接受(可能部份 data 無法訪問，所需時間視數據庫損壞程度而不同)。
這時，如果可能要儘量 archive current online log file:
SQL> alter system archive log current;
(2) 對應在 standby database node，activating 之前，要 apply 最後一個 archived log file。
如果 primary database 的錯誤導致 database down，系統丟失的 data 將會是 online log file 中的 data。同樣的，在 activating 之前，要 apply 最後一個 archived log file。
(3) 在 standby database 處於 mount 的狀態下 activate standby database:
SQL> alter database activate standby database;
(4) shutdown the standby database normal/immediate，之後做一次 cold backup。
在這裏需要解釋一下，當 standby database 被activated 之後成爲 primary database，這個過程將自動 resetlogs。因此，在 startup 之前要做一次 cold backup，因爲以往的 backup 最多隻能 recover 到 standby database 被activated 這一點。
另外，standby database 的 parameter file 中log_archive_start 是 false，系統不能自動 archive log file，在startup 之前要改爲 ture。
這樣即可以保證在 重建 primary database 之前的任何狀況發生，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的重建
當原 standby database 因爲 primary database的 failure而成爲 primary database 之後，一般在僅接下來的第一個非高峯工作時段，就要進行 standby database的重建。
怎樣對 Standby database進行重建，首先要考慮系統的設置，以及有多少的時間進行重建。
實例一：如果 primary/standby 兩個nodes都是爲該數據庫專用的，且設置相同的話，可以保留 standby node上面的數據庫做爲 primary database，在原來的 primary上面建立一個standby database就可以了。系統不需要 downtime。備份文件可以採用上一部份中，standby database變爲 primary database open 之前的冷備份，再手工 apply 從數據庫 open 到目前的所有 archived logs。
注意，這種情形下，要重新設置當前 primary database node的 tnsnames.ora文件，以及當前 standby node上面的 listener.ora文件。(詳細參見上面部份的 standby database的建立)
這種設置在 standby database系統中算是最理想的設置了，甚至在某些情形下面，可以 activing standby database，直接對 primary database進行 recovery，再在standby node上重建 standby database。具體的設置和操作，是要根據項目的要求設定的。
實例二：這種情況下，不管怎樣，原來的primary node 要變回 primary database的服務器， standby node上的database要回歸 standby database 的狀態。在這種情形下，如果你能得到足夠的系統 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的時間只比系統拷貝文件的時間多出 10分鐘而已。
在 standby node上面：在 database shutdown之後，拷貝文件去 primary node的過程中，要對整個 database進行一次冷備份。之後用原來備份的 standby database的 parameter file取代當前的 parameter file，再從已經 open的 primary database上面建立一個 standby database的 control file拷貝到 standby node上面取代當前的 control files。
如果此時，primary database 尚未生成新的 archived log files， standby database 可以直接進入 managed recovery mode。
這個實例是我本人比較喜歡採用的一種方法。現給出具體的操作步驟如下：
重建 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進行一個冷備份
4) 清除所有 archived log files (原來的 primary node上面的)
5) 拷貝除了 parameter file 之外的所有 data files/control files/online redo log files 到 primary node 原來 directory下面，覆蓋掉原來的文件。
6) 可以用原來已經存在的 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相同 (應該是相同的) 之後，就可以直接 Startup standby database:
Startup nomount pfile=’xxxxxxxxxxxxxxxxxxx’;
Alter database mount standby database;
4) Recover managed standby database timeout 15;
(因爲是在非工作繁忙期，所以，primary上面不會有很多 transactions，所以沒有產生新的 archived log file之前，可以直接進入 managed recover mode。如果已經產生了 archived log files，要先手工 recover。
實例三：在實例二的情況下，如果在 primary node 上面重建 primary database 的時間，用戶不允許有足夠多的系統down time，可以採用的方法就是，在 primary node 上面再建目前運行的 database 的standby database，建立好之後，可以在最短時間內，進行一個轉換。
在這種情況下，需要主意的問題是，在原來的 primary node 上面的 parameter file 要修改成爲 standby mode 的 parameter，同時 network file 也需要做相應的更改。 (standby database 改來改去的，最好每個版本的文件，如果 parameter file, tnsnames.ora, listener.ora 等文件，專門收集到一個地方，會受益非淺的。)
在這個實例下運行，在 activated 了在 primary node 上面的 standby database，shutdown 之後，還是要做一次 cold backup 的。因此需要的 system downtime，幾乎就是一次 cold backup 的時間。怎樣重建standby database 在原來的 standby node上面，請參照前面如何建立 standby database 部份所講的內容。
在這篇文章裏面，我無法面面俱到的分析各種性能，僅做一個具體實例分析。
我們承諾客戶的條件：
24x7 uptime of SIS database
in case of failure on primary:
1.1 1/2 hour to fail over to standby database
1.2 no more than 5 mins data loss
1.3 2 hours scheduled downtime to revert back to primary/standby configuration
我們爲了完成以上各項，必須完成的工作：
1. 在remote site 建立 standby database。我們有半小時的時間 activing standby database，我個人喜歡再做一次 cold backup。
2. 以我們的環境，4組 log groups，每組 2 個members，on-line redo log file size 是 10M，運行高峯期，每分鐘可以多達 10 個archived files 產生。因此非高峯的時候，我們用cron job 做強制 log switch.
3. 因爲我們的standby database server 不是專用的，所以在非高峯期時我們需要重新建立 primary/standby database.
在這裏，我又要說一些多餘的話了。DBA 在申請down time 的時候，應該給自己預留足夠的時間，到底多少合適，自己要掌握好。(如果留的時間太少，老闆和客戶可能會認爲DBA的工作很容易，或不重要，如果一旦出了差錯，自己的壓力方面也夠大。所以一般選擇在用戶可接受的最多的時間，我一般要求需要時間的2-4倍) 。
1. 根據上面的條件，我們做的環境設置
(1) 首先我們必須確認 primary database 處於archived mode:
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oradba/sisi/arch
Oldest online log sequence 4783
Next log sequence to archive 4786
Current log sequence 4786
(2) 我們必須滿足的條件是 high availablity，所以我們採用的是雙機。
採用雙機形式，有很多的好處，除了再安裝與primary node 相同的OS系統及oracle 系統外，其他各種設置都可以與primary node 完全相同，省掉很多修改參數的麻煩之處。
(3) 我們的oracle 版本是8.1.7EE，standby node 通過net8 接收 primary node 的 archived log files。我們專門在 standby node 開通了 port 1512 做爲 standby database 的listener。(Oracle 的缺省是 port 1521) 。
2. standby database的建立過程：
standby database一般是用primary database的cold backup建立的。特殊情況下，可以用RMAN或export dmp file來做。這裏我們是講的正常情況。
(1) 在 standby node上面建立與primary node上面相同的datafile directory。我們用的是/oradba/sisi/
(2) 修改 primary database的 initialize parameter file: (我們的例子，請不要問我爲什麼，很多是 application要求的，不是我制定的)
primary database:
db_name = sisi
instance_name = sisi
service_names = sisi
control_files = (/oradba/sisi/ctrl/stctl1si.ctl, /oradba/sisi/ctrl/stctl2si.ctl)
db_files = 500
compatible = 8.1.7.0.0
rollback_segments = (rbs1, rbs2, rbs3, rbs4, rbs5, rbs6, rbs7, rbs8, rbs9, rbs10, rbs11, rbs12, rbs1
3, rbs14, rbs15)
db_file_multiblock_read_count = 32
optimizer_mode = rule #application required
db_block_size = 8192
db_block_buffers = 83200
shared_pool_size = 52428800
sort_area_size = 1048576
sort_area_retained_size = 64000
log_checkpoint_interval = 10000
sessions = 252
transactions = 280
transactions_per_rollback_segment = 4
processes = 800
open_cursors = 1000
dml_locks = 500
log_buffer = 20971520
log_checkpoint_timeout = 10000
cursor_space_for_time = true
utl_file_dir=/tmp
timed_statistics = false # if you want timed statistics
max_dump_file_size = 2097152 # limit trace file size to 5 Meg each
core_dump_dest = /oradba/sisi/cdump
background_dump_dest= /oradba/sisi/bdump
user_dump_dest = /oradba/sisi/udump
remote_login_passwordfile = none
parallel_max_servers = 0
#The following parameters are the HA parameters needed for Standby Database on primary side
LOG_ARCHIVE_START=TRUE
LOG_ARCHIVE_FORMAT = "sisi%S.arc"
LOG_ARCHIVE_DEST_1='LOCATION=/oradba/sisi/arch MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
STANDBY_ARCHIVE_DEST='/oradba/sisi/arch'
LOG_ARCHIVE_DEST_2='SERVICE=standby_sisi MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MIN_SUCCEED_DEST=2
複製到Standby database side相對的directory下面：
db_name = sisi
instance_name = sisi
service_names = sisi
control_files = (/oradba/sisi/ctrl/stctl1si.ctl, /oradba/sisi/ctrl/stctl2si.ctl)
db_files = 500
compatible = 8.1.7.0.0
rollback_segments = (rbs1, rbs2, rbs3, rbs4, rbs5, rbs6, rbs7, rbs8, rbs9, rbs10, rbs11, rbs12, rbs1
3, rbs14, rbs15)
db_file_multiblock_read_count = 32
optimizer_mode = rule
db_block_size = 8192
db_block_buffers = 83200
shared_pool_size = 52428800
sort_area_size = 1048576 #100M Change to 1M after import.
sort_area_retained_size = 64000
log_checkpoint_interval = 10000
sessions = 252
transactions = 280
transactions_per_rollback_segment = 4
processes = 800
open_cursors = 1000
dml_locks = 500
log_buffer = 20971520
log_checkpoint_timeout = 10000
cursor_space_for_time = true
utl_file_dir=/tmp
timed_statistics = false # if you want timed statistics
max_dump_file_size = 2097152 # limit trace file size to 5 Meg each
core_dump_dest = /oradba/sisi/cdump
background_dump_dest= /oradba/sisi/bdump
user_dump_dest = /oradba/sisi/udump
remote_login_passwordfile = none
parallel_max_servers = 0
#The following parameter are the HA parameters needed for Standby Database on standby side
LOG_ARCHIVE_START=FALSE
LOG_ARCHIVE_FORMAT = "sisi%S.arc"
LOG_ARCHIVE_DEST_1='LOCATION=/oradba/sisi/arch MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
STANDBY_ARCHIVE_DEST='/oradba/sisi/arch'
LOG_ARCHIVE_DEST_2='SERVICE=standby_sisi MANDATORY REOPEN=60'
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_MIN_SUCCEED_DEST=2
(3) shutdown primary database normal/immediate，做一個冷備份，再次 startup primary database時，用 pfile標示到上面改過的 parameter file. 用ftp或其他OS工具，把冷備份的 data
files/online redo log files到在standby node已經建好的對應 directory下面。
(4) 建立 standby database control file.
Alter database create standby controlfile as ‘/oradba/sisi/temp/stctl1si.ctl’;
用 rcp或 ftp到standby node對應的directory，用 cp command複製另一個。
(5) 在primary side編輯 tnsnames.ora文件，增加一條(可以用netasst做)：
STANDBY_SISI =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 172.19.26.10)(PORT = 1512))
)
(CONNECT_DATA =
(SID = sisi)
)
)
(6) 在 standby node編輯 listener.ora文件，增加一條(可以用netasst做)：
ST_LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = prtltest)(PORT = 1512))
)
SID_LIST_ST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = sisi)
(ORACLE_HOME = /oracle/8.1.7)
(SID_NAME = sisi)
)
)
(7) start standby listener:
lsnrctl start st_listener;
(8) start standby database
$ export ORACLE_SID=sisi
$ sqlplus
SQL*Plus: Release 8.1.7.0.0 - Production on Mon Dec 31 00:54:28 2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
Enter user-name: internal
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
JServer Release 8.1.7.0.0 - Production
SQL>startup nomount pfile=’/oradba/sisi/pfile/stinitsi.ora’;
SQL>alter database mount standby database;
(9) apply log files.
這裏有兩種情況，覈對已經mount起來的standby database與primary database之間有archived logs上的是否有差距，用下面命令：
SQL> select sequence# from v$log_history;
如果有差距，要手動把差的archived log files copy到standby node，並手動恢復：
SQL> recovery automatic standby database
如果沒有差距，就可以直接進入managed recovery mode:
SQL> recovery managed standby database
二、Standby database的維護與備份
在前面的部份，我們提到過，standby database所處於的狀態。在oracle 8i之前的各版本(指7.3.x – 8.0.x) ，standby database只能處於manual recovery mode以及被actived 成爲 primary database，並且 archived log files的傳送需要靠手動或OS的相關工具完成。
從 oracle8.1.x開始(EE版)，oracle增加了新的功能，在 standby database所處的狀態上面，增加了managed recoveredd mode 和 read only mode，archived log files也可以通過 oracle network自動傳到standby side。
本篇是基於 oracle 8.1.7EE版本在 unix環境下的相關問題進行的討論。
1. standby database的維護
在一般的情況下面，standby database一直是處於 managed recovered mode的情形下。
(1) 如果需要database 處於managed recovered mode 的情況下，必須滿足的條件是：
在 primary database 與 standby database 在建立之後已經手動 recoverd gap log files。因此，如果不是用以前的冷備份及備份的 archived log files 建立的 standby database，兩個database 之間沒有 log 差距的話，即可直接進入 managed mode。
當 primary database 與 standby database 存在 archived log files 差距的時候，需要手動去做 recovery，有關命令是：
SQL> recover standby database;
Or
SQL> recover automatic standby database;
如果這兩個 command 得到 ora-00308, 27037, 01547, 01194, 01110, 01112錯誤的時候，standby database可以直接進入 managed mode:
SQL> recover managed standby database;
(2) 當 standby database是處於 managed recovery mode時，recover managed standby database; command line的 window session要永遠 open， standby database才能一直處於等待狀態，當下一個 archived log file送達 standby node指定位置的時候，會及時被recovery到 standby database中。
如果，受到條件限制，無法永遠 open一個 managed mode session window時，可以採用下面命令。
SQL> recover managed standby database timeout 15;
即爲 managed mode窗口 open並等待 15分鐘，如果 15分鐘之內未收到新的 archived log files，這個session會自己結束。但結束之後，新到的 archived log files將不會被自動 recover到 standby database。這種情形下，可以通過設立 crontab job，在每隔一固定的時間段，運行上述命令，保證 primary database和standby database中的數據差距，最大爲 crontab job的執行頻率。
(3) 在維護方面，我們這裏沒有討論到 primary database數據結構及 data files size等改變對 standby database的影響。這些情況，在一個成熟的 database環境中不是很常見問題，也不是很難解決的。
2. 在使用了 standby database後，database 的備份計劃
在系統尚未使用 standby database之前，大家都知道正常運行在一個node上面的databases的備份計劃非常的重要。從DBA的角度上來講，並不希望因爲系統增加了 standby database，而將全部的全部的備份計劃棄置不用。
以我上面舉例的系統來說，在設立 standby database之前，我們每個星期，有二個小時的 downtime做 cold back，刪除 hard disk上面的所有 archived log files; 每天晚上，有一次 full export和全部 data files的 hotback。
在建立 standby database之後，我們失去了每週二小時的 downtime時間，即意味着，我們沒有辦法每週對 primary database進行 cold backup了，但我們仍然保留了對 primary database每晚上的 full export和全部 data files的 hotback。所有的 archived log files仍然一週清理一次，並轉移到 backup tape上面，保留一年。每一年的 downtime我們仍在與客戶的協商之中。
在這種情形下，對 standby database進行 backup，就變的相對需要考慮，以彌補每週以來，primary database無法進行 cold backup的缺陷。
Standby database可以採用兩種情形進行 backup。一種是處於 shutdown狀態 (必須 shutdown normal/immediate) 。另一種是 standby database處於 read-only狀態。shutdown狀態，相當於 cold backup，缺點是，standby database shutdown以後，database不能處於 managed recovery狀態，有可能再 mount的時候，需要手動 recover primary/standby database的間距 archived log files。而 standby database處於read-only狀態時仍然可以使 database處於 managed recovery mode。
但這種 backup的恢復可能會麻煩一些。
考慮各種情況之後，我們的系統對 standby database每天晚上採用的是 shutdown immediate之後的 cold backup。
三、Opening/Activating a standby database
在通常的情形下，standby database是處於 recovery狀態的。但是在 opened read-only 或者 activeated 之後可以 access standby database 中的 data。
1. opening standby database read-only:
當 standby database 被 opened read-only 時，數據只能處於讀取狀態。
因爲 standby database被opened 成爲 read-only mode之後，還可以恢復成 recovery/managed recovery mode，所以 opening standby database read-only，可以用來試驗 standby database是否建立成功及 archived log files是否成功 applied到database 中。
在更多的情況下，read-only mode 是用於系統 run report。很多擁有很多用戶的系統，需要 on-line data access，同時需要 run report，爲了避免系統 overheat，單機狀態的時候，大的 reports 是在非尖峯期的晚上和週末運行的。如果系統有 standby database，可以 open standby database在 read-only情況下 run reports，不影響 primary database的性能。
需要注意的是，在 read-only狀態下面時，primary database的 archived log files仍然持續送達 standby database，但是不會 apply到 standby database中去。所以，在 run完 reports之後，要將 standby database 迴歸至 managed/manual recovery mode。
有關命令行如下：
如果 standby database處於shutdown狀態：
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 所處狀態的命令：
SQL> select status from v$instance;
STATUS
-------
MOUNTED
2. activating a standby database
當 primary database 由於某種原因不能正常工作，而修復時間超過用戶可以接受的範圍時，需要擊活 standby database，使之成爲 primary database 運行。這個行爲是單向的。被擊活的 standby database 是無法再回到 standby 狀態下的。下一個部份，我們講討論到 standby database 的重建問題。
完成擊活 standby database 使之成爲 primary database 的過程是需要 downtime 的。
過程如下：
(1) 首先要 shutdown primary database. 這種情況出現在 primary database 出了問題，不能正常工作，但 database 仍然處於 open 的狀態下，但是無法做 online recovery，或者 online recovery 所需要的條件，客戶不能接受(可能部份 data 無法訪問，所需時間視數據庫損壞程度而不同)。
這時，如果可能要儘量 archive current online log file:
SQL> alter system archive log current;
(2) 對應在 standby database node，activating 之前，要 apply 最後一個 archived log file。
如果 primary database 的錯誤導致 database down，系統丟失的 data 將會是 online log file 中的 data。同樣的，在 activating 之前，要 apply 最後一個 archived log file。
(3) 在 standby database 處於 mount 的狀態下 activate standby database:
SQL> alter database activate standby database;
(4) shutdown the standby database normal/immediate，之後做一次 cold backup。
在這裏需要解釋一下，當 standby database 被activated 之後成爲 primary database，這個過程將自動 resetlogs。因此，在 startup 之前要做一次 cold backup，因爲以往的 backup 最多隻能 recover 到 standby database 被activated 這一點。
另外，standby database 的 parameter file 中log_archive_start 是 false，系統不能自動 archive log file，在startup 之前要改爲 ture。
這樣即可以保證在 重建 primary database 之前的任何狀況發生，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的重建
當原 standby database 因爲 primary database的 failure而成爲 primary database 之後，一般在僅接下來的第一個非高峯工作時段，就要進行 standby database的重建。
怎樣對 Standby database進行重建，首先要考慮系統的設置，以及有多少的時間進行重建。
實例一：如果 primary/standby 兩個nodes都是爲該數據庫專用的，且設置相同的話，可以保留 standby node上面的數據庫做爲 primary database，在原來的 primary上面建立一個standby database就可以了。系統不需要 downtime。備份文件可以採用上一部份中，standby database變爲 primary database open 之前的冷備份，再手工 apply 從數據庫 open 到目前的所有 archived logs。
注意，這種情形下，要重新設置當前 primary database node的 tnsnames.ora文件，以及當前 standby node上面的 listener.ora文件。(詳細參見上面部份的 standby database的建立)
這種設置在 standby database系統中算是最理想的設置了，甚至在某些情形下面，可以 activing standby database，直接對 primary database進行 recovery，再在standby node上重建 standby database。具體的設置和操作，是要根據項目的要求設定的。
實例二：這種情況下，不管怎樣，原來的primary node 要變回 primary database的服務器， standby node上的database要回歸 standby database 的狀態。在這種情形下，如果你能得到足夠的系統 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的時間只比系統拷貝文件的時間多出 10分鐘而已。
在 standby node上面：在 database shutdown之後，拷貝文件去 primary node的過程中，要對整個 database進行一次冷備份。之後用原來備份的 standby database的 parameter file取代當前的 parameter file，再從已經 open的 primary database上面建立一個 standby database的 control file拷貝到 standby node上面取代當前的 control files。
如果此時，primary database 尚未生成新的 archived log files， standby database 可以直接進入 managed recovery mode。
這個實例是我本人比較喜歡採用的一種方法。現給出具體的操作步驟如下：
重建 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進行一個冷備份
4) 清除所有 archived log files (原來的 primary node上面的)
5) 拷貝除了 parameter file 之外的所有 data files/control files/online redo log files 到 primary node 原來 directory下面，覆蓋掉原來的文件。
6) 可以用原來已經存在的 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相同 (應該是相同的) 之後，就可以直接 Startup standby database:
Startup nomount pfile=’xxxxxxxxxxxxxxxxxxx’;
Alter database mount standby database;
4) Recover managed standby database timeout 15;
(因爲是在非工作繁忙期，所以，primary上面不會有很多 transactions，所以沒有產生新的 archived log file之前，可以直接進入 managed recover mode。如果已經產生了 archived log files，要先手工 recover。
實例三：在實例二的情況下，如果在 primary node 上面重建 primary database 的時間，用戶不允許有足夠多的系統down time，可以採用的方法就是，在 primary node 上面再建目前運行的 database 的standby database，建立好之後，可以在最短時間內，進行一個轉換。
在這種情況下，需要主意的問題是，在原來的 primary node 上面的 parameter file 要修改成爲 standby mode 的 parameter，同時 network file 也需要做相應的更改。 (standby database 改來改去的，最好每個版本的文件，如果 parameter file, tnsnames.ora, listener.ora 等文件，專門收集到一個地方，會受益非淺的。)
在這個實例下運行，在 activated 了在 primary node 上面的 standby database，shutdown 之後，還是要做一次 cold backup 的。因此需要的 system downtime，幾乎就是一次 cold backup 的時間。怎樣重建standby database 在原來的 standby node上面，請參照前面如何建立 standby database 部份所講的內容。