今天处理的三个小问题——20160120(r7笔记第84天)

今天处理了几件事情，有几件还比较有意思，我拿出三件来说说。通过这个可以看出来,数据库还是初始版本，DB time可以大体看出来负载其实也不高。其实整个系统的负载也不高，从TPS，redo这些可以看出来。不过其中的一个亮点就是 物理读比较高，还有一个是硬解析比较高。如果放下看，buffer hit实在是很低，当然这个和本身的配置有一定的关系，就给了500M的sga，还是有一定的压力的。当然关于全表扫描和索引扫描，我也给同学简单解释了一下。接着就是从sql入手了，我提供了关键字，sql order by elapsed让他把截图发给我。通过这个可以看到其实他这个服务器还是默认安装了OEM，估计他也没意识到这个工具的存在，当然主要的就是关心他所说的Insert相关的语句，但是没有 相符的，但是找到了两条update。和他确认了一下，就是目前反馈插入慢的表，所以通过这个我可以简单得出结论，这个表没有索引，后续的结果想必大家也 可以猜到了，加上索引这类的语句可能会飞起来。这也就见解说明了，得到的反馈不一定准确，还是需要一些简单的分析。当然这也算帮了同学一个小忙。后续可以 继续跟进。ORA-00904: "POLTYP": invalid identifierThe Fix For Bug 7568350 Generates ORA-00904: "POLTYP" Error At Export Client (Doc ID 784038.1)然后第三个问题比较有意思，目前的情况是运营的同学反馈有一个统计应用在某些天没有数据。然后开发同学就找到了我，然后想让我帮忙看看，按理说我应该直接 推回去。不过还是为了配合工作，我从我的角度进行了检查，首先他提供的这个表test_storage中的数据来源对于DBA来说也是黑盒的。开发同学反 馈说缺少12月半个月的数据，之后这部分数据又不上了，这个时候就让我有些意外，这都过去了一个月了，之前怎么没有发现，当然也是牢骚之言，得到答复和没 有答复是一样的效果，还是需要查明原因。至于这部分数据的插入逻辑，看来还得靠自己了来摸清楚了，首先这是一个统计业务，那么这部分的数据应该来源于线上 业务，所以说数据源是线上系统，数据需要同步到这个表中，目前是有一定的频率，主要是设置频度来完成同步，可能每天会定时来同步等，通过这些简单的信息就 可以从系统级，数据库级进行排查，当然这个过程也是很顺利的，几分钟就去会出结果，发现一个存储过程会在每天的指定时间去同步数据到 test_storage这个表里。。导致这个统计库的数据同步被阻塞。当然也是耽误了好些天，也是在业务的推动下，问题反馈到了我这里，当时对其 中的部分表的数据进行了追加。这张表当时没有提供，所以也没有进行处理，这不拖了些日子，最终还是浮出水面了。