ORA-00845 : MEMORY_TARGET not supported on this system(调大数据库内存无法启动)

简介:

问题描述:调大数据库内存后,启动数据库报 ORA-00845 : MEMORY_TARGET not supported on this system 。

-- 调大数据库内存后,数据库启动报错
[root@jcdydb1 bin]# ./srvctl start database -d jcdydb
PRCR-1079 : Failed to start resource ora.jcdydb.db
CRS-5017: The resource action "ora.jcdydb.db start" encountered the following error: 
ORA-00845: MEMORY_TARGET not supported on this system
. For details refer to "(:CLSN00107:)" in "/oracle/app/11.2.0/grid/log/jcdydb1/agent/crsd/oraagent_oracle//oraagent_oracle.log".

CRS-5017: The resource action "ora.jcdydb.db start" encountered the following error: 
ORA-00845: MEMORY_TARGET not supported on this system
. For details refer to "(:CLSN00107:)" in "/oracle/app/11.2.0/grid/log/jcdydb2/agent/crsd/oraagent_oracle//oraagent_oracle.log".

CRS-2674: Start of 'ora.jcdydb.db' on 'jcdydb1' failed
CRS-2674: Start of 'ora.jcdydb.db' on 'jcdydb2' failed
CRS-2632: There are no more servers to try to place resource 'ora.jcdydb.db' on that would satisfy its placement policy

-- 查看服务器内存,132103588k /1024/1024 = 125G
top - 19:32:11 up 7:21, 7 users, load average: 1.13, 1.16, 1.16
Tasks: 2089 total, 1 running, 2088 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.3%us, 0.5%sy, 0.0%ni, 99.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 132103588k total, 31130024k used, 100973564k free, 216416k buffers
Swap: 67108856k total, 0k used, 67108856k free, 26919636k cached

-- 查看针对数据库的内核参数,发现没有问题
[root@jcdydb1 bin]# cat /etc/sysctl.conf
#add for oracle 11gR2 rac
kernel.shmmni = 4096
kernel.shmmax = 277439000000
kernel.shmall = 4294967296
kernel.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
kernel.sem = 3010 427420 3010 142
[root@jcdydb1 bin]# 
说明:
kernel.shmmax 共享内存段的大小,设置大小超过SGA大小才不不会造成性能问题。
kernel.shmall 共享内存页总数,设置大小为物理理内存大小/内存页大小。
通过getconf命令来获取内存页大小:
[root@rac01 ~ ]# getconf PAGE_SIZE
4096
[root@rac02 ~ ]# getconf PAGE_SIZE
4096

-- 查看 /dev/shm 大小, 发现只有内存的一半,小于数据库内存为服务器内存的80%,不符合要求。
[root@jcdydb1 bin]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/osvg-lv_root
99G 488M 93G 1% /
/dev/sda1 504M 45M 434M 10% /boot
/dev/mapper/osvg-lv_data
50G 3.7G 44G 8% /data
/dev/mapper/osvg-lv_home
9.9G 3.9G 5.5G 42% /home
/dev/mapper/osvg-lv_ora
99G 12G 82G 13% /oracle
/dev/mapper/osvg-lv_tmp
32G 9.5G 21G 32% /tmp
/dev/mapper/osvg-lv_usr
20G 7.4G 12G 40% /usr
/dev/mapper/osvg-lv_var
9.9G 508M 8.9G 6% /var
/data/soft/rhel-server-6.4-x86_64-dvd.iso
3.5G 3.5G 0 100% /media/rhel64
tmpfs 62G 0G 65G 0% /dev/shm

说明:/dev/shm的容量默认最大为内存的一半大小,使用df -h命令可以看到。但它并不会真正的占用这块内存,
如果/dev/shm/下没有任何文件,它占用的内存实际上就是0字节。

-- 查看 /dev/shm 被谁占用,快速加大 /dev/shm ,确认无重要进程使用/dev/shm后,需要 kill 文件使用者。 
[root@jcdydb1 bin]# lsof /dev/shm
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
pulseaudi 27716 grid mem REG 0,16 67108904 11057360 /dev/shm/pulse-shm-863193574
gnome-ter 42214 grid mem REG 0,16 67108904 11057310 /dev/shm/pulse-shm-3660319902

[root@jcdydb1 bin]# kill -9 27716 42214

-- 再次查看,发现无占用。
[root@jcdydb1 bin]# lsof /dev/shm
[root@jcdydb1 bin]#

-- umount /dev/shm
[root@jcdydb1 bin]# umount /dev/shm

-- 编辑 /etc/fstab , 加大 /dev/shm 。
[root@jcdydb1 bin]# vi /etc/fstab 修改
tmpfs /dev/shm tmpfs defaults,size=110G 0 0

[root@jcdydb1 bin]# mount /dev/shm

-- 查看 /dev/shm 大小。
[root@jcdydb1 bin]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/osvg-lv_root
99G 488M 93G 1% /
/dev/sda1 504M 45M 434M 10% /boot
/dev/mapper/osvg-lv_data
50G 3.7G 44G 8% /data
/dev/mapper/osvg-lv_home
9.9G 3.9G 5.5G 42% /home
/dev/mapper/osvg-lv_ora
99G 12G 82G 13% /oracle
/dev/mapper/osvg-lv_tmp
32G 9.5G 21G 32% /tmp
/dev/mapper/osvg-lv_usr
20G 7.4G 12G 40% /usr
/dev/mapper/osvg-lv_var
9.9G 508M 8.9G 6% /var
/data/soft/rhel-server-6.4-x86_64-dvd.iso
3.5G 3.5G 0 100% /media/rhel64
tmpfs 110G 0 110G 0% /dev/shm

--启动数据库。
[root@jcdydb1 bin]# ./srvctl start database -d jcdydb >成功!

文章可以转载,必须以链接形式标明出处。
本文转自 张冲andy 博客园博客,原文链接:   http://www.cnblogs.com/andy6/p/7309270.html ,如需转载请自行联系原作者


相关文章
|
2月前
|
存储 关系型数据库 MySQL
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
1073 2
|
3月前
|
存储 弹性计算 算法
前端大模型应用笔记(四):如何在资源受限例如1核和1G内存的端侧或ECS上运行一个合适的向量存储库及如何优化
本文探讨了在资源受限的嵌入式设备(如1核处理器和1GB内存)上实现高效向量存储和检索的方法,旨在支持端侧大模型应用。文章分析了Annoy、HNSWLib、NMSLib、FLANN、VP-Trees和Lshbox等向量存储库的特点与适用场景,推荐Annoy作为多数情况下的首选方案,并提出了数据预处理、索引优化、查询优化等策略以提升性能。通过这些方法,即使在资源受限的环境中也能实现高效的向量检索。
|
3月前
|
存储 缓存 API
LangChain-18 Caching 将回答内容进行缓存 可在内存中或数据库中持久化缓存
LangChain-18 Caching 将回答内容进行缓存 可在内存中或数据库中持久化缓存
54 6
|
4月前
|
安全 C++
超级好用的C++实用库之环形内存池
超级好用的C++实用库之环形内存池
86 5
|
4月前
|
存储 关系型数据库 MySQL
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
查询服务器CPU、内存、磁盘、网络IO、队列、数据库占用空间等等信息
268 5
|
4月前
|
C++
超级好用的C++实用库之动态内存池
超级好用的C++实用库之动态内存池
50 0
|
5月前
|
存储 缓存 NoSQL
Redis内存管理揭秘:掌握淘汰策略,让你的数据库在高并发下也能游刃有余,守护业务稳定运行!
【8月更文挑战第22天】Redis的内存淘汰策略管理内存使用,防止溢出。主要包括:noeviction(拒绝新写入)、LRU/LFU(淘汰最少使用/最不常用数据)、RANDOM(随机淘汰)及TTL(淘汰接近过期数据)。策略选择需依据应用场景、数据特性和性能需求。可通过Redis命令行工具或配置文件进行设置。
117 2
|
6月前
|
SQL 缓存 关系型数据库
(十二)MySQL之内存篇:深入探寻数据库内存与Buffer Pool的奥妙!
MySQL是基于磁盘工作的,这句几乎刻在了每个后端程序员DNA里,但它真的对吗?其实答案并不能盖棺定论,你可以说MySQL是基于磁盘实现的,这点我十分认同,但要说MySQL是基于磁盘工作,这点我则抱否定的态度,至于为什么呢?这跟咱们本章的主角:Buffer Pool有关,Buffer Pool是什么?还记得咱们在《MySQL架构篇》中聊到的缓存和缓冲区么,其中所提到的写入缓冲区就位于Buffer Pool中。
520 1
|
6月前
|
SQL 分布式计算 DataWorks
MaxCompute产品使用合集之整库离线同步至MC的配置中,是否可以清除原表所有分区数据的功能
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
5月前
|
SQL 分布式计算 大数据
"大数据计算难题揭秘:MaxCompute中hash join内存超限,究竟该如何破解?"
【8月更文挑战第20天】在大数据处理领域,阿里云的MaxCompute以高效稳定著称,但复杂的hash join操作常导致内存超限。本文通过一个实例解析此问题:数据分析师小王需对两个共计300GB的大表进行join,却遭遇内存不足。经分析发现,单个mapper任务内存默认为2GB,不足以支持大型hash表的构建。为此,提出三种解决方案:1) 提升mapper任务内存;2) 利用map join优化小表连接;3) 实施分而治之策略,将大表分割后逐一处理再合并结果。这些方法有助于提升大数据处理效率及稳定性。
121 0