事故环境：CENTOS6.5 x64，DM7.6企业版，MPP集群2节点。
事故的起因：在生产环境上，现场同事打算扩表空间，采用如下语句扩表空间，一次性增加了4个文件，然后因其它原因，居然脑袋“抽风”直接去OS环境里把刚才新增的数据文件rm了。
ALTER TABLESPACE ts01 ADD DATAFILE '\opt\dmdbms\data\DAMENG\MPP1_01\ts15.dbf' SIZE 20480 AUTOEXTEND ON NEXT 2048 MAXSIZE 51200;
如果在rm掉文件后立即找回缺失文件，可以参考《DM7系统管理员手册》的15.1.9章节进行失效文件恢复；但是现场同事在2小时后才发现问题，这时在OS里查找误删除的文件已经没有结果了。而此时数据库虽然还在正常运行（在 dm.ini 中参数 FIL_CHECK_INTERVAL 的值指定 DM7 系统检查数据文件是否仍存在的时间间隔。将其设为0表示不进行检查），但是集群因为两个节点下某个表空间的数据文件不一致导致1个节点CPU开始报警（CPU超95%)。
解决办法：趁数据库服务还正常运行，建立临时表空间和临时用户，将当前有问题表空间上的用户和数据迁移到临时表空间和临时用户上；然后删除有问题的表空间和用户，重建表空间和用户，再将数据迁移回来。
解决步骤：
1、将当前用户归属模式下的对象整体导出定义，导出内容包括：表定义、主键、索引、注释、存储过程、自定义函数、触发器等所有对象。
此步骤其实是备份操作，在本次运维过程中也起了作用。本次实际运维过程中，由于有超大数据表存在，中途强行取消了部分表数据的迁移做了手工迁移，导致部分表的注释数据丢失，最后就是根据最初的这个备份过程找回了注释定义。
2、建立临时表空间、临时用户，参考语句如下：
CREATE TABLESPACE ts_x DATAFILE 'tsx01.dbf' SIZE 20480 AUTOEXTEND ON NEXT 2048 MAXSIZE 51200;
ALTER TABLESPACE ts_x ADD DATAFILE 'tsx02.dbf' SIZE 20480 AUTOEXTEND ON NEXT 2048 MAXSIZE 51200;
CREATE USER "ts_x" IDENTIFIED BY "123456789" DEFAULT TABLESPACE "ts_x" INDEX_TABLESPACE "ts_x";
GRANT "PUBLIC" TO "ts_x";
3、DTS迁移数据：具体参见“DM数据迁移工具”相关帮助；值得说明的是，DTS迁移会迁移所有对象，包括主键、注释等。
4、删除有问题的表空间（包括其上的对象）：
4.1、删除用户和模式：
实际操作过程中，这一步是问题最多的。由于是生产环境，所以一直有应用在连接数据库，直接drop用户会报“锁超时”；需要根据实际情况查询会话并击杀之。相关操作代码参考如下：
--查询会话信息
SELECT
SESS_ID AS "会话ID",
DECODE(STATE,'CREATE','创建','STARTUP','启动','IDLE','空闲','ACTIVE','活动','WAIT','等待','UNKNOWN','未知') AS "会话状态",
CREATE_TIME, TRX_ID AS "事务ID",SQL_TEXT AS "SQL",USER_NAME, CURR_SCH AS "当前模式", CLNT_TYPE AS "连接类型", DECODE(AUTO_CMT,'Y','是','N','否') AS "是否自动提交", DECODE(DDL_AUTOCMT,'Y','是','N','否') AS "DDL是否自动提交",
APPNAME AS "连接程序名", CLNT_IP AS "客户机IP",
CLNT_HOST AS "客户机名", OSNAME AS "客户机系统"
FROM V\$SESSIONS;
--查询死锁信息
SELECT ADDR AS "锁地址", TRX_ID AS "所属事务ID", LTYPE AS "锁类型", LMODE AS "锁模式", DECODE(BLOCKED,'1','是','0','否') AS "是否阻塞", TABLE_ID AS "对应表锁ID", ROW_IDX AS "TID锁事务ID"
FROM V\$LOCK;
--根据TABLE_ID查TRX_ID
SELECT TRX_ID, LTYPE, LMODE, TABLE_ID FROM VLOCK WHERE TABLE_ID=1199;
--根据TRX_ID查SESS_ID
SELECT * FROM V\$SESSIONS WHERE TRX_ID =50702145;
--根据SESS_ID杀掉会话
call SP_CLOSE_SESSION(140165318846264);
在击杀相关会话，确认用户和表空间未使用后，可以直接删除有问题的用户。
DROP USER "user01" CASCADE;
4.2、表空间离线并删除表空间：
ALTER TABLESPACE ts01 OFFLINE;
DROP TABLESPACE ts01;
删除后可以到OS里查询对应的数据文件，核查确认已经被清理。
4.3、重建表空间，重建用户，并迁移回数据。
4.4、核查迁移后的数据，确认对象和数据有效性和完整性。
说明：
1、因为是在业务内网上的操作，所以没有截图，本次只是记录整理下处理的过程；
2、实际上可以使用备份直接恢复，但是由于采用了“月全量+日增量”的备份策略，所以全量+增量恢复数据太麻烦，而在当前系统中表空间和用户都是一对一的，所以直接使用DTS迁移最快捷。
