Oracle 的自身备份
到现在为止，许多开发人员已经熟悉到 RMAN 的潜力以及它作为数据库备份工具的实用性。 您可能还记得 RMAN 可以将数据直接备份到磁盘和磁带。 当涉及磁带解决方案时，RMAN 使用名为介质治理库 (MML) 的 API 来操纵磁带子系统。
此 MML 特定于所涉及的磁带治理系统和硬件。 （例如，假如涉及 Tivoli Storage Manager，则必须使用特定的 MML — Tivoli Data PRotector，RMAN 需要它来通过 Tivoli 治理磁带。） 尽管 RMAN 是数据库引擎的一个特性，但 MML 不是引擎的一部分，而是由别人提供的；实际上，其价格可能相当高。 此外，假如您的主要目的是备份 Oracle 数据库，则在 MML 方面进行额外的投资就显得不适当了。
在 Oracle 数据库 10g 第 2 版中，一个名为 Oracle Secure Backup (OSB) 的新工具代替了特定于第三方磁带治理系统的 MML，从而使此要求变得更轻易接受。 OSB 可以直接备份到磁带库，因此您不需要任何其他介质治理层。 而其最大的优点是，OSB 与数据库引擎紧密集成，因此可以通过 Oracle Enterprise Manager 对它进行控制和治理。
但其他非数据库备份（如备份 Oracle Home、初始化文件、集群注册表文件（就 RAC 而言）以及其他重要文件）又如何呢？ 您可能会问，这些备份不需要备份工具吗？
回答是“不需要”。就像任何独立工具一样，OSB 也可以执行文件系统备份。 显而易见，无需使用 MML 来进行 RMAN 备份再加上备份文件系统这一功能提供了一个低成本和简化的备份和恢复方法。
下面介绍如何在 Oracle Enterprise Manager 中使用 MML 组件。 首先，在 Oracle Enterprise Manager GUI 中选择 Maintenance 选项卡：
从以上菜单中，选择标题为“Configure Backup Settings”的超链接，随即将显示一个如下所示的屏幕：
注重此屏幕上的“Tape Settings”部分，您将在该部分中配置 Oracle Backup 工具。
Oracle Backup Administrative 软件可以在一台独立的主机上运行，在此主机中，该软件通过数据服务器上运行的代理进行治理。 在本示例中，Administrative 主机安装在主机 proliback.proligence.com 上并在其上运行，且 Oracle Backup 工具已经安装到 /bin/oBT 目录中。
当然，许多 DBA 仍喜欢使用命令行和编写脚本。 OSB 提供了一个名为 obtool 的命令行工具。 可以通过键入以下命令调用该命令行版本： obtool
该命令调出 OSB 提示符 ob>。 可以在此处键入“help”来查看可用的命令。 ob > help
或者，可以在命令名之后使用要害字“glossary”以获得有关此命令的更多具体信息： ob> help restore glossary
要备份 Oracle Home，应使用： ob> backup --level incr --at 2005/03/29.09:00
--priority 1 --family Pool1 --privileged --dataset OracleHome --eXPirerequest 7days
我们需要对以上命令进行一些说明。 第一个参数 (level) 指示备份级别。 在此您指定了增量备份来备份自上次增量备份以来更改的所有文件。 第二个参数 2005/03/29.09:00 指定备份运行的时间， 即 2005 年 3 月 29 日上午 9 点。
假如有多个备份作业，那么它们按照什么顺序执行？ 此顺序由优先级选项（此处设置为 1，表示“最高优先级”）指定。 可以指定一个小于等于 100 的值来指定较低的优先级。
您还为不同类型的备份指定了几个介质池。 例如，您可以有一个用于数据文件备份的介质池，一个用于归档日志的介质池，和一个用于其他非数据库备份的介质池。 此处，您将名为 Pool1 的池指定为用于此备份的池。
您已经通过参数数据集指定了要备份的文件。 当您期望另一个增量备份发生时，您已经通过参数 expirerequest 请求在 7 天后使此备份过期。
我在这里的目的是提供一个非常简要的介绍；完整介绍将需要一本书的篇幅。 有关 OSB 的更多信息，请参考可用的文档集。 既往作业和当前作业的动态 RMAN 视图
与许多其他 DBA 一样，自从 Oracle8 中引入 RMAN 后不久，我便对它情有独钟。 但我从不认为对它的活动有一个彻底的了解。
在 Oracle 数据库 10g 第 2 版中，为 RMAN 作业提供的动态视图简化了对这些作业（无论是当前作业还是既往作业）的理解。
第一个新视图 V$RMAN_BACKUP_JOB_DETAILS 记录所有备份的历史。 除显示像备份历时这样的简单具体信息外，此视图还显示了许多对事后分析很重要的其他具体信息。 下面,我们将介绍一些重要的具体信息，以及它们如何帮助您分析 RMAN 会话。
假设您要对有关该历史记录的所有内容有一个或多或少的了解： 已经发出的 RMAN 作业数、每个作业的状态、这些作业的开始和完成时间、这些作业的类型等。 您将按如下所示发出一个查询： SQL> col STATUS format a9
SQL> col hrs format 999.99
SQL> select
2 session_KEY, INPUT_TYPE, STATUS,
3 to_char(START_TIME,'mm/dd/yy hh24:mi') start_time,
4 to_char(END_TIME,'mm/dd/yy hh24:mi') end_time,
5 elapsed_seconds/3600 hrs
6 from V$RMAN_BACKUP_JOB_DETAILS
7* order by session_key
输出可能类似如下所示： SESSION_KEY INPUT_TYPE STATUS START_TIME END_TIME HRS
----------- ------------- -------- -------------- ------------- -------
1 DATAFILE FULL COMPLETED 03/25/05 00:48 03/25/05 00:48 .00
4 DB FULL COMPLETED 03/27/05 02:09 03/27/05 02:11 .04
7 DB FULL FAILED 03/27/05 02:18 03/27/05 02:24 .10
SESSION KEY 列是显示其他相关信息的其他视图的要害之处。 （稍后将介绍有关该列的更多信息。） 列 START_TIME 和 END_TIME 非常直观。 列 ELAPSED_SECONDS 显示已用时间（以秒为单位），为便于阅读，我已将该时间转换为小时格式。 STATUS 列显示 RMAN 作业的状态。 在该作业执行过程中，此状态列显示 RUNNING。
记录的另一个重要信息是生成备份的速率以及进程读取和数据写入的速度。 该信息可以帮助您诊断 RMAN 作业中的拖沓现象。 SQL> col ins format a10
SQL> col outs format a10
SQL> select SESSION_KEY,
2 OPTIMIZED,
3 COMPRESSION_RATIO,
4 INPUT_BYTES_PER_SEC_DISPLAY ins,
5 OUTPUT_BYTES_PER_SEC_DISPLAY outs,
6 TIME_TAKEN_DISPLAY
7 from V$RMAN_BACKUP_JOB_DETAILS
8 order by session_key;
SESSION_KEY OPT COMPRESSION_RATIO INS OUTS TIME_TAKEN
----------- --- ----------------- ---------- ---------- ----------
1 NO 2.23776224 3.33M 1.49M 00:00:06
4 NO 1.31065794 6.92M 5.28M 00:02:16
7 NO 1.32363058 3.68M 2.78M 00:06:00
注重如何以可读格式（小时:分钟:秒）显示时间。列 INS 和 OUTS 以更易于阅读的格式（如用 M 表示兆字节）显示每秒的数据输入或输出。 在以上示例中，您可以看到由会话键 4 标记的作业有着 6.92MB/s 和 5.2MB/s 的读取速率。您现在可以查看多个 RMAN 执行的输出，并从中搜索某个模式。 该模式分析将帮助您识别通过波动昭示的任何潜在瓶颈。
还可以按备份类型过滤备份信息。 新视图 V$RMAN_BACKUP_JOB_DETAILS 提供了 RMAN 执行的备份类型以及输出的组织方式。 SQL> select * from V$RMAN_BACKUP_TYPE;
WEIGHT INPUT_TYPE
---------- -------------
1 BACKUPSET
2 SPFILE
3 CONTROLFILE
4 ARCHIVELOG
5 DATAFILE INCR
6 DATAFILE FULL
7 DB INCR
8 RECVR AREA
9 DB FULL
对象类型 weight 决定视图中记录的排列顺序。
另一个非常有用的视图是 RMAN 输出。 假设您已经通过 shell 脚本运行了 RMAN 作业，但某个地方出现了故障。 这样，您就有了一个记录 RMAN 输出的输出文件，但不幸的是，您已经把它给丢了。您该怎么办呢？ 幸运的是，新视图 V$RMAN_OUTPUT 记录 RMAN 作业中的输出，以便稍后查看。 该视图对用脚本编制的 RMAN 作业以及即席作业很有用。 SQL> select output
2 from v$rman_output
3 where session_key = 4
4 order by recid;
OUTPUT
----------------------------------------------------------------------
connected to target database: TEST (DBID=1849323268)
Starting backup at 27-MAR-05
using target database controlfile instead of recovery catalog
allocated channel:ORA_DISK_1
channel ORA_DISK_1: sid=201 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00001 name=/u01/app/oracle/oradata/TEST/system01.dbf
input datafile fno=00003 name=/u01/app/oracle/oradata/TEST/sysaux01.dbf
input datafile fno=00002 name=/u01/app/oracle/oradata/TEST/undotbs01.dbf
input datafile fno=00004 name=/u01/app/oracle/oradata/TEST/users01.dbf
input datafile fno=00005 name=/u01/app/oracle/oradata/TEST/accdata01.dbf
channel ORA_DISK_1: starting piece 1 at 27-MAR-05
channel ORA_DISK_1: finished piece 1 at 27-MAR-05
piece handle=/u01/app/oracle/prodUCt/10.2.0/db_1/dbs/07ggc7qr_1_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:46
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
including current controlfile in backupset
channel ORA_DISK_1: starting piece 1 at 27-MAR-05
channel ORA_DISK_1: finished piece 1 at 27-MAR-05
piece handle=/u01/app/oracle/product/10.2.0/db_1/dbs/08ggc7u6_1_1 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
Finished backup at 27-MAR-05
您可以看到，此处捕捉了 RMAN 作业的整个输出。 这是一个保存在内存中的视图，在实例关闭时会从内存中清除。 假如希望保存 RMAN 输出，可以将这些行复制到一个永久表。 列 SESSION_KEY 显示与视图 V$RMAN_BACKUP_JOB_DETAILS 中显示的 RMAN 作业关联的记录。 现在，您将不会再丢失 RMAN 作业中的输出了。
通过 Oracle Enterprise Manager，您可以利用新视图创建新备份报表。 此报表提供了已经在您的企业中执行的备份操作的瞬时概要。 可以按备份类型和状态过滤数据。 为 Oracle RAC 集群动态分配通道
当然，在 Oracle RAC 环境中，有多个数据库运行在多个主机上。 但在这样的环境中调用 RMAN 时，不得不只连接到一个实例（使用 TARGET=/）上，从而导致一个节点执行所有工作而其他节点却相对空闲。
在 Oracle 数据库 10g 第 2 版之前，让两个节点执行该工作的一个方法就是创建多个连接到多个实例的通道。 以下显示了一个相关 RMAN 命令的示例：
allocate channel = c1 type sbt_tape connect = 'rman/rmanpass@inst1';
allocate channel = c2 type sbt_tape connect = 'rman/rmanpass@inst2';
该命令假设您有两个实例，即 inst1 和 inst2。 但该选项并不完全满足要求，这是因为它无法揭示某个节点出现了故障；当某个节点出现故障时，整个 RMAN 作业将发生故障。 此外，它并不创建真正的负载平衡配置。
在 Oracle 数据库 10g 第 2 版中，不必再为每个 RAC 节点显式分配一个通道来执行备份；您只需为操作定义并行度即可。 RMAN 自动创建多个并行流，并根据集群资源治理器连接到负载最小的实例。 除了负载平衡以外，它还提供了通道故障切换功能，以便将一个实例的连接故障切换到幸存节点。 此新特性增强了 RMAN 进程的强健度。
通过 RMAN 恢复临时文件
当您从 RMAN 备份恢复数据库时，所需执行的第一个操作就是重新创建临时表空间文件。 由于临时表空间不包含要恢复的永久对象，因此 RMAN 不备份它们 - 没有必要为非永久对象浪费备份资源。 但 Oracle 数据库需要临时表空间才能使许多操作高效运行。 因此，假如 RMAN 也备份它们岂不是很好？
在 Oracle 数据库 10g 第 2 版中，它做到了。 当您恢复数据库时，还将自动重新创建临时表空间文件。 以下是警报日志文件的片段： ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/app/oracle/oradata/TEST/temp01.dbf'
ORA-27037: unable to obtain file status
linux Error:2: No such file or Directory
Additional information: 3
Sun Mar 27 20:29:00 2005
Errors in file /u01/app/oracle/admin/TEST/bdump/test_dbw0_15457.trc:
ORA-01186: file 201 failed verification tests
ORA-01157: cannot identify/lock data file 201 - see DBWR trace file
ORA-01110: data file 201: '/u01/app/oracle/oradata/TEST/temp01.dbf'
Sun Mar 27 20:29:00 2005
File 201 not verified due to error ORA-01157
Sun Mar 27 20:29:00 2005
Dictionary check complete
Sun Mar 27 20:29:00 2005
SMON: enabling tx recovery
Sun Mar 27 20:29:00 2005
Re-creating tempfile /u01/app/oracle/oradata/TEST/temp01.dbf
通过 RESETLOGS 实现闪回数据库/查询
Oracle 数据库 10g 引入了闪回数据库，它通过撤消存储在闪回日志中的更改回滚整个数据库。 但请考虑以下情形：
数据库活动正常。 记录已更新。
数据库因重做日志文件中存在的物理损坏而崩溃。
使用备份控制文件从备份恢复了数据库。
使用 RESETLOGS 选项打开了数据库。
数据库活动恢复。 以正常方式更新记录。 开发人员喊到“帮帮忙”！ 他更新了错误的记录集。 他请求闪回该数据库。 当使用 RESETLOGS 选项打开数据库时，该数据库从编号为 1 的 SCN 开始。因此，新配置文件不知道过去更新的 SCN 编号。 由于闪回数据库依靠 SCN 编号，因此该特性能否在该情形下起作用？
在 Oracle 数据库 10g 第 2 版中，它将起作用，这是因为该数据库将它的前一个副本存储在控制文件中，并对频繁地使用它。 这种情况下将查询前一个副本，并使用它将数据库闪回到不同的时间，即使在同时重置了 SCN 编号的情况下也是如此。
我们来看一个示例： 首先，检查帐号 3 的帐户持有者。 SQL> select first_name, last_name
2 from accounts
3 where acc_no = 3;
FIRST_NAME LAST_NAME
------------------------------ -----------
Alan Smith
现在更新名称： SQL> update accounts
2 set first_name = 'John'
3 where acc_no = 3;
现在，毁坏数据库，从备份恢复，然后在 RESETLOGS 选项中打开已恢复的数据库。
假设一段时间过后，大厅角落里传来了一个气急败坏的声音“靠”，然后就有人请您将数据库闪回到先前的某个时间点，而这个时间点恰好位于 RESETLOGS 操作之前。
这时只需发出以下命令即可。 SQL> Flashback database to before resetlogs;
该命令恰好把数据库闪回到 RESETLOGS 之前的 SCN。 执行该命令后，再次检查该表。 SQL> select first_name, last_name
2 from accounts
3 where acc_no = 3;
FIRST_NAME LAST_NAME
------------------------------ -----------
Alan Smith
您可以看到，RESETLOGS 操作没有影响闪回操作。
该特性使闪回数据库非常强大和有用。 它的行为对闪回查询也适用。 闪回数据库中的恢复点
还记得 SQL 中保存点的概念吗？ 在一个事务中，您可以创建保存点，进行某些修改，创建另一个保存点，等等。 假如这些更改不是您想要的，则您所要做的就是将它们回滚到某个具体的保存点。
现在，我们将介绍 Oracle 数据库 10g 中引入的一个新功能 — 闪回数据库。通过它您可以将数据库倒回到前一个时间点。 在这种情况下拥有一个与保存点类似的功能（即能够倒回到一个有名称的点，而不仅仅是一个时间点）岂不是很好？
在 Oracle 数据库 10g 第 2 版中，您可以使用一个名为恢复点的新功能来实现该操作。以下是它的工作方式。 假设有一个长期运行的处理（涉及多个必须按顺序运行的批处理程序）。以下是事件序列：
创建恢复点 rp1
运行批处理作业 1
创建恢复点 rp2
运行批处理作业 2 等等。 批处理作业 2 在执行过程中失败，您需要将数据库恢复到一致的状态。 您不必将它一直恢复到运行的开始阶段。 由于恢复点 rp2 是在批处理作业执行之前创建的，因此只需将数据库闪回到该恢复点。
使用以下代码创建一个恢复点 create restore point before_monthend_200503;
现在根据当前的数据库时间和 SCN 创建了恢复点 BEFORE_MONTHEND_200503。 假如要确保可以将数据库闪回到某个特定恢复点，可以通过按如下所示创建有保证的恢复点来指定 guarantee： create restore point before_monthend_200503
guarantee flashback database;
可以通过从动态性能视图 V$RESTORE_POINT 中执行 SELECT 来确认该恢复点是否存在： SQL> select * from v$restore_point;
SCN DATABASE_INCARNATION# GUA STORAGE_SIZE
---------- --------------------- --- ------------
TIME
---------------------------------------------------
NAME
---------------------------------------------------
1429811 1 YES 8192000
27-MAR-05 05.18.39.000000000 PM
BEFORE_MONTHEND_200503
稍后当您要将数据库闪回到该恢复点时，您只需发出： flashback database to restore point before_monthend_200503;
假如检查警报日志，它将显示一个类似如下的行： Media Recovery Applied UNTIL CHANGE 1429814
恢复点（尤其是有保证的恢复点）在许多与数据库相关的任务中非常有用。 QA 数据库就是一个典型示例。在该数据库中，您可能要建立一个恢复点、运行某些测试并闪回到恢复点，从而使数据库看起来好象什么也没发生一样。 然后，您可以执行另一轮测试，并再次将它恢复到恢复点。
研究快速恢复区
您可能已经配置了快速恢复区来备份不同类型的文件。 但您怎么知道其中有哪些可用的备份类型呢？
一个新视图 V$FLASH_RECOVERY_AREA_USAGE 显示了快速恢复区中可用的备份类型。 SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
------------ ------------------ ------------------------- ---------------
CONTROLFILE 0 0 0
ONLINELOG 0 0 0
ARCHIVELOG .02 .02 1
BACKUPPIECE 68.98 1.02 10
IMAGECOPY 0 0 0
FLASHBACKLOG .95 0 3
使用该视图，您可以立即看到快速恢复区中的可用文件类型。 但它只显示百分比，因此您如何确定实际值？ 只需查询视图 $RECOVERY_FILE_DEST 即可。 SQL> select * from V$RECOVERY_FILE_DEST;
NAME
----------------------------------------------------------
SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES
----------- ---------- ----------------- ---------------
/home/oracle
2147483648 1502122496 22201856 14
该查询显示恢复区的总大小为 16384000。闪回日志占用 SPACE_LIMIT 列的 0.95%（上一个查询中所示），因此您可以计算所占用空间的实际大小。 它还显示了从快速恢复区中不同类型的备份中可以回收的空间大小。 例如，您可以因为备份可能已过期而回收 1.02% 的已占用空间。 使用该视图，您可以针对快速恢复区使用率和大小进行智能化的猜测。
Oracle Enterprise Manager 通过向 Recovery Settings 页（显示快速恢复区域中的文件细分）中添加一个饼图来利用新的 V$RECOVERY_FILE_DEST 视图：
DBA 工作（尤其是生产支持 DBA 的工作）的独特方面之一就是成功、可靠以及高效地进行备份和恢复的能力。
在 Oracle 数据库 10g 第 2 版中，该领域中的增强使 DBA 的工作变得更加轻易和可靠。
