达州做网站
大橙子网站建设，新征程启航
为企业提供网站建设、域名注册、服务器等服务
Oracle11g备份恢复新特性有哪些
小编给大家分享一下Oracle11g备份恢复新特性有哪些，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！
成都创新互联公司主营黄石网站建设的网络公司,主营网站建设方案,重庆APP软件开发,黄石h5微信小程序定制开发搭建,黄石网站营销推广欢迎黄石等地区企业咨询
闪回日志急救
还记得 Oracle Database 10g 中引入的闪回日志记录吗？如果数据库中已启用了闪回功能，闪回日志会将更改块的以前映像的优化版本记录到在闪回恢复区生成的闪回日志中。这些日志可以帮助您将数据库闪回到过去的一个时间点，而不必从备份中执行时间点恢复。
那么，既然这些闪回日志包含块的以前的映像，为什么不将它们也用于恢复呢？Oracle Database 11g 正是这么做的。当您恢复特定的块时，Oracle 会在闪回日志（而不是数据文件）中查找该块的以前映像的良好副本，然后应用存档日志以使其向前滚动。由于无需借助备份，该方法可以节省很多时间，尤其是当备份在磁带上时。
ZLIB 压缩
RMAN 在 Oracle Database 10g 中提供了备份段压缩功能以节省网络带宽，但是许多人都不轻易使用它。为什么？因为第三方压缩工具提供的方法比 RMAN 自身的更快。但是，RMAN 10g 压缩具备一些第三方压缩工具所没有的好用功能。例如，当 RMAN 10g 还原数据文件时，不需要先解压缩这些文件（如果以前被压缩过）。该方法在还原期间可以显著节省带宽。
在 Oracle Database 11g 中，RMAN 提供了另一种算法 ZLIB，以前使用的是 BZIP2。ZLIB 算法要快得多，但是不能压缩太多内容。另一方面，它也很节省 CPU。因此，如果您的 CPU 不多，最好使用 ZLIB 压缩。（注意，版本 11.1 中的默认选件是 BZIP2；您需要购买一个新选件 Advanced Compression Option 才能使用 ZLIB。）
要使用 ZLIB 压缩，只需将 RMAN 配置参数设置为：
RMAN> configure compression algorithm 'ZLIB' ;
如果您以前更改过该参数，需要发出上述命令。要将其更改为 BZIP2，发出以下命令：
RMAN> configure compression algorithm 'bzip2';
现在，所有压缩备份都将使用新算法。
同一数据文件的并行备份
您或许已经知道您可以并行备份，方法是，声明多个通道使每个通道成为一个 RMAN 会话。但是，很少有人意识到每个通道一次只能备份一个数据文件。因此，即使有多个通道，但是每个数据文件只通过一个通道进行备份，这与备份真正并行的概念有些相反。
在 Oracle Database 11g RMAN 中，通道可以将数据文件拆分为块，这些块被称为“段”。您可以指定每个段的大小。下面就是一个例子：
RMAN> run {
2> allocate channel c1 type disk format '/backup1/%U';
3> allocate channel c2 type disk format '/backup2/%U';
4> backup
5> section size 500m
6> datafile 6;
7> }
该 RMAN 命令分配两个通道并在两个通道上并行备份用户的表空间。每个通道占用数据文件的一个 500MB 的段并以并行方式备份该文件。这加快了大型文件的备份速度。
以这种方式备份时，备份的内容也显示为段。
RMAN> list backup of datafile 6; ...... List of Backup Pieces for backup set 901 Copy #1 BP Key Pc# Status Piece Name ------- --- ----------- ---------- 2007 1 AVAILABLE /backup1/9dhk7os1_1_1 2008 2 AVAILABLE /backup2/9dhk7os1_1_1 2009 3 AVAILABLE /backup1/9dhk7os1_1_3 2009 3 AVAILABLE /backup2/9dhk7os1_1_4
注意，备份段是如何显示为文件段的。由于每个段去往不同的通道，因此您可以将它们定义为不同的挂载点（如 /backup1 和 /backup2），您还可以并行方式将它们备份到磁带。
但是，如果 6 号大型文件只位于一个磁盘上，使用并行备份就没有优势了。如果您对该文件进行分段，磁头需要不断移动来处理该文件的不同段，其缺点胜过分段的优点。
撤销提交的备份？为什么？
您已经知道撤销数据的用途。当事务更改某个块时，该块以前的映像将被保存在撤销段中。即使事务已提交，数据仍然保存在那里，因为在该块被更改之前启动的某个运行时间较长的查询可能会请求已更改和提交的块。该查询应该获取该块以前的映像，即之前提交的映像而不是当前的映像。因此，即使在提交之后，撤销数据仍然保存在撤销段中。随着时间的推移，该数据会被冲刷出撤销段以便为新插入的撤销数据腾出空间。
当 RMAN 备份运行时，它会备份撤销表空间中的所有数据。在恢复期间，与提交的事务相关的撤销数据将不再需要，因为它们已经在重做日志流中，或者仍然在数据文件中（如果已从缓冲区清除已使用的块并将其写入磁盘），可以从那里进行恢复。那么，为什么还要备份提交的撤销数据呢？
在 Oracle Database 11g 中，RMAN 很智能：它不备份恢复所不需要的已提交撤销数据。而对恢复至关重要的未提交撤销数据照常备份。这减少了备份（以及恢复）的大小和时间。
在许多数据库中，尤其是在事务提交更加频繁，撤销数据在撤销段中的存留时间更长的 OLTP 数据库中，大多数撤销数据实际上已被提交。因此，RMAN 只需备份撤销表空间中的几个块。
最好的是，您不需要做任何事即可实现该优化，Oracle 会自行操作。
虚拟专用目录
您可能会使用一个目录数据库作为 RMAN 信息库。如果没有，您应该认真地考虑使用一个目录数据库。这有很多优点，例如报告、控制文件受损时简化恢复，等等。
现在，又出现了一个问题：多少个目录合适？通常，只创建一个目录数据库作为所有数据库的信息库是合理的。但是，要考虑到安全性，这可能不是一个好方法。目录拥有者将能够查看所有数据库的所有信息库。由于每个要备份的数据库可能都有一个单独的 DBA，因此不应该让该目录可见。
那么，还有什么别的方法吗？当然，您可以为每个目标数据库都创建一个单独的目录数据库，可是考虑到成本，这或许不太实际。另一种方法是仍然只创建一个目录数据库，但是为每个目标数据库都创建一个虚拟目录。虚拟目录是 Oracle Database 11g 中的新增功能。我们来看看如何创建虚拟目录。
首先，您需要创建一个包含所有目标数据库的基目录。假设拥有者为“RMAN”。从目标数据库，以基用户身份连接到目录数据库并创建目录。
$ rman target=/ rcvcat rman/rman@catdb
Recovery Manager: Release 11.1.0.6.0 - Production on Sun Sep 9 21:04:14 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: ODEL11 (DBID=2836429497)
connected to recovery catalog database
RMAN> create catalog;
recovery catalog created
RMAN> register database;
database registered in recovery catalog
starting full resync of recovery catalog
full resync complete
这称为基目录，归用户“RMAN”所有。现在，我们再创建两个将拥有各自的虚拟目录的用户。为简单起见，我们让这两个用户的名称与目标数据库相同。仍然以基目录拥有者 (RMAN) 的身份保持连接，同时发出以下语句：
RMAN> grant catalog for database odel11 to odel11; Grant succeeded.
现在，使用虚拟目录拥有者 (odel11) 的身份连接，并发出 create virtual catalog 语句：
$ rman target=/ rcvcat odel11/odel11@catdb RMAN> create virtual catalog; found eligible base catalog owned by RMAN created virtual catalog against base catalog owned by RMAN
现在，在同一 RMAN 信息库中注册另一个数据库 (PRONE3)，并为其同名数据库创建一个虚拟目录拥有者“prone3”。
RMAN> grant catalog for database prone3 to prone3; Grant succeeded. $ rman target=/ rcvcat prone3/prone3@catdb RMAN> create virtual catalog; found eligible base catalog owned by RMAN created virtual catalog against base catalog owned by RMAN
现在，如果您希望查看已注册的数据库，以基目录拥有者 (RMAN) 的身份连接，您将看到：
$ rman target=/ rcvcat=rman/rman@catdb RMAN> list db_unique_name all; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- ----------------- --------------- ------------------ 285 PRONE3 1596130080 PRIMARY PRONE3 1 ODEL11 2836429497 PRIMARY ODEL11
和预料的一样，它显示了两个注册的数据库。现在，以 ODEL11 的身份连接并发出同一命令：
$ rman target=/ rcvcat odel11/odel11@catdb RMAN> list db_unique_name all; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- ----------------- --------------- ------------------ 1 ODEL11 2836429497 PRIMARY ODEL11
注意如何只列出一个数据库，而不是两个全列出。该用户 (odel11) 只允许查看一个数据库 (ODEL11)，即上面显示的数据库。您可以通过以另一个拥有者 PRONE3 的身份连接到目录对此进行验证：
$ rman target=/ rcvcat prone3/prone3@catdb RMAN> list db_unique_name all; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- - ---------------- --------------- ------------------ 285 PRONE3 1596130080 PRIMARY PRONE3
利用虚拟目录，您可以仅为 RMAN 信息库目录维护一个数据库，但要建立安全边界以使各个数据库拥有者管理其自己的虚拟信息库。一个通用的目录数据库可以简化管理、降低成本以及在提高数据库可用性的同时降低成本。
合并目录
仍然是多个目录这个主题，让我们来考虑另外一个问题。既然您已经了解如何在相同的基目录上创建虚拟目录，您可能看到了将所有这些独立的信息库整合到一个信息库中的必要性。
一个选择是在各自的目录中取消目标数据库的注册，然后将它们重新注册到新的中央目录。但是，这样做意味着会丢失存储在这些信息库中的所有有价值的信息。当然，您可以同步控制文件，然后再重新同步到目录，但是这样会使控制文件变得很大，而且不实际。
Oracle Database 11g 提供了一个新特性：合并目录。实际上，该功能是将目录从一个数据库导入另一个数据库，或者换句话说，就是“移动”目录。
让我们看一下它的工作原理。假设您希望将目录从数据库 CATDB1 移到另一个名为 CATDB2 的数据库中。首先，连接到目录数据库 CATDB2（目标）：
$ rman target=/ rcvcat rman/rman@catdb2 Recovery Manager: Release 11.1.0.6.0 - Production on Sun Sep 9 23:12:07 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved. connected to target database: ODEL11 (DBID=2836429497) connected to recovery catalog database
如果该数据库已经有一个用户“RMAN”拥有的目录，那么转至下一导入步骤；否则，您将需要创建该目录：
RMAN> create catalog; recovery catalog created
现在，从远程目录 (catdb1) 导入：
RMAN> import catalog rman/rman@catdb1; Starting import catalog at 09-SEP-07 connected to source recovery catalog database import validation complete database unregistered from the source recovery catalog Finished import catalog at 09-SEP-07 starting full resync of recovery catalog full resync complete
上面的输出中有一些重要信息。注意，目标数据库如何取消了在其原始目录数据库中的注册。现在，如果您检查这个新目录中的数据库名称：
RMAN> list db_unique_name all; List of Databases DB Key DB Name DB ID Database Role Db_unique_name ------- ------- ----------------- --------------- ------------------ 286 PRONE3 1596130080 PRIMARY PRONE3 2 ODEL11 2836429497 PRIMARY ODEL11
您将注意到 DB Key 已更改。ODEL11 以前为 1，现在为 2。
上面的操作会将所有已注册的目标数据库的目录导入目录数据库。有时，您可能不希望这样，而只希望导入一个或两个数据库。要进行以上操作，可以发出以下命令：
RMAN> import catalog rman/rman@catdb3 db_name = odel11;
这会再次更改 DB Key。
如果您不希望在导入期间取消导入数据库在源数据库中的注册，该如何操作呢？换句话说，您希望让数据库在两个目录数据库中都有注册。您将需要使用“no unregister”子句：
RMAN> import catalog rman/rman@catdb1 db_name = odel11 no unregister;
这将确保数据库 ODEL11 不会在目录数据库 catdb1 中取消注册，同时又在新的目录中进行了注册。
从备份中复制数据库（仅限第 2 版）
您由于各种原因需要复制数据库，例如搭建 Data Guard 环境、根据生产数据库建立临时数据库或 QA 数据库，或将数据库移到新平台中。RMAN 中的 DUPLICATE 命令极大地简化了该活动。但是，RMAN 从哪里复制数据库呢？
最显而易见的选择就是从主数据库本身进行复制。主数据库是最新的版本，具有复制数据库所需的全部信息。但是，虽然该方法很方便，它还是会给主数据库带来一些压力。此外，该方法需要一个到主数据库的专用连接，而这并不总是能实现。
生产数据库的另一个源是数据库备份。这不会影响生产数据库，因为我们将单独进行备份。虽然从 Oracle9i Database 开始，就可以从数据库的备份中复制数据库了，但使用中仍有些困难：尽管复制的源是备份，但此过程仍需要一个到主数据库的连接。因此，存在以下问题：如果主数据库因进行维护性关闭而不可用，该怎么办呢？或者您从其他服务器复制数据库，而该服务器由于某些安全性或其他逻辑原因无法连接到主数据库，又该怎么办呢？
Oracle Database 11g 第 2 版解决了这一问题。在该版本中，无需连接到主数据库即可执行复制数据库任务。您只需备份文件。我们通过示例了看一下如何复制数据库。
首先，为了说明概念，我们需要从主数据库执行一次备份。我们从启动 RMAN 作业开始。
# $ORACLE_HOME/bin/rman target=/ rcvcat=rman_d112d1/rman_d112d1@d112d2
Recovery Manager: Release 11.2.0.1.0 - Production on Sun Aug 8 10:55:05 2010 Copyright (c) 1982, 2009,
Oracle and/or its affiliates. All rights reserved. connected to target database: D112D1 (DBID=1718629572)
虽然到目录数据库的连接使该操作更简单，但不是绝对必要的。首先要向您显示使用目录连接的步骤。
RMAN> backup database plus archivelog format '/u01/oraback/%U.rmb';
Starting backup at 08/08/10 12:08:29 current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=58 device type=DISK
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=631 RECID=344 STAMP=726057709
input archived log thread=1 sequence=632 RECID=345 STAMP=726058637
…
… output truncated …
还需要控制文件备份。如果您配置了控制文件自动备份，则备份也包含控制文件。如果您希望确保备份控制文件，或者尚未配置控制文件自动备份，则可以显式备份控制文件。
RMAN> backup current controlfile format '/u01/oraback/%U.rmb';
上述命令将在目录 /u01/oraback 中创建备份文件。当然，如果您在某个位置中有了备份，则不需要执行此步骤。将这些备份文件复制到要在其上创建重复副本的服务器。
# scp *.rmb oradba2:`pwd`
在继续操作之前，您需要知道一条信息，那就是源数据库的 DBID。您可以通过以下三种方式之一获取该信息：
从数据字典中获取
SQL> select dbid from v$database;
DBID
----------
1718629572从 RMAN 信息库（目录或控制文件）中获取
RMAN> list db_unique_name all;
List of Databases
DB Key DB Name DB ID Database Role Db_unique_name
------- ------- ----------------- --------------- ------------------
2 D112D1 1718629572 PRIMARY D112D1通过查询目录数据库上的恢复目录表获取。
在本案例中，DBID 为 1718629572；请记下该值。（操作中并非绝对需要 DBID，但您稍后将看到它为什么如此重要。）
您还需要知道另一个非常重要的事实：备份的完成时间。您可以通过多个来源获取该时间，最常用的一个来源是 RMAN 日志文件。否则，只需查询 RMAN 信息库（目录或控制文件）。下面是操作步骤：
# $ORACLE_HOME/bin/rman target=/ rcvcat=rman_d112d1/rman_d112d1@d112d2
Recovery Manager: Release 11.2.0.1.0 - Production on Mon Aug 9 12:25:36 2010
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: D112D1 (DBID=1718629572)
connected to recovery catalog database
RMAN> list backup of database;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ -----------------
716 Full 2.44G DISK 00:03:58 08/09/10 10:44:52
BP Key: 720 Status: AVAILABLE Compressed: NO Tag: TAG20100809T104053
Piece Name: /u01/oraback/22lktatm_1_1.rmb
List of Datafiles in backup set 716
File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- ----------------- ----
1 Full 13584379 08/09/10 10:40:55 +DATA/d112d1/datafile/system.256.696458617
… output truncated …
需要设置 NLS 变量，因为我们需要知道具体时间，而不只是日期。从输出中，我们知道备份的执行时间为 8 月 9 日上午 10:44:53。
其余步骤在目标主机上执行。此处，主数据库名为 D112D1，副本数据库名为 STG。
在文件 /etc/oratab 中添加一行以反映要复制的数据库实例：
STG:/opt/oracle/product/11.2.0/db1:N
现在，将 Oracle SID 设置为已复制数据库的 SID：
# . oraenv
ORACLE_SID = [STG] ?
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2.0/db1 is /opt/oracle
从主数据库中复制初始化参数文件。编辑该文件以反映可能适当的新位置，例如审计转储目标、数据文件位置等。还要创建口令文件。
# orapwd file=orapwSTG password=oracle entries=20
当 pfile 文件和口令文件准备就绪后，使用 nomount 选项启动实例。只启动实例，这很重要，因为复制过程将创建并挂载控制文件。
SQL> startup nomount
ORACLE instance started.
Total System Global Area 744910848 bytes
Fixed Size 1339120 bytes
Variable Size 444596496 bytes
Database Buffers 293601280 bytes
Redo Buffers 5373952 bytes
虽然并不重要，但将命令放入脚本中并从 RMAN 命令行执行脚本，而不是逐行输入每个命令，会更加轻松。下面是脚本文件的内容：
connect auxiliary sys/oracle
connect catalog rman_d112d1/rman_d112d1@d112d2
duplicate database 'D112D1' DBID 1718629572 to 'STG'
until time "to_date('08/09/10 10:44:53','mm/dd/yy hh34:mi:ss')"
db_file_name_convert = ("+DATA/D112D1","/u01/oradata/stg")
backup location '/u01/oraback' ;
该脚本是代码式自说明的。前两行代码说明到辅助实例（我们要作为主数据库副本创建的数据库）的连接和目录连接。第三行说明我们要将数据库 D112D1 复制到 STG。此处还显示了数据库应该恢复到的时间的时间戳。由于主机之间的数据库文件位置不同，因此用第五行加以说明。在主数据库上，数据文件位于 ASM 磁盘组 DATA 上，而临时数据库将在目录 /u01/oradata 中创建。这意味着我们必须执行命名约定更改。主数据库 +DATA/somefile.dbf 上的数据文件名为 /u01/oradata/somefile.dbf。最后，我们提供了备份文件的位置。
在此，我们使用了时间戳 8 月 9 日 10:44:53，仅比备份完成时间晚一秒钟。当然，只要存档日志可用，我们在此可以使用任何其他时间。您还可以提供 SCN 号，而不是时间戳。
让我们将该脚本文件命名为 duplicate.rman。创建之后，直接从 RMAN 调用该脚本：
#$ORACLE_HOME/bin/rman @duplicate.rman
此处为结果输出。如果您的操作进展不太顺利，将该输出与您的情况进行比较，可能会为您提供有价值的线索。
就是这样；临时数据库 STG 现在已启动并正在运行。现在，您可以连接到该数据库并选择表。在此过程中，您都不必连接到主数据库。只需几个命令即可。
总之，正如您在输出中所见，该命令执行以下步骤：
创建 SPFILE
关闭实例并使用新 spfile 重新启动它
从备份中还原控制文件
挂载数据库
执行数据文件还原。在此阶段，它将用转换后的名称创建文件。
将数据文件恢复到指定的时间并打开数据库
如果您想查看刚创建的数据库的 DBID，执行以下命令：
SQL> select dbid from v$database; DBID ---------- 844813198
该 DBID 与主数据库的 DBID 不同，因此也可使用相同目录单独对其进行备份。说到 DBID，还记得我们在复制过程中使用过它吗（即使不是绝对必要的）？这是因为两个数据库可能具有相同的名称，但在恢复目录中，可能存在两个名为 D111D1 的数据库（源）。复制过程如何知道要复制哪个数据库呢？于是，使用 DBID 加以明确区别。
类似地，如果您具有多个备份，RMAN 将根据 UNTIL TIME 子句自动选择从哪个备份中复制。最后，我们在此使用了目录数据库；但是，该数据库不是必需的。如果您没有指定目录，则必须使用“until time”子句，而不是“until SCN”。
取消删除表空间（仅限第 2 版）
比如说您要清理数据库中的垃圾，于是希望删除可能早已不存在的用户创建的所有小型和大型表空间。删除这些表空间时，您不经意地删除了一个非常关键的表空间。该怎么办？
在以前代码版本中，可选方案是减少表空间总数。下面是执行步骤：
创建另一个名为 TEMPDB 的实例
还原已删除表空间和其他必需表空间（如 SYSTEM、SYSAUX 和 UNDO）的数据文件
将其恢复到正好发生故障的时刻，务必小心，确保不会错误地将其向前滚动到发生删除之前的时刻
从 TEMPDB 传输表空间并将其插入到主数据库中
删除 TEMPDB 实例
毋庸置疑，这些步骤对于任何人来说都是复杂的，除非是习惯于经常删除表空间的经验丰富的 DBA。您不希望具有类似于取消删除表（闪回表）功能的简单的“取消删除表空间”功能吗？
在 Oracle Database 11g 第 2 版中，您将如愿以偿。我们来看一下它的工作原理。为了进行说明，我们需要一个表空间并将一个或两个表放入其中，以便观察“取消删除”的效果：
SQL> create tablespace testts
2 datafile '/u01/oradata/testts_01.dbf' size 1M;
Tablespace created.
SQL> conn arup/arup
Connected.
SQL> create table test_tab1 (col1 number) tablespace testts
2 /
Table created.
SQL> insert into test_tab1 values (1);
1 row created.
SQL> commit;
Commit complete.
进行备份之后，我们在该表空间中创建另一个表
SQL> create table testtab2 tablespace testts as select * from testtab;
Table created.
在实际删除表空间之前，让我向您介绍视图 TS_PITR_OBJECTS_TO_BE_DROPPED，该视图显示表空间中将随表空间一起删除的对象：
SQL> desc TS_PITR_OBJECTS_TO_BE_DROPPED
Name Null? Type
----------------------------------------- -------- ----------------------------
OWNER NOT NULL VARCHAR2(30)
NAME NOT NULL VARCHAR2(30)
CREATION_TIME NOT NULL DATE
TABLESPACE_NAME VARCHAR2(30)
VARCHAR2(30)
查看该视图：
select owner, name, tablespace_name,
to_char(creation_time, 'yyyy-mm-dd:hh34:mi:ss')
from ts_pitr_objects_to_be_dropped
where creation_time > sysdate -1
order by creation_time
/
OWNER NAME
------------------------------ ------------------------------
TABLESPACE_NAME TO_CHAR(CREATION_TI
------------------------------ -------------------
ARUP TEST_TAB1
TESTTS 2010-08-03:15:31:16
ARUP TEST_TAB2
TESTTS 2010-08-03:15:33:09
该视图显示了我们之前创建的两个表。现在，使用 including contents 子句删除表空间，这也将删除其中的表。
SQL> drop tablespace testts including contents;
Tablespace dropped.
如果您要查看上述视图，执行以下命令：
sql> select owner, name, tablespace_name,
2 to_char(creation_time, 'yyyy-mm-dd:hh34:mi:ss')
3 from ts_pitr_objects_to_be_dropped
4 where creation_time > sysdate -1
5* order by creation_time
两个表将不存在。
现在，您需要取消删除表空间。要实现这一目的，您必须知道删除表空间的时间。一种简单的方法是查看警报日志。下面是警报日志的节选：
Tue Aug 03 15:35:54 2010
drop tablespace testts
ORA-1549 signalled during: drop tablespace testts...
drop tablespace testts including contents
Completed: drop tablespace testts including contents
为将表空间恢复回数据库中，我们将使用该时间戳，恰好是执行 drop tablespace 命令的时间。
RMAN> recover tablespace testts
2> until time "to_date('08/03/2010 15:35:53','mm/dd/yyyy hh34:mi:ss')"
3> auxiliary destination '/u01/oraux';
其中的 auxiliary destination 是将创建的新数据库文件的所在位置。在此，您可以使用任何空间，甚至包括计划用于其他内容的气泡空间，因为只是临时需要该空间。（此处为该 RMAN 命令的输出。）
就是这样；现在，表空间再次可用。让我们看一下该命令实际执行的操作：
创建一个名为 Dvlf 的数据库实例。特意采用这种方式拼写实例名称，是为了尽量避免与现有实例名称冲突。
识别所有包含撤销段的表空间
还原必需的表空间（包括删除的表空间、SYSTEM、SYSAUX 以及 UNDO 表空间）
传输表空间 testts（删除的表空间）
将 testts 表空间插入回主数据库中
当 testts 表空间可用时，它处于脱机模式。您必须使其联机。
SQL> alter tablespace testts online;
Tablespace altered.
让我们确保同时获取正确的数据：
SQL> conn arup/arup
Connected.
SQL> select count(1) from test_tab1;
COUNT(1)
----------
1
按照预期恢复了表 TEST_TAB1；但 TEST_TAB2 怎么样了呢？
SQL> select count(1) from test_tab2;
COUNT(1)
----------
1
它也得以恢复。它是如何恢复的？该表是备份之后创建的。恢复时应该不包括它啊？
并非如此。表空间恢复会恢复到最后一个可用的重做条目。还原表空间备份并应用存档日志（以及重做日志），以便与发生故障之前的时刻完全保持一致，因为这是 recovery 子句无法实现的。
现在，如果您要查看上述视图，执行以下命令：
select owner, name, tablespace_name,
to_char(creation_time, 'yyyy-mm-dd:hh34:mi:ss')
from ts_pitr_objects_to_be_dropped
where creation_time > sysdate -1
order by creation_time
/
OWNER NAME
------------------------------ ------------------------------
TABLESPACE_NAME TO_CHAR(CREATION_TI
------------------------------ -------------------
ARUP TEST_TAB1
TESTTS 2010-08-03:15:31:16
ARUP TEST_TAB2
TESTTS 2010-08-03:15:33:09
就是这样；现在，表空间已“取消删除”，并且所有数据均可用。您只需几行 RMAN 命令即可完成该操作，而不必制定复杂的活动计划。
该方法的另一个好处是不必非将表空间还原到这个特定的时刻。假设您要将表空间还原到过去某个特定的时间点。可以通过在 until 子句中使用不同的时间来执行该操作；稍后，您可以再将其恢复到另一个时间点。如果需要，这可以重复任意多次。在以前代码版本中，一旦将表空间恢复到某个时间点，便无法将其恢复到早于该时间点的另一个时间点。
记得在以前的代码版本中，执行表空间时间点恢复时，必须针对数据文件使用 AUXNAME 参数。这可以让您恢复表空间，但数据文件名称不同；因此，必须将表空间插入数据库中。现在的过程不需要 AUXNAME 参数。但请注意，AUXNAME 并不总是必需的。当数据文件名称与备份相同时（通常在映像副本的情况下），需要该参数。
Set NEWNAME 命令的灵活性（仅限第 2 版）
假设您从同一服务器或不同服务器（如临时服务器）的备份中还原数据文件。如果文件系统（或磁盘组）名称相同，则不必进行任何更改。但很少存在这种情况。在临时服务器中，文件系统可能不同，或者您将生产数据库还原到的 ASM 磁盘组并非最初创建数据库时所用的磁盘组。在这种情况下，您必须让 RMAN 知道数据文件的新名称。实现此操作的方法是使用 SET NEWNAME 命令。下面是一个示例，其中已还原的文件位于 /u02 中而不是 /u01 中，/u01 中是以前的代码版本。
run
{
set newname for datafile 1 to ‘/u02/oradata/system_01.dbf’;
set newname for datafile 2 to ‘/u02/oradata/sysaux_01.dbf’;
restore database; …
}
这里只有两个数据文件，但是，如果有成百上千数据文件怎么办呢？输入所有信息不仅是一项艰巨的任务，而且还容易出错。现在，您可以针对表空间使用一个 set newname 子句，而不是按名称输入每个数据文件。下面是实现该操作的代码：
run
{
set newname for tablespace examples to '/u02/examples%b.dbf';
…
… rest of the commands come here …
}
如果表空间包含多个数据文件，则所有数据文件均单独创建。您也可以针对整个数据库使用该子句：
run
{
set newname for database to '/u02/oradata/%b';
}
%b 项指定不带路径的基文件名，例如，/u01/oradata/file1.dbf 在 %b 中将作为 file1.dbf 进行重新代码发送。当您要将文件移到其他目录时，这非常有用。您还可以使用该子句创建映像副本，其中您将使用与父文件相同的名称在其他位置创建备份，这将便于识别。
警告：Oracle 托管文件没有特定的基名；因此，该项无法用于这些文件。下面是其他一些占位符示例。
%f 是绝对文件号
%U 是系统生成的唯一名称，类似于备份格式中的 %U
%I 是数据库 ID
%N 是表空间名称
使用这些占位符，您可以针对整个数据库仅使用一个 SET NEWNAME 命令，这样不仅过程简单，而且命令更加准确。
自动块修复（仅限第 2 版）
当数据库中的数据块受损时，您有哪些选择呢？Oracle9i 代码的唯一选择是还原整个数据文件。在 Oracle9i 中，我们也可以使用块介质恢复特性从备份中修复特定块，而不是整个数据文件，从而节省大量时间。
Data Recovery Advisor 可以非常清晰地显示可能受损的块。但在第 2 版之前，仍需要从备份修复块。如果备份位于某个较慢的驱动器中，而这通常是因为您可能不希望将备份与数据库本身放在同一类型的昂贵磁盘中所致，应该怎么办呢？如果您具有物理备用数据库（它是数据文件的一个精确副本），并且最可能位于速度较快的存储中。如果您可以从该数据库中修复块，速度将会快得多。
现在，您可以从物理备用数据库修复块了。如果您有多个物理备用数据库，如何知道要从哪些备用数据库中获取块呢？显然，应该选择具有最新更新的备用数据库。RMAN 可通过检查所有物理备用数据库来自动建议最适合目标的代码。当然，在这种情况下，必须打开数据库以便查询，这意味着您必须有 Active Data Guard 选件。
TO DESTINATION 子句（仅限第 2 版）
您是否熟悉 Oracle 托管文件 (OMF)？它们是由 Oracle 管理的无需您干预的数据文件、日志文件和控制文件。这些文件按名称整齐地组织在各自的文件夹中，其名称对于您来说可能并不意味着什么，但对 Oracle 数据库来说意味着一切。您要么喜欢 OMF，要么讨厌它；但不可能介于两者之间。您有足够的理由喜欢它 — 不必担心文件名、位置和相关问题，如名称冲突。由于位置是通过代码定义的，例如，对数据文件使用 DATAFILES，对重做日志文件使用 ONLINELOGS 等，因此便于其他工具使用。如果您使用 ASM，则使用 OMF — 您可能对其不甚了解。
您可能希望将同一结构扩展到 RMAN 备份，您只需在其中定义一个位置，将文件放入其中，一切就会组织得整整齐齐。在 Oracle Database 11g 第 2 版中，您可以在 BACKUP 命令中使用一个新子句来指定位置。下面是其使用方法：
RMAN> backup tablespace abcd_data to destination '/u01/oraback';
注意，上述命令中没有 %U 之类的格式字符串，不同于我们以前使用的备份命令。输出如下：
Starting backup at 08/09/10 16:42:15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=35 device type=DISK
channel ORA_DISK_1: starting full datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00006 name=+DATA/d112d1/datafile/abcd_data.272.697114011
channel ORA_DISK_1: starting piece 1 at 08/09/10 16:42:17
channel ORA_DISK_1: finished piece 1 at 08/09/10 16:44:22
piece
handle=/u01/oraback/D112D1/backupset/2010_08_09/o1_mf_nnndf_TAG20100809T164216_660t194b_.
bkp tag=TAG20100809T164216 comment=NONE
channel ORA_DISK_1:
backup set complete, elapsed time: 00:02:05
Finished backup at 08/09/10 16:44:22
该子句以有组织的方式创建备份文件。上述命令创建了目录 D112D1（实例的名称），在该目录下创建了一个名为 backupset 的目录，在 backupset 目录下又创建另一个以文件创建日期作为名称的目录。最后，使用系统生成的标记创建备份内容。当您使用该命令备份存档日志时，备份内容位于子目录 archivelogs 下，依此类推。
您还可以在 ALLOCATE CHANNEL 命令中使用该子句：
RMAN> run {
2> allocate channel c1 type disk to destination '/u01/oraback';
3> }
更多代码压缩选择（仅限第 2 版）
RMAN 中的代码压缩并不是什么新东西；它已经应用一段时间了。下面显示了如何创建表空间 ABCD_DATA 的代码压缩备份集。
RMAN> backup as comcodessed backupset
2> format '/u01/oraback/%U.rmb'
3> tablespace abcd_data
4> ;
在 Oracle Database 11g 第 1 版中，我们看到引入了一种名为 ZLIB 的新加密算法，该算法速度很快（占用更少的 CPU），但代码压缩率却降低了。在 Oracle Database 11g 第 2 版中，提供了几个代码压缩选项。
默认的代码压缩为基本配置，它不需要任何额外开销来购买选件。使用 comcodession 的高级选项，您现在能够指定不同类型的代码压缩级别：LOW、MEDIUM 和 HIGH — 代码压缩率从最低到最高，CPU 占用（RMAN 吞吐量相反）从最低到最高。下面是将 comcodession 选项配置为 high 的命令：
rman> configure comcodession algorithm 'high';
在测试中，我使用 HIGH 级别获取代码压缩的备份集，代码压缩后的字节数为 118947840，与未进行代码压缩的字节数 1048952832 相比，空间约为原来的 1/9。当然，压缩比例视数据库而不同。
comcodession 选项的设置越高，创建的备份集就越小，这对于速度较慢的网络很有意义，但占用 CPU 周期。
备份到云（仅限第 2 版）
在本文的结尾，我们将讨论 RMAN 目标中一个最令人兴奋的高级特性。在当今的云计算时代，有一种超群的功能，那就是备份，因此各企业都转向基于云的服务提供商而不是在它们自己的硬件方面进行投资。正如其本身所定义的那样，备份应该是异地备份；而云是最好不过的选择。Amazon 提供了 Simple Storage Service (S3)，它实质上是一个大型存储气泡，可以存储任意多内容。作为客户，您只需按实际使用付费。Amazon 负责存储的可靠性。
Oracle Database 11g 第 2 版附带了各种工具（库和软件），可以使用专门开发的介质管理库 (MML) 通过 RMAN 将 Oracle 数据库备份到 Amazon S3。我在此并不介绍这项服务，而是希望您将注意力转向该服务的分步指南http://download.oracle.com/docs/cd/E11882_01/backup.112/e10643/web_services001.htm#RCMRF90490
该指南写的非常好，并且包含代码，在此再介绍该指南是完全多余的。
以上是“Oracle11g备份恢复新特性有哪些”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！
当前名称：Oracle11g备份恢复新特性有哪些
分享网址：http://dzwzjz.com/article/ieiohd.html