备用数据库对 DBA 既不利又有利。好处是能够通过故障转移到备用数据库从主数据库故障中快速恢复，这实质上允许业务在发生不可想象的情况时“从他们中断的地方开始”。很多时候，祸根是错误的交易，这些交易会破坏主端的生产数据。
鉴于在大多数 Standby 或 Data Guard 安装中，Primary 和 Standby 之间的滞后期不超过切换日志所需的时间，这对于 DBA 响应以防止负责任的插入/更新/删除在备用站点上应用。
是的，这种情况可能很少发生，但并非不可能。如果客户使用备用数据库作为近实时报告数据库，情况就会变得更加复杂。DBA 可以做什么？让我们检查一下这个场景，看看 DBA 有哪些可能的选择。
待机是数据恢复的关键。
备用数据库，无论是否通过 Data Guard 进行管理，都是大多数灾难恢复配置中的关键组件。通过配置备用重做日志（版本 11 及更高版本）或重做传输（所有版本），所有流入或流出主数据库的数据都被系统地复制到一个或多个备用数据库。
让我们更详细地看一下最后一条语句。
当引入备用重做日志时，标准alter database recovery managed Standby database disconnect from session 的行为发生了变化；声明 Oracle 自动使用备用重做日志获取事务信息。
是的，旧的可靠归档重做日志仍然传输到备用。但它们并不是主要的信息来源。如果需要，可以通过修改“alter database”语句来使用存档的重做日志。只需添加“使用归档日志文件”指令，该选项就为设置重做应用进程的延迟打开了大门，以便在将问题事务应用到备用系统之前就可以捕获它们——避免问题。
重做日志应用延迟在 spfile 参数 log_archive_dest_N（N 是从 1 到 31 之间的数字，具体取决于 Oracle 版本）中配置，是的，您猜对了，DELAY 参数。此参数需要一个整数值，以分钟为单位。例如，位于堪萨斯城的备用数据库的可能配置是：
log_archive_dest_4='SERVICE=stbyKC, DELAY=1440' log_archive_dest_state_4=ENABLE
当归档日志文件是真实来源时，堪萨斯城的 4 号备用数据库现在将滞后主数据库 24 小时。延迟可以设置为任何分钟值，从 1 到您想要的任何值；如果延迟设置为 2880，则主服务器和备用服务器之间会有 2 天的延迟。是的，2880 分钟有点极端，但它不是参数的无效值。请记住，损坏的事务可能在白天或晚上的任何时间发生，因此我不止一次看到 DELAY 设置为 1440。
延迟待机恢复可以节省一天的时间。
以事务24/7 访问主数据库的情况为例。12 月 7 日（星期二）凌晨 3 点，由于来自 Klottsylvania（不是实际地点；我们在此处处理假设）的馈送损坏，生产数据变得无法使用。
该公司勇敢的 DBA（让我们将她命名为 Dana Alden）明智地设置了主服务器和备用服务器之间的 24 小时延迟。Dana 现在有时间研究何时应用事务，以便可以将当前待机恢复到数据损坏事务将被处理之前的时间。现在可以故障转移到备用数据库，因为我们的 DBA 阻止了导致主数据库无法使用的损坏。是的，角色颠倒了，但是一旦从新的主节点重新创建以前的主节点，它就变成了备用节点，并且损坏的数据不再是问题。
如果备用数据库作为 Active Data Guard 数据库运行，那么美中不足的问题就会变得很明显。通常，当备用数据库用作活动报告数据库时，会发现此类配置。很多时候，这种使用要求备用与主要保持同步：金融和投资行业就是很好的例子。
延迟会使报告基本上毫无用处。但是，不要绝望，即使是金融和投资行业也可以从使用延迟申请中受益。
这种配置可以在不用于报告的第二个或第三个备用数据库中找到。拥有多个可用的备用数据库可以提供至少一个事实来源，可以最大限度地减少或消除数据损坏，为企业提供一条不会危及报告的恢复路径，并且可以在发生灾难时恢复其他备用数据库。当前的报告很可能是从调度程序（在 Windows 上或通过 Unix/Linux 上的 cron）运行的，提供可以随意调用的脚本以根据需要重新生成报告：故障转移、重建剩余的备用数据库并重新运行问题报告. 由于旧的 Standby 现在是新的 Primary，包含可疑事务的归档日志不再有效，并且避免了意外应用它们的危险。
多个备用数据库可以有不同的延迟设置吗？
当然；上面的例子涉及两个备用，一个延迟 0 分钟，一个延迟 1440 分钟。让我们回到明智谨慎的 DBA Dana，看看她如何配置三个备用数据库以用于各种用途。
Dana 的雇主是一家股票经纪公司。它需要使用备用数据库向组织的各个部分提供数据。
- 经纪人需要当前数据来为客户生成投资报告
- 销售人员可以使用长达 24 小时的数据，因为他们正在构建历史绩效报告。
- 投资组合经理要求提供不超过两个小时的数据来跟踪期货。
Dana 在不同的物理位置——托皮卡、KS、里诺、内华达州和巴尔的摩，马里兰州——配置和构建三个备用服务器，以将它们彼此隔离并与主服务器（位于加利福尼亚州圣地亚哥）隔离。
- Standby #1 位于 Topeka，并且配置为没有任何延迟；这是给经纪人的。
- 备用#2 位于里诺，为投资组合经理配置了2 小时的延迟。
- 备用#3 在巴尔的摩，为销售团队配置了24 小时延迟。
现在，查看 Dana 实现的 log_archive_dest_N 参数，我们看到：
log_archive_dest_2='SERVICE=stbyone' log_archive_dest_state_2=enable log_archive_dest_3='SERVICE=stbytwo, DELAY=120' log_archive_dest_state_3=enable log_archive_dest_4='SERVICE=stbythree, DELAY=1440' log_archive_dest_state_4=enable
现在 Dana 已经设置了配置参数，可以启动各种 Standbys。Standby #1 使用 Standby 重做日志，因此可以使用以下命令启动它：
alter database recover managed Standby database disconnect from session;
备用#2 和#3 将需要使用存档日志而不是备用重做日志；Dana 修改她的启动命令：
alter database recover managed Standby database using archived logfile disconnect from session;
这允许 Oracle 使用配置的延迟来缓冲数据损坏事务或事务集应用于主数据库时的恢复。
请注意，在此配置中，主要和备用 #1 都将受到数据损坏输入的影响。让剩余的备用数据库使用不同的延迟设置可以加快数据恢复速度和缩短恢复时间（两小时的延迟备用数据库需要更少的重做来恢复到损坏发生之前，使恢复的主数据库在更短的时间内联机，从而开始备用数据库重建处理更快）。
当然，备用日志目标配置会改变，因为 Reno 的实例现在是新的主数据库；圣地亚哥现在将成为备用 #2。备用重新配置完成后，将需要将 Reno 用作备用的应用程序重新配置为使用 San Diego。这是一个需要几分钟才能完成的简单更改，因为 tnsnames.ora 文件只需要交换 San Diego 和 Reno 之间的连接信息。服务名称可以保持不变，因为没有使用位置名称来定义这些服务。
延迟待机恢复是否应该成为标准做法？
延迟备用恢复可能不是标准做法，但对于任务关键型数据库可能应该是。防止数据损坏在备用环境中蔓延的能力可以通过提供一种在短时间内从此类损坏中恢复的方法来节省业务时间和金钱。公司通过减少重新输入当前交易的重复工作量，快速可靠地回到正轨。
灾难恢复的关键部分不是灾难，而是恢复，过程越顺利，对企业越好。一些事先的思考和准备可以更好地为环境和 DBA 做好准备，以应对 DBA 希望永远不会发生的事情。童军的座右铭是“做好准备”。也许 DBA 也应该采用它。
