ORACLE 备份与恢复


1 ORACLE 交流第一群:48949977 ORACLE 备份与恢复 [群共享读物第五期] 3435626 不靠谱 2009-11-10 编者不靠谱按:天堂向左,DBA 往右,没啥说的,玩命学吧~~ 2 目录 第 1 章 归档设置 ............................................................................................................................. 1 1.1 归档的作用 ...................................................................................................................... 2 1.2 归档模式设置与取消 ...................................................................................................... 4 1.2.1 确定数据库当前状态 ........................................................................................... 4 1.2.2 更改归档模式 ....................................................................................................... 5 1.2.3 设置归档目的地 ................................................................................................... 8 1.2.4 归档目的地的 mandatory 与 Optional ................................................................. 8 1.2.5 手动归档与自动归档 ........................................................................................... 9 1.3 归档模式详细介绍 ........................................................................................................ 10 1.3.1 指定多个归档进程 ............................................................................................. 10 1.3.2 自动归档的管理 ................................................................................................. 11 1.3.3 手动归档 ............................................................................................................. 12 1.3.4 控制归档到目标 ................................................................................................. 13 1.3.5 指定归档文件格式 ............................................................................................. 13 1.4 归档相关视图 ................................................................................................................ 14 1.4.1 v$archived_log 视图 ........................................................................................... 14 1.4.2 V$ARCHIVE_DEST 视图 ................................................................................. 15 1.4.3 v$log_history 视图.............................................................................................. 17 1.4.4 V$DATABASE 视图 .......................................................................................... 17 1.4.5 V$ARCHIVE_PROCESSES 视图 ..................................................................... 19 第 2 章 Oracle 备份与恢复原理 .................................................................................................. 20 2.1 数据库备份、还原和恢复的基本原理 ........................................................................ 21 2.1.1 为什么需要恢复 ................................................................................................. 22 2.1.2 检查点与 CKPT 进程 ......................................................................................... 22 2.1.3 LGWR 进程 ........................................................................................................ 23 2.1.4 日志缓存 ............................................................................................................. 24 2.1.5 联机重做日志文件 ............................................................................................. 25 2.2 Oracle 环境中可能发生的故障类型 ........................................................................... 26 2.2.1 语句故障 ............................................................................................................. 26 2.2.2 用户进程故障 ..................................................................................................... 27 2.2.3 用户错误 ............................................................................................................. 27 2.2.4 数据库崩溃与实例恢复 ..................................................................................... 28 SQL> STARTUP ............................................................................................................................. 28 2.2.5 介质故障与介质恢复 ......................................................................................... 29 2.3 备份和恢复策略 ..................................................................................................... 29 2.3.1 为什么要制定备份恢复策略 ............................................................................. 30 2.3.2 必须考虑的因素 ................................................................................................. 30 2.3.3 优化例程恢复的方法 ......................................................................................... 32 2.4 备份和恢复分类简介 ............................................................................................. 33 第 3 章 用户管理的备份 ............................................................................................................... 33 3.1 相关术语 ........................................................................................................................ 34 3.2 什么是用户管理的备份恢复 ........................................................................................ 35 3 3.3 冷备份 ............................................................................................................................ 37 3.4 热备份 ............................................................................................................................ 38 3.4.1 联机表空间备份 ................................................................................................. 39 3.4.2 只读表空间备份 ................................................................................................. 41 3.4.3 备份控制文件和初始化参数 ............................................................................. 42 3.4.4 在联机备份失败后执行清除 ............................................................................. 43 3.5 使用 DBVERIFY 实用程序检测损坏块 ..................................................................... 44 第 4 章 用户管理的恢复 ............................................................................................................... 46 4.1 用户管理的完全恢复 .................................................................................................... 47 4.1.1 介质恢复 ........................................................................................................... 48 4.1.2 ARCHIVELOG 和 NOARCHIVELOG 比较 ................................................................ 48 4.1.3 在 NOARCHIVELOG 模式下执行恢复 ................................................................ 48 4.1.4 在 ARCHIVELOG 模式下执行完全恢复 ............................................................ 50 4.1.5 完全恢复关闭的数据库 ................................................................................... 53 4.1.6 恢复打开的数据库(数据库最初是打开的) ............................................... 54 4.1.7 恢复打开的数据库(数据库最初是关闭的) ............................................... 56 4.1.8 在没有备份的情况下恢复数据文件 ............................................................... 58 4.1.9 只读表空间恢复 ............................................................................................... 60 4.1.10 丢失控制文件的恢复 ..................................................................................... 61 4.2 用户管理的不完全恢复 ................................................................................................ 62 4.2.1 不完全恢复的步骤 ........................................................................................... 64 4.2.2 执行不完全数据库恢复 ................................................................................... 65 4.2.3 当前联机重做日志文件的丢失的恢复 ........................................................... 69 第 5 章 RMAN 简介与配置 .............................................................................................................. 71 5.1 RMAN 备份恢复简介 ................................................................................................... 71 5.1.1 RMAN 功能简介 ................................................................................................ 72 5.1.2 RMAN 的常用组件 ............................................................................................ 72 5.2 RMAN 配置 ................................................................................................................... 74 5.2.1 RMAN 恢复目录和控制文件的用法 ................................................................ 74 5.2.2 通道分配 ............................................................................................................. 74 5.2.3 介质管理 ............................................................................................................. 76 5.2.4 与 RMAN 连接的类型 ...................................................................................... 77 5.2.5 恢复管理器模式 ................................................................................................. 77 5.2.6 RMAN 命令与参数 ............................................................................................ 78 5.2.7 配置 RMAN 环境 .............................................................................................. 80 5.2.8 使用 RMAN 的注意事项 ................................................................................... 82 第 6 章 RMAN 备份 .......................................................................................................................... 84 6.1 RMAN 备份 ................................................................................................................... 84 6.1.1 恢复管理器备份的概念 ..................................................................................... 85 6.1.2 确定 RMAN 特定的备份类型 ........................................................................... 85 6.1.3 使用 RMAN BACKUP 命令创建备份集 ......................................................... 85 6.1.4 备份控制文件 ..................................................................................................... 92 6.1.5 备份归档重做日志文件 ..................................................................................... 93 6.1.6 RMAN 备份的要求 ............................................................................................ 93 4 6.2 使用 RMAN COPY 命令创建映像副本 ..................................................................... 94 6.2.1 RMAN 映像副本的特性 .................................................................................... 94 6.2.2 使用 RMAN COPY 命令创建映像副本 .......................................................... 95 6.3 RMAN 备份类型 ........................................................................................................... 97 6.3.1 完全备份 ............................................................................................................. 97 6.3.2 差异增量备份 ..................................................................................................... 98 6.3.3 累计增量备份 ..................................................................................................... 99 6.3.4 在 NOARCHIVELOG 模式下进行备份 .......................................................... 99 6.3.5 自动备份 RMAN 控制文件 ............................................................................ 100 6.4 RMAN 问题与监控 ..................................................................................................... 101 6.4.1 RMAN 动态视图 .............................................................................................. 101 6.4.2 监视 RMAN 备份 ............................................................................................ 101 6.4.3 RMAN 其他问题 .............................................................................................. 102 第 7 章 RMAN 恢复 ........................................................................................................................ 104 7.1 RMAN 完全恢复 ......................................................................................................... 104 7.1.1 RMAN 在还原和恢复操作中的用法 ............................................................... 105 7.1.2 ARCHIVELOG 模式下执行完全恢复 ............................................................... 105 7.1.3 将数据文件还原到其它位置 ......................................................................... 105 7.1.4 使用 RMAN 恢复表空间和重新定位表空间 ................................................... 106 7.2 RMAN 不完全恢复 ..................................................................................................... 107 7.2.1 使用 RMAN 进行不完全恢复的过程 ............................................................... 107 7.2.2 使用 UNTIL TIME 进行不完全数据库恢复 .................................................. 108 7.2.3 使用 UNTIL SEQUENCE 进行不完全数据库恢复 .......................................... 109 第 8 章 备份恢复示例 ................................................................................................................. 110 8.1 非归档模式下的备份与恢复 ...................................................................................... 110 8.2 归档模式下丢失或损坏一个数据文件 ...................................................................... 113 8.2.1 OS 备份方案 ...................................................................................................... 113 8.2.2 RMAN 备份方案 .............................................................................................. 116 8.3 丢失多个数据文件,实现整个数据库的恢复 .......................................................... 121 8.3.1 OS 备份方案 ...................................................................................................... 121 8.3.2 RMAN 备份方案 .................................................................................................. 126 8.4 不完全恢复案例 .......................................................................................................... 131 8.4.1 OS 备份下的基于时间的恢复 .......................................................................... 132 8.4.2 RMAN 备份下的基于改变的恢复 ...................................................................... 134 5 序 言 任何数据库在长期使用过程中,都会存在一定的安全隐患。对于数据库管理员来说不 能仅寄希望于计算机操作系统的安全运行,而是要建立一整套的数据库备份与恢复机制。当 任何人为的或是自然的灾难一旦出现,而导致数据库崩溃、物理介质损坏等,就可以及时恢 复系统中重要的数据,不影响整个单位业务的运作。然而如果没有可靠的备份数据和恢复机 制,就会带来系统瘫痪、工作停滞、经济损失等等不堪设想的后果。本文介绍 ORACLE 数 据库的备份恢复。 备份与恢复是数据库管理中最重要的方面之一。如果数据库崩溃却没有办法恢复它,那 么对企业造成的毁灭性结果可能会是数据丢失、收入减少、客户不满等。不管公司是使用单 个数据库还是多个数据库来存储数百 GB 或 TB 的数据,它们都有一个共同点,即需要制 订一个备份与恢复方案来备份重要数据并使自身免于灾难。 备份是数据的一个代表性副本。该副本会包含数据库的重要部分,如控制文件、重做日 志和数据文件。备份通过提供一种还原原始数据的方法保护数据不受应用程序错误的影响并 防止数据的意外丢失。备份分为物理备份和逻备份。物理备份是物理数据库文件的副本。“备 份与恢复”通常指将复制的文件从一个位置转移到另一个位置,同时对这些文件执行各种操 作。 相比而言,逻辑备份包含使用 SQL 命令导出并存储在二进制文件中的数据。Oracle 在 重做日志缓冲区中记录提交的和未提交的更改。逻辑备份用于补充物理备份。还原物理备份 意味着重建它并将其提供给 Oracle 服务器。要恢复还原的备份,需要使用事务日志中的重 做记录来更新数据。事务日志记录在执行备份之后对数据库所做的更改。 Oracle 在例程故障之后自动执行崩溃恢复和实例恢复。在出现介质故障的情况下,数 据库管理员 (DBA) 必须启动恢复操作。恢复备份涉及两种不同的操作:通过应用重做数据 将备份前滚至一个较近的时间;将在未提交的事务中所做的所有更改回滚至其原来状态。一 般而言,恢复指在还原、前滚和回滚备份中涉及的各种操作。备份与恢复指在防止数据库丢 失数据和在丢失数据时重建数据库的过程中涉及的各种策略和操作。 备份是数据文件、表空间或某个时间点的数据库等的快照。如果对数据库进行了周期 性备份,则在数据丢失时用户可以将存储的重做信息应用到他们最新的备份中,从而恢复数 据库的当前状态。Oracle 使用户能够还原一个较早的备份和仅应用某些重做数据,从而将 数据库恢复到一个较早的时间点。这种恢复称为不完全介质恢复。如果备份是一致的,那么 根本不需要用户应用任何重做数据。 本文从物理备份的基础归档开始,主要介绍 Oracle 数据库的物理备份,包括用户管理 的备份、RMAN 备份,并用实例展示备份恢复的步骤。 第 1 章 归档设置 第 一 章 归档设置  归档的作用  归档模式设置与取消  归档模式详细介绍  归档模式的问题解决 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 2 1.1 归档的作用 Oracle 通过 Redo 来保证数据库的事务可以被重演,从而使得在故障之后,数据可以被 恢复。Redo 对于 Oracle 数据库来说至关重要。在数据库中,Redo 的功能主要通过 3 个组件 来实现:Redo Log Buffer、LGWR 后台进程和 Redo Log File(在归档模式下,Redo Log File 最终会写出为归档日志文件)。 在 Oracle 的 SGA 中,存在一块共享内存,称为 Redo Log Buffer,Redo Log Buffer 位于 SGA 之中,是一块循环使用的内存区域,其中保存数据库变更的相关信息。这些信息以重 做条目(Redo Entries)形式存储(Redo Entries 也经常被称为 Redo Records)。 Redo Entries 包含重构、重做数据库变更的重要信息,这些变更包括 INSERT、UPDATE、DELETE、CREATE、 ALTER 或者 DROP 等。在必要的时候 Redo Entries 被用于数据库恢复。 Redo Entries 的内容被 Oracle 数据库进程从用户的内存空间复制到 SGA 中的 Redo Log Buffer 之中。Redo Entries 在内存中占用连续的顺序空间,由于 Redo Log Buffer 是循环使用 的,Oracle 通过一个后台进程 LGWR 不断地把 Redo Log Buffer 的内容写出到 Redo Log File 中。 当用户在 Buffer Cache 中修改数据时,Oracle 并不会立即将修改数据写出到数据文件上, 因为那样做效率会很低,到目前为止,计算机系统中最繁忙的部分是磁盘的 I/O 操作,Oracle 这样做的目的是为了减少 IO 的次数,当修改过的数据达到一定数量之后,可以进行高效地 批量写出。 同 Redo Log Buffer 类似,Redo Log File 也是循环使用的,Oracle 允许使用最少两个日 第 一 节 归档的作用  归档的作用是在出现故障时可以恢复数据  归档日志其实是重做日志的复本,通过 ARCn 归档 进程复制重做日志文件而生成  归档只有在数据库被配置为“归档模式”时才会被 启用 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 3 志组。缺省情况下,数据库创建时会建立 3 个日志组。 SQL> select group#,members,status from v$log; GROUP# MEMBERS STATUS ---------- ---------- ---------------- 1 1 INACTIVE 2 1 CURRENT 3 1 INACTIVE 当一个日志文件写满之后,会切换到另外一个日志文件,这个切换过程称为 Log Switch。 Log Switch 会触发一个检查点,促使 DBWR 进程将写满的日志文件保护的变更数据写回到 数据库。在检查点完成之前,日志文件是不能够被重用的。 在检查点完成之后,此检查点之前修改过的数据都已经写回磁盘,重做日志文件中的相应重 做记录对于崩溃/实例恢复不再有用。如果此后数据库崩溃,那么恢复只需要从最后一次完 成的检查点开始恢复即可。如果数据库运行在归档模式(所有生产数据库,都建议运行在归 档模式),日志文件在重用之前必须写出到归档日志文件,归档日志在介质恢复时可以用来 恢复数据库故障。 如果数据库配置为 NOARCHIVELOG 模式,则没有重做历史记录保存到归档日志文件 中,恢复操作将受到限制,并且可能会导致事务处理工作丢失。这是日志文件自动循环的结 果,在该循环过程中,恢复操作所需的较旧的日志文件被覆盖,只有该事务历史记录的最新 部分可用。 可以以将数据库配置为 ARCHIVELOG 模式,以便重做信息的历史记录可以保留在归 档文件中。归档重做日志文件可以用于介质恢复。 数 据 库 最 初 可 以 在 ARCHIVELOG 模式下创建,但缺省情况下配置为 NOARCHIVELOG 模式。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 4 1.2 归档模式设置与取消 将数据库设置为 ARCHIVELOG 模式的含义: 出现介质故障时,可以防止数据库丢失数据。可以在数据库联机时对其进行备份。由于 介质故障导致表空间(非 SYSTEM)脱机时,数据库的其余部分仍可用,因为表空间(非 SYSTEM)可以在数据库打开时恢复。 介质恢复选项: 无论数据库处于联机或脱机状态,您都可以还原损坏文件的备份副本,并使用归档日志 文件将数据文件更新为当前的版本。可以将数据库恢复至特定的时间点。可以将数据库恢复 至指定归档日志文件的末尾。可以将数据库恢复至特定的系统更改号(SCN)。 1.2.1 确定数据库当前状态 通过在 sqlplus 或者其他客户端软件里面输入 archive log list 可以查看所当前连接的数 据库,如下所示: SQL> archive log list 数据库日志模式 存档模式 自动存档 启用 存档终点 c:\arc_zero 最早的联机日志序列 1 下一个存档日志序列 2 第 二 节 归档模式的设置与取消  确定当前数据库的状态  更改归档模式  设置归档目的地  归档目的地 mandatory  手动归档与自动归档 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 5 当前日志序列 2 我们可以看到,当前数据库处于归档模式,自动存档设置为启用,归档地点为‟ c:\arc_zero‟,最早的联机日值学列为 1,下一个存档日值序列为 2,当前日值序列为 2。 1.2.2 更改归档模式 初始归档模式在 CREATE DATABASE 语句中进行设置。缺省值为 NOARCHIVELOG 模式,在该模式下,不对创建数据库过程中生成的重做信息进行归档。可以在数据库处于装 载状态时使用 ALTER DATABASE 命令更改 ARCHIVELOG 模式。 SQL> ALTER DATABASE [ archivelog | noarchivelog ] 其中: archivelog 将重做日志文件组设置为 ARCHIVELOG 模式 noarchivelog 将重做日志文件组设置为 NOARCHIVELOG 模式 将数据库模式从 NOARCHIVELOG 模式更改为 ARCHIVELOG 模式后,您必须备份所 有 数 据 库 文 件 和 控制文件。您上一次的备份不再有用,因为它是在数据库处于 NOARCHIVELOG 模式下备份的。将数据库置于 ARCHIVELOG 模式之后进行的新备份, 将由所有以后的归档重做日志文件应用。将数据库设置为 ARCHIVELOG 模式并不启用归 档程序(ARCn) 进程。 ORACLE 9i 数据库默认的归档模式为 NOARCHIVELOG,图 1.1 给出了更改归档模式 的过程: 图 1.1 下面我们看看实际的例子,通常,我们是将数据库由非归档模式改为归档模式的,但 是,在数据仓库或者特殊的应用情况下,我们需要将数据库由归档模式改为非归档模式。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 6 通过 shutdown normal 关闭数据库,并修改数据库为归档模式: SQL> shutdown normal; 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。 SQL> startup mount; ORACLE 例程已经启动。 Total System Global Area 289406976 bytes Fixed Size 1290208 bytes Variable Size 104857632 bytes Database Buffers 180355072 bytes Redo Buffers 2904064 bytes 数据库装载完毕。 SQL> alter database archivelog; 数据库已更改。 SQL> alter database open; 数据库已更改。 SQL> archive log list 数据库日志模式 存档模式 自动存档 启用 存档终点 c:\arc_zero 最早的联机日志序列 1 下一个存档日志序列 2 当前日志序列 2 通过 shutdown transactional 关闭数据库,并修改数据库为归档模式: SQL> shutdown transactional; 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。 SQL> startup mount; ORACLE 例程已经启动。 Total System Global Area 289406976 bytes Fixed Size 1290208 bytes Variable Size 109051936 bytes Database Buffers 176160768 bytes Redo Buffers 2904064 bytes ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 7 数据库装载完毕。 SQL> alter database archivelog; 数据库已更改。 SQL> alter database open; 数据库已更改。 SQL> archive log list; 数据库日志模式 存档模式 自动存档 启用 存档终点 c:\arc_zero 最早的联机日志序列 1 下一个存档日志序列 2 当前日志序列 2 通过 shutdown immediate 关闭数据库,并修改数据库为非归档模式: SQL> shutdown immediate; 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。 SQL> startup mount; ORACLE 例程已经启动。 Total System Global Area 289406976 bytes Fixed Size 1290208 bytes Variable Size 100663328 bytes Database Buffers 184549376 bytes Redo Buffers 2904064 bytes 数据库装载完毕。 SQL> alter database noarchivelog; 数据库已更改。 SQL> alter database open; 数据库已更改。 SQL> archive log list 数据库日志模式 非存档模式 自动存档 禁用 存档终点 c:\arc_zero 最早的联机日志序列 1 当前日志序列 2 在上面的三个例子中,我们分别将数据库置为归档模式和非归档模式,他们之间的区 别就是,是否启用归档,是否自动归档。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 8 在设置归档、非归档之前,需要将数据库 shutdown,有三个选项 normal、transactional、 immediate。其他关闭数据库的方式不能正常的设置归档模式。也可以使用 OEM(Oracle Enterprise Manager)改变数据库的归档模式。 1.2.3 设置归档目的地 使用 LOG_ARCHIVE_DEST_n 参数(其中,n = 1、2、3、4、5...10)最多可定义 10 个 归档日志目标。该参数仅在安装了 Oracle 企业版后才有效。在 Oracle8i 中,您最多可定义 5 个目标。 使用 LOG_ARCHIVE_DEST_n 最多可指定归档目标,LOG_ARCHIVE_DEST_n 是动 态参数,可以在系统级或会话级对其进行修改。通过添加后缀 1 到 10,最多可以指定十个 目标。 这些目标可位于本地磁盘和远程备用数据库: log_archive_dest_1 = "LOCATION=/archive1" log_archive_dest_2 = "SERVICE=standby_db1" 目标可以是本地文件系统位置,由关键字 LOCATION 定义。指定的位置必须是有效的, 并且不能是一个 NFS 装载的目录。也可以是远程目标的 Oracle Net 别名,由关键字 SERVICE 指定。指定的服务名通过使用本地的 tnsnames.ora 文件进行解析,以标识远程数 据库。Oracle9i 支持使用 IPC 或 TCP/IP 协议将归档日志文件发送到远程节点。只能为每个 远程数据库指定一个归档目标。必须为至少一个目标指定 LOCATION 参数。 使用 LOG_ARCHIVE_FORMAT 可在文件名中包括日志序列号和线程号。 1.2.4 归档目的地的 mandatory 与 Optional 使用 LOG_ARCHIVE_DEST_n 参数时,可以将目标指定为强制(mandatory) 或可选 (optional),如下所示: MANDATORY 表示必须成功完成归档到该目标的操作才可以覆盖联机重做日志文件。 OPTIONAL 表示即使联机重做日志文件尚未成功地归档到该目标,也可以重新使用。 这是缺省设置。 log_archive_dest_1="LOCATION=/archive/ MANDATORY REOPEN" log_archive_dest_2="SERVICE=standby_db1 MANDATORY REOPEN=600" log_archive_dest_3="LOCATION=/archive2/ OPTIONAL" REOPEN 属性定义发生故障时是否必须重新尝试归档到目标。如果为关键字 REOPEN 指定了值,如 REOPEN=600,则若发生故障,在经过指定时间(以秒计)后,归档程序将 尝试写入该目标。缺省值为 300 秒。归档到目标的尝试次数没有限制。归档中的所有错误 将在主站点的警报文件中报告。 如果未指定 REOPEN,则可选目标上的错误将被记录并忽略。不再将重做日志发送到 这些目标。在归档成功之前,强制目标上的错误将导致无法重新使用联机重做日志。只要归 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 9 档不成功,归档目标的状态就设置为 ERROR。 可以使用联机重做日志文件之前需要成功归档的目标数量是根据以下设置决定的:定义 为 MANDATORY 的目标的数量,LOG_ARCHIVE_MIN_SUCCEED_DEST 参数的值。该参 数用于为需要归档的本地目标数 指定一个下限值。如果该值小于强制本地目标的数量,则它对归档行为没有影响。如果 该值大于强制本地目标的数量,则本地归档目标的数量必须至少等于该值,才可以重新使用 联机重做日志文件。 示例:假定 LOG_ARCHIVE_MIN_SUCCEED_DEST 设置为 2 。如果强制本地目标的 数量为 3,则必须归档这 3 个位置,才可以重新使用联机重做日志文件。相反,如果强制本 地归档目标的数量为 1,则必须至少归档 1 个可选本地归档目标,才可以重新使用联机重做 日志文件。也就是说,LOG_ARCHIVE_MIN_SUCCEED_DEST 可以用于归档到一个或多个 可选强制目标,但反过来不行。 1.2.5 手动归档与自动归档 将数据库设置为 ARCHIVELOG 模式后,您必须决定是自动还是手动归档联机重做日 志文件。这是创建归档重做日志文件以便用于恢复时的第二步。 在自动归档过程中,将启用 ARCn 后台进程,该进程在重做日志文件填满后复制这些 文件。在手动归档过程中,必须使用 SQL*Plus 或 Oracle Enterprise Manager 复制文件。 建议您启用日志文件的自动归档。图 1.2 给出了自动归档和手动归档的区别: 图 1.2 自动归档和手动归档 在决定归档模式(自动或手动)之前,必须将数据库设置为 ARCHIVELOG 模式。如 果未切换到 ARCHIVELOG 模式,将导致 ARCn 无法复制重做日志文件。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 10 启用归档进程之前,应彻底关闭数据库(使用正常、立即或事务处理选项)。 如果由于某种原因导致归档进程(ARCn) 失败,一旦事务处理活动填满了所有重做日志, Oracle 服务器就会停止。将数据库设置为 ARCHIVELOG 模式将通知 Oracle 服务器不 要覆盖联机重做日志,除非这些日志已经归档。因此,联机重做日志的归档必须与系统中 的事务处理活动(生成重做日志)保持同步。 1.3 归档模式详细介绍 1.3.1 指定多个归档进程 并行的数据定义语言(Data Definition Language, DDL) 和并行的数据操纵语言(Data Manipulation Language, DML) 操作可能会生成大量的重做日志文件。使用一个 ARC0 进程 来归档这些重做日志文件可能会不够用。Oracle 将根据需要启动更多进程。不过,如果您 希望避免由于调用附加进程而造成运行时开销,可以指定在例程启动时将启动的进程数。 使用 LOG_ARCHIVE_MAX_PROCESSES 参数最多 可指定 十个 ARCn 进程 。将 LOG_ARCHIVE_START 设置为 TRUE 后,Oracle 例 程 将 按 照 LOG_ARCHIVE_MAX_PROCESSES 定义的数量启动多个归档进程。在例程有效期内,您 一直可以衍生更多归档进程,只要不超过由 LOG_ARCHIVE_MAX_PROCESSES 设置的值, 也可随时终止归档进程。 在事务处理负载较重或活动较多的时期,可临时启动更多归档进程以避免归档瓶颈。事 第 三 节 归档模式详细介绍  指定多个归档进程  自动归档的管理  手动归档  控制归档到目标  指定归档的文件格式 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 11 务处理活动恢复到正常水平后,可停止部分 ARCn 进程。例如,在一个月中的每一天,可 以启动有两个归档进程的例程。在每个月的最后一天,活动量总是增多,因此可以启动更多 进程: SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=3; 这一天过后,如果例程未关闭,则可发出下面的 SQL 命令来停止附加的归档进程: SQL> ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=2; 1.3.2 自动归档的管理 可以在例程启动的时候设置自动归档: 如果数据库处于 ARCHIVELOG 模式,通过设置以下参数,可以在每次启动数据库例 程时启动归档程序进程: LOG_ARCHIVE_START = boolean 如果 Boolean 为 TRUE,将在例程启动时自动启动 n 个 ARCn 进程,其中 n 是由 LOG_ARCHIVE_MAX_PROCESSES 确定的值。 如果 Boolean 为 FALSE,将禁止在例程启动时启动 ARCn。 设置初始化参数后,ARCn 进程将在例程启动时自动启动,而无需您手动启动自动归 档。也可以在例程启动之后启用自动归档,如图 1.3 图 1.3 例程启动后启用自动归档 可以选择使用带有 TO 选项的 ALTER SYSTEM ARCHIVE LOG START 命令指定归档 目标。例如: UNIX :SQL> ALTER SYSTEM ARCHIVE LOG START TO '/ORADATA/ARCHIVE1'; ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 12 Windows NT :SQL> ALTER SYSTEM ARCHIVE LOG START TO 'c:\u04\Oracle\TEST\log'; 也可以禁用自动归档,如图 1.4: 图 1.4 禁用自动归档 通过设置以下初始化参数,确保未在例程启动时启用自动归档: LOG_ARCHIVE_START=FALSE 如果已启用 ARCn 进程,则执行以下命令以停止 ARCn 进程: SQL> ALTER SYSTEM ARCHIVE LOG STOP; 停止 ARCn 进程并不会将数据库设置为 NOARCHIVELOG 模式。如果所有重做日志组 都已使用但未归档,处于 ARCHIVELOG 模式的数据库将会停止。 1.3.3 手动归档 如果数据库处于 ARCHIVELOG 模式,且未启用自动归档,则必须手动归档联机重做 日志文件。发出下面的命令进行手动归档: ALTER SYSTEM ARCHIVE LOG CURRENT; 例如: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 系统已更改。 手动归档联机重做日志文件时,可以在 ALTER SYSTEM ARCHIVE LOG 命令中使用以 下选项: 选项 说明 THREAD 指定包含要归档的重做日志文件组的线程(用于 Oracle Parallel Server) SEQUENCE 归档由日志序列号标识的联机重做日志文件组 CHANGE 基于 SCN 进行归档 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 13 GROUP 归档联机重做日志文件组 CURRENT 归档指定线程的当前重做日志文件组 LOGFILE 归档包含有由文件名标识的成员的重做日志文件组 NEXT 将尚未归档的最旧的联机重做日志文件组进行归档 ALL 对指定线程的已满但尚未归档的所有联机重做日志文件组进行归档 START 启用重做日志文件组的自动归档 TO 指定重做日志文件组归档的目标位置 STOP 禁用重做日志文件组的自动归档 1.3.4 控制归档到目标 归档目标的状态可以动态地进行更改。缺省情况下,归档目标是 ENABLE 状态,表明 Oracle 服务器可以使用该目标。归档目标的状态可以通过设置相应的 LOG_ARCHIVE_DEST_STATE_n 参数来进行修改。例如,要在发生错误时暂时停止归档到 强制位置,可以将该目标的状态设置为 DEFER。在参数文件中可能定义了一个目标,但它 设置为 DEFER。当另一目标出现错误或需要维护时,可以启用该目标。 如果一个目标的状态设置为 DEFER,则不会执行归档到该目标的操作。如果该目标 的状态更改为 ENABLE,则必须手动将所有缺失的日志归档到该目标。 1.3.5 指定归档文件格式 通过指定 LOG_ARCHIVE_FORMAT = extension 参数来指定归档的文件格式,其中, extension 应包括日志序列号变量%s 或%S。缺省值是根据操作系统而定的。如下: UNIX:LOG_ARCHIVE_FORMAT=arch%s.arc Windows NT:LOG_ARCHIVE_FORMAT = %%ORACLE_SID%%T%TS%S.ARC,其中, %ORACLE_SID% 被转换为数据库 SID 文件名选项: %s 或%S:包括日志序列号,作为文件名的一部分。 %t 或%T:包括线程号,作为文件名的一部分。 使用%S 可通过在值的左侧用 0 来填补空位使该值长度保持固定。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 14 1.4 归档相关视图 与归档相关的动态视图有以下几个:V$ARCHIVED_LOG、V$ARCHIVE_DEST、 V$LOG_HISTORY、V$DATABASE、V$ARCHIVE_PROCESSES。 1.4.1 v$archived_log 视图 v$archived_log 视图显示控制文件中的归档日志信息。 SQL> desc v$archived_log; Name Type Nullable --------------------- ------------- -------- RECID NUMBER Y STAMP NUMBER Y NAME VARCHAR2(513) Y DEST_ID NUMBER Y THREAD# NUMBER Y SEQUENCE# NUMBER Y RESETLOGS_CHANGE# NUMBER Y RESETLOGS_TIME DATE Y RESETLOGS_ID NUMBER Y 第 四 节 归档相关视图  V$ARCHIVED_LOG:归档视图  V$ARCHIVE_DEST:归档目的地状态信息视图  V$LOG_HISTORY:日志历史视图  V$DATABASE:数据库基本状态信息视图  V$ARCHIVE_PROCESS:归档进程(ARCn)状态信息 视图 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 15 FIRST_CHANGE# NUMBER Y FIRST_TIME DATE Y NEXT_CHANGE# NUMBER Y NEXT_TIME DATE Y BLOCKS NUMBER Y BLOCK_SIZE NUMBER Y CREATOR VARCHAR2(7) Y REGISTRAR VARCHAR2(7) Y STANDBY_DEST VARCHAR2(3) Y ARCHIVED VARCHAR2(3) Y APPLIED VARCHAR2(3) Y DELETED VARCHAR2(3) Y STATUS VARCHAR2(1) Y COMPLETION_TIME DATE Y DICTIONARY_BEGIN VARCHAR2(3) Y DICTIONARY_END VARCHAR2(3) Y END_OF_REDO VARCHAR2(3) Y BACKUP_COUNT NUMBER Y ARCHIVAL_THREAD# NUMBER Y ACTIVATION# NUMBER Y IS_RECOVERY_DEST_FILE VARCHAR2(3) Y COMPRESSED VARCHAR2(3) Y FAL VARCHAR2(3) Y END_OF_REDO_TYPE VARCHAR2(10) Y 1.4.2 V$ARCHIVE_DEST 视图 对于当前例程,说明所有归档日志目标、当前值、模式和状态。 SQL> desc V$ARCHIVE_DEST Name Type Nullable --------------- ------------- -------- DEST_ID NUMBER Y DEST_NAME VARCHAR2(256) Y STATUS VARCHAR2(9) Y BINDING VARCHAR2(9) Y s NAME_SPACE VARCHAR2(7) Y TARGET VARCHAR2(7) Y ARCHIVER VARCHAR2(10) Y ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 16 SCHEDULE VARCHAR2(8) Y DESTINATION VARCHAR2(256) Y LOG_SEQUENCE NUMBER Y REOPEN_SECS NUMBER Y DELAY_MINS NUMBER Y MAX_CONNECTIONS NUMBER Y NET_TIMEOUT NUMBER Y PROCESS VARCHAR2(10) Y REGISTER VARCHAR2(3) Y FAIL_DATE DATE Y FAIL_SEQUENCE NUMBER Y FAIL_BLOCK NUMBER Y FAILURE_COUNT NUMBER Y MAX_FAILURE NUMBER Y ERROR VARCHAR2(256) Y ALTERNATE VARCHAR2(256) Y DEPENDENCY VARCHAR2(256) Y REMOTE_TEMPLATE VARCHAR2(256) Y QUOTA_SIZE NUMBER Y QUOTA_USED NUMBER Y MOUNTID NUMBER Y TRANSMIT_MODE VARCHAR2(12) Y ASYNC_BLOCKS NUMBER Y AFFIRM VARCHAR2(3) Y TYPE VARCHAR2(7) Y VALID_NOW VARCHAR2(16) Y VALID_TYPE VARCHAR2(15) Y VALID_ROLE VARCHAR2(12) Y DB_UNIQUE_NAME VARCHAR2(30) Y VERIFY VARCHAR2(3) Y SQL> SELECT destination, binding, target, status FROM v$archive_dest; DESTINATION BINDING TARGET STATUS --------------- --------- ------- --------- c:\arc_zero OPTIONAL PRIMARY VALID OPTIONAL PRIMARY INACTIVE OPTIONAL PRIMARY INACTIVE OPTIONAL PRIMARY INACTIVE ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 17 OPTIONAL PRIMARY INACTIVE OPTIONAL PRIMARY INACTIVE OPTIONAL PRIMARY INACTIVE OPTIONAL PRIMARY INACTIVE OPTIONAL PRIMARY INACTIVE OPTIONAL PRIMARY INACTIVE 10 rows selected 1.4.3 v$log_history 视图 v$log_history 包含控制文件中的日志文件信息。 SQL> desc v$log_history; Name Type Nullable ----------------- ------ -------- RECID NUMBER Y STAMP NUMBER Y THREAD# NUMBER Y SEQUENCE# NUMBER Y FIRST_CHANGE# NUMBER Y FIRST_TIME DATE Y NEXT_CHANGE# NUMBER Y RESETLOGS_CHANGE# NUMBER Y RESETLOGS_TIME DATE Y 1.4.4 V$DATABASE 视图 V$DATABASE 视图显示归档的当前状态。 SQL> desc V$DATABASE; Name Type Nullable ---------------------------- ------------- -------- DBID NUMBER Y NAME VARCHAR2(9) Y CREATED DATE Y RESETLOGS_CHANGE# NUMBER Y RESETLOGS_TIME DATE Y PRIOR_RESETLOGS_CHANGE# NUMBER Y PRIOR_RESETLOGS_TIME DATE Y ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 18 LOG_MODE VARCHAR2(12) Y CHECKPOINT_CHANGE# NUMBER Y ARCHIVE_CHANGE# NUMBER Y CONTROLFILE_TYPE VARCHAR2(7) Y CONTROLFILE_CREATED DATE Y CONTROLFILE_SEQUENCE# NUMBER Y CONTROLFILE_CHANGE# NUMBER Y CONTROLFILE_TIME DATE Y OPEN_RESETLOGS VARCHAR2(11) Y VERSION_TIME DATE Y OPEN_MODE VARCHAR2(10) Y PROTECTION_MODE VARCHAR2(20) Y PROTECTION_LEVEL VARCHAR2(20) Y REMOTE_ARCHIVE VARCHAR2(8) Y ACTIVATION# NUMBER Y SWITCHOVER# NUMBER Y DATABASE_ROLE VARCHAR2(16) Y ARCHIVELOG_CHANGE# NUMBER Y ARCHIVELOG_COMPRESSION VARCHAR2(8) Y SWITCHOVER_STATUS VARCHAR2(20) Y DATAGUARD_BROKER VARCHAR2(8) Y GUARD_STATUS VARCHAR2(7) Y SUPPLEMENTAL_LOG_DATA_MIN VARCHAR2(8) Y SUPPLEMENTAL_LOG_DATA_PK VARCHAR2(3) Y SUPPLEMENTAL_LOG_DATA_UI VARCHAR2(3) Y FORCE_LOGGING VARCHAR2(3) Y PLATFORM_ID NUMBER Y PLATFORM_NAME VARCHAR2(101) Y RECOVERY_TARGET_INCARNATION# NUMBER Y LAST_OPEN_INCARNATION# NUMBER Y CURRENT_SCN NUMBER Y FLASHBACK_ON VARCHAR2(18) Y SUPPLEMENTAL_LOG_DATA_FK VARCHAR2(3) Y SUPPLEMENTAL_LOG_DATA_ALL VARCHAR2(3) Y DB_UNIQUE_NAME VARCHAR2(30) Y STANDBY_BECAME_PRIMARY_SCN NUMBER Y FS_FAILOVER_STATUS VARCHAR2(21) Y FS_FAILOVER_CURRENT_TARGET VARCHAR2(30) Y ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 19 FS_FAILOVER_THRESHOLD NUMBER Y FS_FAILOVER_OBSERVER_PRESENT VARCHAR2(7) Y FS_FAILOVER_OBSERVER_HOST VARCHAR2(512) Y 1.4.5 V$ARCHIVE_PROCESSES 视图 V$ARCHIVE_PROCESSES 提供有关例程的各种 ARCH 进程的状态的信息。 SQL> desc V$ARCHIVE_PROCESSES Name Type Nullable ------------ ------------ -------- PROCESS NUMBER Y STATUS VARCHAR2(10) Y LOG_SEQUENCE NUMBER Y STATE VARCHAR2(4) Y ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 20 第 2 章 Oracle 备份与恢复原理 本章主要介绍数据库备份、恢复、还原的基本原理,列出 Oracle 环境中可能发生的故 障类型,并定义针对数据库的备份恢复策略。 数据库管理员(DBA) 的主要职责之一就是确保数据库可用。DBA 可以采取预防措施来 尽量减少系统故障。 尽管有预防措施,但期望永远不出现故障只能是一种幼稚的想法。数据库出现故障后, DBA 必须尽快使之恢复运行,尽量减少数据损失。 为了保护数据免受各种可能发生的故障的影响,DBA 必须定期备份数据库。如果没有 最新的备份,一旦发生文件损失,DBA 就不可能在不损失数据的情况下使数据库恢复运行。 备份对从各种类型的故障中进行恢复至关重要。无论如何强调验证备份都不为过。以 为备份存在而没有实际检查它是否存在,则一旦备份无效,代价可能会极其惨重。 第 二 章 ORACLE 备份与恢复原理  备份、还原、恢复的基本原理  可能的故障类型  备份恢复策略  备份恢复分类简介 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 21 2.1 数据库备份、还原和恢复的基本原理 备份可以分为逻辑备份与物理备份。简单的说,逻辑备份是按数据库中数据的备份,物 理备份是按存储介质,数据文件的备份。比如说,利用数据导入、导出工具进行数据库的导 出属于逻辑备份,而对于表空间数据文件的拷贝就属于物理备份。因而,利用何种方式进行 的备份,相应的也需要对应的恢复方式进行恢复。逻辑备份与恢复一般是通过 Export/Import 等相应的工具进行,物理备份与恢复,请参考图 2.1: 第 一 节 数据库备份、还原、恢复 的基本原理  为什么需要恢复  检查点与 CKPT 进程  LGWR 进程  日志缓存  联机重做日志文件 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 22 图 2.1 物理备份与恢复 该图说明如下: 用户在 SCN=100 的时候,执行数据库备份,在 SCN=500 的时候发生介质损坏,需要执 行恢复,恢复時,取 SCN=100 時的数据库备份,再利用 SCN=100~500 這一段時間的归档 日值进行增量恢复,恢复成功后,数据库达到 SCN=500 时的状态。 另外要提一下实例恢复: 当数据库实例发生故障而发生停机,或用户利用 abort 选项关闭实例后,数据库再启动 后会自动执行实例恢复,实例恢复会回滚上次实例运行时未提交的事务以及一些其他的动作, 将数据库恢复到一致状态,这个过程对于用户来说是透明的,由实例自动进行,不需要人工 干预。 2.1.1 为什么需要恢复 2.1.2 检查点与 CKPT 进程 checkpoint 是一个数据库事件,它将已修改的数据从高速缓存刷新到磁盘,并更新控制 文件和数据文件。什么时候发生 checkpoint? 我们知道了 checkpoint 会刷新脏数据,但什么时候会发生 checkpoint 呢?以下几种情况 会触发 checkpoint。 1.当发生日志组切换的时候。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 23 2. 当符合 LOG_CHECKPOINT_TIMEOUT , LOG_CHECKPOINT_INTERVAL , FAST_START_IO_TARGET,FAST_START_MTTR_TARGET 参数设置的时候。 3.当运行 ALTER SYSTEM SWITCH LOGFILE 的时候。 4.当运行 ALTER SYSTEM CHECKPOINT 的时候。 5.当运行 alter tablespace XXX begin backup,end backup 的时候。 6.当运行 alter tablespace ,datafile offline 的时候。 增量检查点(incremental checkpoint),oracle8以后推出了incremental checkpoint的机制, 在以前的版本里每次 checkpoint 时都会做一个 full thread checkpoint,这样的话所有脏数据会 被写到磁盘,巨大的 i/o 对系统性能带来很大影响。为了解决这个问题,oracle 引入了 checkpoint queue 机制,每一个脏块会被移到检查点队列里面去,按照 low rdb(第一次对此 块修改对应的 redo block address)来排列,靠近检查点队列尾端的数据块的 low rba 值是最 小的,而且如果这些赃块被再次修改后它在检查点队列里的顺序也不会改变,这样就保证了 越早修改的块越早写入磁盘。每隔 3 秒钟 ckpt 会去更新控制文件和数据文件,记录 checkpoint 执行的情况。 增量检查点并不去更新数据文件头,只是在控制文件中记录了 checkpoint progress record 这个区域,记下 low rba,on-disk rba 等信息。这些信息就可以用来快速恢复。(解释)每隔 3 秒钟 ckpt 会去更新控制文件和数据文件,记录 checkpoint 执行的情况。 这里应该是只更新控制文件,每 3 秒不是更新数据文件,记录 checkpoint 的执行情况, 这个说法,没错,但不够详细,应该说,由于增量检查点和 checkpoint queue 的原理,ckpt 进程每次只是告诉 dbwr ,写 dirty buffer 将要一直写到最新这个位置,仅仅是告诉 dbwr 一个 checkpoint queue 中的结束点,而 ckpt 每 3 秒钟,在控制文件中报告一下 dbwr 最 新写入的位置。 这样使得,比如数据库要做恢复的时候(instance recovery)可以从这个 最新位置开始做恢复,而不是从数据文件中的 checkpoint scn 开始做恢复,这样将缩短恢 复时间,尤其是 instance crash 的情况下启动更快。 另外要注意的是,检查点发生的时候,ckpt 去更新数据文件头和控制文件,并不是把 当前检查点发生时候的 scn 更新进去,而是把上一次 dbwr 写入已经完成的检查点发生时候 的 scn 更新进去 ,也就是说,更新控制文件和数据文件头 是 滞后于检查点的发生的, 这个从恢复的原理也很容易理解,因为检查点发生的时候 dirty buffer 还没有写入,自然不 能立即更新成当前的 scn 了。 CHECKPOINT (CKPT) 检查点进程用来在数据库里实现同步,实现之前会强制将脏数据 从内在里写到物理文件里。 会启动 DBWn 来写脏数据(SIGNALLING DBWn at CKPT),完后会更新 DATAFILE 的 HEADER 和控制文件的 HEADER.而 HEADER 中有同步所需要的信息,即 CHECKPOINT 的 信息。在 ORACLE 中,正常情况下,所有文件必须同期性地同步;靠 CHECKPOINT 来完成。 2.1.3 LGWR 进程 LGWR, 当 transaction commit, 发生 LGWR, 把所有 redo buffer 记录到 online redolog 中。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 24 transaction 才能标记 commit 成功。 触发 LGWR 的条件有: 1) 每 3 秒 2) 在 DBWR 触发时,发现 dirty data 对应 redolog 还没有被写入 redo logfile, 触发 LGWR. 3) redolog 达到 redo buffer 的三分之一。 4) redolog 达到 1m 2.1.4 日志缓存 数据库在运行过程中,不可避免的要遇到各种能够导致数据块库损坏的情况。比如突然 断电、oracle 或者操作系统的程序 bug 导致数据库内部逻辑结构损坏、磁盘介质损坏等,都 有可能造成数据库崩溃,从而导致数据丢失的现象发生。 为了避免,或者说为了修复这些状况所导致的数据丢失现象,oracle 引入了日志缓冲区 和日志文件的概念。所谓日志,就是将所有数据库中所有改变数据块的操作,都原原本本的 记录下来。这些改变数据块的操作不仅包括对数据表的 DML 或者对数据字典的 DDL,还包 括对索引的改变、对回滚段数据块的改变、对临时表空间的临时段的改变等。只有将数据库 中所有的变化都记录下来,当发生数据库损坏时,才能够从损坏时的那一点开始,将之后数 据库中的变化重新运用一遍,从而达到恢复数据库的目的。既然是要记录,那就必然引出一 个问题,就是如何记录这些变化?比较容易想到的有两种方式。 第一种是使用逻辑的记录方式,也就是用描述性的语句来记录整个变化过程。比如对于 某个 update 更新操作来说来说,可以记录为两条语句:delete 旧值以及 insert 新值。这种方 式的优点是非常节省空间,因为对每个操作,只需要记录几条逻辑上的语句即可。但是缺点 也很明显,就是一旦需要进行恢复,就会非常消耗资源。设想一下,某个 update 操作更新 了非常多的数据块,由于 buffer cache 内存有限,很多脏数据块都已经写入了数据文件。但 就在更新快结束时,突然发生断电,所做的更新丢失。那么重新启动实例时,oracle 需要应 用日志文件里的记录,于是重新发出 delete 旧值以及 insert 新值的语句。这个过程需要重 新查找数据文件中符合条件的数据块,然后再挑出来进行更新。这个过程将非常消耗时间, 而且会占用大量的 buffer cache。 第二种方式是使用物理的记录方式,也就是将每个数据块改变前的镜像和改变后的镜像 都记录下来。这种方式优点就是恢复起来速度非常快,直接根据日志文件里所记录的数据块 地址和内容更新数据文件中对应的数据块。但是缺点也很明显,就是非常占用磁盘空间。 而 oracle 在记录日志的方式上,采用了逻辑和物理相结合的方式。也就是说,oracle 针 对每个数据块,记录了插入某个值或者删除某个值的描述语句。假如某个 update 更新了 100 个数据块,则 oracle 会针对每个数据块记录一对 delete 旧值和 insert 新值的语句,共有 100 对这样的描述语句。通过这种方式,oracle 获得了物理记录方式的快速恢复的优点,同时又 获得了逻辑记录方式的节省空间的优点。 为了临时存放所产生的日志信息,oracle 在 SGA 中开辟了一块内存区域。这块区域就 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 25 叫做日志缓冲区(log buffer),当满足一定条件以后,oracle 会使用名为 LGWR 的后台进程 将 log buffer 中的日志信息写入联机日志文件里。 可以使用初始化参数 log_buffer 来设置日志缓冲区的大小,单位是字节。 日志缓冲区只是日志信息临时存放的区域,这块区域是有限的,而且其中的每个块都是 能够循环使用的。这也就说明,日志缓冲区中的内容必须要写入磁盘上的文件里,才能永久 保留下来,才能在数据库崩溃时能够用来进行恢复。这个文件就叫做联机日志文件。在每个 日志缓冲区中的日志块被重用之前,其内容必然已经被写入了磁盘上的联机日志文件中。 2.1.5 联机重做日志文件 联机日志文件就是日志缓冲区的完全拷贝,组成日志文件的每个日志块的内容都来自于 日志缓冲区的日志块。每个日志缓冲区中的日志块都对应到日志文件中的一个日志块。日志 缓冲区中的日志块根据发生的先后顺序,放入联机日志文件。由于日志文件在故障恢复中的 重要性,建议至少使用两个日志文件组成一个日志文件组。同一个日志文件组中的日志文件 内容一摸一样,因为日志缓冲区中的日志块同时会写入日志文件组中的每个日志文件中。每 个数据库都必须至少拥有两个日志文件组。这是由于只要数据库一天不停止运行,就会不断 产生日志信息,就会不断写入联机日志文件,联机日志文件总会有写满的时候。我们不可能 让联机日志文件无限大,也不可能放无限多的联机日志文件,所以联机日志文件必须是循环 使用的,在若干个日志文件中轮流的进行写入。一个日志文件写满以后转换到另外一个日志 文件继续写的过程叫做日志切换(log switch)。 当一个联机日志文件写满时,可以选择将其归档为脱机日志文件,通常叫做归档日志文 件。归档也就是拷贝,归档的过程也就是将写满的联机日志文件拷贝到预先指定的目录的过 程。只有当一个联机日志文件完成归档以后,该联机日志文件才能够被再次循环使用。强烈 建议在生产库中选择这种归档方式,只有在测试环境中可以不选择这种归档方式。 可以说,日志缓冲区和日志文件存在的唯一目的就是为了保证被修改的数据不会被丢失。 反过来说,也就是为了能够在数据库崩溃的时候,可以用来将数据库恢复到崩溃的那个时间 点上。这也就是说,只有将被修改的数据块的日志信息写入了联机日志文件以后,该被修改 的数据块才可以说是安全的。如果日志信息在没有被写入日志文件时发生实例崩溃,这时对 数据的修改仍将丢失。由此我们可以看出,将日志缓冲区中的日志信息写入日志文件是一个 多么重要的过程,这个过程是由一个名为 LGWR 的后台进程完成的。LGWR 承担了维护系 统数据完整性的任务,它保证了数据在任何情况下都不会丢失。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 26 2.2 Oracle 环境中可能发生的故障类型 Oracle 环境中可能发现虾米的故障类型:语句故障、用户进程故障、用户错误、网络故 障、例程故障、介质故障。 每种类型的故障都要求 DBA 不同程度地介入以便从中有效地进行恢复。在某些情况下, 恢复取决于已实施的备份策略的类型。例如,语句故障几乎不需要 DBA 干预,而介质故障 则要求 DBA 使用经过测试的恢复策略。 2.2.1 语句故障 在 Oracle 程序中处理语句时如果出现逻辑故障就会导致语句故障。语句故障的类型包 括: 应用程序中出现逻辑错误。 用户试图向表中输入无效数据,可能破坏完整性约束。 用户权限不足却试图执行某个操作,例如只有 SELECT 权限却在表中执行插入操作。 用户试图创建表,但超出了分配给该用户的限额限制。 用户试图对表执行 INSERT 或 UPDATE 操作,导致分配了一个区,但是表空间中的可 用空间不足。 如果遇到语句故障,Oracle 服务器或操作系统将返回错误代码和错误消息。失败的 SQL 语句将自动回退,然后控制权将返回给用户程序。应用程序开发人员或 DBA 可使用 Oracle 错误代码来诊断和帮助解决故障。 第 二 节 Oracle 环境中可能发生 的故障类型  语句故障  用户进程故障  用户错误  数据库崩溃与实例恢复  介质故障与介质恢复 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 27 出现语句故障后,DBA 进行干预的程度各不相同,这取决于故障的类型,可能包括以 下内容: 修复应用程序以使逻辑流正确无误。根据您的环境,这可能是应用程序开发人员的任务, 而不是 DBA 的任务。 修改并重新发出 SQL 语句。这可能也是应用程序开发人员的任务,而不是 DBA 的任 务。 为用户提供成功完成该语句所必需的最低数据库权限。 发出 ALTER USER 命令以更改限额限制。 向表空间中添加文件空间。从技术角度讲,DBA 应确保不发生此类情况;但是在某些 情况下可能需要添加文件空间。DBA 还可以对数据文件使用 RESIZE 和 AUTOEXTEND 选 项。 Oracle9i 提供了一种在出现空间分配故障时先挂起、然后恢复执行大型数据库操作的方 法。这使得管理员可以采取更正措施,而不是由 Oracle 数据库服务器向用户返回错误。在 错误条件得到更正之后,挂起的操作将自动恢复。此功能称为可恢复的空间分配,受影响的 语句称为可恢复语句。 2.2.2 用户进程故障 用户进程失败的原因可能有多种;但最常见的原因如下: 用户在会话中执行了异常断开操作。例如,用户在连接到客户机-服务器配置环境中的 数据库的情况下,关闭了 SQL*Plus 窗口。 用户会话被异常终止。一种可能的情况是用户在连接到客户机-服务器配置环境中的数 据库时重新引导了客户机。 用户程序导致地址异常,从而终止会话。如果在发生异常时,应用程序未对这些异常 进行正确处理,则通常会发生这种情况。 DBA 很少需要执行操作来解决用户进程错误。该用户进程不能继续工作,尽管 Oracle 服务器和其它用户进程会继续正常运行。出现异常终止的用户进程后,PMON 后台进程通 常足以清理该用户进程。PMON 进程检测到异常终止的服务器进程时,它将回退该异常终 止进程的事务处理,并释放它所获得的任何资源和锁。 2.2.3 用户错误 用户错误通常包括以下几种: 用户意外地删除或截断表。用户删除表中的所有行。用户提交了数据,但在其中发现 一个错误。 我们无法完全避免用户错误,只能尽可能减少用户错误,在任何数据库和应用程序环 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 28 境中,一个关键的问题就是确保用户已经过适当培训,并且知道数据库可用性和完整性的含 义。 DBA 应该了解应用程序和商业运作的类型,这可避免由于用户错误而导致数据丢失; DBA 还应该了解在这些情况下如何采取恢复措施。 某些恢复情况涉及的范围可能很广,例如将数据库还原到出现错误之前的时间点、导 出丢失的数据,然后将数据导入到丢失了该数据的数据库。 LogMiner 是一种关系工具,通过它,可以以使用 SQL 来阅读、分析、解释联机和归 档日志文件。使用 LogMiner 分析日志文件可用来查明何时对数据库进行了错误的修改。这 样,就可以在应用程序级(而不是在数据库级)执行逻辑恢复了。 Oracle9i 提供一种称为 FlashBack 的新功能,可以以用它来查看和修复历史数据。 FlashBack 提供对截止某一特定时间或用户指定的系统提交号(SCN) 的数据库执行查 询的功能。 2.2.4 数据库崩溃与实例恢复 数据库崩溃的原因可能有多种: 由于断电,导致服务器不可用。由于硬件问题(如 CPU 故障或内存损坏)或操作系统 崩溃而导致服务器不可用。某个 Oracle 服务器后台进程(DBWn、LGWR、PMON、SMON 或 CKPT)出现故障。 要从崩溃中恢复,DBA 可以使用“startup” 命令启动例程。Oracle 服务器将自动恢复, 并执行前滚和回退阶段。通过阅读警报日志和在例程故障期间生成的其它所有跟踪文件来调 查故障原因。 崩溃恢复和例程恢复将数据库恢复到发生例程故障之前的事务处理一致状态。根据定义, 崩溃恢复是对单例程配置中的数据库或 Oracle Real Application Clusters 配置(其中的所有例 程都已崩溃)中的数据库执行的恢复;而例程恢复是通过 Oracle Real Application Clusters 配 置中的一个活动例程来恢复一个失败的例程。如果需要,可以在数据库打开时,由 Oracle 服 务器自动执行崩溃恢复。 您不必执行任何恢复操作。所有必需的重做信息都由 SMON 来读取。要从这种类型的 故障中进行恢复,请启动例程: SQL> CONNECT / AS sysdba Connected. SQL> STARTUP . . . Database opened. 数据库打开后,通知用户必须重新输入未提交的所有数据。 在启动数据库和出现“数据库已打开” (Database opened) 通知之间可能有一个时间延 迟,这是数据库装载时发生的前滚阶段。SMON 通过应用联机重做日志文件(来自最后一 个检查点)中记录的更改来执行前滚进程。前滚可恢复尚未记录到数据库文件中、但已记录 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 29 到联机重做日志中的数据,包括还原段的内容。 打开数据库时可能发生回退,原因是无论 SMON 或是服务器进程都可以执行回退操作。 这使数据库可以更快地供用户使用。 2.2.5 介质故障与介质恢复 介质故障包含对操作数据库所需的文件进行读写操作时产生的物理问题。介质故障是最 严重的故障类型,原因是它通常需要 DBA 的干预。 与介质有关的问题的常见类型: 包含某一数据库文件的磁盘驱动器出现磁头损坏。 对实现正常数据库操作所需的文件进行读写操作时存在物理问题。 文件被意外删除。 经过测试的恢复策略是解决介质故障问题的关键要素。DBA 能够在多大程度上尽量减 少由介质故障引起的停机时间和数据损失取决于可用备份的类型。因此,恢复策略取决于以 下因素: 选择的备份方法以及受到影响的文件。 数据库操作的 ARCHIVELOG 模式。如果采用归档,可以应用已归档的重做日志文件 来恢复自上次备份以来所提交的数据;如果使用 RMAN,还可以应用增量备份。 2.3 备份和恢复策略 第 三 节 备份和恢复策略  指定多个归档进程  自动归档的管理  手动归档  控制归档到目标  指定归档的文件格式 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 30 不管您选择什么样的备份策略,获得相应管理层的认同是很重要的。例如,如果贵公司 不希望制作文件的物理映像副本,以尽量减少对磁盘空间的占用,那么管理层必须清楚这个 决定可能引起的后果。在选择备份策略时,应考虑以下一些问题: 根据对系统可用性的期望,管理层是否权衡了所选备份策略的利弊? 是否有专门的资源来确保成功实施备份和恢复策略? 是否已明确了解进行备份和准备恢复的步骤的重要性? 对业务要求、操作要求和技术要求进行一次全面的分析,向管理层提供支持有效备份和 恢复策略所需的信息。 2.3.1 为什么要制定备份恢复策略 随着信息系统在各种商务活动中重要性的不断增强,维护系统数据的可用性已成为当 前一个十分重要的课题。为了有效地保持健康的信息系统,必须采取一定的措施防止在由介 质、操作系统、软件和其它事件导致重要数据库文件严重损坏的情况下影响 RDBMS(关系 数据库管理系统),进而影响信息系统的正常运行。 考虑到如今大部分信息系统每周的业务是 24×7 操作,因此采用联机备份,否则可每 隔一定时间进行一次脱机备份。应用上述规则,可得出下述典型的备份策略: 1、镜像拷贝重作日志文件; 2、镜像拷贝控制文件; 3、激活归档进程,即以 ARCHIVELOG 模式操作数据库; 4、每天进行数据库的部分联机备份(每天进行数据库的完全热备份将无畏地增加数据 库的负担且没有必要,同时也增加了数据库恢复时的灵活性); 5、每隔一周或几周进行一次数据库的逻辑备份; 6、定期检查备份是否正常,定期测试备份的可恢复性以及恢复时间。 2.3.2 必须考虑的因素 制定备份恢复策略需要考虑下面几个问题: 业务要求,您应该了解停机时间将对业务产生的影响。管理层必须量化停机时间及数据 损失的代价,并将其与减少停机时间及尽量减少数据损失所需的成本进行比较。 MTTR:数据库的可用性是 DBA 要考虑的一个主要问题。出现故障后,DBA 应努力 缩短平均恢复时间(MTTR)。此策略可确保数据库的不可用时间尽可能地最短。通过预测可 能发生的故障的类型并采取有效的恢复策略,DBA 可以最终达到缩短 MTTR 的目的。 MTBF:保护数据库以防止出现各种类型的故障也是 DBA 的一个重要任务。要做到这 点,DBA 必须延长平均故障间隔时间(MTBF)。DBA 必须了解 Oracle 数据库环境中备份和 恢复的结构,并对数据库进行相应配置,才不会经常发生故障。 演变过程:备份及恢复策略随着业务要求、操作要求和技术要求的变化而逐渐发展。 DBA 和相应的管理层都应定期对备份和恢复策略的有效性进行检查,这一点至关重要。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 31 操作要求,备份和恢复总是受到您所提供的业务操作类型的影响,在数据库必须一周 7 天、一天 24 小时连续运行的情况下更是如此。正确的数据库配置对于支持这样的操作要求 是必需的,因为它们直接影响数据库环境的技术层面。 DBA 可以通过制定计划定期测试备份的有效性,来确保他们的策略可以缩短 MTTR 并 延长 MTBF。有效的恢复取决于有效的备份。在选择备份策略时,应考虑以下一些问题:当 您需要帮助时,是否可以求助于系统管理员、供应商、后备 DBA 以及其他关键人员?您是 否可以按安排的时间间隔经常测试备份和恢复策略?备份副本是否存储在其它地方?计划 是否被详细记录并得到良好的维护? 影响操作要求的其它问题包括数据的易变性和数据库的结构。在选择备份策略时,应考 虑以下一些问题:表是否要经常更新?数据是否频繁变更?如果是这样,您就必须比那些数 据相对稳定的业务更频繁地进行备份。数据库结构是否经常改变?您添加数据文件的频率如 何? 技术方面的考虑因素: 物理映像副本,某些技术要求由所要求的备份类型决定。例如,如果需要数据文件的物 理映像副本,这将显著影响可用存储空间。 逻辑副本,创建数据库中对象的逻辑副本对存储要求的影响没有物理映像副本那么显著; 然而,由于用户访问数据库时执行逻辑副本,系统资源可能会受到影响。 数据库配置,数据库的配置影响执行备份的方式和数据库的可用性。根据数据库配置, 系统资源(如支持备份及恢复策略所需的磁盘空间)可能会受到限制。 事务处理量,事务处理量也会影响系统资源。如果 24 小时(全天候)操作要求定期备 份,则会增加系统资源的负担。 技术要求 在选择备份策略时,应考虑以下一些问题: 您有多少数据?您的计算机的能力及容量是否足以支持备份?数据是否易于重新创建? 您是否可以将数据从纯数据文件重新加载到数据库?数据库配置是否能支持从不同类型故 障中复原? 灾难恢复问题,您的数据可能非常重要,以至于您必须确保甚至在系统完全瘫痪的情况 下也能够复原。自然灾害和其它问题可能影响您的数据的可用性,因此在创建灾难恢复计划 时应考虑这些问题。在选择备份和恢复策略时,应考虑以下一些问题: 在发生以下严重灾难时,您的业务会受到什么样的影响: 水灾、火灾、地震或飓风、存储硬件或软件故障。如果您的数据库服务器发生故障,那 么在更换新硬件系统可能需要的数小时、数天或者甚至数周内,您的业务是否可以继续运转? 备份是否存储在其它地方? 解决方法: ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 32 异地备份,使用 Oracle9i Data Guard,它通过自动创建、管理和监视备用数据库环境的 各个方面来保护关键性数据。 地理镜像,消息传送,TP 监视器。 关于重要人员,应考虑以下问题: 失去这样的人员对您的业务会有多大影响?如果您的 DBA 离开公司或无法工作,您的 数据库系统是否还能继续运行?如果没有 DBA,将由谁负责恢复工作? 2.3.3 优化例程恢复的方法 日志文件中的信息为了当系统出现 failure 时,保证事务可以恢复。当用户事务完成发 出 commit 时,总是先等待 LGWR 进程将事务所需的 redo 信息写到日志文件(之前可能在 redo buffer 中)后,才会收到 commit complete 信息。DBWR 进程总是比 LGWR 进程写的速 度慢(DBWR 进程是随机写,LGWR 进程是顺序写,随机写比顺序写要慢)当 DBWR 进程 要将缓存区中的信息写入到数据文件时,会先通知 LGWR 进程将事务相关的 redo 信息写入 到日志文件。SCN 可以理解为一个标签,ORACLE 对数据库中的每个操作都打上一个标签。 这个标签是顺序增加的。永远不会归 0(除非数据库重建)CHECKPOINT 是 ORACLE 为了 记录哪些数据已经被写入到数据文件中。 CHECKPOINT 的作用就是要保证当 checkpoint 发生时,这个 checkpoint SCN 之前的数 据都要由 DBWR 写入到数据文件中,而在 DBWR 写之前,又会触发 LGWR 进程将相关的 redo 信息写入到日志文件中。这样,checkpoint 完成后,发生 instance failure 时就不再需要 恢复这个 checkpoint SCN 前的信息。 Instance Recovery 所需要的信息,就是最近一次 checkpoint 之后到日志文件结尾的这些 redo 信息。因为 checkpoint 之前的数据都已经一致性地写入到数据文件中了,而之后的数据 可能有一部分已经写进数据文件,而有一部分没有写进数据文件。 Instance Recovery 所需要的时间,将数据文件 从最近一次 checkpoint 开始,恢复到控 制文件中记录的这个数据文件的最后一个 SCN 值为止,应用这两者之间 redo 信息的时间就 是 instance recovery 所要花费的时间。 由上面的信息可以总结出,实例恢复最关键的问题的就是最近一次 CHECKPOINT 发生 的时间,以及 CHECKPOINT 发生的频率。只有确认了最近一次 CHECKPOIN 发生的时间 点,才能确定恢复所需的 redo 信息,以及恢复所要花费的时间。 对于 instance recovery 花费时间的调优,就是对参数 FAST_START_MTTR_TARGE 的调 整,单位“秒”,最大值为 3600 秒。也就是说 FAST_START_MTTR_TARGET 这个参数的设 置会直接影响到 checkpoint 发生的频率。FAST_START_MTTR_TARGE 所设置的时间就是 用户希望数据库用在 instance recovery 的时间。也就是从应用最近一次 checkpoint 到日志信 息最后这两个点之间 redo 信息所要花费的时间。 MTTR 设置的时间过小的话,会造成系统 checkpoint 过于频繁,而发生 checkpoint 时就 要 DBWR,LGWR 等进程写数据文件,产生物理 IO,久而久之,数据库性能会越来越慢; MTTR 设置的时间过大的话,当实例失败时,instance recover 所花费的时间就会过长。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 33 2.4 备份和恢复分类简介 第 3 章 用户管理的备份 第 四 节 备份恢复分类简介 简单的按照备份进行的方式,可以分为逻辑备份、冷备 份(脱机备份)、热备份(联机备份),其实冷备份与热备份 又可以合称为物理备份。 按照备份的工具,可以分为 EXP/IMP 备份、OS 拷贝(用 户管理的备份)、RMAN、第三方工具,如 VERITAS。 第 三 章 用户管理的备份  相关术语  用户管理的备份恢复介绍  冷备份  热备份  使用 DBVERIFY 实用程序检测坏块 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 34 3.1 相关术语 整体数据库备份: 整体数据库备份(也称为整体备份)是指对数据库的所有数据文件和控制文件进行备份。 无论数据库是打开的还是关闭的,都可以执行整体备份。这是最常见的备份方法。 在数据库关闭(使用NORMAL、IMMEDIATE 或TRANSACTIONAL 选项关闭数据库) 后进行的整体备份称为一致备份。在这种备份中,所有数据库文件的标头均与控制文件一致, 完全还原后,数据库不需任何恢复即可打开。数据库以 NOARCHIVELOG 模式进行操作时, 只有一致的整体数据库备份才可以用来还原和恢复。 如果数据库打开并且可操作,数据文件的标头将与控制文件不一致,除非数据库是以只 读模式打开的。如果使用 ABORT 选项关闭数据库,这种不一致性将一直存在。这种状态 下的数据库备份称为不一致备份。不一致备份需要通过恢复才能使数据库进入一致状态。如 果数据库需要每周 7 天、每天 24 小时都可用,则只能使用不一致备份,并且只能对以 ARCHIVELOG 模式运行的数据库执行不一致备份。 表空间备份: 表空间备份是对组成表空间的数据文件进行的备份。只有当数据库处在 ARCHIVELOG 模式下时表空间备份才有效,因为要使数据文件与数据库的其它部分保持一致,需要使用重 做条目。在 NOARCHIVELOG 模式下,如果数据库为只读的或脱机正常的,可以以进行表 第 一 节 相关术语  整体数据库备份:备份数据库中每一个关键文件, 包括所有数据文件、重做日志文件、控制文件和参 数文件  表空间备份:只备份指定表空间下的所有数据文件  数据文件备份:只备份指定的数据文件  控制文件备份:只备份某一时候的控制文件 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 35 空间备份。 数据文件备份: 如果数据库处在 ARCHIVELOG 模式下,可以以对单个数据文件进行备份。在 NOARCHIVELOG 模式下,可以以对只读或脱机正常的数据文件进行备份。 控制文件备份: 可以以对RMAN 进行配置,使之在发出BACKUP 或COPY 命令后自动备份控制文件。 还可以通过 SQL 命令备份控制文件。 3.2 什么是用户管理的备份恢复 用户管理的备份和恢复不使用恢复管理器(Recovery Manager),而是使用操作系统命令 来进行数据库文件的备份并在恢复时还原这些备份。恢复命令在 SQL*Plus 会话中发出。 Oracle 建议将 RMAN 用于所有备份和恢复操作,但也支持用户管理的备份和恢复方法。 在开始备份之前,您应该通过查询 V$DATAFILE、V$CONTROLFILE、V$LOGFILE 和 V$TABLESPACE 视图来获得有关数据库文件的信息。 使用 V$DATAFILE 视图获得所有数据文件的名称和状态列表。 第 二 节 什么是用户管理的备份恢复  用户管理的备份恢复,也就是在备份时由用户自己 使用操作系统提供的复制命令,复制要备份的文 件。  相关视图:V$DATAFILE、V$CONTROLFILE、V$LOGFILE 和 V$TABLESPACE ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 36 SQL> SELECT name, status FROM v$datafile; NAME STATUS ------------------------------------------- ------ /databases/db01/ORADATA/u01/system01.dbf SYSTEM /databases/db01/ORADATA/u02/undotbs.dbf ONLINE /databases/db01/ORADATA/u04/users01.dbf ONLINE /databases/db01/ORADATA/u03/indx01.dbf ONLINE /databases/db01/ORADATA/u02/sample01.dbf ONLINE /databases/db01/ORADATA/u01/querydata01.dbf ONLINE 使用 V$CONTROLFILE 视图显示所有控制文件的名称。 SQL> SELECT name FROM v$controlfile; NAME -------------------------------------------- /databases/db01/ORADATA/u01/ctrl01.ctl /databases/db01/ORADATA/u01/ctrl02.ctl 使用 V$LOGFILE 视图显示所有重做日志文件的名称。 SQL> SELECT member FROM v$logfile; MEMBER ---------------------------------------------- /databases/db01/ORADATA/u03/log01a.rdo /databases/db01/ORADATA/u03/log02a.rdo /databases/db01/ORADATA/u04/log01b.rdo /databases/db01/ORADATA/u04/log02b.rdo 使用 V$TABLESPACE 和 V$DATAFILE 数据字典视图获得所有数据文件及其各 自表空间的列表。在设置用以执行打开的数据库的备份的脚本时,这一点非常 有用,这样,您就可以确保在操作系统级别复制所有文件。 SQL> SELECT t.name tablespace, f.name datafile 2> FROM v$tablespace t, v$datafile f 3> WHERE t.ts# = f.ts# 4> ORDER BY t.name; TABLESPACE DATAFILE ---------- -------------------------------------------- INDX /databases/db01/ORADATA/u03/indx01.dbf QUERY_DATA /databases/db01/ORADATA/u01/querydata01.dbf SAMPLE /databases/db01/ORADATA/u02/sample01.dbf SYSTEM /databases/db01/ORADATA/u01/system01.dbf UNDOTBS /databases/db01/ORADATA/u02/undotbs.dbf USERS /databases/db01/ORADATA/u04/users01.dbf ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 37 3.3 冷备份 冷备份是一致的整体数据库备份(也称为关闭的数据库的备份)是在数据库关闭的情况 下对构成 Oracle 数据库的所有数据文件和控制文件进行的备份。它还可以包括对联机重做 日志文件、参数文件和口令文件的备份。采用用户管理的备份操作时,您应该定义一个操作 系统备份过程,然后一直用它来备份 Oracle 数据文件、控制文件、参数文件和口令文件, 这是为了防止潜在的介质故障破坏这些文件而采取的策略的一部分。 确保记下这些文件的完整路径名并在备份时正确使用。在多个数据库的环境中,由于参 数文件和口令文件的名称并不记录在字典中,所以必须小心地通过某一命名约定将这些文件 与相应的数据库关联起来。如果使用“正常”、“事务处理” 或“立即” 选项彻底地关闭了 数据库,则不必在整体数据库备份中包含联机重做日志文件。但是,在需要还原整个数据库 的情况下,如果已备份了联机重做日志文件,还原过程将得以简化。 进行数据库冷备份的优点: 冷备份在概念上简明易懂,您只需:关闭数据库,将所有需要的文件复制到备份位置, 打开数据库要执行关闭的数据库的备份,只需使用数量极少的几个命令。只要执行一个简单 的脚本,而且只需很少的交互操作,就可以自动的数据库的冷备份,步骤如下:关闭数据库, 复制控制文件和数据文件,打开数据库。 所有在冷备份过程中复制的文件都具有一致的时间点。在备份过程中,由于数据库不可 用,因此不发生任何事务处理。 进行数据库冷备份的缺点: 对于数据库必须处于连续可用状态的那些业务经营活动,由于在一致的整体数据库备份 第 三 节 冷备份  冷备份的概念:关闭数据库的备份  冷备份的优点:恢复后可以直接使用  冷备份的缺点:必须关闭数据库  冷备份的执行过程:先关闭数据库,再复制所有重 要文件 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 38 期间数据库会关闭且不可用,所以不能采用这种备份方式。 数据库不可用的时间长短受数据库大小、数据文件的数量以及复制数据文件的速度的影 响。如果这一时间超过了允许的关机时间,您必须选择其它备份类型。 只能恢复到上一次完全一致的整体数据库备份时的状态,丢失的事务处理必须在执行恢 复操作之后手动输入。 执行一致的整体数据库备份,在 Oracle 服务器例程关闭时执行一致的整体数据库备份。 1. 编译要备份的所有相关文件的最新列表。 2. 使用 SHUTDOWN NORMAL、SHUTDOWN IMMEDIATE 或 SHUTDOWN TRANSACTIONAL 命令关闭 Oracle 例程。 3. 使用操作系统备份实用程序备份所有数据文件和控制文件。您还可以备 份重做日志文件,尽管这不是必需的。您还应该备份参数文件和口令文件。 4. 重新启动 Oracle 例程。 关闭命令的缺省选项是“正常” (normal)。如果事务处理或进程有可能仍在访问数据库, 则使用“事务处理” (transactional) 或“立即” (immediate) 选项。可以考虑对此操作使用 可靠的自动执行过程,以确保每个文件都能正确备份。 在执行关闭的数据库的完全备份时,备份初始化参数文件和口令文件。不必将与只读表 空间相关联的文件包含在完全备份中。如果在执行脱机备份或冷备份时打开了数据库,备份 将无效,不能保证在恢复时可以使用。 3.4 热备份 第 四 节 热备份 热备份是在数据库运行时对数据库进行备份,应该 注意:  联机表空间备份  只读表空间备份  备份控制文件和初始化参数文件  在联机备份失败后执行清除 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 39 如果业务性质不允许关闭数据库来执行冷备份,可以以使用以下方法在使用数据库的同 时对数据库执行备份: 执行所有表空间或各个数据文件的备份(无论它们处在联机状态还是脱机状态)。将控 制文件备份为一个二进制文件,或创建一个脚本以重新创建控制文件。联机重做日志文件不 需要备份。这种备份称为热备份。 热备份的优点: 在备份过程中数据库可以正常使用。可以在表空间级(通过 RMAN)或数据文件级执 行备份。支持每天都全天候运作的业务。 进行打开的数据库的备份的注意事项: 需要对 DBA 进行更多的培训。如果执行打开的数据库的备份,推荐使用经测试的自动 执行脚本。 热备份的条件: 只要符合以下两个标准,您就可以在使用数据库的同时,执行表空间或各个数据文件的 备份: 数据库设置为 ARCHIVELOG 模式。通过启用 Oracle 自动归档(ARCn) 进程或手动归 档重做日志文件,确保联机重做日志得到归档。 热备份的选项: 使用 Oracle 服务器,我们既可以备份某一特定表空间的所有数据文件,也可以只备份 某个表空间的一个数据文件。无论您选择哪个选项,在备份过程中,数据库都可以保持正常 使用(事务处理)。 如果一个数据文件处于备份模式,则可能会生成多个重做日志条目,因为日志写入器将 备份模式下的数据文件中已更改的块的块映像写入重做日志,而不仅仅是写入行信息。这会 对重做日志的大小和日志写入器的性能产生重大影响。 3.4.1 联机表空间备份 我们通过以下步骤可以进行联机表空间的备份: 1. 通过发出 ALTER TABLESPACE...BEGIN BACKUP 命令,将数据文件或表空间设置 为备份模式。这样可避免数据文件头中的序列号发生变化,以便恢复时可以从备份开始时间 应用日志。即使数据文件处于备份模式,仍可用于正常事务处理。 SQL> ALTER TABLESPACE users BEGIN BACKUP; 2. 使用操作系统备份实用程序将表空间中的所有数据文件复制到备份存储中。如果按 顺序备份每个表空间,备份文件中的日志序列号可能不同。 UNIX: ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 40 cp /ORADATA/u03/users01.dbf /BACKUP/users01.dbf Windows NT: ocopy c:\users\disk1\user01.ora e:\users\backup\user01.ora 3. 备份表空间的各数据文件后,发出下面的命令将它们设置为正常模式: SQL> ALTER TABLESPACE users END BACKUP; 4. 归档尚未归档的重做日志,以便归档恢复表空间备份所需的重做日志, 如下所示: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; 对所有表空间重复这些步骤,包括 SYSTEM 和还原段表空间。 ALTER TABLESPACE BEGIN BACKUP 和 ALTER TABLESPACE END BACKUP 命令之间的间隔时间应尽量缩短,因为修改后的块写入重做日志文件 将导致生成更多的重做信息。因此建议您每次执行一个表空间的联机备份。 可以通过下面的视图来查询备份的信息: 通过查询 V$BACKUP 和 V$DATAFILE_HEADER 视图,可以在执行打开的数据库的 备份时获得关于数据文件状态的信息。 查询 V$BACKUP 视图以确定哪些文件处于备份模式。发出 ALTER TABLESPACE BEGIN BACKUP 命令后,状态将更改为 ACTIVE。 SQL> SELECT * FROM v$backup; FILE# STATUS CHAGE# TIME ----- ---------- ------- --------- 1 NOT ACTIVE 0 2 NOT ACTIVE 0 3 ACTIVE 312905 05-APR-01 备份文件后,“状态” (STATUS) 列的值将更改为 NOT ACTIVE。 SQL> SELECT * FROM v$backup; FILE# STATUS CHANGE# TIME ----- ------------ ------- --------- 1 NOT ACTIVE 0 2 NOT ACTIVE 0 3 NOT ACTIVE 312905 05-APR-01 处于备份模式的数据文件的信息也可以通过查询 V$DATAFILE_HEADER 视图 获得。发出 ALTER TABLESPACE BEGIN BACKUP 命令后,表空间的数据文 件的 FUZZY 列中的值将更改为 YES,表明相应的文件处于备份模式。 SQL> SELECT name, status, fuzzy FROM v$datafile_header; NAME STATUS FUZ ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 41 -------------------------------- ------ --- /…/u01/system01.dbf ONLINE /…/u02/undotbs.dbf ONLINE /…/u03/users01.dbf ONLINE YES „ 发出 ALTER TABLESPACE END BACKUP 命令后,FUZZY 列的值将更改为 NULL。 SQL> SELECT name, status, fuzzy FROM v$datafile_header; NAME STATUS FUZ -------------------------------- ------ --- /…/u01/system01.dbf ONLINE /…/u02/undotbs.dbf ONLINE /…/u03/users01.dbf ONLINE 3.4.2 只读表空间备份 只读表空间可以通过下面的方法备份: 1 使用 ALTER TABLESPACE SQL 命令将表空间的状态从读写更改为只读: SQL> ALTER TABLESPACE query_data READ ONLY; 2 发出 ALTER TABLESPACE 命令后,会对所有与表空间相关联的数据文件执行检查 点。然后使用当前 SCN 冻结文件头。 3 使表空间成为只读状态之后,您必须备份该表空间的所有数据文件。 4 DBW0 进程只写入其表空间处于读写模式的数据文件,正常的检查点也只对这些文 件执行。 对只读表空间的说明: 由于不对只读表空间的数据文件执行任何写操作,因此,只有在这些文件损坏的情况下 才必须进行恢复。 将表空间从只读状态更改为读写状态,其结果是导致 DBW0 写入表空间文 件,并象通常一样产生检查点。这样,您就必须对与该表空间相关联的所 有数据文件重新使用正常备份时间表。 使用 ALTER TABLESPACE 命令将表空间更改为只读状态,会导致控制文 件更新。执行恢复操作时,控制文件必须能够正确地标识只读表空间;否 则,您必须恢复该表空间。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 42 3.4.3 备份控制文件和初始化参数 如果您不使用 RMAN 进行备份,就必须手动备份控制文件。您必须防止丢失控制文件, 因为例程启动时需要使用控制文件中的信息。Oracle 服务器在进行例程或介质恢复时会用 到控制文件中的某些状态信息(如当前联机重做日志文件以及数据库文件的名称)。每次对 数据库配置进行更改后,您都需要保留控制文件的最新副本。 备份的原则: 对控制文件进行多元备份,并使用 CONTROL_FILES 参数在 init.ora 文件中为它们命 名。 ALTER DATABASE BACKUP CONTROLFILE TO TRACE 命令创建一个用于重新创建 控制文件的脚本。该文件位于由初始化参数 USER_DUMP_DEST 指定的目录下。此脚本不 包含 RMAN 元数据。此外,还应使用 ALTER DATABASE BACKUP CONTROLFILE 命令 来备份各个控制文件。这样可以提供控制文件在该时间点的二进制副本。完全备份时,正常 关闭例程,然后使用操作系统备份实用程序将控制文件复制到备份存储中。 以下命令更改数据库配置并导致控制文件更改: ALTER DATABASE [ADD | DROP] LOGFILE ALTER DATABASE [ADD | DROP] LOGFILE MEMBER ALTER DATABASE [ADD | DROP ] LOGFILE GROUP ALTER DATABASE [ NOARCHIVELOG | ARCHIVELOG ] ALTER DATABASE RENAME FILE CREATE TABLESPACE ALTER TABLESPACE [ADD | RENAME ] DATAFILE ALTER TABLESPACE [READ WRITE | READ ONLY ] DROP TABLESPACE 注:发出上述任一命令后,都需要备份控制文件。 备份初始化参数: 可以以使用 CREATE PFILE 语句来创建服务器参数文件的备份。服务器参数 文件的内容以文本格式导出到一个初始化参数文件中。CREATE PFILE 命令可以在缺 省位置创建该文件,您也可以按示例指定文件名。 CREATE PFILE = '/backup/init.ora' FROM SPFILE; CREATE PFILE FROM SPFILE; 同样,也可以进行下面的操作: CREATE SPFILE FROM PFILE; CREATE SPFILE FROM PFILE='/backup/init.ora'; ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 43 3.4.4 在联机备份失败后执行清除 联机表空间备份过程中的故障处理: 在联机表空间备份的过程中,可能会发生系统崩溃、电源故障、数据库关闭等故障。一 旦发生任何这些故障:如果操作系统未完成备份,则备份文件将不可用。您需要重新备份这 些文件。处在联机备份模式下的数据库文件不会与数据库同步,原因是备份开始时标头被冻 结。数据库将不会打开,因为 Oracle 服务器认为文件已从备份中还原。可以以使用 ALTER DATABASE „ END BACKUP 命令使数据文件脱离备份模式。只有在您确定这些文件处于 备份模式、且未从备份中还原的情况下,才可使用此命令。 如果您不能确定某一文件是否需要恢复,或者该文件是否仍处于联机备份模式,可查询 V$BACKUP 视图: SQL> SELECT * FROM v$backup; FILE# STATUS CHANGE# TIME ----- ---------- -------- --------- 1 NOT ACTIVE 0 2 ACTIVE 228596 30-NOV-01 3 NOT ACTIVE 0 4 NOT ACTIVE 0 该输出说明号码为 2 的文件当前处于联机备份模式。要取消对标头的冻结,可发出以 下命令: SQL> ALTER DATABASE datafile 2 END BACKUP; Database altered 或者,如果使用 Oracle9i 可以以发出以下命令: SQL> ALTER DATABASE END BACKUP; Database altered. 此命令使处在备份模式中的所有数据文件同时脱离该模式。然后,可以以查询 V$BACKUP 以再次检查状态,如下所示: SQL> SELECT * FROM v$backup; FILE# STATUS CHANGE# TIME -------- ------------------ ------- ------- 1 NOT ACTIVE 0 2 NOT ACTIVE 228596 30-NOV-01 ... 现在,可以以为用户打开数据库: SQL> ALTER DATABASE OPEN; ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 44 3.5 使用 DBVERIFY 实用程序检测损坏块 使用 DBVERIFY 实用程序可以验证数据文件,具体方法是检查指定数据文件中的数据 块结构的完整性。这是数据库之外的实用程序,因此它对数据库活动的影响最小 该实用程序可用于验证联机数据文件。可以以对数据文件的局部调用该实用程序。该实 用程序可用于验证脱机数据文件。可以以将该实用程序的输出指向错误日志。 DBVERIFY 实用程序的可执行程序名称在不同操作系统中是不同的。它位于 Oracle 主 目录的 bin 目录中。在 UNIX 环境中,应执行 dbv 可执行程序。 可以以使用命令行界面来调用 DBVERIFY 实用程序。该实用程序主要用于以下两个目 的:确保备份数据库(或数据文件)在还原之前是有效的;遇到数据损坏问题时用作诊断辅 助工具。 要验证数据文件 users01.dbf 的完整性(从块 1 开始到块 500 结束),可以以 执行如下命令: $ dbv file=/ORADATA/u03/users01.dbf start=1 end=500 DBVERIFY 的名称和位置取决于您的操作系统。有关您的系统的 DBVERIFY 位置的 信息,请参阅针对特定操作系统的 Oracle 文档。 上面命令的输出可能如下所示: DBVERIFY - Verification starting : FILE = /ORADATA/u03/users_01.dbf DBVERIFY - Verification complete 第 五 节 使用 DBVERIFY 实用程序检测坏块  DBVERIFY 程序的作用:检测数据文件是否有坏块  DBVERIFY 实用程序的可执行程序名称在不同操作 系统中是不同的。它位于 Oracle 主目录的 bin 目 录中。在 UNIX 环境中,应执行 dbv 可执行程序。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 45 Total Pages Examined : 500 Total Pages Processed (Data): 22 Total Pages Failing (Data): 0 Total Pages Processed(Index): 16 Total Pages Failing(Index): 0 Total Pages Empty : 0 Total Pages Marked Corrupt: 0 Total Pages Influx: 0 表 17.1 给出了参数的说明: 参数 说明 FILE 要验证的数据库文件的名称 START 验证的块的起始地址。块地址在 Oracle 块中指定。如果 不指定 START,则假定起始地址为文件中的第一个块。 END 要验证的块的结束地址。如果不指定 END,则假定结束地 址为文件中的最后一个块。 BLOCKSIZE 仅在文件中有大于 2KB 的块时才需要此参数 LOGFILE 指定事件记录信息写入的文件。缺省设置是将输出发送到 终端显示器。 FEEDBACK 使 DBVERIFY 为已验证的 n 页显示单个‘.’ HELP 提供屏上帮助 PARFILE 指定要使用的参数文件的名称 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 46 第 4 章 用户管理的恢复 本章以案例为主,介绍普通的控制文件、日志文件、表、数 据文件和表空间丢失后的恢复,再介绍一个特殊情况下的当前日 志损坏、无数据文件备份时的恢复 第 四 章 用户管理的恢复 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 47 4.1 用户管理的完全恢复 第 一 节 用户管理的完全恢复  介质恢复  归档模式与非归档模式下的恢复  完全恢复关闭的数据库  恢复打开的数据库  没有备份的恢复  只读表空间恢复和丢失控制文件恢复 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 48 4.1.1 介质恢复 介质恢复用于恢复丢失的或损坏的当前数据文件或控制文件。它还可用于恢复数据文件 脱 机时由 于未使用 OFFLINE NORMAL 选项而丢失的那些更改。首先是还原文件 (RESTORE),在还原文件时,其实是使用备份副本替代丢失的或损坏的文件。然后是文件 恢复(RECOVER),在恢复文件时,将重做日志文件中记录的更改应用到所还原的文件中。 介质恢复的步骤如下: 从备份还原损坏的或丢失的文件。 根据需要应用归档重做日志文件和联机重做日志文件中的更改。此时将生成还原块。这 称为前滚或高速缓存恢复。 数据库此时可能包含已提交的和未提交的更改。 还原块用于回退任何未提交的更改。这称为回退或事务处理恢复。 数据库现处于已恢复状态。 在还原文件时,使用操作系统命令从备份中复制文件。可以还原数据文件、控制文件、 归档重做日志文件和服务器参数文件。 使用 SQL*Plus RECOVER 命令将重做日志文件应用到还原的文件中。可以执行自动恢 复,或者逐个查看日志文件以应用更改。 4.1.2 ARCHIVELOG 和 NOARCHIVELOG 比较 您为数据库选择的归档模式将影响到在出现介质故障时您所能做出的恢复选择。 在设置归档日志模式时,应该考虑以下因素: 下述情况中,NOARCHIVELOG 模式可能比较合适: 容许备份之间的数据损失(在开发、培训期间等),重新应用事务处理(从批处理文件) 的速度更,快数据极少更改(非 OLTP)。 下述情况中,ARCHIVELOG 模式则更合适: 无法关闭数据库以执行关闭的数据库的备份,不允许数据损失,使用归档重做日志文件 比重新应用事务处理(OLTP) 更易于恢复,缺省情况下,数据库为 NOARCHIVELOG 模式。 4.1.3 在 NOARCHIVELOG 模式下执行恢复 当处于 NOARCHIVELOG 模式的数据库发生介质故障时,需要使用一个有效的、关闭 的数据库的备份进行恢复。在 NOARCHIVELOG 模式下,即使只有一个数据文件被损坏或 丢失,也必须还原所有的 Oracle 数据库文件。确保还原以下所有文件:数据文件和控制文 件。如果您在备份数据文件和控制文件时还备份了联机重做日志文件,则还要还原这些文件。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 49 切记,必须将所有的 Oracle 数据库文件进行同步,以打开该数据库。仅当口令文件和参数 文件被损坏或丢失时,才应该还原它们。对于处于 NOARCHIVELOG 模式下的数据库,如 果自上次备份以来没有覆盖任何重做日志文件,则只需还原受影响的 Oracle 数据文件(如 下所示) 数据库有两个重做日志,关闭的数据库的备份是在日志序列 144 时进行的,当数据库 在日志序列 145 时,数据文件 2 丢失,由于日志序列 144 尚未被覆盖,所以可手动还原和 恢复数据文件 2。 是否决定在 NOARCHIVELOG 模式下操作数据库,应考虑在恢复时的以下优缺点: 优点:易于操作,原因是只需从一个备份中还原所有的文件。唯一的风险在于操作本身: 还原错误的备份、覆盖备份、还原之前未关闭数据库或者备份无效。经过充分的培训和测试, 可最大限度地降低此类风险。在给定的硬件和操作系统下,恢复时间只是还原所有文件所花 的时间长度。 缺点:自上一次备份后用户输入的所有数据将丢失,必须手动重新应用。,即使只丢失 了一个数据文件,也必须从上次执行的、关闭的数据库的整体备份中还原整个数据库。 示例 1: 使用重做日志备份恢复。磁盘 2 被损坏,结果丢失了数据文件 2。仅有 2 个联机重做 日志文件。 上次备份是在日志序列 144 进行的,当前日志序列号为 146。 不能恢复该数据文件,因为重做日志 144 已被覆盖。如果尝试进行恢复,将会证实这 一问题。因此,必须关闭数据库并还原所有的 Oracle 文件。 SQL> SHUTDOWN ABORT 要还原文件,请: UNIX: cp /BACKUP/* /databases/db01/ORADATA Windows NT: copy d:\disk1\backup\*.* d:\disk1\data\ 复制结束后,重新启动例程: SQL> CONNECT / as sysdba SQL> STARTUP 通知用户,他们需要重新输入自上一次备份以后输入的数据。 示例 2: 不使用重做日志备份进行恢复。 如果数据库已打开,则按如下方式关闭它: SQL> SHUTDOWN IMMEDIATE 使用操作系统命令还原对数据库的最新而且完整的备份。必须还原所有的数据文件和控 制文件,而不仅仅是还原损坏的文件。以下示例还原了数据库的完整备份: $ cp /db01/BACKUP/*.dbf /ORADATA/u*/* # restores datafiles $ cp /db01/BACKUP/*.ctl /ORADATA/u*/* # restores control file ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 50 因为您没有备份联机重做日志,所以不能使用数据文件和控制文件还原它们。因此, Oracle 允许重置联机重做日志,您必须按如下方式仿效进行不完全恢复: SQL> RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE SQL> CANCEL 然后,使用 RESETLOGS 选项打开数据库,将当前的重做日志序列重置为 1(如下所 示): SQL> ALTER DATABASE OPEN RESETLOGS; 4.1.4 在 ARCHIVELOG 模式下执行完全恢复 在执行介质恢复时,您将还原的文件更新到当前时间,或者更新到由用户指定的、除当 前时间之外的时间。 在完全恢复中,使用重做日志文件或增量备份将还原文件更新到最近的时间点。将归档 重做日志文件和联机重做日志文件中包含的重做更改全部应用到这些文件中。可以对数据库 表空间或数据文件执行完全恢复。对于不完全恢复,其实就是将数据库恢复到当前时间以前 的某一时刻。通常,您并不会应用备份后生成的所有重做条目。 完全恢复要确保要还原的数据文件处于脱机状态。仅还原丢失的或损坏的数据文件。不 要还原控制文件、重做日志文件、口令文件或参数文件。恢复数据文件。 当处于 ARCHIVELOG 模式的数据库发生介质故障时,需要使用以下内容将数据库完 全恢复到发生故障前那一刻的情形: 在将数据库设置为 ARCHIVELOG 模式后进行的有效备份(其中包含丢失的或损坏的 数据文件),从您所使用的备份起至今的所有归档日志,包含尚未归档的事务处理的重 做日志文件。 在 ARCHIVELOG 模式下进行完全恢复的优缺点: 优点:仅需还原丢失或损坏的文件。已提交的数据不会丢失。通过还原上述文件并应用 归档日志和重做日志,就可将数据库恢复至当前的时间点。恢复的总时间就等于还原文件并 应用所有归档日志和重做日志所需的时间。可以在数据库打开的情况下进行恢复(包含联机 还原段的系统表空间文件和数据文件除外)。 缺点:必须有自上次备份起到当前时间的所有归档重做日志文件。如果缺失一个文件, 则无法执行完全恢复,原因是必须依次应用所有的归档重做日志文件;即,先应用归档日志 144,其次是 145,再次是 146,以此类推。 我们如何查看需要恢复的文件和数据库的日志呢? 要确定需要恢复哪些数据文件以及需要从哪里开始恢复,请按如下方式使用 V$RECOVER_FILE 视图: SQL> SELECT * FROM v$recover_file; FILE# ONLINE ERROR CHANGE# TIME ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 51 ----- ------- ------ ------- --------- 2 OFFLINE 288772 02-MAR-01 ERROR 列返回两个可能的值,从而定义需要恢复该文件的原因: NULL(如果原因未知) OFFLINE NORMAL(如果不需要恢复) CHANGE# 列返回 SCN(系统更改号),必须从 SCN 开始进行恢复。 查找要应用的归档日志文件 要查找归档日志文件,可查看 V$ARCHIVED_LOG 以获得所有归档日志文件,或查看 V$RECOVERY_LOG 以获得恢复时所需的归档日志文件: SQL> SELECT * FROM v$recovery_log; THREAD# SEQUENCE# TIME ARCHIVE_NAME ------- --------- --------- ------- 1 34 02-MAR-01 /…/ORADATA/ARCHIVE1/arch_34.arc ... 1 43 04-MAR-01 /…/ORADATA/ARCHIVE1/arch_43.arc 1 44 04-MAR-01 /…/ORADATA/ARCHIVE1/arch_44.arc 从上面的信息可以看出,要完全恢复数据文件 2,需要使用序列号为 34 之后的所有归 档日志。 注:V$RECOVERY_LOG 包含的信息仅对执行恢复的 Oracle 进程有用。 V$ARCHIVED_LOG 显示控制文件中的归档日志信息,其中包括归档日志名称。 RECOVER 命令: 要恢复数据库,可以发出以下命令之一: RECOVER [AUTOMATIC] DATABASE 此命令只能用于恢复关闭的数据库。 RECOVER [AUTOMATIC] TABLESPACE | 此命令只能用于恢复打开的数据库。 RECOVER [AUTOMATIC] DATAFILE <„filename‟> | 此命令既可用于恢复打开的数据库,又可用于恢复关闭的数据库。 其中:AUTOMATIC 会自动应用归档日志文件和重做日志文件。 在恢复过程中使用归档重做日志文件: 在恢复过程中,Oracle 服务器可以手动或自动应用所需的归档重做日志文件和联机重 做日志文件,以重新构建数据文件。在应用重做日志文件之前,Oracle 服务器会建议您提 供所要应用的日志文件的名称。 如果归档重做日志文件不还原到 LOG_ARCHIVE_DEST 目录中,则需要采取以下方法 之一,在开始恢复之前或在恢复过程中通知 Oracle 服务器: 在恢复提示下指定位置和名称: Specify log: {=suggested | filename | AUTO | CANCEL} ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 52 使用 ALTER SYSTEM ARCHIVE 命令: SQL> ALTER SYSTEM ARCHIVE LOG START TO ; 使用 RECOVER FROM 命令: SQL> RECOVER FROM „‟ DATABASE 可以使用以下方法自动应用重做日志文件: 在开始介质恢复前,先发出以下 SQL*Plus 语句: SQL> SET AUTORECOVERY ON 当提示输入一个重做日志文件时,请输入 auto: SQL> RECOVER datafile 4 ORA-00279: change 308810...03/22/01 17:00:14 needed for thread 1 ORA-00289: suggestion : /ORADATA/ARCHIVE1/arch_35.arc ORA-00280: change 308810 for thread 1 is in sequence #35 Specify log: {=suggested | filename | AUTO | CANCEL} AUTO Log applied. ... 使用 RECOVER 命令的 AUTOMATIC 选项: SQL> RECOVER AUTOMATIC datafile 4 Media recovery complete. 使用用户管理的过程将数据文件还原到新的位置: 1. 使用操作系统命令将文件还原到新的位置。 注:在 UNIX 环境中,在发出 ALTER DATABASE RENAME 命令之前,文件必 须位于新位置。在 Windows NT 环境中,则不必如此。 2. 启动该例程并装载数据库。 3. 使用 ALTER DATABASE 命令来更新控制文件,将其更新为新的文件名或更新到 新的位置: SQL> ALTER DATABASE RENAME FILE 2> „/ORADATA/u03/users01.dbf„ 3> to „/ORADATA/u04/users01.dbf„; 完全恢复的方法: 执行完全恢复的方法有 4 种: 方法 1:恢复关闭的数据库 此方法适用于以下情况:数据库不是全天候(每周 7 天、每天 24 小时)运行。恢复的 文件属于系统表空间或还原段表空间。需要恢复整个数据库或大部分数据文件。 方法 2:恢复打开的数据库(数据库最初是打开的) 此恢复方法一般在以下情况下使用:发生了文件损坏、文件意外丢失或介质故障,但未 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 53 导致数据库关闭。数据库全天候(每周 7 天、每天 24 小时)运行。必须最大限度地减少数 据库的停机时间。恢复的文件不属于系统表空间或还原段表空间。 方法 3:恢复打开的数据库(数据库最初是关闭的) 此恢复方法一般在以下情况下使用:某个介质故障或硬件故障导致系统关闭。数据库全 天候(每周 7 天、每天 24 小时)运行。必须最大限度地减少数据库的停机时间。还原的文 件不属于系统表空间或还原段表空间。 方法 4:在没有备份的情况下恢复数据文件 此恢复方法一般在以下情况下使用:介质故障或用户故障导致丢失了从未备份过的数据 文件。自该文件创建以来的所有归档日志都存在。还原的文件不属于系统表空间或还原段表 空间。 恢复过程中,磁盘中必须有 Oracle 服务器所需的所有归档日志文件。如果这些文件在 备份磁带中,则必须先还原这些文件。 4.1.5 完全恢复关闭的数据库 在以下情况中,通常将此恢复方法与 RECOVER DATABASE 命令或 RECOVER DATAFILE 命令一起使用: 恢复的文件属于系统表空间或回退段表空间。需要恢复整个数据库或大部分数据文件。 数据库不是全天候(每周 7 天、每天 24 小时)运行。示例: 已确定 u01(数据文件 1 存储在其中)包含被损坏的块。通过查询 V$DATAFILE 和 V$TABLESPACE 视图,可以发现数据文件 1 是系统表空间所属的文件之一。请按照以下 步骤恢复数据库: 1. 如果例程尚未关闭,请按如下方式发出 SHUTDOWN 命令: SQL> SHUTDOWN ABORT 2. 从备份(可用的最新备份)中还原该文件: UNIX> host cp /BACKUP/system01.dbf /ORADATA/u01 Windows NT > host copy c:\backup\df1.dbf d:\data\ 3. 以“装载” 模式启动例程,并恢复该数据文件: SQL> STARTUP MOUNT SQL> RECOVER DATABASE or SQL> RECOVER DATAFILE „/ORADATA/u01/system01.dbf„ ORA-00279: change 148448 ...03/29/01 17:04:20 needed for thread ORA-00289: suggestion : /ORADATA/ARCHIVE1/arch_144.arc ORA-00280: change 148448 for thread 1 is in sequence #144 Log applied. ... Media recovery complete. 要将数据文件恢复到发生故障前的那一刻,应该应用所有需要的归档日志和重做日 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 54 志。 4. 恢复结束后,所有数据文件都将实现同步。打开数据库。 SQL> ALTER DATABASE OPEN; 此时,可通知用户数据库可以使用了,并告诉他们重新输入系统发生故障前未提交的所 有数据。 在使用此恢复方法进行恢复的期间,必须关闭数据库;在恢复进程中,整个数据库都无 法让用户进行访问。如图 4.1: 图 4.1 关闭的数据库恢复 4.1.6 恢复打开的数据库(数据库最初是打开的) 恢复打开的数据库(数据库最初是打开的) 此恢复方法一般在以下情况下使用: 未导致数据库关闭的文件损坏、文件意外丢失或介质故障。数据库全天候(每周 7 天、 每天 24 小时)运行。必须最大限度地减少数据库的停机时间。受到影响的文件不属于系统 表空间或还原/回退段表空间。示例: 数据库当前已打开,并且已使用操作系统命令误删了数据文件 2。因为数据库当前已打 开,所以可以使用以下命令确定该数据文件属于哪个表空间: SQL> SELECT file_id f#, file_name, 2> tablespace_name tablespace, status 3> FROM dba_data_files; F# FILE_NAME TABLESPACE STATUS ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 55 --- ------------------------- ---------- --------- 1 /disk1/data/system01.dbf SYSTEM AVAILABLE 2 /disk2/data/df2.dbf USER_DATA AVAILABLE 3 /disk1/data/rbs01.dbf RBS AVAILABLE ... 1. 发出以下查询,以确定是否需要将数据文件 2 脱机: SQL> SELECT d.file# f#, d.name, d.status, h.status 2> FROM v$datafile d, v$datafile_header h 3> WHERE d.file# = h.file#; F# D.NAME D.STATUS H.STATUS --- ------------------------- ---------- --------- 1 /disk1/data/system01.dbf SYSTEM ONLINE 2 /disk2/data/df2.dbf RECOVER OFFLINE 3 /disk1/data/rbs_01.dbf ONLINE ONLINE ... 在这种情况下,Oracle 服务器已将该文件脱机。 2. 因为该文件处于脱机状态,所以此时可从备份中还原该文件: UNIX > host cp /disk1/backup/df2.dbf /disk2/data/ Windows NT > host copy c:\backup\df2.dbf d:\data\ 3. 使用 RECOVER 命令将归档和重做日志应用到还原的数据文件中。 SQL> RECOVER DATAFILE „/disk2/backup/df2.dbf„ or SQL> RECOVER TABLESPACE user_data 4. 恢复结束后,所有数据文件都将实现同步。将该数据文件联机: SQL> ALTER DATABASE DATAFILE „/disk2/data/df2.dbf„ ONLINE; 或 SQL> ALTER TABLESPACE user_data ONLINE; 如图 4.2: ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 56 图 4.2 打开的数据库恢复 有时 Oracle 服务器会检测到某个文件有问题并自动将该文件脱机。在进行恢复之前, 一定要查看警报日志以检查是否有任何错误,并检查文件的状态;可能需要恢复脱机文件。 在将表空间脱机后,就会将其所有数据文件脱机,并且无法访问该表空间中包含的任何数据。 对于具有多个文件的表空间来说,如果将其中一个数据文件脱机,则只有该数据文件中包含 的数据无法进行访问,而表空间仍然可以使用。 4.1.7 恢复打开的数据库(数据库最初是关闭的) 恢复打开的数据库(数据库最初是关闭的)此恢复方法一般在以下情况下使用:介质或 硬件故障导致系统关闭。数据库全天候(每周 7 天、每天 24 小时)运行。必须最大限度地 减少数据库的停机时间。损坏的文件不属于系统表空间或还原段表空间。示例: 您刚刚确定介质故障是由于某个磁盘控制器发生故障而引起的,该控制器只包含磁盘 2。 根据您对数据库的了解,您知道数据文件 2 不是系统数据文件或还原段数据文件,并且并 不会由于无法使用该文件而妨碍用户运行其月末报告。 1. 装载该数据库。由于数据文件 2 无法打开,因此无法打开该数据库。 SQL> STARTUP MOUNT Database mounted. 2. 如果该数据文件未脱机,则无法打开数据库。因此,必须将该文件脱机。您已经 查询了 V$DATAFILE 并确定该文件处于联机状态。 必须发出以下命令: SQL> ALTER DATABASE datafile „/disk2/data/df2.dbf„ offline; ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 57 注:此时不能使用 ALTER TABLESPACE 命令,原因是数据库尚未打开。 3. 然后就可以打开数据库,使用户能够访问系统: SQL> ALTER DATABASE OPEN; 4. 然后,还原该文件。因为无法将文件还原到损坏的磁盘 2 上,所以将它还原到磁盘 3 上: UNIX > host cp /disk1/backup/df2.dbf /disk3/data/ Windows NT > host copy c:\backup\df2.dbf e:\data\ 现在必须通知 Oracle 服务器新文件的位置: SQL> ALTER DATABASE rename file „/disk2/data/df2.dbf„ 2> to „/disk3/data/df2.dbf„; 如果数据库已打开并且需要恢复表空间,请发出以下查询,以确定该数据文件所属的表 空间的名称: SQL> SELECT file_id f#, file_name, 2> tablespace_name tablespace, status 3> FROM dba_data_files; F# FILE_NAME TABLESPACE STATUS --- ------------------ --------- ------- 1 /disk1/data/system_01.dbf SYSTEM AVAILABLE 2 /disk3/data/df2.dbf USER_DATA AVAILABLE 3 /disk1/data/rbs01.dbf RBS AVAILABLE 5. 使用 RECOVER 或 ALTER DATABASE RECOVER 命令开始将归档重做日志文件 和联 机重做日志文件应用到还原的数据文件中。 SQL> RECOVER DATAFILE „/disk3/data/df2.dbf„ 或 SQL> RECOVER TABLESPACE user_data 6. 恢复结束后,所有数据文件都将实现同步。将该数据文件联机: SQL> ALTER DATABASE datafile „/disk3/data/df2.dbf„ online; 或 SQL> ALTER TABLESPACE user_data online; 如图 4.3: ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 58 图 4.3 打开的数据库恢复示例 4.1.8 在没有备份的情况下恢复数据文件 在没有备份的情况下恢复数据文件,此恢复方法一般在下列情况使用:介质故障或用户 故障导致丢失了从未备份过的数据文件,自该文件创建以来的所有归档日志都存在,受到影 响的文件不属于系统表空间或还原段表空间。 如果定期备份中不包含新的表空间或数据文件,或者该数据文件的备份丢失了,则通常 使用该方法。使用 ALTER DATABASE 命令,用相同的名称重新创建该数据文件: SQL> ALTER DATABASE CREATE DATAFILE 2> '/ORADATA/u03/users01.dbf'; 将使用数据字典中记录的原始文件名创建该文件。使用以下版本重新创建该数据文件, 但使用新的文件名或位置: SQL> ALTER DATABASE CREATE DATAFILE 2> '/ORADATA/u03/users01.dbf' 3> AS '/ORADATA/u04/users01.dbf'; 示例: 没有备份的情况下恢复数据文件可如图 4.5: ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 59 图 4.4 没有备份的恢复 数据文件 4(在磁盘 1 上)丢失了。在通过磁带还原该数据文件时,出现一个错误,指 明该文件以前没有进行备份。您找到两天前创建 TABLE_DATA 表空间的那个 DBA,结果 发现该表空间中包含重要的用户数据,但它从未被纳入备份策略中。由于数据文件 4 不是系 统数据文件或回退段数据文件,并且您有过去两天的所有归档日志,因此,可以按如下方式 进行恢复: 1. 如果数据库已关闭,则装载该数据库、将该数据文件(无备份)脱机,然后打开数 据库。这将允许不需要 TABLE_DATA 表空间的用户对系统执行操作。如果数据库已打开, 则将该数据文件或表空间脱机。如果数据库已打开,则必须包含“立即” (IMMEDIATE) 选 项,以避免数据库写入器试图写入到一个并不存在的文件中: SQL> ALTER TABLESPACE table_data OFFLINE IMMEDIATE; Tablespace altered. 查询 V$RECOVER_FILE 确定恢复状态,以检查备份的状态: SQL> SELECT * FROM v$recover_file; FILE# ONLINE ERROR CHANGE# TIME ----- ------- -------------- ------- ---- 4 OFFLINE FILE NOT FOUND 0 2. 发出以下命令来重新创建该文件: SQL> ALTER DATABASE create datafile „/disk2/DATA/df4.dbf‟ 2> as „/disk1/DATA/df4.dbf„; Database altered. SQL> SELECT * FROM v$recover_file; FILE# ONLINE ERROR CHANGE# TIME ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 60 ----- ------- ------------------ ---------- ------ 4 OFFLINE 248621 01-DEC-97 3. 用 RECOVER 或 ALTER DATABASE RECOVER 命令,开始将归档重做日志文件和 联机 重做日志文件应用到重新创建的数据文件中: SQL> RECOVER TABLESPACE table_data; 要将数据文件恢复到发生故障前的那一刻,应该应用所有需要的归档日志和重做日 志。此时所有数据文件都将实现同步。 4. 恢复完成后,将该表空间联机: SQL> ALTER TABLESPACE table_data ONLINE; 所有数据现已恢复。将文件包括在备份策略中,并通知用户可以再次使用表空间了。 4.1.9 只读表空间恢复 只读表空间的恢复可见图 4.5 图 4.5 只读表空间的恢复 情况 1:被恢复的表空间现在是只读的,并且在上次备份时也是只读的。在这种情况下, 只需从备份中还原表空间。无需应用任何重做信息。 情况 2:被恢复的表空间现在可读写,但在上次备份时则是只读的。在这种情况下,需 要从备份中还原表空间,并应用自表空间被设置为可读写状态以来的重做信息。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 61 情况 3:被恢复的表空间现在是只读的,但在上次备份时是可读写的。因为您应该在将 表空间设置为只读状态后始终对它进行备份,所以不应该遇到这种情况。但是,如果确实出 现这种情况,则必须从备份中还原表空间,并将其恢复到被设置为只读状态前的那一刻。 如果您需要用 CREATE CONTROL FILE 命令重新创建控制文件,并且您的数据库有只 读表空间,则必须按照特殊的过程进行操作。发出 ALTER DATABASE BACKUP CONTROLFILE TO TRACE 命令以获得这些过程的列表。 如果不能将只读数据表空间中的数据文件副本还原到正确的目标位置,则可以使用 ALTER DATABASE RENAME 命令将这些文件放到新的位置。 带备份控制文件的只读表空间与脱机正常表空间的恢复过程实质上是相同的,只是您 需要在打开数据库后将表空间联机。 4.1.10 丢失控制文件的恢复 以下是三种可能需要您恢复或重新创建控制文件的情形: 第一,所有控制文件由于某个故障而丢失。如果您已正确地多元备份了控制文件并将这 些文件分布到多个物理设备上,则很少会遇到这种问题。 第二,您需要更改数据库的名称。如果数据库将成为分布式环境的一部分,并且其它数 据库具有相同的名称,则有必要更改数据库的名称。如果是出于恢复目的而还原数据库,则 可能也需要更改其名称。 第三,您需要更改控制文件中的设置。控制文件中的很多设置是在文件创建之时确定下 来的。在创建了控制文件后,就不能动态地更改这些设置;若要更改这些设置,必须重新创 建控制文件。 有三种方法可以用于还原和恢复控制文件: 第一,用当前副本还原丢失的文件。这种方法假定您没有丢失所有的控制文件。 第二,使用 CREATE CONTROLFILE 命令创建一个新文件。要完成此项操作必须知道 数据库的所有文件。间或备份控制文件以进行跟踪有助于完成此过程。 第三,使用 RECOVER DATABASE USING BACKUP CONTROLFILE 命令。如果丢失 了所有的控制文件,则需要使用此命令。 如果使用镜像的数据文件正确配置数据库,则丢失所有控制文件的可能性将降至最低。 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 62 4.2 用户管理的不完全恢复 不完全恢复能够重建数据库,使之恢复到以前的某个时间点(发生故障之前)。该情况 会导致进行恢复操作后提交的事务处理中丢失数据。如果需要,这些数据将需要手动重新输 入。只在绝对必要的情况下执行这种恢复操作。不完全恢复操作可能比较困难而且耗费时间 较长。要执行不完全恢复,需要: 恢复时间点之前制作的所有数据文件的有效脱机或联机备份,截止到指定的恢复时间之 前备份中生成的所有归档日志通常在完全恢复操作失败的情况下进行不完全恢复。 需要进行不完全恢复的常见情况: 丢失归档:由于归档日志损坏或丢失,完全恢复操作失败。数据库只能恢复到应用归档 日志之前的过去的某一时间的状态。 丢失重做日志:未镜像重做日志,并且重做日志在归档之前丢失,数据文件也丢失。恢 复无法继续到丢失的重做日志之后。 用户错误:用户错误地删除了某个表,提交了用错误的 WHERE 子句更新的数据等等。 丢失控制文件:您未镜像控制文件,不知道数据库的结构,但您有旧的二进制副本的备 份。 第 二 节 用户管理的不完全恢复  不完全恢复,也就是将数据库恢复到过去的某一个 时刻的状态。  很多情况时都必须进行不完全恢复,如: - 恢复用户的误操作,可以将数据库恢复到误操 作前的状态 - 当前联机重做日志文件损坏或丢失时,必须进 行不不完全恢复 ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 63 不完全恢复的类型: 基于时间的恢复,截止指定时间点之前的所有更改提交后,该恢复方法终止。在以下情 况下使用此方法:对数据作出了不必要的更改,或者删除了重要的表,并且知道错误发生的 大概时间。如果您立即得到通知,恢复时间最短、数据损失最少。精心测试过的程序、安全 性和过程应当可以避免此类恢复。知道未镜像的联机重做日志损坏的大概时间。镜像日志可 以避免此类恢复。 基于取消的恢复,在恢复提示符下输入 CANCEL(而不是日志文件名),即可终止该恢 复方法。在以下情况下使用此方法:当前重做日志文件或组被破坏,并且不可用于恢复。镜 像可以避免此类恢复。进行恢复所需的归档重做日志文件丢失。经常备份并将归档存放在多 个目标位置可以避免此类恢复。 基于更改的恢复,截止指定系统更改编号(SCN) 之前所做的所有更改提交之后,该恢 复方法即终止。在分布式环境中恢复数据库时,使用这种方法。本课程不对这种方法进行详 细说明。 使用备份控制文件恢复,指定的恢复方法(基于取消、基于时间或基于更改的恢复)已 完成或控制文件已恢复时,该恢复方法终止。必须在 RECOVER DATABASE 命令中指定恢 复将使用控制文件的旧副本。在以下情况下使用这种方法: 所有控制文件都已丢失,并且无法重新创建,但存在控制文件的二进制备份。镜像控制 文件(至不同磁盘)并保留 CREATE CONTROLFILE 语句的当前文本版本将减少使用该方 法的几率。将某个结构与当前数据库不同的数据库还原到先前的某个时间点。 不完全恢复原则: 认真按照所有恢复步骤进行操作很重要,因为不完全恢复的大多数问题都是由恢复过程 中的 DBA 错误造成的。事务活动只能前滚至期望的时间,而不能回退至期望的时间。这就 是对要及时恢复的数据库必须还原所有数据文件的原因。如果没能还原所有数据文件,将无 法打开(非同步)数据库。 开始不完全恢复之前应执行整体关闭数据库备份(包括控制文件和重做日志)。这样 做的好处有:允许从错误中恢复。如果恢复失败(例如,恢复超出了期望的恢复点),重做 日志和控制文件将无法用于下一次恢复,除非存在这些文件的备份。如果恢复失败,可以节 省时间。在这种情况下,可以以从新备份中还原数据文件,而不是从需要应用归档的上一次 备份中还原。 如果不执行整体备份,至少应归档当前重做日志(ALTER SYSTEM ARCHIVE LOG CURRENT) 并备份控制文件(ALTER DATABASE BACKUP CONTROLFILE TO )。 恢复成功后,执行关闭的数据库的整体备份。如果需要进行恢复才能完成下一次排定的 备份,则建议使用这种方法。在允许用户访问系统之前一定要验证故障是否已经修复,以防 止恢复失败而需要再次进行恢复。从系统中备份(以后删除)归档日志,以避免混合不同数 据库复本中的归档。 请看以下示例: ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 64 日志序列号为 144 的数据库包含从 arch_120.rdo 到 arch_143.rdo 的归档日志。执行不 完全恢复后,将创建新的数据库复本,并将数据库的日志序列号设置为 0。归档日志 arch_120.rdo 到 arch_143.rdo 现在是旧数据库复本的一部分。 日志切换 120 次后,归档日志 arch_120.rdo 将被覆盖,并通过所有其它归档(包括旧 的归档日志 arch_121.rdo 至 arch_143.rdo)备份。此后,如果恢复需要 arch_124.rdo,您需 要确保从该备份还原的归档日志属于正确的数据库复本,否则将出现错误。 不完全恢复和警报日志: 恢复过程中,进度信息存储在警报日志中。恢复前后,都应检查该文件。下面是一个 alert.log 文件示例: $ vi /disk1/BDUMP/alert_DB00.log ... Media Recovery Log ORA-279 ... RECOVER database until time „2001... Wed Mar 07 11:55:13 2001 RECOVER DATABASE CONTINUE DEFAULT Media Recovery Log /disk1/archive/arch_34.rdo Incomplete recovery done UNTIL CHANGE 309121 Media Recovery Complete Completed: RECOVER DATABASE CONTINUE DEFAULT Wed Mar 07 11:55:13 2001 alter database open resetlogs ... 4.2.1 不完全恢复的步骤 出现故障而要求进行不完全恢复时,必须拥有下列文件才能进行恢复:包含所有数据文 件的有效脱机或联机备份。从上次还原的备份到发生故障之前的所有归档重做日志。 请按照下列步骤进行恢复: 1. 对现有数据库执行关闭的数据库的完全备份。关闭数据库,从备份还原所有数据 文件(包括系统表空间文件)。 2. 还原所有数据文件,以及时恢复数据库。 3. 将数据库置于装载模式并确保数据文件处于联机状态。 4. 恢复数据库。 5. 使用 RESETLOGS 选项打开数据库并验证恢复。 6. 对数据库执行关闭的数据库的整体备份。 以下命令用于执行不完全恢复: ORACLE 交流第一群:48949977 TG-1110 Oracle SQL 备份和恢复 65 RECOVER [AUTOMATIC] DATABASE
还剩144页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 8 金币 [ 分享pdf获得金币 ] 2 人已下载

下载pdf

pdf贡献者

xulz1984

贡献于2014-07-12

下载需要 8 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf