问题背景 客户一套10.2.0.4的rac数据库，因为要进行11g升级，所以最近部署了spa采集任务，结果该任务部署没多久，smon就爆发了ora-21779错误。导致数据库运行非常缓慢。作为运维厂商，我们立马对数据库出错原因进行了分析。我们首先来看一下具体的smon报的错
问题背景 客户一套10.2.0.4的rac数据库，因为要进行11g升级，所以最近部署了spa采集任务，结果该任务部署没多久，smon就爆发了ora-21779错误。导致数据库运行非常缓慢。作为运维厂商，我们立马对数据库出错原因进行了分析。我们首先来看一下具体的smon报的错误信息。
*** 2014-04-26 13:47:28.987smon: following errors trapped and ignored:ora-21779: duration not activeora-06512: at line 1sat apr 26 13:48:06 2014>>> waited too long for a row cache enqueue lock! pid=36system state dumped to trace file /oracle/app/oracle/admin/wcrma/bdump/wcrma2_smon_3610.trcwcrma2_smon_3610.trcname=spa.systp9+mpuyj8/wlgraaut0sbea== drop transient type: systp9+mpuyj8/wlgraaut0sbea==m call stack:ksdxfstk()+36 0.0007hash=f8aafde8df1d0384b3c6849b889a14c9 timestamp=04-26-2014 12:48:31 library object handle: handle=1431525e88 mtx=1431525fb8(0) cdp=0
我们仔细的来看，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。
* function kqrigtmay call kslfre (...)may call kqrprl (...)may call ksesec0 (0x0fb5)may call ksbasend (dword ptr ds:kqrglk_+4, offset kqrglk_, 0x10, ...)may call kslgetl (?, 1, 0, offset kqrpl10_)may call kslwait (?, ds:kqrelk_, 0, ...)may call kslgetl (?, 1, ?, offset kqrpl10_)may call ksu_dispatch_tac ()may call kskchk ()may call ksuitr ()may call ksesec0 (...)may call kgeasnmierr (ds:ksmgpp_, ds:ksefac_, kqrigt-1, 0)may call kqrchk ()may call ksurea ()may call ksdwrf (failed to get row cache instance lock (post=%d,res=%lx)\n)may call kqrdrs (...)may call ksesec0 (0x259)may call ksesec0 (0x2bf)may call ksbcic (0x1e, ?, ?, 1)may call kslgetl (?, 1, ?, offset kqrpl43_)may call kgeasnmierr (ds:ksmgpp_, ds:ksefac_, kqrgplt, 2)may call kgeasnmierr (ds:ksmgpp_, ds:ksefac_, kqrigt-2, 0)may call ksdwra (>>> waited too long for a row cache enqueue lock! pid=%d)may call ksdwrf (>>> waited too long for a row cache enqueue lock! 解决办法 那么这个问题怎么解决了？我们可以参考文档receiving ora-21780 continuously in the alert log and smon trace reports drop transient type. (文档 id 1081950.1)的解决办法。首先针对这个transient type,smon大概会12个小时去清理一次。我们可以去手动进行清理，或者设置内部事件22834去阻止smon清理这类的type。
1.直接删除
step 1make sure you have a good full backup.step 2spool obj.lisalter session set nls_date_format='dd-mon-yyyy hh24:mi:ss';set pagesize 1000select o.* from obj$ o, type$ twhere o.oid$ = t.tvoid andbitand(t.properties,8388608) = 8388608 and (sysdate-o.ctime) > 0.0007;spool offstep 3find the object owner:step 4 drop the objects.drop type systpf/r2wn4kex7gqkja3afmsw== force;
2.设置内部事件22834去阻止smon清理这类型的type，但是可能会消耗更多的内存。
sql> alter system set event='22834 trace name context forever, level 1' scope=spfile;system altered.sql> alter system set event='22834 trace name context forever, level off' scope=spfile;system altered.
当然这个事件也可以使用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错误, 感谢原作者分享。