第一个问题：
SQL> conn / as sysdba
Connected to an idle instance.
（连接了一个空闲的实例，数据库未启动，需要启动数据库）
SQL> startup
报错：
ORA-01078: failure in processing system parametersLRM-00109: could not open parameter file '/opt/oracle/product/11.2/db_1/dbs/initorcl.ora'
原因：无法找到initorcl.ora文件：
（需要到上述路径查找文件，没有的话进行拷贝添加、重命名）
cd 到上述目录下：cd /opt/oracle/product/11.2/db_1/dbs/
ls查看确实找不到上述文件。
补充一下：
a.数据库的启动过程图
b.数据库启动与参数文件的关系
需要到spfile目录下（切换到安装数据库的admin目录下，看到spfile目录）
最终在目录/opt/oracle/admin/orcl1/pfile下看到init.ora.542018151831文件
拷贝到报错提示路径下
cp init.ora.542018151831 /opt/oracle/product/11.2/db_1/dbs/initorcl.ora
重新启动数据库，依然报同样的错，认定上面命令没有执行成功（考虑为权限问题或者需要重新登录），
权限问题，用root增加权限：chmod -R 777 目标 /目标文件夹
即
[[email protected] dbs]# chmod -R 777 initorcl.ora /opt/oracle/product/11.2/db_1/dbs/
（为确保命令生效，可退出再登录：exit，sqlplus连接后再startup）
来看一下：
第二个问题：
这次又报了个别的错（至少解决了刚才的问题。。。）
报错：
ORA-00845: MEMORY_TARGET not supported on this system
参考博客https://blog.csdn.net/iloli/article/details/45335315
得知是 oracle 11g 中有一个新特性 MEMORY_TARGET，
来自Oracle的官方解析是：
Starting with Oracle Database 11g, the Automatic Memory Management feature requires more shared memory (/dev/shm)and file descriptors. The size of the shared memory should be at least the greater of MEMORY_MAX_TARGET and MEMORY_TARGET for each Oracle instance on the computer. If MEMORY_MAX_TARGET or MEMORY_TARGET is set to a non zero value, and an incorrect size is assigned to the shared memory, it will result in an ORA-00845 error at startup.
文章给出的解释是 MEMORY_MAX_TARGET 的设置不能超过 /dev/shm 的大小。
于是需要进行：加大这个目录（/dev/shm）并使其生效。
查看并修改配置文件 /etc/fstab
xiang
mount -o remount,size=4G /dev/shm
df -h进行查看确认
再次启动数据库
实例终于启动了，但是看最后一行，非常好（sad），又有了一个报错：
第三个问题：
ORA-01102: cannot mount database in EXCLUSIVE mode
参看文章
https://blog.csdn.net/lzwgood/article/details/26368323
原因：
一、在HA系统中，已经有其他节点启动了实例，将双机共享的资源（如磁盘阵列上的裸设备）占用了；
二、说明Oracle被异常关闭时，有资源没有被释放，一般有以下几种可能，
1、 Oracle的共享内存段或信号量没有被释放；
2、 Oracle的后台进程（如SMON、PMON、DBWn等）没有被关闭；
3、 用于锁内存的文件lk<sid>和sgadef<sid>.dbf文件没有被删除。
解决思路：
本次操作为虚拟机，不存在HA系统，且在安装后一直未启动数据库，不存在释放和进程问题，定位到3——
“用于锁内存的文件lk<sid>和sgadef<sid>.dbf文件没有被删除”
lk<SID>的主要作用是说明DATABASE MOUNT上了,不用在MOUNT了.DATABASE UNMOUNT 后会删除掉,如果DATABASE确实没有MOUNT,这个文件在存在情况下，也MOUNT上，选择手工删除。
切到oracle宿主目录的dbs目录下,查看是否存在sgadef*和lk*文件
$cd $ORACLE_HOME
$cd dbs
$ls sgadef*
$ls lk*
确实存在lk文件
删除：rm lkORCL1
查看确认，已被删除。
备注：删除lk*文件的命令，可以参考另一份文章的 /sbin/fuser，以备自己下次遇到问题使用。
https://www.linuxidc.com/Linux/2017-06/144748.htm
/sbin/fuser的主要功能是使用文件或者套接字来表示识别进程。常把它用来查看相关进程和杀死相关进程。此处用来清除lk<SID>文件
/sbin/fuser -u /u01/app/oracle/product/11.2.0/db_1/dbs/lkHSDB 查询占用该临时文件的进程pid和username
/sbin/fuser -k /u01/app/oracle/product/11.2.0/db_1/dbs/lkHSDB 直接kill相关pid释放文件lk<SID>文件
/sbin/fuser -u /u01/app/oracle/product/11.2.0/db_1/dbs/lkHSDB 再次查看发现已经没有那些进程了
本来看博客，我还准备好了会出现博客下面的问题，结果神奇的连接上了
不夸张地说，这句“Connected”是今天看到的最开心的一句话了。加上之前安装过程的报错，这次安装数据库是出问题最多的一次，从一开始缺少软件包开始，经历了多个插曲，本来已经有多次重装的打算了。不知道后面使用中还会不会遇到问题，不过，出错越多越好，这样才能学习更多的知识。