不可思议Oracle主从库恢复出乎意料之中（oracle主从恢复）

不可思议！Oracle主从库恢复出乎意料之中

在企业级应用系统中，数据库的可靠性和稳定性是非常重要的，所以主从复制模式被广泛使用来提高应用的可用性和可靠性。然而，即使在主从复制模式下，数据库也可能出现问题，从而使我们需要尝试进行恢复。但是，恢复过程可能会出现各种问题，让我们充满措手不及的感觉。

一次针对Oracle主从库进行的恢复任务，让我体验了这种感觉。最初，我们的主从数据库运行良好，直到在维护期间仅仅由于一个错误的操作，导致了主从数据库中的一些数据被误删除。当我们意识到这一点时，我们的第一反应是立即从备份恢复丢失的数据。然而，这个想法很快遭到了我们的否决，主要是由于时间和资源的限制，而且我们也不想扰乱现有的业务。

于是，我们选择了使用Oracle的日志传输来进行数据恢复。在进行恢复之前，我们需要对主数据库上的所有日志进行备份，并将从数据库装载到备份日志中。然后，我们运行一个ORACLE命令来启动增量日志传输，并确认日志传输正在正确地运行。虽然我们预期需要一些时间才能完成恢复，但是，实际的恢复速度出乎我们的意料之外。两个小时以前，我们已经完成了向备份日志中装载从数据库，并开始了日志传输。然而，在大约30分钟后，主数据库中的所有丢失数据已经恢复成功，而“传输到从数据库”的进程甚至还没有完成！

这个结果让我们感到非常意外，因为我们之前曾尝试过使用日志传输进行恢复，但是恢复速度非常慢。我们开始探究是什么原因导致了这个结果。我们仔细检查了系统配置，确认了没有配置问题。然后，我们查看了之前的恢复日志，发现我们在之前的尝试中，使用的是不同的网络。于是，我们把新的网络卡换成了更快的版本，并接通了相应端口，这样我们就更快地传输日志了。

这次恢复过程经验的收获是，当我们遇到恢复时，我们应该考虑到所有可能的变数，包括硬件配置、网络资源等，以确保我们在恢复过程中能够达到最佳的效果。同时，我们也意识到，Oracle的主从复制模式的可靠性和恢复性还有提高的空间。我们希望在将来的工作过程中，能够持续地学习和改进，提高我们的技术水平和经验，以便更好地应对这类问题。以下是恢复过程中我们使用的ORACLE命令：

1.在主数据库上，执行：

alter system log archive all;

2.将所有的归档日志复制到一个新的位置：

cp $ORACLE_HOME/rdbms/arc/* ${New_Log_Directory}

3.在备库上，装载此归档日志：

SQL>alter database recover automatic，start with '...', 'ARCH';

4.检查恢复情况：

SQL> select thread_id,sequence# from v$archived_log;
THREAD_ID  SEQUENCE#
--------- ----------
        1         N
        2         N

尽管Oracle主从复制模式的可靠性和恢复性是可靠的，但是我们还是要时刻注意配置和技术上的变数，以便通过最优的方式进行恢复。