0

我试图弄清楚我现在拥有的当前重做日志大小是否是最佳的。这是我所做的：

  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 文档， 请参阅有关推荐的重做日志组大小的表

使用此查询

         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。

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

4

2 回答 2

1

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

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

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

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

于 2020-05-29T15:40:26.730 回答
0

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

在 Oracle 中查找重做日志大小/切换频率/位置

于 2020-10-06T15:30:06.717 回答