[oracle@jcy1 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Sun Feb 2 14:01:14 2020 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to an idle instance.SQL> startup ORA-01078: failure in processing system parameters LRM-00109: could not open parameter file '/u01/app/oracle/product/11.2/db_1/dbs/initTEST1.ora' 查询百度的解决方法：将$ORACLE_BASE/admin/数据库名称/pfile目录下的init.ora.012009233838形式的文件copy 到$ORACLE_HOME/dbs目录下initoracle.ora即可。（注：initoracle.ora中的oracle为你的实例名 ORACLE_SID） 比如我的就为： [oracle@jcy1 pfile]$ cp /u01/app/oracle/admin/test1/pfile/init.ora.12202064546 /u01/app/oracle/product/11.2/db_1/dbs/initTEST1.ora再次启动SQL> startup ORACLE instance started. Total System Global Area 413372416 bytes Fixed Size 2253784 bytes Variable Size 327158824 bytes Database Buffers 79691776 bytes Redo Buffers 4268032 bytes ORA-01102: cannot mount database in EXCLUSIVE mode 查询百度的解决方法：
分析原因：
一、在HA系统中，已经有其他节点启动了实例，将双机共享的资源（如磁盘阵列上的裸设备）占用了；
二、 说明Oracle被异常关闭时，有资源没有被释放，一般有以下几种可能，
1、 Oracle的 共享内存段或信号量没有被释放；
2、 Oracle的后台进程（如SMON、PMON、DBWn等）没有被关闭；
3、 用于 锁内存的文件lk<sid>和sgadef<sid>.dbf文件没有被删除。
具体做法：
首先，虽然我们的系统是HA系统，但是备节点的实例始终处在关闭状态，这点通过在备节点上查数据库状态可以证实。
其次、是因系统掉电引起数据库宕机的，系统在接电后被重启，因此我们排除了第二种可能种的1、2点。最可疑的就是第3点了。
查$ORACLE_HOME/dbs目录：
$ cd $ORACLE_HOME/dbs
$ ls sgadef*
ls: cannot access sgadef*: No such file or directory
没有
[oracle@jcy1 dbs]$ ls lk* lkTEST lkTEST1
果然，lk<sid>文件没有被删除。将它删除掉
[oracle@jcy1 dbs]$ rm lk*
启动open
SQL> startup mount ORACLE instance started. Total System Global Area 413372416 bytes Fixed Size 2253784 bytes Variable Size 327158824 bytes Database Buffers 79691776 bytes Redo Buffers 4268032 bytes Database mounted.
没问题
启动到open
SQL> alter database open; alter database open * ERROR at line 1: ORA-01190: control file or data file 1 is from before the last RESETLOGS ORA-01110: data file 1: '/ooradata/test1/system01.dbf'
最后也没有解决，第二天，重启虚拟机，就能open了。
