谨慎使用达梦manger工具

全文中心思想一句话：不要用root用户打开达梦的manager工具！！！！

晚上七点左右突然接到测试人员的电话，报数据库无法连接。我表示，拒绝，震惊，不可能，我刚刚看还是好的，是不是你端口或者密码错了？然而当我登陆到数据库的时候，我发现数据库服务已经停止了。试图直接重启服务，报错端口被占用。查看进程发现，虽然dmserver的进程同样不在了，但是导入数据库dimp进程还在进行。杀掉dimp进程继续重启，依旧报错无法启动。我只能尝试用./dmserver的方式启动，报错，控制文件没有权限。我大为震惊，我看了一下控制文件，竟发现有一部分控制文件变为了root用户：组。

因为测试很急，我也没想太多，直接改了权限，希望尽快让服务恢复正常。但是同样通过直接起服务的方式无法启动数据库。只能再通过./dmserver的方式启动。数据库只能到mount状态，无法正常变为open。尝试手动，alter database open;依旧报错。我跑去看数据文件，再度惊讶地发现，TEMP.DBF也变为了root用户组。改了TEMP.DBF的权限后，数据库可以正常打开。这时我发现，所有的非系统表空间都显示脱机状态，数据文件在一个我完全陌生的路径下。万幸的是，这是一个新数据库，所有的数据可以重新进行迁移。删掉用户，删掉表空间，重头来过。

我联系了同事，交流之后。我们发现，这事情只有一种可能！就是创建表空间的时候，我同事把路径写错了，这个路径是另外一台数据库，数据文件存放的位置。本机并不存在这样一个目录。它本不应该成功。但是由于他是用root打开的manager工具，manager工具借助root的权限狐假虎威，不仅仅创建了数据文件，还捎带手把一系列的路径也创建好了。但是，权限也同样是root的。当我选择用dmdba用户把dmp文件导入到新建用户中，数据文件不是dmdba的，TEMP.DBF不是dmdba的，连控制文件都不是dmdba的。数据库接受不了这种现实就halt了。

现在还不确定如果在应用服务器上，root用户使用达梦工具是否会造成同样的伤害。后续会进行测试。

那今后遇到这种情况，怎么办呢？只能原谅他啊。只是在这里向各位提醒：

不要用root用户使用达梦的管理工具。