数据库是一个系统的核心，存放着整个企业的数据库，数据库数据异常、数据丢失等往往导致整个系统瘫痪，甚至有可能影响整个企业发展前景，可见数据安全成为了重中之重，本文简单探讨本人工作经验总结的故障处理思路和DM数据库常见的问题处理方法，有不对之处，请大家多多指教。

一、故障处理流程：

收集信息，对问题定位。
分析定位问题，找到原因。
能处理的当场处理、无法处理的复现问题。
问题反馈、上报。
确认问题的重要性、紧迫性、影响范围、用户关切度等相关因素。

二、问题定位和分析：

当系统出现问题，无法及时响应用户/应用请求时，可能得原因是多方面的：
一般情况下：
网络是否正常
内存使用量
CPU使用率
I/O是否正常
系统日志
动态性能视图

2.1、收集信息：

LINUX常用监控命令
free命令查看内存使用情况
top命令查看cpu使用率
iostat命令查看磁盘I/O使用情况
nmon工具监控系统一段时间的整体情况
系统信息收集工具nmon，需要提前安装，下载对应操作系统版本，数据采集、分析。

2.2、系统日志：

事件日志：系统启动、关闭内存申请失败、IO错误等一些致命错误。
跟踪日志：
系统各会话执行的SQL语句、参数信息、错误信息等。
设置不同的语句掩码可以收集不同的语句。
主要用于分析错误和分析性能问题

2.3、动态性能视图：

数据库连接信息：

通过 V$SESSIONS可获取会话的具体信息，如执行的sql语句、主机名、当前会话状态、用户名以及回话总数等等 。

数据库锁、事务等信息
通过V$ LOCK 、V$TRX 可以获取锁和事务的具体信息，如锁对象、状态、等待的事务及事务对应的会话等相关信息。

2.4、DM监控工具：

理由DM监控工具查看各项监控指标

2.5、故障重现：

需要现场简化问题，使用manager等工具确认问题，配合开发编写测试程序，模拟生产库环境。

三、常见问题处理方式：

3.1、服务器无响应：

现象：

当前操作长时间不返回；
服务器CPU负载比较高；
数据库连接池暴涨；
数据库响应延迟。

原因：

事务未提交或长时间执行占用，造成其他事务堵塞，产生不良循环；

解决方式：

通过动态性能视图获取未提交事务的session id
通过 session id 关闭对应连接，

sp_close_session(sess_id);

利用kill命令，主动产生core文件并获取堆栈信息。

kill -SIGSEGV pid 

3.2、服务器宕机：

现象：

数据库无法连接，dmserver进程不存在；

原因：

系统内部BUG或磁盘IO等硬件错误。

处理方式：

有 CORE文件， 通过CORE文件，找出正在执行的SQL。
没有CORE文件，通过跟踪日志文件，找出宕机前最后一条执行的SQL 。
一般第一个线程里面正在执行的sql语句就是故障SQL语句，gdb dmserver core文件名字，打开core文件。

3.3、文件损坏：

LOG文件损坏：

初始化新库，初始参数与问题库保持一致，然后正常新库并正常关闭。
将新库的ROLL.DBF和DAMENG0*.LOG拷贝覆盖到问题库。
使用dmmdf修改日志文件的db_magic。
再次启动，dmserver 就可以正常启动。
注意：正常启动后要进行数据备份工作。

ROLL文件损坏：

dm.ini中添加配置项PSEG_RECV = 0 （类似MySQL5.7忘记root密码登录）。
再次启动，dmserver 就可以跳过回滚操作，启动起来。
DBF文件损坏:
数据库可正常启动：
disql 下执行check_db_index(), 会打印出问题的索引名。
查询系统字典表SYSOBJECTS 获取 索引 ID

SELECT ID FROM SYSOBJECTS  where SUBTYPE$ = 'INDEX' AND NAME = 'IDX_NAME'

查询 SYSINDEXES 获取索引类别，0 为聚集索引；1为二级索引

SELECT  XTYPE & 0x01 FROM SYSINDEXES  WHERE ID = IDX_ID

二级索引则直接删除然后重建即可
聚集索引则只能重导数据或备份还原的方式进行数据恢复
数据库无法正常启动
建新库导数据
利用备份文件和归档文件进行还原

3.4、数据库表数据误删：

首先确定是什么时候做的操作？数据库是否有备份？有备份的情况下数据可以恢复到任意时间点。如果没有备份一般是无法恢复的。

3.5、误删除 undo/redo 日志

如果有备份文件：

可以重新初始化一个新的数据库（初始化参数要和源库一模一样），然后将备份文件和归档日志文件拷贝到新的环境，然后再进行备份+归档的还原操作。

如果没有备份文件：

可以通过修改永久魔术值的方式来恢复，但是这种情况下有可能丢失数据。
重新初始化一个新的数据库（初始化参数要和原库一样），将重新初始化的数据库中 DAMENG01.log、DAMENG02.log 文件拷贝到当前丢失 REDO 日志的库目录下。
使用 dmmdf 工具获取 SYSTEM.DBF 的 db_magic，并记录下来。

[root@dmyanshi2 bin]# ./dmmdf /data/DAMENG/SYSTEM.DBF 

使用 dmmdf 工具设置 DAMENG01.log 文件的 db_magic

[root@dmyanshi2 bin]# ./dmmdf /data/DAMENG/DAMENG01.log

重启数据库即可。

3.6、表空间的数据文件被删除：

数据文件被删除，那这部分的数据是丢失的，数据库无法正常启动。处理方式是将控制文件转成文本文件，在控制文件中把对应表空间信息删除，再把文本文件转成控制文件，删除对应的数据文件，最后启动数据库即可。

具体操作如下：

数据安装路径：/opt/dmdbms/bin下执行./dmctlcvt help
将 dm.ctl 文件转换成 dm.txt 文件:

./dmctlcvt TYPE=1 SRC=/opt/dmnew/data/DAMENG/dm.ctl DEST=/opt/dmnew/data/DAMENG/dmctl.txt

删除掉 dmctl.txt 中被删除的数据库文件指定的路径。
将 dmctl.txt 生成 .dm.ctl 文件执行以下操作:

./dmctlcvt TYPE=2 SRC=/opt/dmnew/data/DAMENG/dmctl.txt DEST=/opt/dmnew/data/DAMENG/dm.ctl

3.7、数据库表被 truncate：

无法找回，只能通过备份+归档日志的方式，恢复到指定时间点 。

3.8、控制文件dm.ctl被删除：

启动数据库报错如下：【code - 803】
通过 ctl_bak 找回，用最近的一个 dm_xxx.ctl 改名启动

3.9、在更新 /updte 数据的时候突然卡住，没有任何报错：

可能原因：update/ 更新同一行语句需要提交之后才能修改，默认行锁。
提交或回滚产生阻塞的事务
只需要在发生阻塞的会话下提交或回滚事务，锁自然会被释放，阻塞解决。
关闭产生阻塞的会话
我们也可以使用系统过程 SP_CLOSE_SESSION(SESS_ID) 来关闭对应的会话。

3.10、数据库卸载，只剩数据 data 文件夹里面文件：

重新安装数据库，安装时不用重新初始化库，将 data 目录全部拷贝到新安装的数据库安装目录下，只需要通过工具重新注册数据库服务，然后正常启动数据库即可。