请问：Cursor: pin S wait on X是不是oracle的bug？

upper123 · 发表于 2007-2-7 16:51

请问：Cursor: pin S wait on X是不是oracle的bug呢？在metalink里面找到的是在bug列表里，据说是library lacth的替代品，是不是这个技术还不成熟呢？

另外，是不是在Oracle 10.2.0.2.0中已经更改了呢？

upper123 · 发表于 2007-2-7 19:25

最初由 upper123 发布
[B]请问：Cursor: pin S wait on X是不是oracle的bug呢？在metalink里面找到的是在bug列表里，据说是library lacth的替代品，是不是这个技术还不成熟呢？

另外，是不是在Oracle 10.2.0.2.0中已经更改了呢？ [/B]

没有人见过这个等待事件吗？
metalink中这么说的：

Bug 号       5184776
已归档       24-APR-2006                               已更新 11-MAY-2006
产品          Oracle Server - Enterprise Edition       产品版本  10.2.0.2.0
平台          Solaris Operating System (SPARC 64-bit) 平台版本 8
数据库版本    10.2.0.2.0                               影响平台  Generic
优先级       Severe Loss of Service                   状态 Closed, Could Not Reproduce
基本 Bug    N/A                                     修复产品版本无数据

问题陈述:

HIGH 'CURSOR: PIN S WAIT ON X'
--------------------------------------------------------------------------------

  *** 04/24/06 08:26 pm ***
  TAR:
  ----
  .
  PROBLEM:
  --------
  High 'cursor: pin S wait on X' % waits seen in v$session_wait.
  .
  DIAGNOSTIC ANALYSIS:
  --------------------
  Similar to bug :
  .
  Bug 5079609/4402255 APPSST GSI 10G THOUSANDS OF SESSIONS WAITING ON 'CURSOR  PIN S WAIT ON X'
  .
  Bug 5095738/4402255 APPSST - 10GGSI - HIGH CURSOR PIN S WAIT ON X WAITS ON  PRODUCTION INSTANCE
  .
  . However bug 4402255 is suppose to be fixed in 10.2.0.2.0
  .
  WORKAROUND:
  -----------
  None.
  .
  RELATED BUGS:
  -------------
  .
  REPRODUCIBILITY:
  ----------------
  .
  TEST CASE:
  ----------
  .
  STACK TRACE:
  ------------
  .
  SUPPORTING INFORMATION:
  -----------------------
  .
  24 HOUR CONTACT INFORMATION FOR P1 BUGS:
  ----------------------------------------
  .
  DIAL-IN INFORMATION:
  --------------------
  .
  IMPACT DATE:
  ------------
  .
  *** 04/24/06 08:30 pm
  ***
  *** 04/24/06 08:30 pm
  *** (CHG: Sta->16)
  *** 04/24/06 08:36 pm
  ***
  *** 04/24/06 08:40 pm
  ***
  *** 04/25/06 01:28 am
  *** (CHG: Asg->NEW OWNER)
  *** 04/25/06 01:28 am
  *** BDE Screening....
  *** 04/25/06 03:46 am
  *** (CHG: Sta->10)
  *** 04/25/06 03:46 am
  ***
  *** 04/25/06 07:25 pm
  ***
  *** 04/25/06 07:25 pm
  *** (CHG: Sta->16)
  *** 04/26/06 02:37 am
  *** (CHG: Sta->10)
  *** 04/26/06 02:37 am
  ***
  *** 05/02/06 02:24 am
  ***
  *** 05/02/06 02:25 am
  *** (CHG: Sta->16)
  *** 05/03/06 05:28 am
  *** (CHG: Sta->10)
  *** 05/03/06 05:28 am
  ***
  *** 05/11/06 07:23 pm
  ***
  *** 05/11/06 07:23 pm
  *** (CHG: Sta->16)
  *** 05/11/06 11:08 pm
  *** (CHG: Sta->91)
  *** 05/11/06 11:08 pm
  ***

但是具体情况我就不理解了阿，有没有大虾给解释一下？

玉面飞龙 · 发表于 2007-5-16 21:42

现在你们有何进展？

oracle10g 10.2.0.2 ，当使用那个自动gather schema statistics的job时候，可能会引起该bug.

又或者shared_pool_size参数设置得太小；这个参数和9i中的shared_pool_size意义不一样，你应该知道的。

http://archive.netbsd.se/?ml=oracle-l&a=2006-04&t=1969601

upper123 · 发表于 2007-5-17 09:16

最初由玉面飞龙发布
[B]现在你们有何进展？

oracle10g 10.2.0.2 ，当使用那个自动gather schema statistics的job时候，可能会引起该bug.

又或者shared_pool_size参数设置得太小；这个参数和9i中的shared_pool_size意义不一样，你应该知道的。

http://archive.netbsd.se/?ml=oracle-l&a=2006-04&t=1969601 [/B]

五一前修改了_kks_use_mutex_pin为FALSE，但是现在又被大量的library cache pin代替了。现在数据库比较奇怪，每次CPU高的时候，等待事件存在大量的library cache pin，然后手工flush共享池之后，CPU就降下来了，看来不使用共享池机制反而使系统性能变好了。呵呵，当然这个问题肯定要解决的。

这两天我正在考虑是否要对oracle进行版本升级到10.0.2.3，但是考虑到10.0.2.3版本为最新版本，不敢轻易踩雷阿。

不知道大家那里是否有oracle r10比较稳定的版本推荐？

upper123 · 发表于 2007-5-17 09:20

最初由 Kamus 发布
[B]如果Cursor: pin S wait on X占据top wait事件前几名，那么是bug的可能性比较大。

至少在10.2.0.3中也仍然同样存在如下的这些bug
bug 5907779 - proactively avoid "cursor: ping S wait on X", dbms_stats.gather_database_stats_job_proc
bug 5485914 - proactively avoid "cursor: ping S wait on X", MUTEX REPORTED SELF DEADLOCK AFTER DBMS_MONITOR.SESSION_TRACE_ENABLE [/B]

请问：10.2.0.3版本中出现了关于cursor: ping S wait on X的bug以及patch，这个是否意味着我们需要升级到10.0.2.3，现在这个版本可能还不稳定阿，怎么办呢？您有什么建议呢？

robincao · 发表于 2007-5-17 09:25

关注！

玉面飞龙 · 发表于 2007-5-17 13:33

最初由 upper123 发布
[B]

五一前修改了_kks_use_mutex_pin为FALSE，但是现在又被大量的library cache pin代替了。现在数据库比较奇怪，每次CPU高的时候，等待事件存在大量的library cache pin，然后手工flush共享池之后，CPU就降下来了，看来不使用共享池机制反而使系统性能变好了。呵呵，当然这个问题肯定要解决的。
[/B]

你的应用是不是没有使用绑定变量？

MUXTX机制最好在bind variable的应用中使用。

修改_kks_use_mutex_pin为FALSE后，统计显示CPU 利用率会增加，library cache latch contention会增加。

玉面飞龙 · 发表于 2007-5-17 13:42

最初由 Kamus 发布
[B]如果Cursor: pin S wait on X占据top wait事件前几名，那么是bug的可能性比较大。

至少在10.2.0.3中也仍然同样存在如下的这些bug
bug 5907779 - proactively avoid "cursor: ping S wait on X", dbms_stats.gather_database_stats_job_proc
[/B]

这个job看来要disable了。这个job没什么好处。

不过这个bug 是个问题。

bug 5485914 - proactively avoid "cursor: ping S wait on X", MUTEX REPORTED SELF DEADLOCK AFTER DBMS_MONITOR.SESSION_TRACE_ENABLE

MTS的话，就不爽了。unpublish. 还未fix?

upper123 · 发表于 2007-5-17 15:33

最初由玉面飞龙发布
[B]

你的应用是不是没有使用绑定变量？

MUXTX机制最好在bind variable的应用中使用。

修改_kks_use_mutex_pin为FALSE后，统计显示CPU 利用率会增加，library cache latch contention会增加。 [/B]

绑定变量作的不好，现在的共享池命中率只有80%左右，郁闷

xin1shou3 · 发表于 2009-8-21 01:43

怎样解决呢？

请问：Cursor: pin S wait on X是不是oracle的bug？

Re: 请问：Cursor: pin S wait on X是不是oracle的bug？

浏览过的版块