问题背景 客户一套10.2.0.4的RAC数据库,因为要进行11g升级,所以最近部署了SPA采集任务,结果该任务部署没多久,SMON就爆发了ORA-21779错误。导致数据库运行非常缓慢。作为运维厂商,我们立马对数据库出错原因进行了分析。我们首先来看一下具体的SMON报的错
客户一套10.2.0.4的RAC数据库,因为要进行11g升级,所以最近部署了SPA采集任务,结果该任务部署没多久,SMON就爆发了ORA-21779错误。导致数据库运行非常缓慢。作为运维厂商,我们立马对数据库出错原因进行了分析。我们首先来看一下具体的SMON报的错误信息。
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
我们仔细的来看,SMON在清理一个transient type的时候,报了这个错误,也就是清理过程中出现了问题。而transient type是一种临时的type。它是在动态执行的时候产生在内存里面的。例如应用程序在语句里面定义了自定义的Type,在运行过程中,运行到这一步它就会转化成transient type。根据文档SMON: Following Errors Trapped And Ignored ORA-21779 (文档 ID 988663.1)的描述。这个问题会引起alert日志大量的增长,产生大量的trace,但是不会影响到数据库正常使用,但是在实际情况下,我们发现并非如此,因为我们的SMON进程是非常关键的进程,它在删除某些东西的时候需要申请到锁,而我们从这一次的堆栈中可以看到下列函数。我们主要来看下kqrigt函数。该函数在谷歌上搜索可以查到下列内容,可以看到这个函数里面需要申请row cache instance lock锁,如果申请不到,就会报WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK。而这里它需要申请的是dc_rollback_segments。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 |
|
2.设置内部事件22834去阻止SMON清理这类型的Type,但是可能会消耗更多的内存。
1 2 3 4 |
|
当然这个事件也可以使用oradebug来进行设置。这样就不需要进行重启的操作。
参考文档:
Receiving ORA-21780 Continuously in the Alert Log and SMON Trace Reports "Drop transient type". (文档 ID 1081950.1)
SMON: Following Errors Trapped And Ignored ORA-21779 (文档 ID 988663.1)
原文地址:SMON遇到ORA-21779: duration not active错误, 感谢原作者分享。