老大帮我看看我的statspack report.

biti_rainy

redo buffer allocation retries  /  redo entries  

你这好象也不是业务高峰期?

doctest

最初由 biti_rainy 发布
[B]redo buffer allocation retries  /  redo entries  

你这好象也不是业务高峰期? [/B]

今天比较闲

繁忙的时间不确定

有时很长时间retries没有增长
有时连续每十分钟retries增长100~200
最多达到每十分钟retries增长700

用户抱怨系统很慢

如果能将将分析和调整的原理
就太好了

jxc_hn

晕, 怎么把我的位置给抢了?

doctest

老大您比较吸引眼球
我的问题有点关联
所以就顺风搭船了

doctest

LOG_TIME            RETRIES   INCREASE
---------------- ---------- ----------
07/03/2003 06:42      34886        403
07/03/2003 06:53      35807        921
07/03/2003 07:03      37072       1265
07/03/2003 07:13      38764       1692
07/03/2003 07:24      39715        951
07/03/2003 07:34      40927       1212
07/03/2003 07:45      41693        766
07/03/2003 07:55      42218        525
07/03/2003 08:05      42850        632
07/03/2003 08:16      43008        158
07/03/2003 08:26      43011          3
07/03/2003 08:36      43148        137
07/03/2003 08:46      43340        192

LOG_TIME:记录时间
RETRIES  : redo log allocation retries
INCREASE: 和上一个RETRIES比较的增长量

各位老大帮我看看
今天早上特别严重


操作系统: HP UNIX 11
数据库 : 8.1.7
memory : 4G

每天15点作Statspack
所以今天的Statspack还没有

能将将分析和调整的原理吗
或推荐本书看看

谢谢

machao

1.你的日志太小,
估计你的情况可能要将日志文件设到100M大小,
如果有可能你把alert.log文件传上来,

2.一般情况下,做statspack用来解决性能问题,应该在间隔10分钟做一次,如果审计系统的吞吐量,应该二三个小时做一次,象你这样一天做一次,基本上是没有意义的.

3.我看过你的report,基本上是磁盘IO很重,可能与索引,sql有关.

eygle

最初由 jxc_hn 发布
[B]嗯.  可能就是log buffer小导致的log file sync ,log buffer space .

每个日志组只有一个member , 这个确实有点危险.

但是,我又有疑问了. 既然只有一个current member, 何来 parallel write ? [/B]

如果磁盘支持异步IO,或者使用IO slaves ,这个写操作就可能并行.

doctest

最初由 machao 发布
[B]1.你的日志太小,
估计你的情况可能要将日志文件设到100M大小,
如果有可能你把alert.log文件传上来,

2.一般情况下,做statspack用来解决性能问题,应该在间隔10分钟做一次,如果审计系统的吞吐量,应该二三个小时做一次,象你这样一天做一次,基本上是没有意义的.

3.我看过你的report,基本上是磁盘IO很重,可能与索引,sql有关. [/B]

100M?
当LGWR将缓冲区内容写入磁盘时,等待写入缓冲区不是要更久?

磁盘IO很重,物理文件现在没法散的开
索引前几天有重建过,没有什么效果

只感觉现在头有点痛
头每天问为什么现在系统这么慢
生产部门每天都电话抱怨
哎,对于我这半路出家的DBA
怎是一个愁字了得

但原快点成长

machao

你的日志切换很快,长的是7,8分钟,
短的只有1分钟
Wed Jul  2 23:56:47 2003
Thread 1 advanced to log sequence 823161
  Current log# 2 seq# 823161 mem# 0: /ap1/db817/oradata/CNCL/redo02.log
  Current log# 2 seq# 823161 mem# 1: /ap1/db817/oradata/CNCL/redo02m1.log
Wed Jul  2 23:57:51 2003

日志切换的时间,大家比较推荐的是20-30分钟,
所以如果你的日志是20M,
建议改到200M.
长时,太约80分钟切换,
短时,太约10分钟切换

LGGW 将log_buffer写入磁盘在下列情况
1.每隔3秒
2.有用户提交
3.lob_buffer的1/3被使用.

在你的报告中,redo size is 31k/s
所以超过1M的log_buffer对你来说是没用的.
在你的statspack中也可以看出来
redo wastage                            54,332,400
它们没有被使用.

另外,我不认为你的系统瓶颈在于log_buffer
我认为在于过多的IO.

你做每隔10分钟做一个report,做二到三个传上来看看.

doctest

非常具体
非常感谢
我现在就作每隔10分钟做一个report

谢谢!