四、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，建立好之后，可以在最短时间
