在数据库环境中，一主一备是比较传统的使用方式，在灾难发生的时候，可以灵活的切换主备角色，依然可以保持服务的可访问性。但是一些核心系统来说还是会有更多的过滤，一主一备似乎还是不够稳妥，如果主备出现问题，如果有另外一个备库还是有可选的余地，这种情况不是不可能发生，正是因为核心业务的需要还是需要保证数据的安全。
很多场景下，一主两备会保持这样的场景，一主一备在同一个区域内，这样在出现问题的时候方便切换，如果区域出现故障，可以保证异地的机房可以顺利承接服务。
比如下面的这种方式是比较传统的一主一备的方式。因为是在10g的环境中，所以备库还是Mount，不能open在线接收数据变更。

在这种结构下，如果根据需要去添加另外一个备库节点，就需要考虑到一些负载的因素。毕竟我们不希望主库有很多的数据文件复制工作，尽管duplicate特性还是比较方便的。
这个时候我们可以只动用备库导出响应的备份数据来。如果这个时候主库出现问题，可以随时终止rman备份，直接切换环境。

当然利用备库导出rman dump，在另外一个备库来做恢复，如果文件路径等等存在偏差，或者限于dump的大小和磁盘空间，可能会把dump放在不同的路径下，就可以直接设定catalog来恢复。
大体的四个步骤如下面的蓝色方框所示。这个时候主库和备库之间还是没有任何的直接关联，所以从这个地方，也把主库的负载降到了最低。

数据库恢复之后，这就是一个新的备库，我们可以通过dg broker来建立和主库的关联关系。这个时候回在三个节点间进行一些配置信息的同步，过程还是比较快的。

就这样，一主两备的环境就搭建好了。
其实我们还可以这么思考，把switchover的场景和failover都结合起来，如果在switchover出现失败的情况下，我们可以动用第二个备库来做failover.
怎么理解呢，switchover在一些外部因素的作用下还是可能会失败，比如在10g版本中，我们把备库启动到了read only状态，结果数据变更都会延迟，如果延迟够大，rman配置可能会把一些历史的归档给删除掉，尽管RFS把归档传到了备库，但是MRP还没有开始工作，所以备库中的归档还没有使用到。这个时候主库奔溃，那个read only的备库做switchover就很可能失败。
这个时候我们还是保证另外一个备库在mount状态，我们可以直接做failover