我们知道在 windows 平台下,一旦文件在程序中打开,则不能被删除,所以不存在误删数据文件的情况,如下图所示。
但是在 LINUX 操作系统中,被进程打开的文件仍可以被删除,因此存在 DM 数据文件可能被误删的风险。并且,在默认情况下,若数据文件被删除,数据库是不会返回任何报错信息的,这样无形中就增大了数据丢失的风险。因此,本篇文章主要讲两个方面:
注:本文实验环境的 DM 数据库版本为:
DM Database Server x64 V7.1.6.16-Build(2017.10.10-85437)ENT
1.首先建一个测试表。
create table test (id int );
insert into test values(1);
2.删除数据文件 MAIN.DBF,此时去查询 test 表,发现一切正常,数据库没有任何报错。
3.进行相关设置,使数据库可以检测出文件被删除,有以下两种方式:调用系统过程 SP_FILE_SYS_CHECK() 来手动检查,数据库重启后失效;设置参数 FIL_CHECK_INTERVAL 大于 0 即可(单位是 s),若使其永久生效,则需要将参数添加进 dm.ini 文件中。
sp_set_para_value(1,'FIL_CHECK_INTERVAL',3);
4.设置成功后,再次查询 test 表,即报错:表空间 [MAIN] 中文件 [/opt/dmdbms/data/DAMENG/MAIN.DBF] 已被删除。
进行以上设置后,若数据文件被删除,我们可以及时得知,下面来讲如何进行数据恢复。
数据恢复分两种方法:联机恢复和脱机恢复。
此方法只适用于被删除的是用户数据文件(以 MAIN.DBF 为例):
1.首先调用以下系统过程进行恢复的准备工作:
call SP_TABLESPACE_PREPARE_RECOVER('MAIN');
2.在服务器终端执行 ps ef |grepdms,获取数据库服务的 pid 为 12130。
3.接下来,就用 ls 命令查看被删除文件对应的副本:ls /proc/12130/fdl,如下图,在 MAIN.DBF 文件 后,有个 delete,表示已被删除掉。
4.将上述 MAIN.DBF 文件复制到原数据文件路径下即可:
cp /proc/12130/fd/11 /opt/dmdbms/data/DAMENG/MAIN.DBF
5.复制成功后,执行以下语句完成表空间失效文件的恢复。
call SP_TABLESPACE_RECOVER('MAIN');
6.再次查询 test 表,可正常执行,并得到正确数据。
为什么联机恢复只适用于恢复被删除的用户数据文件呢,因为当被删除的是 ROLL.DBF、TEMP.DBF 或 SYSTEM.DBF 文件时,数据库一旦检测到它们其中任何一个文件不在了,就会直接挂掉,所以根本没有机会进行联机恢复的操作。此时,只能利用备份文件和归档文件进行还原,并因为数据库属于异常退出,有部分 REDO 日志还没来得及写进归档中,导致归档不全,无法恢复到数据库异常退出前的状态。因此,在进行还原前,需进行归档修复(归档修复会扫描联机日志文件,将那些已经写入联机日志文件、但还没有写入到归档日志文件的 REDO 日志,重新写入到归档日志文件,详见手册DM7_Backup_And_Recovery.pdf)。
在利用备份进行还原时,根据被删除文件类型,也分为以下两种情况:
1.归档修复
repair archivelog database '/opt/dmdbms/data/DAMENG/dm.ini';
2.利用备份加归档,进行还原
./dmrestore ini_path=/opt/dmdbms/data/TEST/dm.ini file=/opt/dmdbms/data/TEST/bak/test.bak archive_dir=/opt/dmdbms/data/TEST/arch/
1.SYSTEM.DBF被删除后,无法修复归档,所以会导致部分数据丢失。
2.SYSTEM.DBF 被删除后,无法在原库上直接进行还原,必须新初始化一个库才可以。
总结:在留有备份和完整归档文件情况下,只有 SYSTEM.DBF 被删除后,无法完整恢复数据库,其余数据文件被删除,均可通过不同方式进行数据恢复。
文章
阅读量
获赞