1.客户发消息称,在DM管理工具里执行【创建表空间】命令报错,直接使用工具图形添加也报错
2. 发生时间为2023-2-14
3. 发送问题环境为测试库
4. 并且附带如下一张报错截图:
报错提示信息为控制文件错误,而非语法错误,不过我们还是看看,语句是否有问题,经检查无误。
检查控制文件,存在;要求客户发送数据库实例日志,即查看数据库日志$DM_HOME/log/dm_实例名.log文件,通过客户发送的文件来看,日志截止到2023-2-7就没有后续日志了,并且没有明显的报错信息
要求客户查看数据库进程,存在
这个时候客户反馈,管理工具和disql断开重连无法连接到数据库,并且检查了数据库状态为running
直到这里都未发现什么可疑迹象,建议开始尝试重启数据库
敢于尝试重启的是有原因的:控制文件DM是有自动备份的,即便重启也不会出现大问题,但是如果是数据文件报错就不能轻易尝试重启了
客户重启用户使用的是root用户非dmdba用户,并且启动失败,这时候沟通远程过去具体看下
经过数据库重启发现,当前客户指向的DM数据库目录和服务文件需要寻找的DM数据文件路径不一致
经确认,数据库目录被手动修改过但是客户并没有对数据库的控制文件进行修改
原来客户为了保持和生产相同的路径,对数据文件路径进行了变更
这种问题有两种解决方法
● 方法一:将目录改回原路径
例:这里原路径为:/data/dmdbms/data/DAMENG,而修改后是/home/data/dmdbms/data/DAMENG
那么需要执行以下语句:
# 1. 修改路径
mkdir -p /data/dmdbms/data
mv /home/data/dmdbms/data/DAMENG /data/dmdbms/data/
chown dmdba:dinstall /data/dmdbms/data -R
# 2.重启数据库
DmServiceDMSERVER start
● 方法二:修改数据库的控制文件中数据库文件路径指向新的路径,具体操作方法如下:
# 1. 将控制文件解析成文本形式
dmctlevt TYPE=1 SRC=/home/data/dmdbms/data/DAMENG/dm.ct1 DEST =/tmp/dmctl.txt
# 2. 修改控制文件中的file_path为新文件路径
:%s#/data/dmdbms/data/DAMENG#/home/data/dmdbms/data/DAMENG#g
:wq
# 3. 将文本形式的控制文件转为控制文件
./dmctlcvt TYPE=2 SRC=/tmp/dmctl.txt DEST=/home/data/dmdbms/data/DAMENG/dm.ct1
# 4. 修改注册服务文件里dm.ini 路径
vi ${DM_HOME}/bin/DmServiceDMSERVER
:%s#/data/dmdbms/data/DAMENG#/home/data/dmdbms/data/DAMENG#g
:wq
# 5. 修改数据库实例路径
mv /data/dmdbms/data/DAMENG /home/data/dmdbms/data/DAMENG
# 6. dm.ini文件里的实例路径
vi
:%s#/data/dmdbms/data/DAMENG#/home/data/dmdbms/data/DAMENG#g
:wq
# 7. 重启数据库
DmServiceDMSERVER start
# 1~6. 前4步同修改路经方法2的前6步,路径中的DAMENG为数据库名,也要注意修改哦。
# 7. 修改redo文件名,比如库名由DAMENG改为了DM
mv /home/data/dmdbms/data/DM/DAMENG01.log /home/data/dmdbms/data/DM/DM01.log
mv /home/data/dmdbms/data/DM/DAMENG02.log /home/data/dmdbms/data/DM/DM02.log
# 8. 启动数据库
DmServiceDMSERVER start
DM的控制文件中包含DM重要文件的路径。
数据文件路径一旦发生变化,但未修改控制文件,数据库仍将按照旧的数据文件路径去寻找文件,如果无法找到将会产生报错。
这也是为什么手动在服务器修改数据文件路径之后,控制文件里的内容也需要同步修改的原因。
经过这次的事件,发生控制文件报错时,可以优先考虑是否发生物理移动数据文件问题,这种无意识的误操作问题概率会比较高。
这点DM与MySQL是不同的,MySQL关库状态可以随意变更数据目录的物理位置,而不用担心发生意外。所以对于MySQL的用户来说,可能更容易发生此类问题。
文章
阅读量
获赞