当前位置:   article > 正文

ORA-01034 oracle not available_ora-01034: oracle not available

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/shmMEMORY_TARGET 小就会报错。所以之前重启数据库就遇到了报错。

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

在这里插入图片描述

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

在这里插入图片描述

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

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

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

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/菜鸟追梦旅行/article/detail/500134
推荐阅读
相关标签
  

闽ICP备14008679号