ORA-01102: cannot mount database in EXCLUSIVE mode报错解决与原因分析

前因

升级salt-master的时候执行了yum update，然后把docker升级了，docker升级的时候覆盖掉了原来的service文件，而且还不知道为啥对iptables也做了更改（可能没改原来就那样。。）
然后起的容器服务就不可用了

后果

所以就去

清了iptables规则iptables -F。
注：这个命令慎用。。严重程度跟删库差不多了。
重设了service文件，然后重新systemctl daemon-reload、systemctl restart docker，
但是去重新起容器的时候告诉我，

Error response from daemon: OCI runtime create failed: container with id ... exists unknown

根据容器id起不来容器了？？？？？

然后就捣鼓了个啥，好像用容器名起了下？总之没改什么。然后就报了个新错

Error response from daemon failed to listen to abstract unix socket "/containerd-shim/moby/e485fefb2a6633abeb5012f43466888266dabba954c030a33c41a3d562e50ad4/shim.sock" listen unix /containerd-shim/moby/e485fefb2a6633abeb5012f43466888266dabba954c030a33c41a3d562e50ad4/shim.sock bind address already in use unknown

然后就去查了docker此类进程ps ux|grep docker，杀了下docker-containerd-shim -namespace moby -workdir /home/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby.....之类的，然后再重启就报了新错。。id不存在又id已存在。。最后无奈放弃，只能删除容器，使用原来的挂载重新run一个。于是起oracle的时候就遇到问题了（mongo倒是没问题）。

ps：关于以上的总结：1、3、4这三步走的好失败呀。应该再具体分析下，不然get不到原因。

后果之后的后果果：

oracle启动日志报错

Total System Global Area 5344731136 bytes
Fixed Size                  2213136 bytes
Variable Size            4294970096 bytes
Database Buffers         1006632960 bytes
Redo Buffers               40914944 bytes
ORA-01102: cannot mount database in EXCLUSIVE mode

Starting web management console
BEGIN DBMS_XDB.sethttpport(8080); END;

      *
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'DBMS_XDB.SETHTTPPORT' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored

根据报错ORA-01102: cannot mount database in EXCLUSIVE mode，百度了下，参考博客https://blog.csdn.net/lzwgood/article/details/26368323
试了下删除lk<sid>文件，然后再startup，跟博客中报了一样的错，但接下来博客中的解决方法并没有解决我的问题。
于是就去具体查了日志：
容器中oracle的部署目录/u01/app/oracle，所以
切换到trace目录cd /u01/app/oracle/diag/rdbms/xe/EE/trace，并查看alert log
tail -200 alert_EE.log

ALTER DATABASE   MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/flash_recovery_area/xe/control02.ctl'
ORA-27086: unable to lock file - already in use
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 8
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/u01/app/oracle/oradata/xe/control01.ctl'
ORA-27086: unable to lock file - already in use
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 8
ORA-205 signalled during: ALTER DATABASE   MOUNT...

又看了下alert下的log文件，tail -200 /u01/app/oracle/diag/rdbms/xe/EE/alert/log.xml

<msg time='2019-12-26T09:31:24.722+00:00' org_id='oracle' comp_id='rdbms'
 client_id='' type='UNKNOWN' level='16'
 host_id='d1f21b11dc48' host_addr='172.17.0.2' module=''
 pid='1308'>
 <txt>ORA-00210: cannot open the specified control file
ORA-00202: control file: &apos;/u01/app/oracle/flash_recovery_area/xe/control02.ctl&apos;
ORA-27086: unable to lock file - already in use
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 8
ORA-00210: cannot open the specified control file
ORA-00202: control file: &apos;/u01/app/oracle/oradata/xe/control01.ctl&apos;
ORA-27086: unable to lock file - already in use
Linux-x86_64 Error: 11: Resource temporarily unavailable
Additional information: 8
 </txt>

为了解决上面的报错，接下来我：

在容器里和宿主机里都查了下是什么进程在占用，但没get到什么有用的结果，然后就跳过了。
oracle容器里是oracle进程在占用（需要以特权方式启动--privileged），宿主机上是es用户的oracle进程在占用，没找到具体的进程来源。
1.1. 宿主机fuser -m -v /home/oralce查询结果：

/home/sgs/tj_oralce: root     kernel mount /home
                     es         1230 F.c.m oracle
                     es         1232 F.c.m oracle
                     es         1236 F.c.m oracle
                     es         1238 F.c.m oracle
....
                     es        24695 F.c.. oracle
                     es        24702 F.c.. oracle
                     es        24799 F.c.. oracle
                     root      29712 F...m dockerd
                     es        31103 F.... java

然后查了下具体什么进程

[root@xxx ~]# ps -ef|grep 24799
root      4127 32057  0 20:59 pts/0    00:00:00 grep --color=auto 24799
es       24799 16907  0 20:32 ?        00:00:00 oracleEE (LOCAL=NO)

或者
1.2. lsof查具体的控制文件

[root@manage ~]# lsof /home/oralce/flash_recovery_area/xe/control02.ctl 
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF       NODE NAME
oracle  19899   es   19u   REG  253,2  9748480 4295450992 /home/oralce/flash_recovery_area/xe/control02.ctl
oracle  19901   es   19u   REG  253,2  9748480 4295450992 /home/oralce/flash_recovery_area/xe/control02.ctl
oracle  19903   es   19uW  REG  253,2  9748480 4295450992 /home/oralce/flash_recovery_area/xe/control02.ctl
oracle  19909   es   21u   REG  253,2  9748480 4295450992 /home/oralce/flash_recovery_area/xe/control02.ctl

再查具体进程：

[root@manage ~]# ps -ef|grep 19899
root      5359 32057  0 21:02 pts/0    00:00:00 grep --color=auto 19899
es       19899 19635  0 13:40 ?        00:00:02 ora_dbw0_EE

还是没get到什么有用信息。

将两个新的控制文件另存一份
sqlplus /nolog登陆数据库后，切换sys用户conn sys/password as sysdba，然后创建pfilecreate pfile='/path/xepfile.ora’ from spfile;，并修改pfile中控制文件为新另存出来的
创建pfile的时候遇到了报错：

*
ERROR at line 1:
ORA-07391: sftopn: fopen error, unable to open text file.

属于文件权限问题，oracle用户可能对要创建的文件所在目录没有读写权限。

使用pfile重启数据库

shutdown immediate; 
startup pfile='/path/xepfile.ora';

startup的时候又有报错：

ORA-01157: cannot identify/lock data file 1 - see DBWR trace file 
ORA-01110: data file 1: '/u01/app/oracle/oradata/xe/system01.dbf'

试了下将datafile drop掉alter database datafile /u01/app/oracle/oradata/xe/system01.dbf offline drop;，然后执行recover databse;
但是没用，依旧报了其它数据文件lock，然后同样的方法继续试下去，发现所有的datafile都是lock，然后就怀疑整体的oracle文件挂载目录由于被占用，所以导致oracle mount失败。
于是，

在宿主机上将oracle容器的数据挂载目录重新拷贝了一份，然后用新拷贝出来的数据起一个新oracle容器，然后结果是：
居然可用！居然mount没问题！！由此可见还是文件被占用了。

不愧是我，挖坑自己跳。