今天上午准备去参加同事的婚礼，突然一个微信上的朋友发了一份awr，简单粗略地分析了下，发现了一些猫腻。这里简单记录一下，以供大家参考分析思路。

    首先从AWR的开头部分发现核心系统居然是单机，而让我有些差异的居然是跑在Windows，这或多或少显得很不专业。资深DBA应该都不会建议客户将重要的Oracle系统部署到Windows环境。从Session数量来看，可以看到快照开始和结束的差距极大，这似乎不太正常，可以肯定的是一定没有使用连接池，实际上熟悉医疗行业架构的朋友都知道，基本上轻一些的C/S结构，不会使用连接池的。这些都不是问题，我们接下来继续看。

    从top event来看，似乎症状是非常的清晰明了，主要是全表扫、资源管理、直接路径读以及并行查询相关；更为主要的是，大家一眼就能看出wait Avg是比较高的，难怪应用会反应比较卡顿，不出意外的话，此时的cpu消耗也不低。

    上面几个event都比较简单，首先需要关闭resource manager，其次从top event看，这个数据库一定都是使用默认参数配置，相关特性是没有关闭的；很明显这里全表扫描转成了直接路径读，把系统的IO拉高了，导致IO延迟。要确认这一点，查看IOStat部分内容即可：

   我们可以非常清晰的看到总的IO是457G，其中direct reads就占了332.7G，接近80%，如果能消除这部分IO，那么整个系统的IO压力将得到极大缓解；因此首先要做的就是调整如下2个参数：

alter system set resource_manager_plan='FORCE:' scope =both sid='*';

alter system set event=10949 trace name context forever,level 1'scope=both sid='*';

     这里我要补充一点的是，直接路径读并非所有环境都要关闭，实际上Oracle 11g引入这样一个特性的目的是：为了避免大表全扫对Buffer cache的冲击，进而将其转成直接路径读；对于IO能力欠佳的环境，建议直接关闭；反过来如果你的环境都是NvME全闪，那么就不需要关注了。

     既然都分析到这里了，我们再来看看这个库是否还有其他的问题点呢。

     首先我们来看下内存参数配置：

    从配置来看，这台服务器物理内存256G,sga 设置为140G左右，也没啥问题，但是我们可以发现，使用了自动调节，db_cache_size仅设置为32g，显然不合理，尽管目前实际上db cache大小约为130G，其shared pool大约8G左右，似乎有点过小，根据Oracle最佳实践，OLTP系统，一般建议share pool大小为sga的15%~20%。其次我们可以发现cursor_sharing居然设置为similar，这是非常不建议的（会导致cursor子游标暴涨，其实Bug也很多），要设置还不如直接设置成force；其次open_cursors 默认值300也似乎有点过小了，包括db_file_multiblock_read_count多块读参数居然还是16，建议直接设置为128. 实际上大家可以看到参数部分内容非常少，其他很多重要的参数都没有进行调整，尤其是11g acs相关的bug，简直要人老命。总之从这个awr简单分析来看，建议参考我们之前所讲的一些最佳实践参数做一下调整。

    其实我们看这个库才刚启动不久，就已经开始出现SQL version问题了，我估计这库坚持不了一周。

   11g中默认值SQL Version最大可到1024（12c+版本最大是8192），建议还是适当限制一下大小(_cursor_obsolete_threshold)，当子游标过多，同时执行也非常频繁，那么一定会出现library cache lock，严重的情况下会导致数据库夯死。

     我们都知道医疗行业的软件代码质量似乎普遍不高，从这个awr报告也可以大概看出来，低效SQL还真是不少：

    对于一些单次执行要几分钟的SQL，真是需要好好优化一下才行了。

    说到这里，突然想起来前天晚上部门聚餐时，同事的一些感慨：之前感觉Oracle AWR觉得习以为常了，做国产或者开业数据库性能分析，才发现AWR做的真tm牛B。

    最后，如果大家有些Case或者故障需要帮助分析，可以加我微信或者公众号私信我！（免费、免费、永久免费）。

    以后我们公众号尽量多分享一些Case给大家。