ORA-1034 ORA-27102
Table of Contents
- 1. 现象
- 2. 分析
- 2.1. 内核参数
- 2.2. 数据库内存使用情况
- 3. 解决
- 3.1. 第一次尝试
- 3.2. 第二次尝试
- 4. 总结
没有足够的空闲内存. 这个问题很难分析。因为有时候，我们所依赖的操作系统命令，其实是在逗我们玩儿。 下面是我的一欠遍体鳞伤的经历，不堪回首呀。
1 现象
客户反馈数据库无法连接，报错信息如下:
SQL*Plus: Release 12.2.0.1.0 Production on Thu May 21 20:47:50 2020 Copyright (c) 1982, 2016, Oracle. All rights reserved. ERROR: ORA-01034: ORACLE not available ORA-27102: out of memory Linux-x86_64 Error: 12: Cannot allocate memory Additional information: 2731 Additional information: 557064 Additional information: 1744830464 Process ID: 0 Session ID: 0 Serial number: 0 Enter user-name:
2 分析
连接的时候无内存分配。。数据库连接的时候，都哪里需要内存呢？操作系统进程和oracle pga，但是后者所需很少. 先看物理内存吧。
[root@bossdb1 ~]# free -m
total used free shared buff/cache available
Mem: 64213 6219 25718 31115 32275 25987
Swap: 32191 0 32191
有25G 的空闲内存，哎哟，看来不是内存的问题,。难道是内核参数设置不正确或者分给Oracle 的内存用光了?如果是后者那太可怕了。
!就是从这儿开始，我在鬼打墙里转了两天!
2.1 内核参数
查看内核参数和用户限制吧。
# 查看用户最大允许锁定内存 [grid@bossdb1 ~]$ ulimit -m unlimited [oracle@bossdb2 ~]$ ulimit -m unlimited [grid@bossdb2 ~]$
都没有限制。 查看shmmax 和shmall:
[root@bossdb1 69431]# sysctl -a |grep kernel.shm kernel.shm_next_id = -1 kernel.shm_rmid_forced = 0 kernel.shmall = 16438528 kernel.shmmax = 67332210688 kernel.shmmni = 4096 ........
从上面查看的物理总内存为64G . 这里shmmax=67332210688/1024/1024/1024 = 62G shmall=16438528*4096/1024/1024/1024 = 62G
从这里看，也没有问题。
难道真的数据库把内存用光了？
2.2 数据库内存使用情况
内存上限
show parameter memory_max_target NAME TYPE VALUE ------------------------------------ -------------------------------- ------------------------------ memory_max_target big integer 50048M
SGA
select inst_id,sum(bytes)/(1024*1024*1024) from gv$sgainfo where name not in ('Granule Size','Maximum SGA Size','Startup overhead in Shared Pool','Free SGA Memory Available') group by inst_id INST_ID SUM(BYTES)/(1024*1024*1024) ---------- --------------------------- 1 26.2499972 2 19.7499972PGA
select inst_id,value/(1024*1024*1024) from gv$pgastat where name='total PGA allocated'; INST_ID VALUE/(1024*1024*1024) ---------- ---------------------- 2 2.93612671 1 4.7712841以上内存使用总量:
节点 内存使用量 1 26.25+4.77 = 31.02 2 19.75+2.94 = 22.69 两个节点内存使用远没有达到上限呢。
这是什么鬼？？物理内存充足，Oracle 内存没有达到上限。怎么就无法分配内存了呢？难道是Oracle 12C BUG ?
MOS 查起来。。。发现没有BUG. 而且遇到这种情况的都是之前检查的内容。难道是进程数达到上限了？不对。达到进程数上限不是这个错误。
生无可恋了。。。。无心睡眠。。这是哪儿的问题。。 正好赶上客户要做变更。。晚上要停业务。。
重启是万能的法宝。晚上一起重启了吧。第二天，一个白天都灰常顺利。。开心下班。。以为这次就这么过去了。 可是刚到家。同事发来消息: 数据库又不能连了，跟昨天一样的错误。
我的以内那是一万匹草泥马奔腾而过…………….
从头开始。
物理内存
接着查看物理内存使用情况:
total used free shared buff/cache available Mem: 64213 7209 33239 20670 23764 35384 Swap: 32191 0 32191
并没有太大的变化 。
top - 23:51:30 up 1 day, 23:35, 4 users, load average: 1.99, 1.97, 2.06 Tasks: 699 total, 2 running, 697 sleeping, 0 stopped, 0 zombie %Cpu(s): 6.4 us, 2.0 sy, 0.0 ni, 85.6 id, 6.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 65754708 total, 34170344 free, 7248336 used, 24336028 buff/cache KiB Swap: 32964604 total, 32964604 free, 0 used. 36368028 avail Mem
并没有问题。虽然有预期，但是还是有点失望。随便看看吧。现在数据库有多少进程呀？
3 解决
3.1 第一次尝试
select inst_id,machine,program,count(*) from gv$session group by inst_id,machine,program order by 4;
INST_ID MACHINE PROGRAM COUNT(*)
---------- ------------ ---------------------------- ----------
2 bossdb2 oracle@bossdb2 (PING) 1
.............
2 boss-ei1 JDBC Thin Client 13
1 ilogmaster shiyi@ilogmaster (TNS V1-V3) 23
1 KMGDCCWeb1 JDBC Thin Client 24
2 ipcc-hp-app JDBC Thin Client 522
1 ipcc-hp-app JDBC Thin Client 887
我个去，这是什么情况，一台应用服务器怎么连到数据库里有1400+ 进程。。都是活动的？
select inst_id,status,count(*) from gv$session where machine='ipcc-hp-app' group by inst_id,status;
INST_ID STATUS COUNT(*)
---------- -------- ----------
1 INACTIVE 862
2 INACTIVE 522
1 ACTIVE 1
都是不活动的。这些进程，占用了多少数据库内存，又占用了多少操作系统的物理内存？前者可能不大，但是后者肯定是有些恐怖的。
这些进程为什么不会退出呢？就算应用里没有退出机制，在数据库里也有空闲连接的配置呀:
col limit for a10 col resource_name for a15 col profile for a20 select profile,resource_name,limit from dba_profiles where resource_name = 'IDLE_TIME'; PROFILE RESOURCE_NAME LIMIT -------------------- --------------- ---------- DEFAULT IDLE_TIME UNLIMITED
居然是个Unlimited.
此刻我内心，其实已经倾向于是这些进程搞的鬼了。。。先把idle_time 限制起来吧。
alter profile default limit idle_time 180;
限制180，也就是3个小时，已经很长了。等一会儿，看看，果然pmon 已经清理超时进程了。
........ KILL SESSION for sid=(2973, 57359): Reason = profile limit idle_time Mode = KILL SOFT -/-/- Requestor = PMON (orapid = 2, ospid = 33310, inst = 1) Owner = Process: USER (orapid = 815, ospid = 95705) Result = ORA-0 .........
现在数据库也可以正常连接。那么基本可以肯定是这些进程搞的鬼。
但是，我心里仍有不甘。真的是这些进程搞得鬼么？还是只是凑巧，其他地方的问题也恢复了。
观察两天，之前重复出现的问题没有再出现。那么基本肯定是这些进程引起的问题。
研究很久，目前也没有找到方法统计进程占用的真实的物理内存，哎。
本以为这次已经解决了。但是三天后的傍晚再一次报错。
3.2 第二次尝试
现象与之前一样，但是实在是没办法了。按照往常的经验，分配给 Oracle 的内存是物理内存的80%。 64*0.8 是51g+ ,我分配给ORACLE 50G(memory_target,memory_max_size). 但是这次发现buffer/cache 占用非常高几乎达到了我分配给oracle 的内存。
[oracle@bossdb1 ~]$ free -m
total used free shared buff/cache available
Mem: 64213 13147 1248 32566 49817 17399
Swap: 32191 0 32191
按原理来讲，Linux 在物理内存不足的情况下，会自动清理buffer/cache 中。但系统并没有清理，关于 在5、6版本中控制尽快清理 buffer/cache 的内核参数vm.extra_free_kbytes 在CentOS7中也被去除了。 尝试设置此参数时会有如下提示：
sysctl -w vm.extra_free_kbytes=10240000 sysctl: cannot stat /proc/sys/vm/extra_free_kbytes: No such file or directory
没有办法了，黔驴技穷的我，只有两个操作可以做了，一是降低Oracle 内存分配，另一个就是定时清理cache.
# 降低Oracle 内存分配。将原来的50G 改为30G . alter system set memory_target=30G scope=spfile sid='*'; startup force
做定时任务，每小时清理一次。 编写脚本：
cat >> /root/scripts/clear_buffer.sh</proc/sys/vm/drop_caches EOF 编写定时任务,crontab -e 编写，crontab -l 查看，内容如下： 0 * * * * sh /root/scripts/clear_buffer.sh
设置系统参数 vm.vfs_cache_pressure=500,以加速清理vfs缓存。
sysctl -w vm.vfs_cache_pressure=500 cat >> /etc/sysctl.conf<操作完成后，内存使用情况如下：
节点1： [oracle@bossdb1 ~]$ free -m total used free shared buff/cache available Mem: 64213 5170 37881 20195 21160 37969 Swap: 32191 0 32191 节点2： [oracle@bossdb2 ~]$ free -m total used free shared buff/cache available Mem: 64213 4215 32670 19278 27328 39781 Swap: 32191 0 32191次日:
[root@bossdb1 ~]# free -m total used free shared buff/cache available Mem: 64213 10061 32486 20587 21665 32459 Swap: 32191 0 32191 [root@bossdb2 scripts]# free -m total used free shared buff/cache available Mem: 64213 8660 33739 20830 21812 33652 Swap: 32191 0 32191观察一星期后，问题不再出现。
4 总结
在第一次尝试解决的时候，其实我没有注意到,oracle(sga+pga)+ 操作系统中的buffer/cache 其实已经接近满内存了。
对于CentOS 7.6 没有了控制清除buffer/cache的内核参数，所以只有通过crontab 定时任务清理。否则会出现由于 buffer/cache不释放将内存耗光的情况。
Created: 2020-05-29 Fri 14:17
Validate