然后第5个问题,那就来复现一些,复现的过程如果顺利会解释清楚第一个和第二个问题的可能性 验证很简单,就是把备库置为read-only状态 DGMGRL> edit database speak4 set state='read-only'; Succeeded. 然后查看日志,发现问题竟然能够马上复现,而且很有规律,是一分钟会出现一次,从目前的青年卡来看,和应用的sql导致的影响不大了。 对于数据库层面的资源使用,可以参考下面的查询结果。 SQL> select * from v$resource_limit; RESOURCE_NAME CURRENT_UTILIZATION MAX_UTILIZATION INITIAL_ALLOCATION LIMIT_VALUE ----------------------- ------------------- --------------- -------------------- -------------------- processes 36 41 1000 1000 sessions 27 46 3000 3000 enqueue_locks 29 93 32860 32860 enqueue_resources 29 29 13420 UNLIMITED 发现session数还远远未达到,所以这个可能性极低。 所以这个问题基本能够看出确实复现了问题,那么怎么进一步验证呢,我们可以打开另外一个备库来,验证一下,切换两次之后,也看到了同样的错误。 通过上面的各种测试已经能够充分能够验证问题所在了。 好了最后一个问题,那就是如何解决,官方提供了两种方案。 一种是重启,另外一种是设置关闭sga自动管理,并设置statistics=basic 这种方案还是根据具体的情况来选用。为什么设置statistics=basic需要关闭sga的自动管理呢。 SQL> alter system set statistics_level=basic; alter system set statistics_level=basic * ERROR at line 1: ORA-02097: parameter cannot be modified because specified value is invalid ORA-00830: cannot set statistics_level to BASIC with auto-tune SGA enabled 这个错误已经很明显说明了这种依赖。 当然自己还是认真测了论证了一番,发现确实如此,重新切换read-only,online就再没有这个问题了。 通过这个小的案例可以看出,其实一个很细小的问题还是需要投入一些认真的测试,不能简单认为是一个bug就草率了事,自己说服了自己,处理问题才会更加从容不迫。 |