在MOS中查看Bug database，会看到每个bug都有自己的status，那么这其中常见的status有哪些，又都分别是什么含义呢？ 我们可以通过MOS中的Advanced Search功能查找特定状态的Bug，比如有哪些是已经确认为Bug移交到研发部门但是还没有补丁写出来的？ 比较常见的status有以下这些。而这些状态也基本上表明了一个bug从接收到解决的流程。 10 – Description Phase Development is requesting more information. 研发部门需要更多信息。 16 – Support bug screening Bug is being reviewed by our Bug Diagnostics group. Bug诊断小组正在评估。 11 – Code Bug (Response/Resolution) Bug is being worked by Development. 已经确认为Bug，研发部门正在尝试修正。 30 – Additional Information Requested Bug is being worked by Support and/or more…
Tag: bug
Oracle 10.2.0.3 Bind Peeked Parallel Bug
昨晚11:30，客户电话，报告数据库服务器CPU负载陡然上升到95%以上，并且报ORA-4031错误。12:00赶到现场。 查看故障发生期间的AWR报告。 1. 最高的等待事件是“latch: library cache lock”和“latch: library cache” 2. Shared Pool Memory Usage 达到了98% (Shared Pool Size: 4,096M) 3. SQL ordered by Elapsed Time部分显示一条SQL占用了91.9%的总时间 4. SQL ordered by CPU Time 部分显示同样这条SQL占用了91.9%的CPU时间 5. SQL ordered by Sharable Memory部分，大批Executions=N/A的SQL，并且最高的一条SQL已经消耗了将近2G的Sharable Memory 6. SQL ordered by Version Count部分，刚才那句占用了将近2G缓存的SQL有高达77,237的Version Count 至此，大概可以猜测整个问题的发生原因了。因为过度的Version Count导致Shared Pool消耗殆尽，在Library Cache中开始频繁获取空闲空间以parse新进的SQL，于是产生大量的library cache latch，最终Shared Pool中再也无法找到足够解析一个SQL的空闲空间，于是报ORA-4031。整个系统全线崩溃。 那么现在问题就在于为什么会有如此巨大的Version Count？…