技术人生系列 · 我和数据中心的故事（第四期）——Orac 11203必须要调整的重要参数

zengmuansha · 发表于 2016-6-30 18:41

26125794 发表于 2016-1-28 11:32
DB Time除以Elapsed，可以看到每秒DB TIME达到75，不应该是DB Time*逻辑cpu个数除以Elapsed么？

DBTIME / CPU CORE / ELAPSED 平均CPU负载啊

zengmuansha · 发表于 2016-7-6 15:19

26125794 发表于 2016-1-28 11:32
DB Time除以Elapsed，可以看到每秒DB TIME达到75，不应该是DB Time*逻辑cpu个数除以Elapsed么？

你是算平均负载情况嘛?
应该是DBTIME /CPU CORE /ELAPSED

sqysl · 发表于 2016-7-8 23:31

非常感谢楼主的分享。
针对楼主的case,下面谈下个人的看法。
1、感觉楼主在11g那个新特性上有点惯性思维，从而思路受到了影响。因没有完整的awr，仅从楼主提供的信息上看，存在大量严重的log file sync等待，且伴随大量严重的其他IO相关等待的情况下，应该首先排查系统的IO，至于AWR中的log file parallel write，只是期间的平均值，也并不能成为排除IO问题的充分理由，其实，楼主在修改参数后，也并未看AWR中的log file parallel write,而是手工查的实时等待，最终确定节点1还是存在IO问题。此外，前面一开始描述说客户那边已经确认系统各方面资源都正常，可后来还是确定IO存在问题，难道是客户方开始确认错了？这点来说不太理解。
2、之前对航空项目有所了解，只不过当时是国际航空的一个项目，当时数据库这块是一个团队在支撑，如果说单个人实力和经验弱些，但整个团队应该吼得住。不清楚楼主说的是怎么个情况，如果整个团队加第三方服务商都解决不掉一个测试库上的问题，那么这个还是会有些问题的。因为相对于生产库来说，测试库上的问题时间上会更从容些。
3、确定IO问题相对更便捷些，但真正锁定一个版本的bug，除非原厂及时介入，还是需要一定的时间的，楼主能在短时间内定位到，说明对这个问题还是有很丰富的经验。遗憾的是，本case中，并未看到首先解决节点1上IO问题后，不调整隐含参数“_use_adaptive_log_file_sync”情况下的状态和结果。如果楼主有系统资源不存在问题，完全因为隐含参数“_use_adaptive_log_file_sync”引起故障的case，可否麻烦共享下，先谢了。
个人观点，仅供大家参考和讨论。