简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

通过日志传送实现Oracle数据库灾难恢复

10/14/2024 贡献者

PDF

Oracle数据库的复制过程与备份过程基本相同。主要要求是、必须将构成可恢复备份的快照复制到远程存储系统。

如前面有关本地数据保护的文档所述、可以使用热备份过程或利用针对快照优化的备份来创建可恢复的备份。

最重要的要求是将数据文件隔离到一个或多个专用卷中。它们必须未受任何其他文件类型的污染。其原因是、要确保数据文件复制完全独立于其他数据类型(如归档日志)的复制。有关文件布局的其他信息以及有关确保存储布局便于快照的重要详细信息，请参见"数据布局"。

假设数据文件封装在专用卷中、下一个问题是如何管理重做日志、归档日志和控制文件。最简单的方法是将所有这些数据类型放在一个卷中。这样做的好处是、复制的重做日志、归档日志和控制文件可以实现完美同步。不要求恢复不完整或使用备份控制文件、但对于其他可能的恢复场景、可能还需要使用脚本创建备份控制文件。

双卷布局

下图显示了最简单的布局。

错误：缺少图形映像

这是最常见的方法。从数据库管理角度来看、将重做日志和归档日志的所有副本放在同一个卷上似乎并不常见。但是、如果文件和LUN仍都位于同一个底层驱动器集上、则隔离不会提供太多额外保护。

三卷布局

有时、由于数据保护问题或需要在控制器之间分布重做日志I/O、需要分离重做日志。如果是、则下图所示的三卷布局将用于复制、同时仍然避免执行不完整的恢复或依赖备份控制文件的任何要求。

错误：缺少图形映像

这样、可以在源上的一组独立磁盘轴和控制器之间对重做日志和控制文件进行条带化。但是、归档日志以及一组控制文件和重做日志仍可与归档日志同步进行复制。

在此模型中、不会复制重做日志B卷。

灾难恢复过程—热备份

要使用热备份执行灾难恢复、请使用以下基本操作步骤：

前提条件

Oracle二进制文件安装在灾难恢复服务器上。
中列出了数据库实例 /etc/oratab。
。 passwd 和 pfile 或 spfile 实例必须位于中 $ORACLE_HOME/dbs 目录。。

灾难恢复

中断数据文件和通用日志卷的镜像。
将数据文件卷还原到数据文件的最新热备份快照。
如果使用SAN、请激活卷组和/或挂载文件系统。
将归档日志重放至所需位置。
如果需要完全恢复、则重放当前重做日志。

使用NFS可以显著简化操作步骤、因为数据文件和日志文件的NFS文件系统可以随时挂载到灾难恢复服务器上。镜像中断后、它将变为读/写状态。

灾难恢复过程—针对快照优化的备份

从快照优化的备份中恢复与热备份恢复操作步骤几乎相同、但进行了以下更改：

中断数据文件和通用日志卷的镜像。
将数据文件卷还原到当前日志卷副本之前创建的快照。
如果使用SAN、请激活卷组和/或挂载文件系统。
将归档日志重放至所需位置。
如果需要完全恢复、则重放当前重做日志。

这些差异简化了整体恢复操作步骤、因为无需确保在数据库处于热备份模式时在源上正确创建快照。灾难恢复操作步骤基于灾难恢复站点上快照的时间戳。创建快照时数据库的状态并不重要。

使用热备份快照进行灾难恢复

这是一个基于热备份快照复制的灾难恢复策略示例。它还可以作为简单且可扩展的本地备份策略的示例。

示例数据库位于基本的双卷架构上。 /oradata 包含数据文件和 /oralogs 用于合并的重做日志、归档日志和控制文件。

[root@host1 ~]# ls /ora*
/oradata:
dbf
/oralogs:
arch  ctrl  redo

需要两个计划、一个用于每晚数据文件备份、另一个用于日志文件备份。分别称为午夜和15分钟。

Cluster01::> job schedule cron show -name midnight|15minutes
Name                Description
----------------    -----------------------------------------------------
15minutes           @:00,:15,:30,:45
midnight            @0:00
2 entries were displayed.

然后、在快照策略中使用这些计划 NTAP-datafile-backups 和 NTAP-log-backups，如下所示：

Cluster01::> snapshot policy show -vserver vserver1 -policy NTAP-* -fields schedules,counts
vserver   policy                schedules                    counts
--------- --------------------- ---------------------------- ------
vserver1  NTAP-datafile-backups midnight                     60
vserver1  NTAP-log-backups      15minutes                    72
2 entries were displayed.

最后、这些快照策略将应用于卷。

Cluster01::> volume show -vserver vserver1 -volume vol_oracle* -fields snapshot-policy
vserver   volume                 snapshot-policy
--------- ---------------------- ---------------------
vserver1  vol_oracle_datafiles   NTAP-datafile-backups
vserver1  vol_oracle_logs        NTAP-log-backups

此选项用于定义卷的备份计划。数据文件快照在午夜创建并保留60天。日志卷包含72个以15分钟为间隔创建的快照、这些快照的覆盖时间最长可达18小时。

然后、确保在创建数据文件快照时数据库处于热备份模式。这可通过一个小脚本来完成、该脚本接受一些基本参数、用于在指定SID上启动和停止备份模式。

58 * * * * /snapomatic/current/smatic.db.ctrl --sid NTAP --startbackup
02 * * * * /snapomatic/current/smatic.db.ctrl --sid NTAP --stopbackup

此步骤可确保数据库在围绕午夜快照的四分钟窗口内处于热备份模式。

复制到灾难恢复站点的配置如下：

Cluster01::> snapmirror show -destination-path drvserver1:dr_oracle* -fields source-path,destination-path,schedule
source-path                      destination-path                   schedule
-------------------------------- ---------------------------------- --------
vserver1:vol_oracle_datafiles    drvserver1:dr_oracle_datafiles     6hours
vserver1:vol_oracle_logs         drvserver1:dr_oracle_logs          15minutes
2 entries were displayed.

日志卷目标每15分钟更新一次。这样可实现大约15分钟的RPO。根据更新期间必须传输的总数据量、确切的更新间隔略有不同。

数据文件卷目标每六小时更新一次。这不会影响RPO或RTO。如果需要进行灾难恢复、首先要做的一个步骤是将数据文件卷还原回热备份快照。更新间隔更频繁的目的是使此卷的传输速率保持平稳。如果计划每天更新一次、则必须立即传输当天累积的所有更改。更新频率越高、所做的更改就会在一天中逐渐复制。

如果发生灾难、第一步是中断两个卷的镜像：

Cluster01::> snapmirror break -destination-path drvserver1:dr_oracle_datafiles -force
Operation succeeded: snapmirror break for destination "drvserver1:dr_oracle_datafiles".
Cluster01::> snapmirror break -destination-path drvserver1:dr_oracle_logs -force
Operation succeeded: snapmirror break for destination "drvserver1:dr_oracle_logs".
Cluster01::>

副本现在为读写副本。下一步是验证日志卷的时间戳。

Cluster01::> snapmirror show -destination-path drvserver1:dr_oracle_logs -field newest-snapshot-timestamp
source-path                destination-path             newest-snapshot-timestamp
-------------------------- ---------------------------- -------------------------
vserver1:vol_oracle_logs   drvserver1:dr_oracle_logs    03/14 13:30:00

日志卷的最新副本是3月14日13：30：00。

接下来、确定在日志卷的状态之前创建的热备份快照。这是必需的、因为日志重放过程需要在热备份模式下创建所有归档日志。因此、日志卷副本必须早于热备份映像、否则不会包含所需的日志。

Cluster01::> snapshot list -vserver drvserver1 -volume dr_oracle_datafiles -fields create-time -snapshot midnight*
vserver   volume                    snapshot                   create-time
--------- ------------------------  -------------------------- ------------------------
drvserver1 dr_oracle_datafiles      midnight.2017-01-14_0000   Sat Jan 14 00:00:00 2017
drvserver1 dr_oracle_datafiles      midnight.2017-01-15_0000   Sun Jan 15 00:00:00 2017
...

drvserver1 dr_oracle_datafiles      midnight.2017-03-12_0000   Sun Mar 12 00:00:00 2017
drvserver1 dr_oracle_datafiles      midnight.2017-03-13_0000   Mon Mar 13 00:00:00 2017
drvserver1 dr_oracle_datafiles      midnight.2017-03-14_0000   Tue Mar 14 00:00:00 2017
60 entries were displayed.
Cluster01::>

最近创建的快照为 midnight.2017-03-14_0000。这是数据文件的最新热备份映像、然后按如下所示进行还原：

Cluster01::> snapshot restore -vserver drvserver1 -volume dr_oracle_datafiles -snapshot midnight.2017-03-14_0000
Cluster01::>

在此阶段、数据库现已准备好进行恢复。如果是SAN环境、下一步将包括激活卷组和挂载文件系统、这是一个轻松自动化的过程。由于此示例使用的是NFS、因此文件系统已挂载并变为读写状态、在镜像中断后不再需要挂载或激活。

现在、可以将数据库恢复到所需的时间点、也可以根据所复制的重做日志副本将其完全恢复。此示例说明了归档日志、控制文件和重做日志卷的组合值。恢复过程显著简化、因为无需依赖备份控制文件或重置日志文件。

[oracle@drhost1 ~]$ sqlplus / as sysdba
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1610612736 bytes
Fixed Size                  2924928 bytes
Variable Size            1090522752 bytes
Database Buffers          503316480 bytes
Redo Buffers               13848576 bytes
Database mounted.
SQL> recover database until cancel;
ORA-00279: change 1291884 generated at 03/14/2017 12:58:01 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_34_938169986.dbf
ORA-00280: change 1291884 for thread 1 is in sequence #34
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 1296077 generated at 03/14/2017 15:00:44 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_35_938169986.dbf
ORA-00280: change 1296077 for thread 1 is in sequence #35
ORA-00278: log file '/oralogs_nfs/arch/1_34_938169986.dbf' no longer needed for
this recovery
...
ORA-00279: change 1301407 generated at 03/14/2017 15:01:04 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_40_938169986.dbf
ORA-00280: change 1301407 for thread 1 is in sequence #40
ORA-00278: log file '/oralogs_nfs/arch/1_39_938169986.dbf' no longer needed for
this recovery
ORA-00279: change 1301418 generated at 03/14/2017 15:01:19 needed for thread 1
ORA-00289: suggestion : /oralogs_nfs/arch/1_41_938169986.dbf
ORA-00280: change 1301418 for thread 1 is in sequence #41
ORA-00278: log file '/oralogs_nfs/arch/1_40_938169986.dbf' no longer needed for
this recovery
ORA-00308: cannot open archived log '/oralogs_nfs/arch/1_41_938169986.dbf'
ORA-17503: ksfdopn:4 Failed to open file /oralogs_nfs/arch/1_41_938169986.dbf
ORA-17500: ODM err:File does not exist
SQL> recover database;
Media recovery complete.
SQL> alter database open;
Database altered.
SQL>

使用针对快照优化的备份进行灾难恢复

使用针对快照优化的备份的灾难恢复操作步骤与热备份灾难恢复操作步骤几乎相同。与热备份快照操作步骤一样、它也是本地备份架构的基本扩展、在该架构中、备份会进行复制以用于灾难恢复。以下示例显示了详细的配置和恢复操作步骤。此示例还说明了热备份与针对快照优化的备份之间的主要差异。

示例数据库位于基本的双卷架构上。 /oradata 包含数据文件、和 /oralogs 用于合并的重做日志、归档日志和控制文件。

 [root@host2 ~]# ls /ora*
/oradata:
dbf
/oralogs:
arch  ctrl  redo

需要两个计划：一个用于每晚数据文件备份、一个用于日志文件备份。分别称为午夜和15分钟。

Cluster01::> job schedule cron show -name midnight|15minutes
Name                Description
----------------    -----------------------------------------------------
15minutes           @:00,:15,:30,:45
midnight            @0:00
2 entries were displayed.

然后、在快照策略中使用这些计划 NTAP-datafile-backups 和 NTAP-log-backups，如下所示：

Cluster01::> snapshot policy show -vserver vserver2  -policy NTAP-* -fields schedules,counts
vserver   policy                schedules                    counts
--------- --------------------- ---------------------------- ------
vserver2  NTAP-datafile-backups midnight                     60
vserver2  NTAP-log-backups      15minutes                    72
2 entries were displayed.

最后、这些快照策略将应用于卷。

Cluster01::> volume show -vserver vserver2  -volume vol_oracle* -fields snapshot-policy
vserver   volume                 snapshot-policy
--------- ---------------------- ---------------------
vserver2  vol_oracle_datafiles   NTAP-datafile-backups
vserver2  vol_oracle_logs        NTAP-log-backups

此选项用于控制卷的最终备份计划。快照在午夜创建并保留60天。日志卷包含72个以15分钟为间隔创建的快照、这些快照的覆盖时间最长可达18小时。

复制到灾难恢复站点的配置如下：

Cluster01::> snapmirror show -destination-path drvserver2:dr_oracle* -fields source-path,destination-path,schedule
source-path                      destination-path                   schedule
-------------------------------- ---------------------------------- --------
vserver2:vol_oracle_datafiles    drvserver2:dr_oracle_datafiles     6hours
vserver2:vol_oracle_logs         drvserver2:dr_oracle_logs          15minutes
2 entries were displayed.

日志卷目标每15分钟更新一次。这样可以实现大约15分钟的RPO、精确更新间隔略有不同、具体取决于更新期间必须传输的总数据量。

数据文件卷目标每6小时更新一次。这不会影响RPO或RTO。如果需要灾难恢复、则必须先将数据文件卷还原回热备份快照。更新间隔更频繁的目的是使此卷的传输速率保持平稳。如果计划每天更新一次、则必须立即传输当天累积的所有更改。更新频率越高、所做的更改就会在一天中逐渐复制。

如果发生灾难、第一步是中断所有卷的镜像：

Cluster01::> snapmirror break -destination-path drvserver2:dr_oracle_datafiles -force
Operation succeeded: snapmirror break for destination "drvserver2:dr_oracle_datafiles".
Cluster01::> snapmirror break -destination-path drvserver2:dr_oracle_logs -force
Operation succeeded: snapmirror break for destination "drvserver2:dr_oracle_logs".
Cluster01::>

副本现在为读写副本。下一步是验证日志卷的时间戳。

Cluster01::> snapmirror show -destination-path drvserver2:dr_oracle_logs -field newest-snapshot-timestamp
source-path                destination-path             newest-snapshot-timestamp
-------------------------- ---------------------------- -------------------------
vserver2:vol_oracle_logs   drvserver2:dr_oracle_logs    03/14 13:30:00

日志卷的最新副本是3月14日13：30。接下来、确定在日志卷状态之前创建的数据文件快照。这是必需的、因为日志重放过程需要从快照之前到所需恢复点的所有归档日志。

Cluster01::> snapshot list -vserver drvserver2 -volume dr_oracle_datafiles -fields create-time -snapshot midnight*
vserver   volume                    snapshot                   create-time
--------- ------------------------  -------------------------- ------------------------
drvserver2 dr_oracle_datafiles      midnight.2017-01-14_0000   Sat Jan 14 00:00:00 2017
drvserver2 dr_oracle_datafiles      midnight.2017-01-15_0000   Sun Jan 15 00:00:00 2017
...

drvserver2 dr_oracle_datafiles      midnight.2017-03-12_0000   Sun Mar 12 00:00:00 2017
drvserver2 dr_oracle_datafiles      midnight.2017-03-13_0000   Mon Mar 13 00:00:00 2017
drvserver2 dr_oracle_datafiles      midnight.2017-03-14_0000   Tue Mar 14 00:00:00 2017
60 entries were displayed.
Cluster01::>

最近创建的快照为 midnight.2017-03-14_0000。还原此快照。

Cluster01::> snapshot restore -vserver drvserver2 -volume dr_oracle_datafiles -snapshot midnight.2017-03-14_0000
Cluster01::>

数据库现在可以恢复了。如果是SAN环境、则可以激活卷组并挂载文件系统、这是一个轻松自动化的过程。但是、此示例使用的是NFS、因此文件系统已挂载并变为读写状态、不再需要在镜像中断后挂载或激活。

现在、可以将数据库恢复到所需的时间点、也可以根据所复制的重做日志副本将其完全恢复。此示例说明了归档日志、控制文件和重做日志卷的组合值。恢复过程显著简化、因为不需要依赖备份控制文件或重置日志文件。

[oracle@drhost2 ~]$ sqlplus / as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Wed Mar 15 12:26:51 2017
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to an idle instance.
SQL> startup mount;
ORACLE instance started.
Total System Global Area 1610612736 bytes
Fixed Size                  2924928 bytes
Variable Size            1073745536 bytes
Database Buffers          520093696 bytes
Redo Buffers               13848576 bytes
Database mounted.
SQL> recover automatic;
Media recovery complete.
SQL> alter database open;
Database altered.
SQL>