关于redo log buffer contention的两个问题?

csutzp

关于redo log buffer contention的两个问题?
A.当V$SESSION_WAIT 中的字段 SECONDS_IN_WAIT 如果大于0,那么表示 time was spent waiting for space
in the redo log buffer.
那么为了减小等待时间，两个方案：
1.增大redo log buffer
2.将redo log file 放置于faster disks上。

B.当查询V$SYSSTAT中的 Redo Buffer Allocation Retries 大于1% of the Redo Entries,process have had
to wait for space in the buffer. 应该要增加redo log buffer的大小，或improve the checkpointing
or archiving processes to minimize the number of waits.

为何A的解决方案是将redo log file 放置于faster disks上,而B的解决方案是improve the checkpointing or archiving processes to minimize the number of waits.
可以解释区别吗？为什么？
谢谢！

biti_rainy

1 是由于写日志太慢 或者 buffer太小造成buffer不足，需要尽快腾出 buffer

2 是由于日志切换时候由于将被覆盖的日志组还是 active 状态不能覆盖，也就是说 该日志文件对应的dirty  buffer 还没有被写入数据文件  或者该日志文件组还没有被归档完毕，或者buffer不足所造成

虽然这里buffer 不足包含在两种情况中，而通常数据库中buffer不足的情况很少，所以更多地是注意 归档、检查点 以及 日志文件写足够快 等方面

csutzp

最初由 biti_rainy 发布
[B]1 是由于写日志太慢 或者 buffer太小造成buffer不足，需要尽快腾出 buffer

2 是由于日志切换时候由于将被覆盖的日志组还是 active 状态不能覆盖，也就是说 该日志文件对应的dirty  buffer 还没有被写入数据文件  或者该日志文件组还没有被归档完毕，或者buffer不足所造成

虽然这里buffer 不足包含在两种情况中，而通常数据库中buffer不足的情况很少，所以更多地是注意 归档、检查点 以及 日志文件写足够快 等方面 [/B]

  大哥，你的意思我明白，但是我还是有点混淆，就是redo buffer的wait和allocation retries不都表示redo log buffer不够用？那增加buffer没问题，但为何一个要快速磁盘，一个又要增加checkpoint或archivelog的速度呢？

biti_rainy

因为：
redo  buffer 是跟  redo  logfile 的物理地址格式化好对应的，并且是根据日志文件切换的时候重新对应地址关系的
覆盖 redo  buffer 也意味着该地址的日志文件内容也可以被覆盖，你不能要求oracle随时去检查文件本身，而是在日志切换的时候做好然后在内存中可适时的判断了

而什么时候不能覆盖呢，这分几种情况
当发现将要分配的buffer中内容是还没有来得及被写入日志文件，那就标记为 redo  buffer space wait。这时就要求日志文件写入效率高比如使用 raw  device等来提高写入速度。

当发现将要分配的buffer的时候当前日志已经写满并且要发生log  switch，由于要格式化buffer和日志文件对应，这个时候必须确保将被覆盖的日志文件可以允许被覆盖。允许被覆盖的前提就是 该日志文件对应的dirty  buffer已经被写入数据文件（检查点已经完成） 并且该日志文件已经完成归档（假如设置了归档）。


所以说，oracle能比较出差异，没被写入意味着大小不足，buffer增大固然可以缓解，但这根本不是解决问题的办法，因为buffer再大一些也很快被写满了，后者关键落在让日志可以尽快被覆盖，也就和 归档和检查点挂上了关系，前者落在加快日志文件的写速度。

csutzp

最初由 biti_rainy 发布
[B]因为：
redo  buffer 是跟  redo  logfile 的物理地址格式化好对应的，并且是根据日志文件切换的时候重新对应地址关系的
覆盖 redo  buffer 也意味着该地址的日志文件内容也可以被覆盖，你不能要求oracle随时去检查文件本身，而是在日志切换的时候做好然后在内存中可适时的判断了

而什么时候不能覆盖呢，这分几种情况
当发现将要分配的buffer中内容是还没有来得及被写入日志文件，那就标记为 redo  buffer space wait。这时就要求日志文件写入效率高比如使用 raw  device等来提高写入速度。

当发现将要分配的buffer的时候当前日志已经写满并且要发生log  switch，由于要格式化buffer和日志文件对应，这个时候必须确保将被覆盖的日志文件可以允许被覆盖。允许被覆盖的前提就是 该日志文件对应的dirty  buffer已经被写入数据文件（检查点已经完成） 并且该日志文件已经完成归档（假如设置了归档）。


所以说，oracle能比较出差异，没被写入意味着大小不足，buffer增大固然可以缓解，但这根本不是解决问题的办法，因为buffer再大一些也很快被写满了，后者关键落在让日志可以尽快被覆盖，也就和 归档和检查点挂上了关系，前者落在加快日志文件的写速度。 [/B]

  兄弟的意思是说：
1. v$session_wait 中的等待字段，表示的是 redo buffer 等待是日志文件的写操作，而不是switch logfile的操作，这是由于磁盘慢的原因造成。
2. v$sysstat 中的 redo log retries字段表示的是 redo buffer 等待日志切换或archivelog 操作，那么理所应当的应该加快checkpoint或archivelog的速度？
  是这么理解吗？是这么区分这两个view中字段吗？
  关于这两个view中字段的详细解释，我从SG中看来看去，也没太搞清除字段的不同含义。
  谢谢...

biti_rainy

你要这么理解也无所谓

sys@OCN>select  name from  v$event_name  where  name  like  '%log%';

NAME
----------------------------------------------------------------
log switch/archive
log file sequential read
log file single write
log file parallel write
log buffer space
log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch (clearing log file)
switch logfile command
log file switch completion
log file sync
STREAMS capture process waiting for archive log
rfrxptarcurlog

13 rows selected.

sys@OCN>

对于 log  buffer /redo  logfile 相关的等待事件来说
从  v$system_event 中更容易体现出来

v$session_wait 表示当前 session 的等待，只要不是正在切换日志，必然就是 写日志速度问题，而 log  buffer 设置在1---3  m 基本不会有什么问题

更多的我们容易看到的等待是

log file  sync
log  file  parallel  write
类似这样的

所以对于数据库我们的原则  不选择过小的日志文件，log  buffer  1--3m  ,日志文件尽量不放在 io 争用严重的磁盘上，数据库应用中如果有大量数据处理不要单条频繁地提交， 优化数据文件IO（包括使用AIO等等） ，从整体上提高性能 。实际上也就是说整体 IO 才是关键。

对于局部的深入理解不错，但千万要从宏观上抓住重点

csutzp

最初由 biti_rainy 发布
[B]你要这么理解也无所谓

sys@OCN>select  name from  v$event_name  where  name  like  '%log%';

NAME
----------------------------------------------------------------
log switch/archive
log file sequential read
log file single write
log file parallel write
log buffer space
log file switch (checkpoint incomplete)
log file switch (archiving needed)
log file switch (clearing log file)
switch logfile command
log file switch completion
log file sync
STREAMS capture process waiting for archive log
rfrxptarcurlog

13 rows selected.

sys@OCN>

对于 log  buffer /redo  logfile 相关的等待事件来说
从  v$system_event 中更容易体现出来

v$session_wait 表示当前 session 的等待，只要不是正在切换日志，必然就是 写日志速度问题，而 log  buffer 设置在1---3  m 基本不会有什么问题

更多的我们容易看到的等待是

log file  sync
log  file  parallel  write
类似这样的

所以对于数据库我们的原则  不选择过小的日志文件，log  buffer  1--3m  ,日志文件尽量不放在 io 争用严重的磁盘上，数据库应用中如果有大量数据处理不要单条频繁地提交， 优化数据文件IO（包括使用AIO等等） ，从整体上提高性能 。实际上也就是说整体 IO 才是关键。

对于局部的深入理解不错，但千万要从宏观上抓住重点 [/B]

是苏杭的兄弟吗？ 谢谢啊，以前怎么好少见你回答啊，其实解答的真的有水平，很细致，能让人真正搞明白这些问题。
  而有些版主，可能水平太高深了，或太忙了，基本上就是一句话搞定，也不管别人懂不懂，细致说明那是一定impossible了。。。

biti_rainy

认证版块极少过来看看而已

你要是有兴趣可以去管理版  或者  深入讨论区   及相关精华区 看看


http://www.itpub.net/quintessence2.html

http://www.itpub.net/forum2.html

http://www.itpub.net/quintessence67.html

http://www.itpub.net/forum67.html

csutzp

最初由 biti_rainy 发布
[B]认证版块极少过来看看而已

你要是有兴趣可以去管理版  或者  深入讨论区   及相关精华区 看看


http://www.itpub.net/quintessence2.html

http://www.itpub.net/forum2.html

http://www.itpub.net/quintessence67.html

http://www.itpub.net/forum67.html [/B]

没办法啊，平时工作不用oracle的，所以基本属于菜鸟级，全是理论，几乎没有时间。因此，在过ocp最后一门之前，不太敢涉足于高级管理板块和深入讨论板块。
不过我很快也要去那里“讨扰讨扰“大虾你们了。。。请问biti兄，你oracle主要开发还是dba?

lijie74

好