赞
踩
今晚进行代码运行突然遇到下述报错,直接导致数据库关闭,所有的sql都无法执行,更无法连接。
尝试重启数据库实例,报错如下:
值得注意的是重启服务器之前,服务器存储使用情况如下:
重启服务器之后,存储使用情况如下:
最大的区别就在于 /dev/shm
路径下的已占用空间直接得到了全部释放。但是在我重启数据库之后,该路径的存储又被占用到服务器重启之前的水平。
/dev/shm
这个目录是linux下一个利用内存虚拟出来的一个目录,这个目录中的文件都是保存在内存中,而不是磁盘上。其大小是非固定的,即不是预先分配好的内存来存储的。(shm == shared memory)
/dev/shm
的容量默认最大为内存的一半大小,使用 df -h
命令可以看到。但它并不会真正的占用这块内存,如果 /dev/shm/
下没有任何文件,它占用的内存实际上就是0字节。
通过下面的命令,我们可以看到 /dev/shm
的文件系统为 tmpfs
,即为临时文件系统。其他的几个 tmpfs
的挂载目录,其实质上于 /dev/shm
是一致的。
只是需要注意,存储在 /dev/shm
的数据,在服务器重启后会全部丢失。
在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等的参考值,来调整数据库的相关参数,并把数据库内存管理变为手动。因为开启自动内存管理,也是有一些不可预测的风险,好比如,既然想让它为你多做事情,就得承担多一点的风险!
因为开启自动内存管理,也是有一些不可预测的风险,好比如,既然想让它为你多做事情,就得承担多一点的风险!**
当然这个看自己权衡利弊。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。