问题
联机备份数据库的时候，碰到如下异常提示：
SQL> backup database full to ONLINEBAK_01 backupset '/dm8/backup/full/ONLINEBAK_01';
backup database full to ONLINEBAK_01 backupset '/dm8/backup/full/ONLINEBAK_01';
[-718]:收集到的归档日志不连续.
已用时间: 59.266(毫秒). 执行号:0.
DCA培训老师给的解决方案是：
1）执行完全检查点 checkpoint(100);
2）重启数据库；
3）等待几分钟数据库会自动执行检查点操作。
上述任一操作均可修复“收集到的归档日志不连续”的异常。
为啥上述操作可以修复这个异常呢？
基础概念
首先澄清一些基础概念（来自<<DMB备份与还原.pdf>>）：
LSN
LSN（Log Sequence Number）是由系统自动维护的 Bigint 类型数值，具有自动递增、全局唯一特性，每一个 LSN 值代表着 DM 系统内部产生的一个物理事务。物理事务（Physical Transaction，简称 ptx）是数据库内部一系列修改物理数据页操作的集合，与数据库管理系统中事务（Transaction）概念相对应，具有原子性、有序性、无法撤销等特性。
DM数 据 库 中 与LSN相 关 的 信 息 ， 可 以 通 过 查 询V
R
L
O
G
和
V
RLOG和V
RLOG和VRAPPLY_PARALLEL_INFO 表来获取。
DM 主要包括以下几种类型的 LSN：
1）CUR_LSN是系统已经分配的最大 LSN 值。物理事务提交时，系统会为其分配一个唯一的 LSN 值，大小等于 CUR_LSN+1，然后再修改CUR_LSN=CUR_LSN+1。
2）FLUSH_LSN 是已经发起日志刷盘请求，但还没有真正写入联机 Redo 日志文件的最大 LSN 值。
3）FILE_LSN 是已经写入联机 Redo 日志文件的最大 LSN 值。每次将 Redo 日志包 RLOG_PKG 写入联机 Redo 日志文件后，都要修改 FILE_LSN 值。
4）CKPT_LSN 是检查点 LSN，所有 LSN <= CKPT_LSN 的物理事务修改的数据页，都已经从 Buffer 缓冲区写入磁盘，CKPT_LSN 由检查点线程负责调整。
数据库故障重启时，CKPT_LSN 之前的 REDO 日志不需要重做，只需要从 CKPT_LSN+1开始重做 REDO 日志，就可以将系统恢复到故障前状态。并且，在联机重做日志文件中，LSN值<=CKPT_LSN 的 REDO 日志都可以被覆盖。
检查点
检查点（checkpoint）是一个数据库事件，它的功能是按照数据页的修改顺序，依次将 BUFFER 缓冲区中的脏页写入磁盘，并在这个过程中动态调整 CKPT_LSN值，释放日志空间。
DM 的检查点分为两种：完全检查点和部分检查点：
1）完全检查点：会将内存缓冲区中的所有脏页写入磁盘，并调整 CKPT_LSN，在数据库正常关闭时会产生一个完全检查点。
2）部 分 检 查 点 ： 根 据 dm.ini 配 置 文 件 中 的 参 数 CKPT_FLUSH_RATE 和CKPT_FLUSH_PAGES，确定每次检查点刷脏页的数量。执行部分检查点的过程中，DDL/DML操作都可以正常执行，DM 系统中绝大多数情况下触发的都是部分检查点。
数据库运行过程中产生的待写入日志首先写入 Redo 日志包 RLOG_PKG，当日志刷盘时一起写入联机日志文件中。在联机日志文件中，可以覆盖写入 REDO 日志的文件长度为可用日志空间；不能被覆盖的 REDO 日志，系统故障重启需要重做的 REDO 日志为有效日志，有效日志的 LSN 取值范围是(CKPT_LSN,FILE_LSN]。
备份
DM 备份的本质就是从数据库文件中拷贝有效的数据页保存到备份集中，这里的有效数据页包括数据文件的描述页和被分配使用的数据页。而在备份的过程中，如果数据库系统还在继续运行，这期间的数据库操作并不是都会立即体现到数据文件中，而是首先以日志的形式写到归档日志中，因此，为了保证用户可以通过备份集将数据恢复到备份结束时间点的状态，就需要将备份过程中产生的归档日志也保存到备份集中。
数据库处于运行状态、并正常提供数据库服务情况下进行的备份操作，我们称为联机备份。
联机备份则使用客户端工具连接到数据库实例后，通过执行 SQL 语句进行；也可以通过配置作业，定时完成自动备份。
联机备份时，可能存在一些处于活动状态的事务正在执行，为确保备份数据的一致性，需要将备份期间产生的 REDO 日志一起备份。因此，只能在配置本地归档、并开启本地归档的数据库上执行联机备份。
还原与恢复
还原与恢复是备份的逆过程。
还原是将备份集中的有效数据页重新写入目标数据文件的过程。恢复则是指通过重做归档日志，将数据库状态恢复到备份结束时的状态；也可以恢复到指定时间点和指定 LSN。
恢复结束以后，数据库中可能存在处于未提交状态的活动事务，这些活动事务在恢复结束后的第一次数据库系统启动时，会由 DM 数据库自动进行回滚。
归档备份
在 DIsql 工具中使用 BACKUP 语句可以备份归档日志。
归档备份的前提：
一，归档文件的 db_magic、permanent_magic 值和库的 db_magic、permanent_magic 值必须一样；
二，服务器必须配置归档；
三，归档日志必须连续，如果出现不连续的情况，前面的连续部分会忽略，仅备份最新的连续部分。如果未收集到指定范围内的归档，则不会备份。
联机备份的时候经常会切换归档文件，最后一个归档总是空的，所以最后一个归档不会被备份。
实验环境
操作系统版本：
[dmdba@dca arch]$ cat /proc/version
Linux version 3.10.0-1160.66.1.el7.x86_64 (mockbuild@kbuilder.bsys.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Wed May 18 16:02:34 UTC 2022
[dmdba@dca arch]$ cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
数据库版本：
SQL> select id_code;
行号 ID_CODE
---------- -----------------------------------------
1 --03134283890-20220525-161267-10045 Pack7
已用时间: 0.664(毫秒). 执行号:618.
问题重现
当前数据库未归档：
SQL> select arch_mode from v$database;
行号 ARCH_MODE
---------- ---------
1 N
已用时间: 0.394(毫秒). 执行号:619.
未开启归档前执行一段执行DDL脚本：
create table HR.ITI_FULL_BAK(steps varchar2(100));
未开启归档前执行一段DML脚本：
insert into HR.ITI_FULL_BAK values ('未开启归档，第一次insert的记录');
数据库第一次开启归档：
alter database mount;
alter database ARCHIVELOG;
alter database ADD ARCHIVELOG 'type=local, dest=/dm8/arch, file_size=128,space_limit=10240';
alter database open;
成功开启归档后执行一段DML脚本：
insert into HR.ITI_FULL_BAK values ('第一次开启归档后insert的记录');
第一次关闭归档：
alter database mount;
alter database noarchivelog;
alter database delete archivelog 'type=local,dest=/dm8/arch';
alter database open;
成功关闭归档后执行一段DML脚本：
insert into HR.ITI_FULL_BAK values ('第一次关闭归档后insert的记录');
紧接着第二次开启归档：
alter database mount;
alter database ARCHIVELOG;
alter database ADD ARCHIVELOG 'type=local, dest=/dm8/arch, file_size=128,space_limit=10240';
alter database open;
第二次打开归档成功后，执行一段DML脚本：
insert into HR.ITI_FULL_BAK values ('第二次开启归档后未备份前insert的记录');
此时开启全库联机备份：
SQL> backup database full to ONLINEFULBAK_01 backupset '/dm8/backup/full/ONLINEFULBAK_01';
backup database full to ONLINEFULBAK_01 backupset '/dm8/backup/full/ONLINEFULBAK_01';
[-718]:收集到的归档日志不连续.
已用时间: 31.556(毫秒). 执行号:0.
SQL>
问题重现。
问题分析
备份、还原与恢复的关系如图：
查询redo log的CKPT_LSN和归档文件的信息：
当前CKPT_LSN是129694，FILE_LSN是134673；
而归档文件的CLSN是134638，DB_MAGIC是1340246040；
由于数据缓冲区有部分脏页并未及时写入数据文件，因此联机备份全库时，需要检查归档日志中>129694的日志完整性，以确保在执行还原恢复时，可以通过重做归档日志将数据库状态恢复到备份结束时的状态：
而归档文件中的序号，57813~57856这一段是缺失的；因此在执行联机备份时，数据库认为由于此时数据缓冲区仍存在脏页未及时写入数据文件，因此必须确保在CKPT_LSN后的归档日志是完整的，如果检测发现不完整，就会中断本次的联机备份操作。
手动执行checkpoint
手动执行checkpoint(100)：
SQL> checkpoint(100);
DMSQL 过程已成功完成
已用时间: 7.086(毫秒). 执行号:630.
查询redo log的CKPT_LSN和归档文件的信息：
此时的CKPT_LSN是134600，归档日志不连续的现象依然存在，但是刷新了CKPT_LSN的值；
此时执行全库备份：
SQL> backup database full to ONLINEFULBAK_01 backupset '/dm8/backup/full/ONLINEFULBAK_01';
操作已执行
已用时间: 00:00:03.005. 执行号:631.
在成功全库备份后执行一段DML：
insert into HR.ITI_FULL_BAK values ('第一次全库备份后insert的记录');
查询数据库的记录：
SQL> select * from HR.ITI_FULL_BAK;
行号 STEPS
---------- ---------------------------------------------------
1 未开启归档，第一次insert的记录
2 第一次开启归档后insert的记录
3 第一次关闭归档后insert的记录
4 第二次开启归档后未备份前insert的记录
5 第一次全库备份后insert的记录
已用时间: 0.434(毫秒). 执行号:634.
SQL>
接着进行还原恢复的操作，检验备份的结果；
首先关闭数据库：
[dmdba@dca bin]$ ./DmServiceDMTESTSVR stop
Stopping DmServiceDMTESTSVR: [ OK ]
[dmdba@dca bin]$ ./DmServiceDMTESTSVR status
DmServiceDMTESTSVR is stopped
[dmdba@dca bin]$
RMAN恢复还原：
RMAN> restore database '/dm8/data/DMTEST/dm.ini' from backupset '/dm8/backup/full/ONLINEFULBAK_01';
restore database '/dm8/data/DMTEST/dm.ini' from backupset '/dm8/backup/full/ONLINEFULBAK_01';
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
[Percent:100.00%][Speed:0.00M/s][Cost:00:00:02][Remaining:00:00:00]
restore successfully.
time used: 00:00:02.624
RMAN> recover database '/dm8/data/DMTEST/dm.ini' with archivedir '/dm8/arch';
recover database '/dm8/data/DMTEST/dm.ini' with archivedir '/dm8/arch';
Database mode = 0, oguid = 0
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
EP[0]'s cur_lsn[135030], file_lsn[135030]
[Percent:100.00%][Speed:0.00PKG/s][Cost:00:00:00][Remaining:00:00:00]
recover successfully!
time used: 393.901(ms)
RMAN> recover database '/dm8/data/DMTEST/dm.ini' update db_magic;
recover database '/dm8/data/DMTEST/dm.ini' update db_magic;
Database mode = 0, oguid = 0
Normal of FAST
Normal of DEFAULT
Normal of RECYCLE
Normal of KEEP
Normal of ROLL
EP[0]'s cur_lsn[135374], file_lsn[135374]
recover successfully!
time used: 00:00:01.009
查询开启数据库，检查记录是否恢复：
SQL> select * from HR.ITI_FULL_BAK;
行号 STEPS
---------- ---------------------------------------------------
1 未开启归档，第一次insert的记录
2 第一次开启归档后insert的记录
3 第一次关闭归档后insert的记录
4 第二次开启归档后未备份前insert的记录
5 第一次全库备份后insert的记录
已用时间: 2.012(毫秒). 执行号:600.
记录有完全恢复，查询redo log的CKPT_LSN和归档文件的信息：
当前CKPT_LSN是135374，FILE_LSN是136642；
而归档文件的CLSN是136692，DB_MAGIC是103593263；
DB_MAGIC已经更新，恢复还原的操作也成功完成。
问题结论
DM 的物理备份一般包括数据备份和日志备份两部分，数据备份是拷贝数据页内容，日志备份则是拷贝备份过程中产生的 REDO 日志。
联机备份数据库的时候，由于数据缓冲区仍有脏页未写入数据文件，因此备份完成的备份集并不能帮助数据库还原到数据库备份时的最新状态，需通过重做日志进行恢复的操作，因而会去检测归档日志从CKPT_LSN后的日志是否完整等。
联机备份全库抛出的这个异常“[-718]:收集到的归档日志不连续.”，我觉得是数据库在检测归档日志中从CKPT_LSN以后的LSN记录是否完整，以供后续的恢复操作用；并非是检测归档文件序号的连续性；因此执行checkpoint(100)；的操作后，归档文件的序号不连续的问题依然存在，但是CKPT_LSN往后偏移了。因此数据库在执行还原恢复的操作时，通过备份集的数据文件还原+重做归档日志（>CKPT_LSN）恢复，可以帮数据库还原恢复到数据库备份时的最新状态。
DCA培训老师提供的三个步骤均可以达到刷新CKPT_LSN的作用，但如果数据库是异常关机的，则建议先通过repair完成指定数据库的归档修复，否则后续还原恢复将会导致联机日志中未刷入本地归档的 REDO 日志丢失，届时再利用本地归档恢复也无法恢复到故障前的最新状态。
扫一扫
548
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
