Как рассчитать размер журнала повторного выполнения? - PullRequest
Новая
       34

Как рассчитать размер журнала повторного выполнения?

0 голосов
/ 29 мая 2020

Я пытаюсь выяснить, оптимален ли текущий размер журнала повторов, который у меня есть. Вот что я сделал:

  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

По результатам я вычисляю среднее значение МБ / с, которое составляет 7,67, и максимальное МБ / с, которое составляет 245 МБ / с

Согласно документации Oracle См. Таблицу рекомендованного размера группы журналов повторного выполнения

Используя этот запрос 

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

Я обнаружил, что у меня 15 групп по 2 ГБ, поэтому размер группы журнала повторения составляет 30 ГБ.

Oracle говорит, что «Обычно мы рекомендуем добавить дополнительные 30% сверх пиковой скорости», так что это будет означать, что у меня ожидается 245 МБ / с * 1,3 = 318,5 МБ / с. Тогда вот где я немного заблудился. Могу ли я использовать таблицу на прикрепленной картинке? Если это так, можно ожидать, что размер группы журнала повторного выполнения будет 64 ГБ? Или я устанавливаю соединение там, где его не должно быть?

Наконец, я также сделал 

  select optimal_logfile_size from v$instance_recovery

и вернул 14 ГБ.

У меня проблемы с установкой всех подключений, и я пытаюсь подтвердить, что размер моего журнала повторов достаточен.

1 Ответ

1 голос
/ 29 мая 2020

Если у вас 15 групп по 2 ГБ каждая, то размер вашей группы будет 2 ГБ, а не 30 ГБ.

Идея состоит в том, чтобы не переключать логи слишком часто - не чаще, чем каждые 20 минут. Итак, посмотрите, как часто происходит переключение журнала. Если между переключениями по-прежнему больше 20 минут, то, вероятно, все в порядке. Если у вас когда-либо будет более частое переключение, чем это, вам могут потребоваться журналы большего размера.

На основе выполненных вами вычислений максимальная скорость ~ 319 МБ / с будет означать, что отдельные файлы журнала повторов должны быть 64 ГБ, и вам нужно минимум (согласно передовой практике) три группы журналов повторного выполнения. Тем не менее - сколько времени вы проводите при пиковой нагрузке? Если только небольшое количество времени в день (ваша средняя скорость транзакций намного ниже), это может быть излишним. Вы также не хотите, чтобы переключение журнала происходило слишком далеко друг от друга, иначе ваша способность выполнять восстановление на определенный момент времени после сбоя журнала повторного выполнения может быть скомпрометирована.

log-файлы размером 16 ГБ, которые в среднем поддерживают постоянную скорость переключения и допускают более высокую скорость переключения во время пиковой нагрузки. Вам может потребоваться больше отдельных файлов журнала, чтобы обрабатывать одинаковое общее количество транзакций в минуту, не дожидаясь неполных переключений журнала: скажем, три группы по 64 ГБ каждая против 12 групп по 16 ГБ каждая. Та же общая емкость журнала, но меньшими порциями для коммутаторов и архивирования журналов. Вероятно, поэтому у вас сейчас настроено 15 групп по 2 ГБ каждая ...

...