前因
升级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
于是就去具体查了日志：
容器中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
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
为了解决上面的报错，接下来我：
- 在容器里和宿主机里都查了下是什么进程在占用，但没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没问题！！由此可见还是文件被占用了。
不愧是我，挖坑自己跳。