【问题标题】:How to calculate redo log size?如何计算重做日志大小?
【发布时间】:2020-09-17 05:15:46
【问题描述】:

我正在尝试确定我现在拥有的当前重做日志大小是否是最佳的。这是我所做的:

  1. 我使用 Oracle 文档找到了大部分此类信息: http://www.oracle.com/technetwork/database/availability/async-2587521.pdf
  2. 使用 SQL 我使用了以下查询

     select thread#,sequence#,blocks*block_size/1024/1024 "MB",(next_time-first_time)*86400 "sec", 
     (blocks*block_size/1024/1024)/((next_time-first_time)*86400) "MB/s"  
     from V$ARCHIVED_LOG 
     where ((next_time-first_time)*86400<>0) and 
    first_time between to_date('2020/03/28 08:00:00','YYYY/MM/DD HH24:MI:SS')
    and to_date('2020/05/28 11:00:00','YYYY/MM/DD HH24:MI:SS') 
    and dest_id=3
    order by first_time
    

根据结果,我计算出平均 MB/S 为 7.67,最大 MB/S 为 245 MB/S

  1. 根据 Oracle 文档 See table on recommended redo log group size

使用这个查询

         select * from V$LOGFILE a, V$LOG b where a.GROUP# = b.GROUP#

我发现我有 15 个 2 GB 的组,所以重做日志组大小是 30 GB。

  1. Oracle 说“一般来说,我们 建议在峰值速率的基础上再增加 30%”,这意味着我预计将有 245mb/s*1.3 = 318.5 MB/S。那么这里是我有点迷失的地方。我是否使用表格我附上的图片?如果是这样,我应该有一个 64GB 的重做日志组大小?还是我在不应该有的地方建立连接?

最后我也做了

  select optimal_logfile_size from v$instance_recovery

然后返回 14 GB。

我无法建立所有连接并尝试确认我的重做日志大小足够。

【问题讨论】:

  • 最优是什么意思?为了在写入 ORL 时获得更快的性能,为了更快的恢复时间,还有其他什么?

标签: database oracle logging oracle11g dataguard


【解决方案1】:

如果您有 15 个组,每组 2GB,那么您的组大小为 2GB,而不是 30GB。

我们的想法是不要过于频繁地切换日志 - 不超过每 20 分钟。因此,请查看您的日志切换发生的频率。如果您在切换之间仍然超过 20 分钟,那么您可能没问题。如果您有比这更频繁的切换,那么您可能需要更大的日志。

根据您执行的计算,~319MB/s 的最大速率表示单个重做日志文件应为 64GB,并且您需要最少(根据最佳实践)三个重做日志组。也就是说 - 你有多少时间花在峰值负载上?如果每天只有少量时间(您的平均交易率要低得多),那么这可能是矫枉过正。您也不希望日志切换发生得太远,否则您在重做日志失败后执行时间点恢复的能力可能会受到影响。

拥有 16GB 的日志文件并保持平均稳定的切换率并在峰值负载期间接受更高的切换率可能更有意义。您可能需要更多单独的日志文件来处理每分钟相同的总事务,而无需等待不完整的日志切换:比如三组每组 64GB 与每组 12 组 16GB。相同的总日志容量,但用于切换和归档日志记录的块更小。这可能就是您现在配置 15 组 2GB 的原因...

【讨论】:

  • 谢谢你,这更有意义。我现在去检查一下日志开关。
【解决方案2】:

理想情况下,每小时不应频繁切换日志。检查重做日志切换频率并相应增加重做日志的大小。 找到了有用的链接,可用于获取下面的所有重做日志相关详细信息。

Find Redo Log Size / Switch Frequency / Location in Oracle

【讨论】:

    猜你喜欢
    • 2017-10-02
    • 2018-03-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2023-03-19
    • 1970-01-01
    相关资源
    最近更新 更多