ORACLE数据库备份入门：第二部分：6-备份元数据维护

原创已于 2025-05-15 08:44:17 修改 · 972 阅读

13 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

数据库备份

于 2025-03-27 15:34:37 首次发布

备份的元数据(catalog)，保存在数据库的控制文件中（也可以保存在远端的catalog库中）。下面介绍一些常用的维护操作。

1. 查看备份信息

通过之前的两个简单场景，应该对备份和恢复操作有了基本的了解。现在，我们需要了解如何查看备份信息，这是恢复时经常需要了解的，用于制定具体的恢复方法。
在这里插入图片描述

首先，我们以“summary”的方式查看备份记录。
字段的解释如下：
Key：Backup set序号
TY：操作类型，B代理Backup
LV：备份的level，如0或1级备份，F表示控制文件和参数文件备份，A表示归档日志备份
S：状态，A表示可用，X表示过期
Device Type：DISK表示数据备份到磁盘，SBT表示数据备份到介质服务器（备份软件服务）
Completion Time：表示备份完成时间
#Pieces：当前Backup Set对应了几个piece，也就是生成了几个备份文件
#Copies：备份有几个副本
Compressed：是否进行压缩
Tag：Backup Set标签。备份时自动分配，也可手动指定。这个属性在管理备份时有很大作用，后续后介绍
Summary是以汇总的方式简要的列出备份的信息，如果想查看具体的备份内容，可使用list backup来显示所有详细信息。但是这种方式显示内容过多，可读性不好，因此可使用命令查看具体的Backup Set信息：
在这里插入图片描述
Backup Set 46是数据文件备份，包括了4个数据文件，即1、3、4、7。Piece Name是备份数据保存和路径。

Backup Set 52是归档备份，包括了9个日志文件。每个文件标注了SCN的起止编号，以及线程号(Thrd)、顺序号(Seq)。
也可以按照类型来查看，例如输出归档的备份信息：
在这里插入图片描述

可以更精确的定位，如找到某个SCN所在的归档日志：
在这里插入图片描述

也可以按照时间查找备份信息：
在这里插入图片描述

更多的使用语法，需要参照官方文档《Database Backup and Recovery Reference》。

2. 清除备份

有些时候我们需要清除备份数据和备份信息，减少存储空间的点用，这也是管理员的日常工作项目之一。清除操作命令：
删除全部备份，
在这里插入图片描述

删除指定日期，如14天之前的备份，

 RMAN> delete backup completed before 'sysdate-14';

有时候，在删除备份时会遇到这样的错误，
在这里插入图片描述

提示删除失败，原因是状态不一致。为什么会出现这种错误？同时还它还提示使用CROSSCHECK命令修复。
数据库要求备份信息和备份数据的存储状态保持一致，也就是Catalog和文件系统的状态要相同。什么情况下会不一致？例如，我在文件系统中删除了备份数据，但是备份信息在控制文件中保存，它不会感知操作系统的删除动作，这就是不一致。因此，删除备份之前，先要让它保持一致。例如：
在这里插入图片描述

Backup Set 51状态变成了Expired，信息同步完成，再进行一次删除尝试。
在这里插入图片描述

删除成功，Backup Set 51在备份信息中被清除掉。
也可以使用crosscheck backup，一行命令对所有备份信息进行校验。
有些系统没有分配默认的通道，在进行以上操作时会提示需要进入维护通道，可以手工分配通道：
在这里插入图片描述

3. CATALOG数据库

前面提到了，备份的catalog信息保存在控制文件中，但是它有局限性。比如，受控制文件物理大小限制，只能保存近期的备份信息（默认7天）。又比如，在Data Guard环境中，主库和备库的备份要进行统一管理。在主库在控制文件中看不到备库的备份信息，反之亦然。在任何一端需要进行恢复时，就必须要先从备份数据中恢复控制文件，这带来了很多不便。在实际操作中，备库通常会承担备份源的角色。当主库需要进行恢复操作时，本地的控制文件中没有任何备份信息，无法完成恢复。这类的场景，必须要使用Catalog数据库。

3.1 使用CATALOG数据库

Catalog数据库，形式上就是一个普通的Oracle实例，只是创建了一个特殊的Schema。整个环境中，使用一个或多个Catalog服务器，集中管理全部数据库的备份信息。DBA只需要在Catalog数据库中，就可以查看所有数据库的备份情况。回到之前的Data Guard场景的例子，看看Catalog数据库如何工作。首先，在Catalog数据库中注册数据库，注册主库和备库的任意一端都可以。在备份时，使用新的连接方式进入RMAN，

[oracle ~]$ rman target / catalog username/password@catalogDB

进入RMAN终端后，按照之前的操作即可，所有的备份信息会同时保存在控制文件和Catalog数据库中。
在备库完成备份后，主库通过以上连接方式进入RMAN，Catalog数据库会自动识别出主库和备库的关系（相同的DBID）。这时，可以利用备库的备份数据来进行恢复了。

3.2 RMAN脚本

除了保存备份的信息之外，CATALOG数据库还可以保存RMAN脚本。例如，

[oracle ~]$ rman target / catalog username/password@catalogDB
RMAN> create script backup_test1 {
allocate channel c1 type disk format ‘/home/oracle/bk/%U’ database;
}
RMAN> run {
Execute script backup_test1;
}

查看脚本列表，

RMAN> list script name;

查看脚本内容，

RMAN> print script backup_test;

3.3 INCARNATION

在CATALOG这个章节引入INCARNATION这个概念的讨论，并不是两者在逻辑上有什么必然的关系，而是通常在CATALOG数据库的场景下，遇到INCARNATION的问题可能性更高。前面我们介绍过SCN的概念，它是持续增长的正整数，但是它并非一直是按照一条直线变化的，它会“分叉”。如图，我们假设数据库的初始SCN为100，在SCN 200时进行了备份，之后进行运行。这个截断，定义为INCARNATION 1。在某一时刻故障发生了，使用SCN 200时间点的备份数据进行了恢复。如果没有故障发生，数据将会正常的向SCN 300前进。由于恢复进行RESETLOGS，因此生成了新的INCARNATION 2。在SCN 300时间点，进行了一次备份。又在某一时刻，数据库再次出现故障，使用了SCN 300时间点的备份数据进行了恢复。如果没有发生故障，数据库会正常的向SCN 400前进。恢复依然使用RESETLOGS，因此新的INCARNATION 3产生了。
在这里插入图片描述
查看INCARNATION信息，

当前数据库的4个INCARNATION，第一个为实验室版本，第二个为创建数据库时的版本。如果从没有对数据库进行过RESETLOGS，那将始终只能看到前两个INCARNATION。第一个INCARNATION都是从RESETLOGS开始的，SCN为RESETLOGS操作之前的SCN+1.
看起来还挺复杂的，像科幻电影里的平行宇宙，但是这对备份、恢复有什么影响呢？我们进行日常运维时也没有遇到过和INCARNATION相关的问题。所以，为什么要去关注它？通常情况下，备份的CATALOG保存在控制文件中，每一次恢复，特别是全量恢复时，都会先去恢复同一套备份数据中的控制文件。因此恢复任务没有跨越INCARNATION，问题也就没有体现出来。但是在CATALOG数据库的情况下，备份信息保存在一个台独立的数据库中，包括所有的INCARNATION版本。因为RESETLOGS不会改变DBID，CATALOG始终认为是同一个数据。在恢复时，如果当前数据库尝试去调取不同版本INCARNATION的备份数据，控制文件与CATALOG数据库里保存的备份数据信息不一致，恢复会失败。
演示一个例子，

在这里插入图片描述
对数据库进行RECOVER时报错，提示INCARNATION不一致。我们来查看一下当前数据库的INCARNATION情况，

再来看看CATALOG数据库的INCARNATION情况，
在这里插入图片描述

问题找到了，控制文件与CATALOG数据库中的当前INCARNATION不同。控制文件中记录的CURRENT为5402484，但是它在CATALOG中被标记为ORPHAN，意为与其它INCARNATION没有任务依赖关系。而CATALOG中记录的CURRENT的RESETLOGS SCN为1920977，原因有很多种可能性。数据库恢复时，自动从CATALOG获取的CURRENT与控制文件中的不一致，因此恢复失败了。解决办法也简单，在恢复前RESET控制文件中的ID，保持与CATALOG中的CURRENT ID相同。

RMAN> reset database to incarnation 11586;

再进行恢复，问题就解决了。
CSDN视频课程：
https://edu.csdn.net/lecturer/8135?spm=1002.2001.3001.4144

标签