一则oracle 12c的bug问题解决过程记录
一套新安装的12c 的主库和 dataguard 库中发现 alert 日志报错：
2018-07-30T22:04:17.522506+08:00 Non critical error ORA-48913 caught while writing to trace file "/opt/app/oracle/diag/rdbms/mingdb_dg/mingdb_dg/trace/mingdb_dg_mmo n_12919.trc" Error message: ORA-48913: Writing into trace file failed, file size limit [1048576] reached Writing to the above trace file is disabled for now on... 2018-07-30T22:04:18.774521+08:00 Non critical error ORA-48913 caught while writing to trace file "/opt/app/oracle/diag/rdbms/mingdb_dg/mingdb_dg/trace/mingdb_dg_gen 0_12867.trc" Error message: ORA-48913: Writing into trace file failed, file size limit [1048576] reached Writing to the above trace file is disabled for now on... |
后台进程的 trace 文件已经达到了最大容量限制，涉及到两个进程： mmon 进程和 gen0 进程。
Mmon ：该进程是 awr 主要进程，将统计数据写入 sysaux 表空间。
Gen0 ：通用任务执行进程，分担其他进程的阻塞处理
Trace 文件内容如下：
*** 2018-07-30T14:20:18.835255+08:00 (CDB$ROOT(1)) AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1 *** 2018-07-30T14:20:21.836263+08:00 (CDB$ROOT(1)) AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1 *** 2018-07-30T14:20:24.837269+08:00 (CDB$ROOT(1)) AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1 *** 2018-07-30T14:20:27.838318+08:00 (CDB$ROOT(1)) AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1 *** 2018-07-30T14:20:30.839297+08:00 (CDB$ROOT(1)) AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1 *** 2018-07-30T14:20:33.840291+08:00 (CDB$ROOT(1)) AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1 *** 2018-07-30T14:20:36.841287+08:00 (CDB$ROOT(1)) AUTO SGA: kmgs_parameter_update_timeout gen0 0 mmon alive 1 |
看起来跟 SGA 自动管理有关系。这套库 sga 和 PGA 是分别自动管理的。
在 mos 中搜索是未发布的 bug ：
Unpublished Bug 25415713 - MMON TRACE FILE GROWS WHEN NO TRACES ARE ENABLED
解决措施：
Unix 和 Linux 需要打补丁，补丁包： p25415713_12201180717DBJUL2018RU_Linux-x86-64 。
打这个 RU 之前，需要先打 PSU 28163133 。
Windows 平台， patch 25415713 不起作用。
或者，将自动 SGA 管理转变成手动管理。
alter system set sga_target=0 scope=spfile;
然后根据内存大小设置 db_cache_size ， shared_pool_size ， java_pool_size ， log_buffer ， streams_pool_size
通过第二种方法，后续日志中没有再出现过相同的报错了。
