达梦常见故障模拟与恢复

一、误删除文件

1、误删除执行文件

        在 Windows 环境下，执行文件在被引用过程中是无法被删除的，出现此类问题的情况比较少，但在 Linux 环境下，数据库进程存在的情况下，相关执行文件可以被删除，程序会继续运行，但是运行过程中的日志等文件在程序执行完后可能会丢失，此中情况下，通过查询 dmserver 的进程 pid，然后进入到 /proc/pid/cwd 路径下，依然可以看到执行过程中依赖的相关文件，可以通过拷贝命令将相关文件拷贝存放，供后续使用。

        如图所示：先找到dmserver的pid,即1163，则进入对应目录/proc/1163/cwd/，拷贝误删除的命令到对应目录下。

图1

2、误删除控制文件

        控制文件，即 dm.ctl。记录数据库实例的实例相关信息、数据版本信息和重做日志文件、数据文件路径属性等，如果被异常删除，表空间属性相关修改可能出现异常，如果不能正常修复，可能导致某些数据文件、REDO 日志文件没有被数据库实例纳入到管理范围，引发其他的严重问题。

如果发现（一般在巡检中）该文件被异常删除，需要及时对该文件进行修复，DM 数据库自身定期会对该文件进行备份，ctl 的备份路径可以在 dm.ini 中进行配置。

• 在该目录下找到最接近故障时间的 ctl 备份文件。

 图2

 图3

• 通过 $DM_HOME/bin 目录下的 dmctlcvt 工具（具体命令查看 dmctlcvt help）将 dmctlcvt 转换成可读的 txt 文件。

 图4

• 打开 txt 文件，通过数据库客户端进行查询 v​datafile 以及 vrlogfile，仔细检查各个文件是否可以逐一对应，如果存在差异，以动态视图结果为准，手工对 txt 文件中的内容进行修改（增加或者删除相关文件描述）。

 图5

 图6

• 修改完成后，通过 dmctlcvt 工具将 txt 文件转换成 ctl 文件，移动到 dm.ini 中配置的 ctl 文件路径下，至此修复完成。

 图7

3、误删除重做日志文件

        默认在数据库实例下存在以实例名 .log 命名的重做日志文件，该文件记录的是数据库运行过程中对实际的数据文件修改的日志信息，并且相关的修改信息达到一定的条件才会实际被应用在数据文件上，如若发生误删除，首先在日志上这些部分未应用日志信息涉及的数据一定就丢失了，另外可能导致数据库无法正常启动。

3.1 模拟数据库故障

       1). 模拟误删除重做日志

重命名DAMENG01.log为DAMENG01_BAK.log 

 图8

     2).验证重做日志误删除后，数据库无法启动

图9

 

3.2 恢复方法及步骤

      首选的恢复方式是通过备份还原，由于归档文件中如实的记录了重做日志的信息，所以 REDO 中涉及的数据通过备份还原并对归档的读取可以正常的将数据库恢复。

      如果备份还原不可用，或者归档丢失等，只能通过替换重做日志文件的方式对库做应急处理，如下所示：

• 通过 dminit 工具初始化一个新的实例，相关参数参考目前故障库的 dminitxxxx.log 中的配置保持一致。
• 将新建实例正常启动并停止一次。
• 将新实例的重做日志文件拷贝到故障库下。
• 通过 $DM_HOME/bin 目录下的 dmmdf 工具查看故障库的数据文件的相关信息。
• 用 dmmdf 工具按照前面查到的信息对拷贝过来的新重做日志文件修改两个 magic 值。
• 修改完成后，数据库可以正常启动。

此类方法在集群环境下不适用，由于重做日志记录的部分头部信息和实例间同步相关，新建重做日志会导致集群不可用，另外使用该方法正常启动后，以前未应用的部分数据会丢失，系统可靠性也会降低，只能临时用于启动数据库，需要尽快将数据迁出至健康环境。

3.3 演示数据恢复过程

        3.3.1 备份+归档还原（完全恢复）
        如果有备份文件，可以重新初始化一个新的数据库（初始化参数要和原库一样，比如页大小、大小写敏感、字符集等，这些可以在 DM 数据库安装路径，…/data/DAMENG 目录下以 dminit+日期时间.log 命名的文件中查询），然后将备份文件和归档日志文件拷贝到新的环境，然后再进行备份+归档的还原操作。
1）、查看原库（192.168.*.10）初始化信息

3). 初始化新数据库

     初始化数据库

[dmdba@localhost dmdbms]$ cd bin
[dmdba@localhost bin]$ ./dminit path=/home/dmdba/data/ DB_NAME=DAMENG_01 INSTANCE_NAME=DMSERVER_01 PAGE_SIZE=32 EXTENT_SIZE=32 PORT_NUM=15236 CHARSET=0 CASE_SENSITIVE=1 

       

前台启动

./dmserver /home/dmdba/data/DAMENG_01/dm.ini

     

    注册并启动数据库服务

[root@localhost bin]# cd /home/dmdba/dmdbms/script/root/
[root@localhost root]# ./dm_service_installer.sh -t dmserver -dm_ini  /home/dmdba/data/DAMENG_01/dm.ini -p DMSERVER_01

 

 

 3).拷贝备份和归档到新环境

     （此处省略）

4).备份+归档恢复数据库

#登录dmrman
[dmdba@localhost bin]$ ./dmrman

#还原
RMAN> restore database '/home/dmdba/data/DAMENG_01/dm.ini' from backupset '/home/dmdba/dmbak/FULL_BAK_DAMENG';

#使用归档恢复
RMAN> recover database '/home/dmdba/data/DAMENG_01/dm.ini' with archivedir '/home/dmdba/dmarch/' ;

#更新魔术
RMAN> recover database '/home/dmdba/data/DAMENG_01/dm.ini' update db_magic;

#退出
RMAN> exit

5）.启动数据库即可

        

 

        3.3.2 替换重做日志（不完全恢复）

         此方法是在没有备份的情况下恢复数据库。这种方法恢复存在数据丢失的风险。

        思路如下：        

• 通过 dminit 工具初始化一个新的实例，相关参数参考目前故障库的 dminitxxxx.log 中的配置保持一致。

[dmdba@localhost ~]$ cd /home/dmdba/dmdbms/bin
[dmdba@localhost bin]$ ./dminit path=/home/dmdba/data/ DB_NAME=DAMENG_02 INSTANCE_NAME=DMSERVER_02 PAGE_SIZE=32 EXTENT_SIZE=32 PORT_NUM=15237 CHARSET=0 CASE_SENSITIVE=1

• 将新建实例正常启动并停止一次。

[dmdba@localhost bin]$ ./dmserver /home/dmdba/data/DAMENG_02/dm.ini

• 将新实例的重做日志文件拷贝到故障库下。

        

 

• 通过 $DM_HOME/bin 目录下的 dmmdf 工具查看故障库的数据文件的相关信息。

[dmdba@localhost bin]$ ./dmmdf TYPE=1 FILE=/home/dmdba/data/DAMENG/SYSTEM.DBF

 

 

• 用 dmmdf 工具按照前面查到的信息对拷贝过来的新重做日志文件修改dm_magic和pemnt_magic 值。

[dmdba@localhost bin]$ ./dmmdf TYPE=2 FILE=/home/dmdba/data/DAMENG/DAMENG01.log

 

• 修改完成后，数据库可以正常启动。

         

 

4、误删除数据文件

        如果运行过程中 DBF 文件被误删除，首选的方式是通过备份还原对数据库进行最大长度的恢复（指定时间点），如果备份不存在或者不可用，在可能的情况下，尽可能快的停止一切对数据库的写操作（切断应用、网络），同样，如果在 Linux 环境下，可能对该文件还存在镜像，可以从 proc 中进行冷拷贝操作尝试还原，Windows 下这种情况可以处理的办法不多。

        

4.1 备份+归档恢复数据库（完全恢复）

       参考 3.3.1备份+归档还原（完全恢复）

4.2 在线逻辑导出导入

前提：误删除后，数据库未停止服务

•  通过逻辑导出数据

./dexp USERID=SYSDBA/SYSDBA   FILE=FULL_DB.dmp LOG=FULL_DB_exp.log FULL=Y DIRECTORY=/home/dmdba/dmbak/

• 初始化一个和故障实例参数一致的新实例

        初始化时的参数可查看 dminit###.log文件（###为八位日期+6位流水）

./dminit path=新实例目录  

•    通过逻辑导入数据

./dimp SYSDBA/SYSDBA:5236  FULL=Y  FILE='/home/dmdba/dmbak/FULL_DB.dmp' LOG=/home/dmdba/dmbak/FULL_DB_imp.log 

      

二、误删除/修改数据

1、误修改数据 (upd del ins)

运维过程中经常会直接在数据库客户端上直接执行一些语句对数据进行修改，也不免出现误操作的情况。

• 任何时候我们在生产环境中直接用客户端操作，需要保证相关工具的会话属性的自动提交是关闭状态，这样如果误操作的话，可以简单的通过 rollback 直接补救。
• 如果出现误操作并提交，最安全的办法依然是通过备份恢复到尽可能新的状态（3.3.1备份+归档还原（完全恢复）），如若备份、归档存在问题，则需要其他的方式进行处理，这里着重讲一下这种情况的处理措施。
• 对于错误插入，在 DM 的每一行数据上，都存在 trxid 伪列，一般情况误插入如果是批量的，通过查询相关事务号进行分组，确认批量行数，结合检查数据一般是可以找到问题数据再进行清理。

2、误更新/删除数据

数据可能存在的地方如下：

• 表所在表空间数据文件 (*.DBF)
• 回滚表空间数据文件 (ROLL.DBF)
• 重做日志 (DAMENG01.log 等)
• 归档文件（物理）
• 附加逻辑归档
• Logcommit 日志

以删除 (DELETE/TRUNCATE) 为例，介绍如何进行数据恢复。

当数据发生删除并提交时，实际的数据还是存在于数据文件上的，只是该行数据被打上了删除标记，被打上删除标记的数据对查询是不可见的，并且在 ini 配置的 undo_retention 时间后，有删除标记的数据会被完全清理，在数据文件上就不可见了。如果启用了闪回查询，出现此类问题时，直接通过闪回查询指定时间点，可以将不可见的数据直接返回到数据库客户端上（UPDATE类似），然后将这些数据进行落地保存，用于后续的修复。

如果开启了逻辑附加归档，可以通过 dbms_logmnr 工具对逻辑附加归档进行分析(参考博客：达梦DBMS_LOGMNR归档数据挖掘)，分析完成后获取相关数据信息，用于数据回填。对删除而言，logcommit 日志里面记录的内容作用有限，因为很可能只记录了删除语句本身以及相关where条件信息，没有实际的数据。

如果是 UPDATE 误操作，且不满足上述条件，如果存在物理归档，可以通过 $DM_HOME/bin 目录下的 dmlcvt 工具对归档进行分析（具体用法参考 dmlcvt help），分析表空间号为 1（ROLL.DBF）的所有记录，分析完成后，在分析结果中找到所有的 urec_upd 类型记录，该记录包含了更新涉及的 KEY，以及更新的旧值信息，均为二进制显示，通过原厂工程师提供解析方法，将此类信息还原成更新语句，直接执行更新语句可以将相关数据还原。

如果以上条件均不满足，可能的情况下，尽量杀掉数据库进程，并且防止自启动（正常关闭和启动过程中会对删除标记数据进行清理），抓取误删除的表所在的表空间的相关数据文件，原厂工程师可以通过直接解析该文件，将该表所有数据进行还原。

本文参考：人为操作故障 | 达梦技术文档 (dameng.com)

更多内容请访问： 达梦数据库 - 新一代大型通用关系型数据库 | 达梦在线服务平台