12C ORA-27106 错误处理过程_hugepage=false
2017-07-28 14:30
886 查看
12C ORA-27106 错误处理过程
前两天客户Exadata 12c环境因为内存分配报错,以下为处理过程。节点重新启动的时候报错,但是其他节点却启动正常。报错内容:
ORA-27106 System pages not available toallocate memory
cd /ORACLE_BASE/diag/rdbms/zdzrac/zdzrac2/trace
tail -200 alert_zdzrac2.log 查看日志内容:
Supported system pagesize(s):
Fri Apr 10 18:07:43 2015
PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s) Fri Apr 10 18:07:43 2015
2048K 3079 8194 3076 ORA-27125
判断有可能是hugePage的分配不足导致。
检查了参数文件中修改的内容。发现设置了use_large_pages。参数值有三个代表的含义如下:
TRUE表示如果系统配置好了HugePage,则会使用,如果没有,SGA也可以使用通常页大小的内存,也就是说SGA可以运行在混合模式下。
FALSE表示,实例不会使用HugePage。
ONLY表示只使用Huge。
故障节点上use_large_pages值为ONLY。所以出现了上面没有足够的HugePage而报错的情况。
知道的问题的根源,解决起来就容易了。两种解决方案。
1、 修改操作系统参数vm.nr_hugepages将值扩大。
2、 修改数据库参数use_large_pages为TRUE。
SQL> show parameter use_large
SQL> alter system set use_large_pages=true scope=spfile;
经过沟通,用户方没有特别要求数据库参数的值,所以将其修改为TRUE后,事情结束。
为什么其他节点的数据库正常开启呢?
其实是因为这样,这套集群中一共有两个数据库。第二个数据库是后来创建的,use_large_pages的值为默认值TRUE。
故障节点重启后第二个数据库的实例先行启动,使用了大部分的HugePage,导致剩余的数量不够第一个数据库实例启动,因此报错。
更多内容,请参考http://blog.itpub.net/17203031/viewspace-775004/
前两天客户Exadata 12c环境因为内存分配报错,以下为处理过程。节点重新启动的时候报错,但是其他节点却启动正常。报错内容:
ORA-27106 System pages not available toallocate memory
cd /ORACLE_BASE/diag/rdbms/zdzrac/zdzrac2/trace
tail -200 alert_zdzrac2.log 查看日志内容:
Supported system pagesize(s):
Fri Apr 10 18:07:43 2015
PAGESIZE AVAILABLE_PAGES EXPECTED_PAGES ALLOCATED_PAGES ERROR(s) Fri Apr 10 18:07:43 2015
2048K 3079 8194 3076 ORA-27125
判断有可能是hugePage的分配不足导致。
检查了参数文件中修改的内容。发现设置了use_large_pages。参数值有三个代表的含义如下:
TRUE表示如果系统配置好了HugePage,则会使用,如果没有,SGA也可以使用通常页大小的内存,也就是说SGA可以运行在混合模式下。
FALSE表示,实例不会使用HugePage。
ONLY表示只使用Huge。
故障节点上use_large_pages值为ONLY。所以出现了上面没有足够的HugePage而报错的情况。
知道的问题的根源,解决起来就容易了。两种解决方案。
1、 修改操作系统参数vm.nr_hugepages将值扩大。
2、 修改数据库参数use_large_pages为TRUE。
SQL> show parameter use_large
SQL> alter system set use_large_pages=true scope=spfile;
经过沟通,用户方没有特别要求数据库参数的值,所以将其修改为TRUE后,事情结束。
为什么其他节点的数据库正常开启呢?
其实是因为这样,这套集群中一共有两个数据库。第二个数据库是后来创建的,use_large_pages的值为默认值TRUE。
故障节点重启后第二个数据库的实例先行启动,使用了大部分的HugePage,导致剩余的数量不够第一个数据库实例启动,因此报错。
更多内容,请参考http://blog.itpub.net/17203031/viewspace-775004/
相关文章推荐
- 12C ORA-27106 错误处理过程
- 统计分析表的存储过程遇ORA-00600错误分析与处理
- ORA-12537:TNS:connectionclosed错误处理过程
- 统计分析表的存储过程遇ORA-00600错误分析与处理
- 关于 12c GI 安装过程中,如果使用 NFS 方式提供 ASM 磁盘, 出现 ORA-15018 ORA-15072 ORA-15080 错误 (文档 ID 1945862.1)
- 一次Oracle宕机切换后产生ORA错误的处理过程
- 非禁用validateRequest=false使用Page_Error()错误处理[摘自网络]
- ORA-28056错误处理过程
- ORA-12537: TNS:connection closed错误处理过程
- ORA-4065错误处理过程
- 非禁用validateRequest=false使用Page_Error()错误处理
- oracle 12C RAC启动实例时报ORA-00206: error in writing (block 1, # blocks 1) of control file错误处理
- oracle11g 云上dataguard 在线降低cpu内存 50% 后报错误ORA-27101的处理过程
- ORA-1461错误处理过程!
- Ora-00600 4194错误的处理过程
- Oracle 11g default profile 默认启用密码过期180天 ORA-28001错误处理
- ASP.NET Core应用的错误处理[2]:DeveloperExceptionPageMiddleware中间件如何呈现“开发者异常页面”
- ORA-12547经典错误处理
- 处理错误:ORA-27101: shared memory realm does not exist记实
- 详解数据库之存储过程与错误处理