论坛徽章:: 0

电梯直达

1楼 [收藏(0)] [报告]

发表于 2004-07-13 17:09 |只看该作者 |倒序浏览

RMAN \r\n\r\nRMAN 的功能更强大，它具有重新设计的增量备份模式、增量备份的脱机恢复、预览恢复、复原日志进行恢复、文件压缩等功能。 \r\n\r\n大多数人都认同 RMAN 是用于 Oracle 数据库备份的实际工具。但是与它们所具有的强大功能相比，RMAN 的早期版本并未提供人们所期待的一些功能。就像许多 DBA 一样，如果它没有包含我认为必须具有的功能，我将会异常恼怒。 \r\n\r\n幸运的是，Oracle 数据库 10g 通过合并人们所想要的许多功能解决了很多这类问题，这使 RMAN 成为一种更强大、更有用的工具。让我们看一下这些功能。 \r\n\r\n\r\n再论增量备份 \r\n\r\nRMAN 包含一个用于增量备份的选项。但是老实讲，您多久使用一次呢？可能经常用，也可能永远也不会用。 \r\n\r\n该选项用于指示该工具以相同或较低的级别来备份自上一次增量备份后发生改变的块。例如，在第 1 天采用完全备份 (level_0)，而在第 2、3 天采用两个 level_1 的增量。后面的两个备份只是备份了第 1 天和第 2 天之间，及第 2 天和第 3 天之间更改过的块，而不是跨整个备份时间进行备份。这种策略减少了备份规模、需要的空间较少，并缩小了备份窗口，减少了网络间移动的数据量。 \r\n\r\n执行增量备份的最重要的原因是：与数据仓库环境关联起来，在该环境中许多操作都是在 NOLOGGING 模式下执行的，并且数据更改不会涉及到存档的日志文件—因此，不可能发生介质恢复。考虑到今天的数据仓库的巨大规模，以及其中的大部分数据并没有发生改变的事实，就会知道执行完全备份既不值得又不实际。相反，在 RMAN 中执行增量备份是一个理想的选择。 \r\n\r\n既然如此，那么为什么许多 DBA 极少执行增量备份呢？一个原因是：在 Oracle 9i 及其较低的版本中，RMAN 会扫描所有的数据块以确定要备份的内容。这个过程给系统施加了如此大的压力，以致于执行增量备份变得不实际。 \r\n\r\nOracle 数据库 10g RMAN 以消除了该缺陷的方式来执行增量备份。它使用一个文件，类似于文件系统中的日志，来跟踪自上一次备份起更改过的块。RMAN 读取该文件来确定将要备份的块。 \r\n\r\n您可以通过发布以下命令来启用该跟踪机制： \r\n\r\nSQL>; alter database enable block change tracking using file \'/rman_bkups/change.log\';\r\n\r\n\r\n该命令将创建一个名为 /rman_bkups/change.log 的二进制文件，以用于跟踪。相反，您可以使用以下命令来禁用跟踪： \r\n\r\nSQL>; alter database disable block change tracking;\r\n\r\n\r\n要想查看当前是否启用了对更改的跟踪，您可以查询： \r\n\r\nSQL>; select filename, status from v$block_change_tracking;\r\n\r\n\r\n快速恢复区 \r\n\r\n在 Oracle 9i 中引入的闪回查询，依赖于撤消表空间来闪回到先前的版本，因此限制了它深入到过去的能力。快速恢复通过创建闪回日志提供了一个可选的解决方案，它类似于重做日志，用于将数据库恢复到先前的状态。总之，您为数据库创建了一个快速恢复区，指定了其大小，并用如下 SQL 命令将数据库置于快速恢复模式下： \r\n\r\nalter system set db_recovery_file_dest = \'/ora_flash_area\';\r\nalter system set db_recovery_file_dest_size = 2g;\r\nalter system set db_flashback_retention_target = 1440;\r\nalter database flashback on; \r\n\r\n\r\n该数据库必须处于存档日志模式下以支持闪回。此过程在目录 /ora_flash_area 中创建了 Oracle 管理文件，其总大小高达 2GB。对数据库所作的更改将写入到这些文件中，并且可用于将数据库快速恢复到过去的某个点上。 \r\n\r\n默认情况下，RMAN 还使用 /ora_flash_area 来存储备份文件；因此，RMAN 是存储在磁盘上，而不是磁带上。鉴于此，您就有能力指定您需要备份的天数。在该期限之后，如果需要更多的空间，则会自动将这些文件删除。 \r\n\r\n快速恢复区不必是一个文件系统或一个目录，但是—，它可以是一个自动存储管理 (ASM) 磁盘组。如果是那样的话，就可以通过如下命令来指定快速恢复区： \r\n\r\nalter system set db_recovery_file_dest = \'+dskgrp1\';\r\n\r\n\r\n因此，结合使用 ASM 和 RMAN，您就可以使用廉价的磁盘（如 Serial ATA 或 SCSI 驱动）来构建一个高度可伸缩的、容错能力强的存储系统，而不需要额外的软件。（有关 ASM 的详细信息，请参阅本系列中的第 8 周的内容。）此过程不但使存储过程更快，也使之能用足够便宜的、基于磁带的方法来完成。 \r\n\r\n一个额外的好处是防止用户错误。由于 ASM 不是真正的文件系统，使其遭受 DBA 和系统管理员意外破坏的可能性也更小一些。 \r\n\r\n增量合并 \r\n\r\n假如您有如下备份计划： \r\n\r\n星期天 - 第 0 级（完全），带有标签 level_0\r\n星期一 - 第 1 级（增量），带有标签 level_1_mon\r\n星期二 - 第 1 级（增量），带有标签 level_1_tue \r\n\r\n等等。如果数据库在星期天发生故障，在 Oracle 10g 之前的版本中，您将不得不恢复标签 level_0，然后应用所有六个增量。它将持续一段较长的时间，这是许多 DBA 不进行增量备份的另一个原因。 \r\n\r\nOracle 数据库 10g RMAN 从根本上改变了此格局。现在，您的增量备份命令看起来如下所示： \r\n\r\nRMAN>; backup incremental level_1 for recover of copy with tag level_0 database;\r\n\r\n\r\n在此，我们指示 RMAN 进行 level_1 增量备份，并将其与带有 level_0 标签的完全备份副本合并。在执行该命令之后，level_0 就成为了那一天的完全备份。 \r\n\r\n因此，在星期二，带有标签 level_0 的备份，当将其与 level_1 增量备份合并时，它就变得与完全的星期二备份相等。同样地，对于星期六采用的增量，当采用磁盘上的备份时，它将会与完全的 level_0 星期六备份相等。如果数据库在星期六发生故障，您只需恢复 level_0 备份外加一小份存档日志，使数据库一致；在此不需要应用额外的增量。该方法显著地削减了恢复时间、加快了备份速度，并消除了再一次执行完全的数据库备份的需要。 \r\n\r\n压缩文件 \r\n\r\n对于快速恢复区中基于磁盘的备份，仍有一个大的限制：磁盘空间。特别是当经网络进行时—通常情况下就是这样—那么创建一个尽可能小的备份集是明智的。在 Oracle 数据库 10g RMAN 中，您可以在备份命令内部压缩文件： \r\n\r\nRMAN>; backup as compressed backupset incremental level 1 database;\r\n\r\n\r\n注意子句 COMPRESSED 的用法。它将用一个显著不同的方式压缩备份文件：在恢复时，RMAN 不用解压缩就能读取文件。为了确认压缩，检查如下的输出信息： \r\n\r\nchannel ORA_DISK_1:starting compressed incremental level 1 datafile backupset\r\n\r\n\r\n此外，您可以通过检查 RMAN 列表输出来验证备份已被压缩： \r\n\r\nRMAN>; list output;\r\n\r\nBS Key Type LV Size Device Type Elapsed Time Completion Time\r\n------- ---- -- ---------- ----------- ------------ ---------------\r\n3 Incr 1 2M DISK 00:00:00 26-FEB-04 \r\nBP Key:3 Status:AVAILABLE Compressed:YES Tag:TAG20040226T100154\r\nPiece Name:/ora_flash_area/SMILEY10/backupset/2004_02_26/o1_mf_ncsn1_TAG20040226T100154_03w2m3lr_.bkp\r\nControlfile Included:Ckp SCN:318556 Ckp time:26-FEB-04\r\nSPFILE Included:Modification time:26-FEB-04\r\n\r\n\r\n对于任意的压缩过程，该方法都会对 CPU 产生压力。作为折衷，您可以在磁盘上保存更多的 RMAN 备份，它准备好为还原和恢复操作所用。此外，您可以在物理备用数据库上制作 RMAN 备份，它可用于恢复初始的数据库。该方法将备份源卸载到另一台主机上。 \r\n\r\n在您开始行动之前先看看：恢复预览 \r\n\r\n在 Oracle 数据库 10g中，RMAN 通过提供执行恢复操作所需要的预览备份的能力向前迈进了一大步。 \r\n\r\nRMAN>; restore database preview;\r\n\r\n\r\n列表 1 显示了该操作的输出结果。您还可以预览特定的恢复操作；例如： \r\n\r\nrestore tablespace users preview;\r\n\r\n\r\n预览允许您通过执行周期性的、有规则的检查，来确保您的备份基础架构的恢复准备就绪。 \r\n\r\nResetlogs 和恢复 \r\n\r\n假设您丢失了当前的联机重做日志文件，并且您不得不执行一个不完全的数据库恢复—一种很少见但听说过的情况。最大的问题是 resetlogs；在不完全的恢复之后，您必须用 resetlogs 子句打开数据库，它把日志线程的序列号设置为 1，会使您的 RMAN 中的早期备份作废并使恢复操作面临更多的挑战。 \r\n\r\n在 Oracle 9i 及其较低的版本中，如果您需要将数据库恢复到执行 resetlogs 操作之前的某个版本，您将不得不恢复到一个不同的拷贝。在 Oracle 数据库 10g 中，您不必这样做。由于控制文件中额外的基础架构，在执行 resetlogs 之前或之后，RMAN 现在都可以容易地使用所有备份来恢复 Oracle 数据库。它不需要关闭数据库来制作一个备份。这种新功能意味着在执行 resetlogs 操作之后，可以立即为用户社区重新打开数据库。 \r\n\r\n为 RMAN 作好准备 \r\n\r\nOracle 数据库 10g RMAN 中的增强功能使它成为您的备份策略中的甚至更具强制性的工具。对增量备份过程的改进只会使 RMAN 难以被忽视。 \r\n\r\n有关 Oracle 10g 中的 RMAN 的更多信息，请参阅 Oracle Database Backup and Recovery Basics 10g 第 1 版 (10.1) 中第 4 章的内容。