问题描述
我理解而不是日志生成速率,我们应该考虑生成的重做量。
我的问题是-我们如何使用重做量来识别任何数据库瓶颈?
有没有办法比较两天或几个月之间的重做生成量,看看是否需要调整或调整大小?
我的问题是-我们如何使用重做量来识别任何数据库瓶颈?
有没有办法比较两天或几个月之间的重做生成量,看看是否需要调整或调整大小?
专家解答
我通常不会关注生成率,因为您将生成所需的...不是更多,不是更少。
这只是一个问题,如果它正在影响用户会话或正在影响数据库外部的活动 (例如,它可能会减慢非数据库操作的I/O,因为重做处理消耗了太多的I/O带宽)。
对于用户会话,您要测量它们是否在等待LGWR活动完成时停滞不前。
监视您的系统,以了解以上可能表示重做问题的事件。我使用术语 “问题” 而不是I/O,因为它不一定与I/O相关。如果您的服务器处于CPU压力下,这可能会减慢LGWR的速度,然后 * 看起来 * 像重做问题,因为每个人都被阻止了。
v $ log_history和v $ archived_log可以显示重做日志切换频率,然后可以将其映射到指定时间段内的重做大小。
这只是一个问题,如果它正在影响用户会话或正在影响数据库外部的活动 (例如,它可能会减慢非数据库操作的I/O,因为重做处理消耗了太多的I/O带宽)。
对于用户会话,您要测量它们是否在等待LGWR活动完成时停滞不前。
SQL> select name from V$EVENT_NAME 2 where name like 'log%'; NAME --------------------------------------------------- ... log file single write log file parallel write log buffer space log file switch (checkpoint incomplete) log file switch (private strand flush incomplete) log file switch (archiving needed) log file switch completion log file sync ...
监视您的系统,以了解以上可能表示重做问题的事件。我使用术语 “问题” 而不是I/O,因为它不一定与I/O相关。如果您的服务器处于CPU压力下,这可能会减慢LGWR的速度,然后 * 看起来 * 像重做问题,因为每个人都被阻止了。
v $ log_history和v $ archived_log可以显示重做日志切换频率,然后可以将其映射到指定时间段内的重做大小。
文章转载自ASKTOM,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




