Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Oracle Новый топик    Ответить
 physical standby recovery rate  [new]
lh@work
Member

Откуда: Москва
Сообщений: 49
Задача: увеличить скорость наката логов на физическую standby-базу

Что есть: кластерная primary-база Oracle10g на ASM, standby на ASM (другом).
Recovery запускается в 32 параллельных процесса (опция parallel 32).
Контрольная сумма не вычисляется: db_block_checksum=false
Подкручено общение между параллельными процессами: parallel_execution_message_size = 8192
Архивные логи лежат на локальных дисках, база -- на SAN и грузит его не сильно.
Суммарная скорость генерации логов на всем кластере -- около 800Кб/сек

Что не нравится: average apply rate после часа работы опускается до 400Кб/сек, то есть догнать primary не представляется возможным.

Коллеги, есть ли еще какие-то варианты по ускорению standby, которые я пропустила?

Спасибо.
19 окт 06, 17:53    [3284162]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
Sevick
Member

Откуда: из-за компа
Сообщений: 833
lh@work
Задача: увеличить скорость наката логов на физическую standby-базу

Что есть: кластерная primary-база Oracle10g на ASM, standby на ASM (другом).
Recovery запускается в 32 параллельных процесса (опция parallel 32).
Контрольная сумма не вычисляется: db_block_checksum=false
Подкручено общение между параллельными процессами: parallel_execution_message_size = 8192
Архивные логи лежат на локальных дисках, база -- на SAN и грузит его не сильно.
Суммарная скорость генерации логов на всем кластере -- около 800Кб/сек

Что не нравится: average apply rate после часа работы опускается до 400Кб/сек, то есть догнать primary не представляется возможным.

Коллеги, есть ли еще какие-то варианты по ускорению standby, которые я пропустила?

Спасибо.



Совсем недавно вроде обсуждение было по медленному накату на standby -
https://www.sql.ru/forum/actualthread.aspx?tid=222644
Может поможет что из советов...
19 окт 06, 18:37    [3284428]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
lh@work
Member

Откуда: Москва
Сообщений: 49
Спасибо.

Поучительный тред, но на самый интересный вопрос ответа нет.
А вопрос такой: почему primary успевает производить изменение данных, а standby -- нет? Теоретически-то standby должно быть легче, чем primary -- select'ы она не выполняет.

Может, кэш на standby используется не так, как на primary?

Уменьшить логи в моем случае очень не хочется.
19 окт 06, 18:58    [3284522]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
ыекь
Guest
параметры СГА какие, у меня проблемы со скоростью наката были при неправильно высталенном db кеше, маленький был он. Ето все соотвественно вымониторислоь из v$session_wait.
19 окт 06, 19:05    [3284545]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
!
Guest
"А вопрос такой: почему primary успевает производить изменение данных, а standby -- нет?" ЭТО ВООБЩЕ РАЗНЫЕ ОПЕРАЦИИ. СРАВНИВАТЬ НЕТ СМЫСЛА ДАЖЕ.
19 окт 06, 19:06    [3284546]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
!
Guest
Подобные вещи решаются организационным способом:
- регулирование размера логов
- регулирование задержки перед накатом
и т.п.

И вообще что означает, что PRIMARY что-то там успевает...:) Перед чем, собственно, преимущество?
19 окт 06, 19:11    [3284571]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
lh@work
Member

Откуда: Москва
Сообщений: 49
2 ыекь
параметры и у primary и у standby одинаковые.

sga_max_size=8000M
19 окт 06, 19:11    [3284573]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
!
Guest
lh@work
2 ыекь
параметры и у primary и у standby одинаковые.

sga_max_size=8000M


Я же тебе говорю, что ты пытаешься сравнить коня и козу. Ты смотришь на две разные операции.
19 окт 06, 19:12    [3284580]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
!
Guest
Сам пойми, ведь в этих операциях учавствуют разные процессы, задействованы разные участки памяти, ситуацию контролируют разные параметры и т.п.
19 окт 06, 19:15    [3284592]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
lh@work
Member

Откуда: Москва
Сообщений: 49
!
"А вопрос такой: почему primary успевает производить изменение данных, а standby -- нет?" ЭТО ВООБЩЕ РАЗНЫЕ ОПЕРАЦИИ. СРАВНИВАТЬ НЕТ СМЫСЛА ДАЖЕ.


А если попробовать? (Дальше -- только предположения, если кто умный есть -- поправьте)
Накат лога -- это валидация, чтение (наверняка тоже с валидацией),складирование в log_buffer, какой-то парсинг,
затем вытаскивание в буферный кэш блоков данных, которые надо менять, изменение их и т.д.
19 окт 06, 19:19    [3284610]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
lh@work
Member

Откуда: Москва
Сообщений: 49
!
Подобные вещи решаются организационным способом:
- регулирование размера логов
- регулирование задержки перед накатом
и т.п.

И вообще что означает, что PRIMARY что-то там успевает...:) Перед чем, собственно, преимущество?


Регулирование размера логов -- это прекрасно, но не всегда возможно. Если мелкий лог удобен для standby, то кластерную primary под хорошей OLTP-нагрузкой он просто кладет по дисковому I/O.
О задержке перед накатом речь вообще не идет. Recovery не успевает накатить логи, скопившиеся за время между завершением бэкапа, из которого поднят standby до завершения рестора standby.

Вопрос, успевает или не успевает, пожалуй, был сформулирован неверно. Скажем так: скорость генерации лога на primary -- n Kb/sec, на standby -- n/2 Kb/sec. Очевидно, что standby отстанет от primary. И будет отставать все больше и больше, так что когда потребуется сделать switchover, ждать придется очень долго. Не хочется.
19 окт 06, 19:28    [3284631]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
BW
Member

Откуда:
Сообщений: 727
lh@work
Задача: увеличить скорость наката логов на физическую standby-базу

Что есть: кластерная primary-база Oracle10g на ASM, standby на ASM (другом).
Recovery запускается в 32 параллельных процесса (опция parallel 32).
Контрольная сумма не вычисляется: db_block_checksum=false
Подкручено общение между параллельными процессами: parallel_execution_message_size = 8192
Архивные логи лежат на локальных дисках, база -- на SAN и грузит его не сильно.
Суммарная скорость генерации логов на всем кластере -- около 800Кб/сек

Что не нравится: average apply rate после часа работы опускается до 400Кб/сек, то есть догнать primary не представляется возможным.

Коллеги, есть ли еще какие-то варианты по ускорению standby, которые я пропустила?

Спасибо.

Нужно больше информации.
1. Информация о железе: сервера, storage systems и т.п.
2. Какая ОС?
3. Версия Оракла?
4. Какие замеры производительности делали?
5. Проблема проявляется только после часа работы, т.к. первый час работает с нужной скоростью?

С уважением,
bw.
19 окт 06, 21:07    [3284820]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
i/o
Member

Откуда:
Сообщений: 46
И еще пожалуйста init файлы промышленной и стендбая + результат запроса на стендбае:
select event,
       total_waits,
       round(time_waited / 100) "TIME(s)",
       average_wait * 10 "AVG(ms)",
       TO_CHAR(SYSDATE, 'DD-MON-YYYY HH:MI:SS') time
  from v$system_event
 where time_waited > 100
   and event not in ('rdbms ipc message', 'pmon timer', 'control
file heartbeat', 'smon timer')
   and event not like '%PX%'
   and event not like '%rdbms%'
   and event not like '%SQL*Net%'
 order by time_waited
20 окт 06, 10:09    [3285894]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
i/o
Member

Откуда:
Сообщений: 46
Имхо кэш буферов на StandBy по размеру подшаманить нужно.
20 окт 06, 10:12    [3285909]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
!?
Guest
!
"А вопрос такой: почему primary успевает производить изменение данных, а standby -- нет?" ЭТО ВООБЩЕ РАЗНЫЕ ОПЕРАЦИИ. СРАВНИВАТЬ НЕТ СМЫСЛА ДАЖЕ.


а зачем чтобы стендбай успевал? И в каком режиме все это работает? (high availability|high protection|etc)

не устраивает время switchover?
20 окт 06, 10:39    [3286127]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
DВА
Member

Откуда:
Сообщений: 5439
lh@work

Коллеги, есть ли еще какие-то варианты по ускорению standby, которые я пропустила?
Спасибо.


в десятке есть возможность, которой мне очень не хватает в девятке - в случае "сильного" отставания, стендбай может догнаться инкрементальным бэкапом основной базы - процесс куда менее трудоемкий, чем накат логов - способ описан в стандартной документации.
21 окт 06, 13:59    [3291732]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
DВА
Member

Откуда:
Сообщений: 5439
кстати, стендбай кластерный?
21 окт 06, 14:18    [3291753]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
BW
Member

Откуда:
Сообщений: 727
DВА
кстати, стендбай кластерный?

А что принципиально это изменит? Накат логов идет ведь одним инстансем?!

С уважением,
bw.

P.S. автор топика куда-то пропал. Или проблема разрешилась или собирает ответы на мои вопросы :-)))
21 окт 06, 19:38    [3292099]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
DВА
Member

Откуда:
Сообщений: 5439
BW
[quot DВА]кстати, стендбай кластерный?

А что принципиально это изменит? Накат логов идет ведь одним инстансем?!
[quot]

как-то столкнулась с тем, что работа двумя нодами - одна логи формирует, вторая накатывает - оказалась тормознутее, чем когда одна и формирует и накатывает :(
22 окт 06, 13:15    [3292736]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
BW
Member

Откуда:
Сообщений: 727
DВА
BW
DВА
кстати, стендбай кластерный?

А что принципиально это изменит? Накат логов идет ведь одним инстансем?!


как-то столкнулась с тем, что работа двумя нодами - одна логи формирует, вторая накатывает - оказалась тормознутее, чем когда одна и формирует и накатывает :(

А можно чуть по-подробнее? И что значит "формирование" и "накатывание" в упомянутом контексте?

С уважением,
bw.
22 окт 06, 15:10    [3292853]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
DВА
Member

Откуда:
Сообщений: 5439
http://dba-services.berkeley.edu/docs/oracle/manual-10gR2/server.102/b14239/rac_support.htm
22 окт 06, 16:08    [3292903]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
BW
Member

Откуда:
Сообщений: 727
DВА
http://dba-services.berkeley.edu/docs/oracle/manual-10gR2/server.102/b14239/rac_support.htm


Понял. Не догадался, что "формирование" - это receiving instance

С уважением,
bw.
23 окт 06, 15:18    [3296671]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
lh@work
Member

Откуда: Москва
Сообщений: 49
BW
DВА
кстати, стендбай кластерный?

А что принципиально это изменит? Накат логов идет ведь одним инстансем?!

С уважением,
bw.

P.S. автор топика куда-то пропал. Или проблема разрешилась или собирает ответы на мои вопросы :-)))


Прошу прощения за долгое молчание.

Ответы собрать недолго:
hardware
NetApp3020
IB Switch Silverstorm 5000
software
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters and Data Mining options

Primary -- кластер из 6 узлов на asm, standby -- cluster_database=false, но asm кластерный.

Пока шел накат смотрели в v$managed_standby, v$session,v$recovery_progress, v$system_event
Да и тупо по alert.log можно было вычислить примерную скорость наката.

Про первый час нормальной работы я ошибалась -- на самом деле база с самого начала применяла логи с типовой скоростью, просто сразу после старта и средняя и мгновенная скорости применения логов были большими, а потом все тихо стабилизировалось и съезжало к 300-400


Проблема разрешилась "насильным докатыванием" standby с помощью RMAN'а. Костыль, конечно, но выбирать не приходилось. Что обиднее всего -- после переключения standby на primary производительность этого нового primary (на том же железе и прочем) была ровно такая же, как и на прежней primary, с которой все сравнивали. Так что грабли явно в накате логов. Логи (на всякий случай повторюсь) лежали на локальных дисках.
23 окт 06, 16:25    [3297359]     Ответить | Цитировать Сообщить модератору
 Re: physical standby recovery rate  [new]
BW
Member

Откуда:
Сообщений: 727
lh@work
BW
DВА
кстати, стендбай кластерный?

А что принципиально это изменит? Накат логов идет ведь одним инстансем?!

С уважением,
bw.

P.S. автор топика куда-то пропал. Или проблема разрешилась или собирает ответы на мои вопросы :-)))


Прошу прощения за долгое молчание.

Ответы собрать недолго:
hardware
NetApp3020
IB Switch Silverstorm 5000
software
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)
Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters and Data Mining options

Primary -- кластер из 6 узлов на asm, standby -- cluster_database=false, но asm кластерный.

Пока шел накат смотрели в v$managed_standby, v$session,v$recovery_progress, v$system_event
Да и тупо по alert.log можно было вычислить примерную скорость наката.

Про первый час нормальной работы я ошибалась -- на самом деле база с самого начала применяла логи с типовой скоростью, просто сразу после старта и средняя и мгновенная скорости применения логов были большими, а потом все тихо стабилизировалось и съезжало к 300-400


Проблема разрешилась "насильным докатыванием" standby с помощью RMAN'а. Костыль, конечно, но выбирать не приходилось. Что обиднее всего -- после переключения standby на primary производительность этого нового primary (на том же железе и прочем) была ровно такая же, как и на прежней primary, с которой все сравнивали. Так что грабли явно в накате логов. Логи (на всякий случай повторюсь) лежали на локальных дисках.


Во-первых, я бы убрал опцию parallel 32. Достаточно просто parallel, ведь у Вас не 32 процессорный стендбай?!
Во-вторых, Вы не привели описание "что и как смотрели", предлагаю посмотреть на документ "Oracle Database 10g Best Practices: Data Guard Redo Apply and Media Recovery". В Приложение Б (Appendix B) есть список шагов по сбору статистики и тюнингу.
Если Вам не поможет, то Вы хотя бы будете готовы огласить собранные статистические данные.

С уважением,
bw.
23 окт 06, 17:45    [3298028]     Ответить | Цитировать Сообщить модератору
Все форумы / Oracle Ответить