ORA-01034 oracle not available

ORA-01034 oracle not available

1-问题描述

今晚进行代码运行突然遇到下述报错，直接导致数据库关闭，所有的sql都无法执行，更无法连接。

尝试重启数据库实例，报错如下：

2-解决方案

重启服务器

值得注意的是重启服务器之前，服务器存储使用情况如下：

重启服务器之后，存储使用情况如下：

最大的区别就在于 /dev/shm 路径下的已占用空间直接得到了全部释放。但是在我重启数据库之后，该路径的存储又被占用到服务器重启之前的水平。

3-问题分析

3.1 /dev/shm目录

/dev/shm 这个目录是linux下一个利用内存虚拟出来的一个目录，这个目录中的文件都是保存在内存中，而不是磁盘上。其大小是非固定的，即不是预先分配好的内存来存储的。(shm == shared memory)

/dev/shm 的容量默认最大为内存的一半大小，使用 df -h 命令可以看到。但它并不会真正的占用这块内存，如果 /dev/shm/ 下没有任何文件，它占用的内存实际上就是0字节。
通过下面的命令，我们可以看到 /dev/shm 的文件系统为 tmpfs，即为临时文件系统。其他的几个 tmpfs 的挂载目录，其实质上于 /dev/shm 是一致的。

只是需要注意，存储在 /dev/shm 的数据，在服务器重启后会全部丢失。

3.2 oracle MEMORY_TARGET

在oracle 11g中新增的内存自动管理的参数 MEMORY_TARGET , 它能自动调整SGA和PGA，这个特性需要用到 /dev/shm 共享文件系统， 而且要求 /dev/shm 必须大于 MEMORY_TARGET，如果 /dev/shm 比 MEMORY_TARGET 小就会报错。所以之前重启数据库就遇到了报错。

经查询可以看到，我的数据库的memory_target的大小设置为63G，若 /dev/shm 目录下的空闲大小小于63G，就会报错。解决办法就是增大 /dev/shm 或是减小 MEMORY_TARGET。

在我重启数据库之后，发现 /dev/shm 目录下的存储又满了一大半，且全部是 ora_orcl 开头的文件。。。。

暂时没有再做处理，目前一切正常。

也有人直接关闭自动内存管理，即可释放 /dev/shm 目录下的存储占用。

一般情况下，数据库刚建立的时候，建议是自动管理，等运行一段时间，或者进入正常的时候，根据个人经验和awr.addm等的参考值，来调整数据库的相关参数，并把数据库内存管理变为手动。因为开启自动内存管理，也是有一些不可预测的风险，好比如，既然想让它为你多做事情，就得承担多一点的风险！
因为开启自动内存管理，也是有一些不可预测的风险，好比如，既然想让它为你多做事情，就得承担多一点的风险！**
当然这个看自己权衡利弊。