为什么DB需要不停重启

runinwind

客户的oracle环境：11.2.0.1，redhat 64位。
故障现象是每隔十来天就要重启下，不重启IO会严重等待(db seauence/scattered read，read by other session），重启马上正常了，重启前后业务都是一样的。杀进程不能解决，flush data cache不行。主机的iostat重启后维持在30%左右，出问题时就一直100%。
本人是应用开发方，客户基本上没有DBA，附上故障时/重启后的awr报告，简单比较下能看到sga/pga大小明显不同，其它的我就不懂了。麻烦大家帮助分析一下。alert中没有可疑的内部错误等情况。

runinwind

Maclean Liu(刘相兵 发表于 2013-1-11 11:02
IO 阻塞时 每秒物理读 1769 * 8k = 13M
Physical reads:         1,769.5         141.0                  
Physical writes:         16.2         1.3 ...

刘大， 这是个OLTP+OLAP混合的业务DB，5块SAS硬盘做raid5，我对主机不了解，不知道繁忙时持续10多M的随机读取速度，是不是很慢，是不是意味着主机的存储很可能有问题？
还有个奇怪的地方，我又拉了今天9点到10点的数据，昨天出问题的相同时间段，业务是相似的，但今天DB很快。昨天占物理IO40%的那句SQL bmt4znqvbgcx7，昨天运行了8次，每次10597秒，物理读352,962块。今天它仍是最耗时的SQL，运行了18次，但每次只有29秒，物理读362块。而且gets是差不多的，每次2百万-3百万，也就是说这些昨天耗IO的SQL突然“变快”了。
不知道是不是遇到了oracle的bug，或是内存管理有问题？

低调小马哥

刘大的分析有理

低调小马哥

你这个库是数据分析库吧，第一个top sql（bmt4znqvbgcx7）都执行了10,597秒，还有好几个这样的sql，执行的不多，但把库拖垮了，个人感觉要进行sql优化才行

Maclean Liu(刘相兵

IO 阻塞时 每秒物理读 1769 * 8k = 13M
Physical reads:         1,769.5         141.0                  
Physical writes:         16.2         1.3                  

IO 正常时 每秒物理读 55 * 8k = 0.4M

Physical reads:         55.1         4.3                  
Physical writes:         11.1         0.9                  

IO阻塞时的TOP 物理读SQL

Physical Reads        Executions        Reads per Exec        %Total        Elapsed Time (s)        %CPU        %IO         SQL Id        SQL Module        SQL Text
2,823,701        8        352,962.63        43.78        84,776.28        0.71        99.11        bmt4znqvbgcx7         ????????        begin if :p_action = '??' then...
1,452,539        9        161,393.22        22.52        49,418.19        0.71        99.04        04dn798sjfkxm         ????????\????????\????????????        select distinct ??, ??, ??, ??...
635,685        11        57,789.55        9.86        23,014.02        0.68        99.29        5fgfs1548rar9         ????????        select distinct ??, ??, ??, ??...
635,559        6        105,926.50        9.85        10,496.34        0.73        98.61        5mykk74xr35dd         ????????        select distinct ??, ??, ??, ??...
343,188        18        19,066.00        5.32        4,891.77        2.23        97.30        7jk60jabybkg3         ????????        SELECT :"SYS_B_0" ChildCount, ...
249,802        1,816,246        0.14        3.87        55,413.92        0.52        99.46        8b5c0u498ufmg         BA_java        SELECT T.F_LEVEL_ID FROM F_STO...
191,356        7        27,336.57        2.97        17,642.81        0.15        99.89        0xxbtat38cu2m         ????????\????????\??????????????        begin /* p_????: INTEGER = ; p...



IO正常时的TOP 物理读SQL:

Physical Reads        Executions        Reads per Exec        %Total        Elapsed Time (s)        %CPU        %IO         SQL Id        SQL Module        SQL Text
7,312        2,995,674        0.00        3.75        317.52        93.23        7.14        8b5c0u498ufmg         kwappserver.exe        SELECT T.F_LEVEL_ID FROM F_STO...
1,230        4,915        0.25        0.63        16.59        30.31        70.36        d60w0vs5t8b9f         kwappserver.exe        begin Pkg_CellTree.DoCellTreeV...
1,139        16,722        0.07        0.58        21.85        54.25        43.91        48kuxbj2zcsj0         kwappserver.exe        begin pkg_celltree.CTLog(:p1, ...
1,023        17        60.18        0.52        148.66        96.32        3.61        3z7awvju0qa5u         ????????        begin if :p_action = '??' then...
864        17        50.82        0.44        148.21        96.42        3.50        0k30kvsqp2atq         ????????        INSERT INTO TT_BILL_QUERY (ID,...
420        4,538        0.09        0.22        4.09        24.61        74.93        4m7m0t6fjcs5x                 update seq$ set increment$=:2,...



结论:

1. 物理Io 读能力极差，和笔记本差不多
2. Io阻塞时对比IO正常时 运行了更多 消耗Io的不良SQL