看看这两个AWR

bluemoon0083 · 发表于 2016-1-8 17:36

IO是比好的时候慢了，ASM有啥问题吗，特别是放log的

bluemoon0083 · 发表于 2016-1-8 17:53

alert log有啥异常吗，没有ORA-错误就未必一定没问题

shahand · 发表于 2016-1-8 22:29

andzen 发表于 2016-1-8 16:56
IO 不好只是问题的表面，如果真的io不好，
db file sequential read + db file scattered read 的等待时间 ...

log file sequential read是比较怪。因为该库是非归档的，不应该有读redo的东东存在。

因为要迅速定位问题，所以比较AWR是一个比较快的办法，像log file sequential read因为之前也存在并很高直接被我忽略了。

shahand · 发表于 2016-1-8 22:36

lfree 发表于 2016-1-8 14:46
SELECT DISTINCT flt.FLIGHT_FLIGHT_NO flight_no, MAX (FCT.DEP_TIME) dep_time
FROM HHDW.REAL_MO ...

才看到，这个distinct是可以去掉吧？？

shahand · 发表于 2016-1-8 22:37

bluemoon0083 发表于 2016-1-8 17:53
alert log有啥异常吗，没有ORA-错误就未必一定没问题

已经在让客户找了。准备再弄两份ash比较一下

sqysl · 发表于 2016-1-9 15:18

andzen 发表于 2016-01-08 16:56IO 不好只是问题的表面，如果真的io不好，
db file sequential read + db file scattered read 的等待时间为何只占 5%？
5百万次 log file sequential read 的等待也是几十ms级别，能说IO不好，我到觉得IO很强大。

最应该关注的应该 5百万次 log file sequential read 是从哪里来的， TOP 40 的sql 执行一次6000多秒“经过时间”的语句才是问题的重点，实际消耗cpu只有几百而已。

如果你用这种指标来看io那是不对的，如果根据这两个指标就得出存储强大的结论，那就更不对了。特定场景下，就算再差的存储都可以跑出很高的这种指标来。

andzen · 发表于 2016-1-9 17:07

sqysl 发表于 2016-1-9 15:18
如果你用这种指标来看io那是不对的，如果根据这两个指标就得出存储强大的结论，那就更不对了。特定场景下， ...

高技术都是靠逻辑的，请摆出自己的逻辑，不能只会一句：你就是不对。

sqysl · 发表于 2016-1-9 18:54

呵呵，你说的这些等待事件和io并没有直接关系，尤其是前两个。
另外，这个问题的关键也许在大量的logfileseqentialread上，这点你说的有道理。

bluemoon0083 · 发表于 2016-1-11 11:34

楼主在吗，后来是啥问题呀

sqysl · 发表于 2016-1-11 13:23

其实，这种短期内大量的文件顺序读对系统的杀伤力还是很大的，有时可能会造成系统短暂的没反应，也就是业内通常说的hang住，不管是不是这个原因，楼主还是要找找这些log file sequential read的原因。