我们知道在windows平台下,一旦文件在程序中打开,则不能被删除,所以不存在误删数据文件的情况,如下图所示。
但是在LINUX操作系统中,被进程打开的文件仍可以被删除,因此存在DM7数据文件可能被误删的风险。并且,在默认情况下,若数据文件被删除,数据库是不会返回任何报错信息的,这样无形中就增大了数据丢失的风险。因此,本篇文章主要讲两个方面:
1.在表空间文件被误删后,如何使数据库及时反馈出来。
2.在表空间文件被误删后,如何进行数据的恢复。
注:本文实验环境的DM7数据库版本为:
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]已被删除
进行以上设置后,若数据文件被删除,我们可以及时得知,下面来讲如何进行数据恢复。
二、在表空间文件被误删后,如何进行数据的恢复
数据恢复分两种方法:联机恢复和脱机恢复。
2.1 联机恢复,此方法只适用于被删除的是用户数据文件(以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)。
2.2 脱机恢复,即备份还原机制
在利用备份进行还原时,根据被删除文件类型,也分为以下两种情况:
2.2.1若被删除的是ROLL.DBF或TEMP.DBF,通过以下过程,即可完整恢复数据库。
1.归档修复:
repair archivelogdatabase '/opt/dmdbms/data/DAMENG/dm.ini';
2.利用备份加归档,进行还原:
./dmrestoreini_path=/opt/dmdbms/data/TEST/dm.inifile=/opt/dmdbms/data/TEST/bak/test.bakarchive_dir=/opt/dmdbms/data/TEST/arch/
2.2.2 若被删除的是SYSTEM.DBF文件,则无法完整恢复数据库。
1.SYSTEM.DBF被删除后,无法修复归档,所以会导致部分数据丢失。
2.SYSTEM.DBF被删除后,无法在原库上直接进行还原,必须新初始化一个库才可以。
总结:在留有备份和完整归档文件情况下,只有SYSTEM.DBF被删除后,无法完整恢复数据库,其余数据文件被删除,均可通过不同方式进行数据恢复。
领取专属 10元无门槛券
私享最新 技术干货