学步园

当chao_ping提议我开一个STANDBY DATABASE技术专题讨论的时候，我本来是想专门就STANDBY DATABASE的技术方面进行讨论的。看罢三十余篇的跟贴，实在感到有必要在深入技术问题之前，先说一些题外的话，虽然这些是与技术无关的话题，但对于从业IT界的打工者来说，却是一个首先应该考虑的问题。

我们是做技术的人员，意思就是说，在企业的管理上，我们最多能做的，我们所说的，对管理者来说，只能是参考的意见，决策并不在于我们。很多IT的技术员，特别是很多初出茅庐的年轻朋友，都觉得，技术人员是一个企业中，最重要的。如果我的技术好，天下就是我的了。这里面有很多的误区。打个比方来说，技术人员对公司将用什么服务器，用什么database server做后台，有多少控制的能力呢？现在有很多公司把oracle数据平台，定在IBM的AIX UNIX 服务器，这是一个有道理的选择吗？在众多UNIX 平台上面，众所周知是，AIX并不是Oracle首选推荐的操作系统，Oracle在AIX平台上的许多bugs，这两个公司相互推诿，用户根本不能及时得到patch解决存在的问题，但是公司的决策如此，做技术的人员能决定多少，公司管理阶层也许有他们的道理，譬如说，公司层决定所有服务器象某一个公司购买，可以得到更大的折扣，减少技术上面打交到的支持厂商，等等，我们只能接受公司的选择。在这一点上，我们与公司其他的职员没有什么两样的，如果抱着“惟我独尊”的思想，首先在人际上就得不到赞同。

提到了人际关系，许多人会讲，中国的人际关系很复杂，国外也许好多了。实际上呢，全世界那里都是一样，在中国处理不好，出了国也一样处理不好。我们都有在看论坛的帖子，有人贴出来，也有人反弹，诸如低手不宜，或讽刺别人的程序不好等等，我不想用古人曰，三人行，必有我师之类来论证一番，从最低之处感念，你有问题，有人愿意帮助你，无论帮上了或没帮上你，都应心存感激之心，不是吗。

回归到STANDBY DATABASE的讨论上，许多帖子提到是否应该选用STANDBY DATABASE的问题。其实，这个问题，也并不仅仅是一个技术上面的问题。这就是我上面说了一堆题外话的原因。

当某一个DATEBASE需要特别的功能的时候，譬如HIGH AVAILABLE，DISASTER RECOVERY，SCALABILITY等等，做为技术人员，我们首先要做的是，看看市面相关的产品中，那样能提供我们所要的功能，各类产品，各有千秋。在我们所需要的功能，那个最能满足要求，不要第一个念头就问别人，没有人比你自己更了解你需要什么。做了研究之后，不确定的话，可以请向资深的人咨询一下，不过基本观点就是，别人的提议只是你的参考，我还要说，因为没有人比你自己更了解你需要什么。

技术人员确实要从技术上了解那个产品最适合技术要求，但这并不能保证最后选用的产品是最适合技术要求的产品，最后的选择，与很多方面的条件有关。举个例子来说，我有一个DATABASE需要HIGH AVAILABLE, SCALABILITY，这样子看下来OPS是最适合的，可是接下来的问题是，OPS需要额外的LICENSING FEE，我们目前有的硬件不能支持OPS，需要订购新的，订购新设备的到达之前，DATABASE就必须进入生产模式。再复杂一点呢，我们技术部门的老板要用OPS，可是项目管理部门的老板要用STANDBY DATABASE，因为现有硬件支持，又不需要购买额外软件，他们两个一个管技术，一个管钱，两个人都懂一些Oracle技术，又都不是专家。凭良心讲OPS和STANDBY都能应付目前的需求，长远来讲OPS好一些，毕竟用的是client/server式的前台软件，用户以后也许有增加的趋势。不过这些内容也超过了技术人员的职责范围，我只管按照最后的决定做就是了。因为我没有最后选择和决定的权利。

最后我希望能谈一下IT从业人员的职业道德问题。做为某一领域的专家，也许很多时候会被请教与专业相关的问题。有项目会请你推荐运行平台或后台选用那个公司的DATABASE支持。虽然很多新技术很具吸引力，但IT的技术人员不能因为自己想学，想用某一产品，而推荐并不适合该项目的产品。

1. Oracle 与 High Availability, Disaster Recovery 及 Data Duplicate 相关功能的产品概述

Oracle 的 High Availability 功能，Oracle 是从下面几个方面来诠释的：

(1) system faults and crashes
(2) application and middleware failures
(3) network failures
(4) media failures
(5) Human Error
(6) Disasters and extended outages
(7) Planned downtime, maintenance and management tasks

上述第六项就包含了disaster recovery 在内。因此 disaster recovery 应该算做 high availability 的一个方面了。

总的来说，除了以Oracle database 本身参数进行性能调解外，Oracle 提供支持high availability 相关产品主要有下面几种：

(1) Oracle Fail Safe on NT
(2) Oracle Parallel Server
(3) Oracle Parallel Fail Safe
(4) Oracle Advanced Quening
(5) Oralce Advanced Replication
(6) Oracle Standby Database

在Duplication data 方面主要有用于distribited data 功能的Advanced Replication 和我们讨论过 standby database。

从参与讨论的帖子来看，相关的问题是集中在OPS，standby database 和 Advanced Replication 的选择，因此我就先将这三种产品做一下比较。

OPS (Oracle Parallel Sever)

OPS 最原始的设计初衷就是system/application high availability。与其他产品相比较：
OPS 是多个单CUP机或SMP(Symmetric Multi-Processing system) 的cluster (MPP Massively Parallel Processing) 。cluster 里面不同的 node 使用一个(一般是一个)或多个oracle instances 与一个database 连接。

主要的技术特点：
(1) database 所有的data files 是建立在 raw devices 上面的，因此在技术方面对OS 的设置有很高的依赖性，很多方面取决于OS的对设置是否支持。
(2) 在database 方面，每个node都有自己单独的 on-line redo log file groups，因此在做backup 和recovery 的时候，需要特殊的处理。
(3) OPS 的data files 方面并没有redundance，因此 media failure 方面，要依靠RAID (redundant array of inexpensive disk) subsystem.
Oracle 从8i 开始在OPS的基础上，逐步在不同的OS平台上，增加了Fail Safe/Failover 的功能，这里不尽详细描述。

Advanced Replication

Replication 的设计初是分散异地的application access database locally。这种技术可以将一个database 中的Tables，Indexes，Views，Packages and Package Bodies，Procedures and Functions，Triggers，Sequences，Synonyms复制到另一database中。如果是全部database 的复制，也可用于high availability。

一个范例，yahoo在美国的东岸和西岸，各有一个镜像database，是采用的 replication 的技术。东西两岸的用户是连到最近的database，从而提高访问的速度。如果一个database出了问题，用户自动转入与另一个相连，实现网站的high availability。这种high availability 对用户来说，是透明的。

其他的范例，在公司中的应用，例如，HR database中雇员资料，在accounting database 中需要除去薪资等的其他资料，可以在HR中建立一个view，以replication 技术复制到 accounting database 中。
因为大多 replicas 都是在异地，从而在异地建立了redundance data。Replication 是对于database 来说的 high availability。

2. standby database 的工作原理

写了这么多，现在才开始真正要讨论的题目。

从设计原理上来讲，standby database 是为 primary database 建立的备份，因此具有 redundance data，也是相对于 database 来说的 high availability。

standby database 为 primary database 做的备份，是通过 primary database 不断产生出的archived log files 来实现的。primary database 处于 archive mode 的状态，持续送出 archived log files 给 standby database，而 standby database 则处于 recovery mode，持续apply primary database 的 archived log files.

为了完成上述过程，必须具备以下的条件：

(1) 如果primary database 和 standby database 是运行在不同的服务器上面，那么这两台服务器必须有相同version 和 release 的操作系统；必须有相同 version, release 和 patch 的 oracle RDBMS 系统。
(2) Oracle 是允许 primary 和 standby database 在同一个服务器上面运行的。如果是这种情形，建议这两个databases 要分布在不同的physical disk drives 上面。并且不是所有的操作系统都支持mount 两个instances 连接两个同名的databases。
(3) Primary database 必需处于archive log mode。
(4) Oracle 从 version 7.3才开始支持 standby database。7.3.x – 8.0.x 需要手工copy 所有的archived log files 从 primary server 到 standby server，并且，需要手工 recovery archived log files (当然这些可以通过 OS shell scripts, sql scripts 等等方法来实现) ；并且standby database 只能够处于close/nomount/mount 的状态。
(5) Oracle 从version 8i (8.1.5以后) 开始支持 primary database 可以将 arhived log files 自动送到最多一个remote site (一般即standby database server) ，本地则可多达七个地点。并且，standby database 在mount 的状态下，增加了 managed recovery mode，在这种状态下，standby database 可以自动立即apply 由 primary node 送过来的 archived log files。
(6) Oracle 从version 8i (8.1.5以后) 开始支持standby database的mount recovery mode和database read only mode的转换。这样方便了系统可以利用standby database产生reports，而不影响用户正常使用 primary database。
(7) 一旦 standby database被activated，即成为primary database，无法再回归 standby database mode。因此primary database出了问题，standby database被actived成为primary database之后，如果需要在原来的 primary/standby node上面重建 primary/standby database，两个database都需要重建。
(8) 关于启动standby database时与 primary database之间的数据丢失问题。如果primary database在出问题之前如果无法完成 log file switch的话，两个database之间会相差 current on-line redo log file中的数据。oracle9i中的 data guard弥补了这一缺陷。oracle8i只有solaris平台支持 data guard。

注意：第(5) (6) 两项只有oralce 8i EE(Enterprise Edition)版本支持。SE (Standard Edition) 不支持这两项功能。

不同于OPS和Advanced Replication，使用standby database的时候，无论在actived standby database时，或在primary node上面重建 primary database的时候，系统都需要down time。所需时间长短，与系统状态有关。如果可以在primary mode建立standby database (如果两个server的硬件设置一样，一般standby node要差一些，节约费用) ，可以减少downtime。

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所处于的状态。在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是处于 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

当原 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 等文件，专门收集到一个地方，会受益非浅的。)

从去年的十二月十八日开始写 standby database 的技术总结，到今天完成后记，历时两年，可谓长矣。

對于本篇的內容，白雪力求完成一份概括全部讨论问题的技术总结，希望从来没有使用的 standby database 的朋友，有一个基本的概念；希望对要实施 standby database 的朋友，有一个基本的技术指导。希望该篇技术总结能够达到白雪的初衷，对论坛的各位朋友有所帮助。

日精月华，斗转星移。回想每每遇到困难，得到了论坛上朋友们多方鼓励和支持，是很多年来未曾有過的﹐白雪非常的感動。在此﹐向這些朋友致以衷心的敬意和感谢。

同时亦非常感谢当初参加讨论的所有朋友，特别是提供资料的朋友：blossom(ak66), allanliao, 半瓶醋(it is a good name. ), guan_yi 等。

日后在精力和时间都允许的情形下，白雪愿意继续推出大家感兴趣的技术专题。如果您有问题，请贴在论坛上，或留悄悄话给我，欢迎大家参与。

最后，对支持白雪的朋友再次的感谢。

参考文献：
1. Oracle 8i 随机文档：Oracle8i Standby Database Concepts and Administration
http://otn.oracle.com/docs/products.../a76995/toc.htm