本文档根据官方文档,进行整理。
DM 数据库中的数据存储在数据库的物理数据文件中,数据文件按照页、簇和段的方式进行管理,数据页是最小的数据存储单元。任何一个对 DM 数据库的操作,归根结底都是对某个数据文件页的读写操作。
DM备份的文件内容有哪些?
- 从数据库文件中拷贝有效的数据页保存到备份集中,这里的有效数据页包括数据文件的描述页和被分配使用的数据页。
- 数据库继续运行期间,备份过程中产生的归档日志。
还原与恢复是备份的逆过程。还原是将备份集中的有效数据页重新写入目标数据文件的过程。恢复则是指通过重做归档日志,将数据库状态恢复到备份结束时的状态;也可以恢复到指定时间点和指定 LSN。恢复结束以后,数据库中可能存在处于未提交状态的活动事务,这些活动事务在恢复结束后的第一次数据库系统启动时,会由 DM 数据库自动进行回滚。备份、还原与恢复的关系如图所示。
DM 数据库的表空间是一个逻辑概念,其目的主要是为了方便数据库的管理,数据库的所有对象在逻辑上都存放在某个表空间中,而物理上都存储在所属表空间的数据文件中。一个表空间由一个或多个数据文件组成。
数据文件是数据库中最重要的文件类型,是真实数据存储的地方。DM 中数据文件的扩展名为.DBF,分为系统默认生成的数据文件和用户自己创建的数据文件两类。需要注意的是,HUGE 数据文件不同于一般数据文件,其扩展名为.DTA。
DM 数据库中的表空间可以分为普通表空间
和混合表空间
。普通表空间
不能存储 HUGE 表,而混合表空间
可以同时存储普通(非 HUGE)表和 HUGE 表,其中 HUGE 数据文件存储在混合表空间定义中指定的 HUGE 数据文件路径下。可以通过为普通表空间添加 HUGE 数据文件路径将其升级为混合表空间。
表空间 | 说明 |
---|---|
SYSTEM | 存放了 DM 数据库全局字典信息和全局系统数据,是**DM 数据库能够正常运行的必要前提**。CREATE TABLE 等 DDL 操作会修改 SYSTEM 表空间数据。 |
ROLL | 存放 DM 数据库运行过程中产生的所有回滚记录。DM 中几乎所有的数据库修改操作都会生成回滚记录,并保存在 ROLL 表空间的数据文件中。 |
TEMP | 存放临时表数据以及数据库运行过程中产生的临时数据。在数据库运行过程中,SORT、HASH JOIN 等操作都可能会生成临时结果集,它们作为临时数据存放在 TEMP 表空间中。 若数据库重启,保存在 TEMP 表空间中的所有数据都会丢失。 |
MAIN | MAIN 表空间为混合表空间 。在创建用户时,如果没有指定默认表空间,系统自动指定 MAIN 表空间为用户默认的表空间。MAIN 表空间的默认数据文件为 MAIN.DBF,默认 HUGE 数据文件路径为 HMAIN 目录所在路径。 |
重做日志,又叫 REDO 日志,忠实记录了所有物理页的修改,基本信息包括操作类型、表空间号、文件号、页号、页内偏移、实际数据等。数据库中 INSERT、DELETE、UPDATE 等 DML 操作以及 CREATE TABLE 等 DDL 操作最终都会转化为对某些数据文件、某些数据页的修改。数据库系统正常运行时候,用不上REDO日志。但是在系统故障重启时,通过重做 REDO 日志,可以将数据库恢复到故障时的状态。
任何数据页从内存缓冲区写入磁盘之前,必须保证其对应的 REDO 日志已经写入到联机日志文件。
REDO 日志包(RLOG_PKG)是 DM 数据库保存 REDO 日志的数据单元,一个日志包内可保存一个或多个 PTX 产生的 REDO 日志。
PTX:物理事务(Physical Transaction,简称 ptx)
日志包生成时按照序号连续递增,相邻日志包的 LSN 顺序是总体递增的,但是在 DMDSC 集群环境下不一定连续。
系统在归档模式下运行会更安全,当出现介质故障,如磁盘损坏导致数据文件丢失、异常时,利用归档日志,系统可以恢复至故障发生的前一刻。因此,为了保证归档日志文件和数据文件不同时出现问题,建议将归档目录与数据文件配置、保存到不同的物理磁盘上。除了表备份还原,其他的联机备份与还原必须运行在归档模式下。
LSN(Log Sequence Number)是由系统自动维护的 Bigint 类型数值,具有自动递增、全局唯一特性,每一个 LSN 值代表着 DM 系统内部产生的一个物理事务。物理事务(PTX)是数据库内部一系列修改物理数据页操作的集合,与数据库管理系统中事务(Transaction)概念相对应,具有原子性、有序性、无法撤销等特性。
DM 数据库中与 LSN 相关的信息,可以通过查询 v$rlog
和V$RAPPLY_PARALLEL_INFO
表来获取。
类型 | 说明 |
---|---|
CUR_LSN | 系统已经分配的最大 LSN 值。物理事务提交时,系统会为其分配一个唯一的 LSN 值,大小等于 CUR_LSN+1,然后再修改 CUR_LSN=CUR_LSN+1。 |
FLUSH_LSN | 已经发起日志刷盘请求,但还没有真正写入联机 Redo 日志文件的最大 LSN 值。 |
FILE_LSN | 已经写入联机 Redo 日志文件的最大 LSN 值。每次将 Redo 日志包 RLOG_PKG 写入联机 Redo 日志文件后,都要修改 FILE_LSN 值。 |
CKPT_LSN | 检查点 LSN,所有 LSN <= CKPT_LSN 的物理事务修改的数据页,都已经从 Buffer 缓冲区写入磁盘,CKPT_LSN 由检查点线程负责调整。 |
APPLY_LSN | 数据库还原恢复后已经写入联机 Redo 日志文件的日志包的原始最大 LSN 值,APPLY_LSN 取自源库的原始日志包中的最大 LSN 值。DSC 集群的每一个节点独立维护 APPLY_LSN。 |
RPKG_LSN | 数据库还原恢复后已经重演日志的最大 LSN。DSC 集群的每一个节点独立维护 RPKG_LSN。 |
注意:
- 数据库故障重启时,CKPT_LSN 之前的 REDO 日志不需要重做
- 只需要从 CKPT_LSN+1 开始重做 REDO 日志,就可以将系统恢复到故障前状态。
- 在联机重做日志文件中,LSN 值<=CKPT_LSN 的 REDO 日志都可以被覆盖。
每个 RLOG_PKG 都有对应的序号属性,称之为包序号(PKG SEQNO),日志包生成时按照序号连续递增。包序号包括本地包序号(LSEQ)和全局包序号(GSEQ),本地包序号是节点内唯一、连续递增的值,用于校验联机日志连续性;全局包序号由数据守护集群的主备库共同维护,具有全局唯一、连续、递增的特性,用于校验归档日志的连续性。
DM 数据库中与全局包序号相关的信息,可以通过查询 v r l o g 和 V rlog 和 V rlog和VRAPPLY_PARALLEL_INFO 表来获取。
类型 | 说明 |
---|---|
CUR_SEQ | 系统已经分配的最大全局包序号。RLOG_PKG 写入联机日志文件前,系统会为其分配一个唯一的全局包序号。 |
FILE_SEQ | 已经写入联机 Redo 日志文件的最大全局包序号。每次将 Redo 日志包 RLOG_PKG 写入联机 Redo 日志文件后,都要修改 FILE_SEQ 值。 |
APPLY_SEQ | 数据库还原恢复后已经写入联机 Redo 日志文件的原始最大全局包序号,APPLY_SEQ 取自源库的原始日志包的包序号。DSC 集群的每一个节点独立维护 APPLY_SEQ。 |
RPKG_SEQ | 数据库还原恢复后已经重演日志的最大全局包序号。DSC 集群的每一个节点独立维护 RPKG_SEQ。 |
DM 数据库运行过程中,用户的所有操作都在内存中进行。每修改一条记录都必须先把记录所在的数据页加载到 BUFFER 缓冲区中,然后进行修改。事务运行时,会把生成的 REDO 日志保留在 Redo 日志包 RLOG_PKG 中,每条日志记录对应一个 LSN,当事务提交或 Redo 日志包满或执行检查点时会进行日志刷盘。
检查点(checkpoint)是一个数据库事件,它的功能是按照数据页的修改顺序,依次将 BUFFER 缓冲区中的脏页写入磁盘,并在这个过程中动态调整 CKPT_LSN 值,释放日志空间。
DM 的检查点分为两种:完全检查点和部分检查点:
数据库正常关闭
时会产生一个完全检查点**。数据库运行过程中产生的待写入日志首先写入 Redo 日志包 RLOG_PKG,当日志刷盘时一起写入联机日志文件中。在联机日志文件中,可以覆盖写入 REDO 日志的文件长度为可用日志空间;不能被覆盖的 REDO 日志,系统故障重启需要重做的 REDO 日志为有效日志
,有效日志的 LSN 取值范围是(CKPT_LSN,FILE_LSN]。
下图说明了联机日志文件、Redo 日志包 RLOG_PKG 以及相关各 LSN 之间的关系。
我的个人解读(不知道正确与否):
假设我本次需要传输LSN范围1200的REDO日志包RLOG_PKG,目前已经写入联机日志文件的LSN为180的RLOG_PKG,并且系统已经刷盘了1~60的RLOG_PKG的数据页。那么我么可以得到如下结果:
CKPT_LSN
=60,(1~60 REDO日志包影响的数据页已经持久化到硬盘,已经写入REDO日志文件)FILE_LSN
=80,(61~80 REDO日志包影响的数据页还没有持久化到硬盘,但是已经写入REDO日志文件)FLUSH_LSN
=200,(81~200 REDO日志包还没有写入REDO日志文件)这就意味着,这会如果出现了故障,需要还原。那么数据库重新启动后会自动重做LSN为61~80的RLOG_PKG。
备份集用来存放备份过程中产生的备份数据及备份信息。一个备份集对应了一次完整的备份。一般情况下,一个备份集就是一个目录,备份集包含一个或多个备份片文件,以及一个备份元数据文件。并行备份和非并行备份情况下,备份集里的内容略有不同。
备份片用来存储备份数据的文件。备份时,目标数据文件内容或归档日志内容经过处理后,都会存放到各自的备份片文件中。备份片文件后缀为.bak,用来存放备份数据
备份片的大小可以在备份时通过 MAXPIECESIZE
指定,一个备份集中可能生成多个备份片。
元数据文件用来存放备份信息,元数据文件的后缀为.meta。通过元数据文件,可以了解整个备份集信息。元数据文件中包含的备份信息包括:
备份就是从源库(备份库)中读取有效数据页、归档日志等相关信息,经过加密、压缩等处理后写入备份片,并将相关备份信息写入备份元数据文件的过程。
备份的分类
划分标准 | 分类 |
---|---|
备份组织形式 | 1??物理备份 2??逻辑备份 |
数据库是否运行 | 1??联机备份 2??脱机备份 |
备份的粒度 | 1??库备份 2??表空间备份 3??归档备份 4??表备份 |
一致性 | 1??一致性备份 2??非一致性备份 |
完整性 | 1??完全备份 2??增量备份 |
逻辑备份是指利用 dexp 导出工具,将指定对象(库级、模式级、表级)的数据导出到文件的备份方式。逻辑备份针对的是数据内容,并不关心这些数据物理存储在什么位置。
物理备份则直接扫描数据库文件,找出那些已经分配、使用的数据页,拷贝并保存到备份集中。物理备份过程中,不关心数据页的具体内容是什么,也不关心数据页属于哪一张表,只是简单的根据数据库文件系统的描述,来挑选有效的数据页。
数据库处于运行状态、并正常提供数据库服务情况下进行的备份操作,我们称为联机备份。数据库处于关闭状态时进行的备份操作,被称为脱机备份。
备份异常关闭的数据库
,要求配置了本地归档,如果本地归档不完整,则需要先修复本地归档,再进行备份。
为什么联机备份要开启本地归档?联机备份,可能存在一些处于活动状态的事务正在执行,为确保备份数据的一致性,需要将备份期间产生的 REDO 日志一起备份。因此,只能在配置本地归档、并开启本地归档的数据库上执行联机备份。
注意:
只有已经关闭的数据库才允许执行脱机备份。正在运行的数据库,无法执行脱机备份,系统会报错。
按照备份内容不同,可以分为数据备份和归档日志备份。
数据备份主要针对数据文件内容,包括库备份、表空间备份和表备份。其中,未指定 WITHOUT LOG
参数执行的库备份和表空间备份还包含了 REDO 日志备份。
数据备份粒度:
粒度 | 说明 | 联机备份 | 脱机备份 | 全量备份 | 增量备份 |
---|---|---|---|---|---|
库备份 | 库备份会拷贝数据库中所有数据文件的有效数据页。 | √ | √ | √ | √ |
表空间备份 | 针对特定表空间执行的备份,只能在联机状态 下执行。 | √ | X | √ | √ |
表备份 | 拷贝指定表的所有数据页到备份集中,并会记录各个数 据页之间的逻辑关系用以恢复。 1??表备份 只能在联机状态下 执行2??**一次表备份操作只能备份一张用户表 3??不支持增量表备份**。 | √ | X | √ | X |
归档日志 | √ |
归档日志备份是专门针对归档日志文件进行操作,不涉及任何数据文件内容。归档日志备份扫描归档目录收集归档日志文件,并将归档日志写入到备份集中。既可以在数据库运行状态下
,执行联机归档日志备份;也可以在数据库关闭状态下
执行脱机归档日志备份。
按照备份集中的数据是否满足一致性,可以将备份划分为一致性备份和非一致性备份。
备份类型 | 是否指定WITHOUT LOG 选项 | 备份集内容 |
---|---|---|
一致性备份 | X | 1??完整的数据文件内容 2??**REDO 日志信息** |
非一致性备份 | √ | 1??完整的数据文件内容 |
注意:
- 利用非一致性备份集还原的数据库,无法直接启动,必须借助归档日志进行恢复之后才可以启动。但是有一种情况除外:数据库正常关闭时,会生成完全检查点,脱机备份生成的备份集中,不包含任何 REDO 日志。因此脱机备份一个正常关闭的数据库,既可以从归档日志恢复也可以从备份集恢复。
- 表空间备份生成的备份集是非一致性备份集。
按照备份数据完整性,可将备份分为完全备份和增量备份。
库备份和表空间备份支持增量备份,表备份不支持增量备份。
备份类型 支持全量备份 支持增量备份 库备份 √ √ 表空间备份 √ √ 表备份 X 表备份不是直接扫描数据文件,而是从
BUFFER
中加载数据页,拷贝到备份片文件中。表备份不需要配置归档就可以执行,并且不支持增量表备份。
完全备份生成的备份集包含了指定库(或者表空间)的全部有效数据页。当数据规模比较大的情况下,生成的完全备份集通常会比较大,而且备份时间也会比较长。
增量备份是在某个特定备份集基础上,收集数据库新修改的数据页进行备份,可以有效减少备份集的空间占用、提高备份速度。这个特定的、已经存在的备份集称为增量备份的基备份,根据对基备份的要求不同,DM 的增量备份分为以下两种:
差异增量备份
的基备份既可以是一个完全备份集,也可以是一个增量备份集。
利用增量备份进行还原操作时,要求其基备份必须是完整的;如果差异增量备份的基备份本身也是一个增量备份,那么同样要求其基备份是完整的;任何一个增量备份,最终都是以一个完全备份作为其基备份。因此,完全备份是增量备份的基础。
累积增量备份
的**基备份只能是完全备份集,而不能是增量备份集**。
增量备份的基备份集既可以是脱机备份生成的,也可以是联机备份生成的,脱机增量备份的基备份集可以是联机备份生成的,联机增量备份的基备份集也可以是脱机备份生成的。
还原是备份的逆过程,就是从备份集中读取数据页,并将数据页写入到目标数据库对应数据文件相应位置的过程。
联机备份
时,系统中可能存在一些处于活动状态的事务正在执行,并**不能保证备份集中的所有数据页是处于一致性状态**;脱机备份
时,数据页不一定是正常关闭的,也不能保证备份集中所有数据页是处于一致性状态。因此,还原结束后目标库有可能处于非一致性状态,不能马上提供数据库服务;必须要进行数据库恢复操作后,才能正常启动。还原类型 | 还原的数据来源 | 还原工具 |
---|---|---|
逻辑还原 | dexp工具导出的备份数据 | dimp 工具 |
物理还原 | DMRMAN工具导出的备份集 | DMRMAN工具 |
联机还原指数据库处于运行状态时,通过 SQL 语句执行还原操作。表还原可以在联机状态下执行。
脱机还原指数据库处于关闭状态
时执行的还原操作,脱机还原通过 DMRMAN 工具进行。库备份、表空间备份和归档备份,可以执行脱机还原。
脱机还原操作的目标库必须处于关闭状态。
根据备份集类型,数据还原可以分为库还原、表空间还原和表还原。
备份集类型 | 还原的数据来源 | 联机执行 | 脱机执行 |
---|---|---|---|
库还原 | 1??库备份集 | X | √ |
表空间还原 | 1??表空间备份集 2??库备份集 | X | √ |
表还原 | 1??表备份集 | √ | X |
表空间还原,还原的目标表空间不能是 TEMP 表空间,只能是 MAIN、SYSTEM、ROLL 表空间,或者用户定义的表空间。
归档日志还原则将归档日志备份集中的归档日志内容,重新生成到指定目录中。
完全还原是指直接利用完全备份集进行数据还原操作。增量还原指通过增量备份集进行数据还原操作。但是考虑到增量备份集的基础一定是一个完全备份集,因此增量还原过程中隐含了一个完全还原操作。如果增量备份集的基备份集被删除了,那么单独使用这个增量备份集是无法进行还原操作的。
针对不同的备份对象,一个完整的备份还原过程包含的步骤不同。
有的步骤既可以在联机状态下执行,又可以在脱机状态下执行。用户可根据实际需要选择联机或脱机执行,任选一种即可。
下表中列出了不同的状态下所支持的操作。
状态 | 备份粒度 | 备份 | 还原 | 恢复 | |
---|---|---|---|---|---|
恢复一致性 | 更新DB_MAGIC | ||||
联机 | 库 | √ | |||
表空间 | √ | ||||
表 | √ | √ | |||
归档 | √ | ||||
脱机 | 库 | √ | √ | √ | √ |
表空间 | √ | √ | |||
表 | |||||
归档 | √ |
根据上表可得结论:
联机状态 脱机状态 任何对象都能备份 库才能备份 表能还原,其他对象不能还原 除了表以外,任何对象都能还原 任何对象都不能执行恢复操作 库对象支持 恢复一致性
和更新DB_MAGIC
操作,表空间支持恢复一致性
操作
当前仅支持备份集方式的备份还原,不再支持其他备份方式。备份还原实现策略有两种:dmap 辅助进程方式和无辅助进程方式。用户可通过 DM.INI 参数 bak_use_ap 来选择(dmrman 使用参数 use_ap),bak_use_ap 可取值 1、2。默认为 1。
bak_use_ap 的两种取值的相应作用如下:
1:DMAP 辅助进程方式,可支持第三方备份(指定 DEVICE TYPE 为 TAPE)。DMAP 插件执行,改造了备份还原任务子系统,允许指定并行度,大幅提升了备份还原的效率,特别是加密、压缩的处理效率。如果选择使用 DMAP 辅助进程,执行备份还原之前就必须启动 DMAP 服务。安装 DM 数据库以后,DMAP 服务会自动启动。如果需要手动启动,有两种途径,一是启动 DM 服务查看器中的 DmAPService。二是通过手动启动 DMAP 执行码实现,DMAP 执行码位于 DM 安装目录的 bin 子目录下。除此之外,LINUX 下,还可以调用 bin 目录下的 DmAPService 脚本。
2:无辅助进程方式,不依赖 DMAP,由主进程 dmserver 自身执行备份还原,但不支持第三方备份(指定 DEVICE TYPE 为 TAPE)。