linux内存96后无法连接,linux服务器因磁盘空间满导致oracle数据库无法连接问题探索...

记录一下程序连不上库问题解决过程：

此前没接触过linux，所以过程比较繁琐

首先我部署在linux服务器上的项目莫名其妙连不上oracle库了，用plsql连接报这个：

然后我就上putty，ssh连接服务器，sqlplus登录库时报这个：

ORA-01034 - Oracle not available

ORA-27101 - shared memory realm does not exist

我查询有说tnsnames.ora没有配置，但我的配置的很正常

然后想到是不是磁盘空间满了导致oracle关闭了，就输入命令测试了一下

df -lh

果然我vda3这个分区挂载在/根目录上，已经占用100%，全满了。

查了查关于linux分区和目录的关系：https://www.cnblogs.com/lbole/p/8904298.html

知道了linux中只有一个树状目录，不像windows中每个盘符都是一个树状目录。

linux虽然只有一个目录，但是存储的子目录及文件可以分别存在不同的分区盘上。

比如我这里有 vda3,vdb2,vdb1三个分区，分别代表第一个盘的第三个分区，第二个盘的第二分区，第二个盘的第一分区。

其中vda3挂载到了“/”根目录上，而vdb2挂载到了/opt/app上。

我感觉vda3就像windows中的c盘，因为它挂载了根目录，也就是说如果它的子目录如果不被其他分区挂载的话，所有文件都会在这个vda3中，但这里/opt/app 和data都被其他盘挂载了，感觉其他盘就像 D,E盘似的。

我想看看根目录上什么占用这么大空间，于是查到这个命令

du -h --time --max-depth=1 / | sort -hr

此命令显示根目录“/”下文件夹由大到小排序

可见/u01目录占用了我13g，是个占内存大户。

但我又看到了/opt这个目录，占了2.3g，但我看上面查分区内存情况时 /opt/data挂载到了vdb1分区去了，咋又跑这来占跟路径分区来了。

所以我想到看一下opt到底在哪个分区下，于是找到这个命令：

df 路径

可以看到/opt目录虽然在vda3分区上，但它下面的/opt/data已经跑到vdb1分区下面去了，也就是说在/opt/data下面放再多东西也不会占vda3根目录的分区。

所以想要清理一些有效垃圾主要还是在u01和home文件夹中，home中删除了一些日志文件，然后看这个清除了一些oracle垃圾

https://blog.csdn.net/qinshi965273101/article/details/83617128

然后再看我的剩余空间：

有1.4g的剩余空间了

这下就可以启动我的oracle了。

(1) 以oracle身份登录数据库，命令：su – oracle

(2) 进入Sqlplus控制台，命令：sqlplus /nolog

(3) 以系统管理员登录，命令：connect / as sysdba

(4) 启动数据库，命令：startup

(5) 如果是关闭数据库，命令：shutdown immediate

(6) 退出sqlplus控制台，命令：exit

(7) 进入监听器控制台，命令：lsnrctl

(8) 启动监听器，(如果已经启动就无需管了)命令：start

(9) 退出监听器控制台，命令：exit

(10) 重启数据库结束

重启oracle成功后程序果然正常了。

总结：

其实这就是一个简单的磁盘满了倒是oracle服务停止了问题。主要不了解linux磁盘目录和分区关系，只要知道了那些目录占用根目录较大，而且还没有挂载到其他分区上，就要想办法删除无用数据或者直接将这个目录移到其他分区去就行了