|
|
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
всем, привет! возможен ли subject? или только archived redo можно накатывать через register logfile? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 00:53 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Возможен Правда, в EE это делается автоматически с указанием транспорта LGWR и Standby Redo Logs. Но даже в том случае, если перед сбоем боевой навернулся канал передачи REDO-потока и последнее, что передалось -- это цельный архивлог, перед выполнением failover подкладываются Online Redo Logs (и недостающие архивлоги) и выполняется накат до последней записи в REDO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 02:04 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
спасибо, удавалось делать это на практике (подкладывать все недостающие archived logs и в конце online log(s))? почему-то в документации Oracle не указано какой именно тип лог-файла можно использовать, с другой стороны какая разница между archived и online в ситуации когда от Primary целыми остались только логи и их нужно накатить на Standby? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 02:25 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Во времена 8-ки это было документировано, в том числе с самого появления стендбая, с 7.3 -- подкладывание REDO (и контролов для switchover) -- Graceful Switchover and Switchback of Oracle Standby Databases (Doc ID 76450.1) То, что появился Managed Standby и SRL совсем не отменяет базовых вещей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 03:15 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
на основании этого документа online logs нужно скопировать из Primary в Standby, а не регистрировать и применять как archived logs ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 12:07 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
На основании этого документа выполняется Graceful Switchover -- т.е. ты тащишь не только ONLINE REDO, но и контролы (или, в новой версии, пересоздаешь) Поэтому REDO у тебя подхватятся сами, т.к. стендбайная БД будет выступать в роли Primary Если тебе нужно докатить стендбай при сбое основного, то его контролы ничего не знают о состоянии оперативных журналов (их может и не быть), поэтому они не подхватятся. Поэтому скармливаешь их как архивные (если у тебя нет SRL или в них неактуальная информация). Хочешь, чтоб они пролезли в результате MANAGED RECOVERY -- регистрируй. А можно просто накатить руками И, на мой взгляд, лучшее описание физики стендбая в доке по 8-ке (например, твой случай ) В новых уже куча всяких свистелок-перделок и как-то забывается, что накат физического стендбая и активация это не более чем накат обычных логов на бэкап и открытие после [не]полного восстановления ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 13:13 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
да, моя задача - докатить Standby при сбое Primary без потери данных (RPO=0): напр. я обновляю ОС на Standby и в это время происходит сбой на Primary (вероятность не очень велика, но она есть). допустим сбой Primary DB не позволяет ее смонтировать и выполнить 'flush redo', но если иметь online/archived redo logs на площадке Standby (дисковая репликация), то задача решается прекрасно понимаю, что дополнительный Standby убирает все эти вопросы, но он будет рассматриваться как один из нескольких при расчете TCO ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.03.2017, 17:33 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровНа основании этого документа выполняется Graceful Switchover -- т.е. ты тащишь не только ONLINE REDO, но и контролы (или, в новой версии, пересоздаешь) Поэтому REDO у тебя подхватятся сами, т.к. стендбайная БД будет выступать в роли Primary Если тебе нужно докатить стендбай при сбое основного, то его контролы ничего не знают о состоянии оперативных журналов (их может и не быть), поэтому они не подхватятся. Поэтому скармливаешь их как архивные (если у тебя нет SRL или в них неактуальная информация Пожалуйста, поясните, как это сделать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 12:26 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
нашел вот что: Doc ID 1634979.1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2017, 17:54 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
псж2да, моя задача - докатить Standby при сбое Primary без потери данных (RPO=0): напр. я обновляю ОС на Standby и в это время происходит сбой на Primary (вероятность не очень велика, но она есть). допустим сбой Primary DB не позволяет ее смонтировать и выполнить 'flush redo', но если иметь online/archived redo logs на площадке Standby (дисковая репликация), то задача решается прекрасно понимаю, что дополнительный Standby убирает все эти вопросы, но он будет рассматриваться как один из нескольких при расчете TCO вам надо делать приблизительно так : авторLOG_ARCHIVE_DEST_X='SERVICE=standydb LGWR SYNC AFFIRM'; В случае если что то случиться со стендбаем праймари БД замерзнет на комитах пока вы не отремонтируете стендбай. А в нормальном режиме работы ожидания log file sync вырастут на время ответа от стендбая. Не говорите потом, что вас не предупреждали .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2017, 18:59 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
д0kХвам надо делать приблизительно так : LOG_ARCHIVE_DEST_X='SERVICE=standydb LGWR SYNC AFFIRM'; Зачем SYNC? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2017, 17:01 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
По-поводу наката создал быстренько стендбайdupl_stb_tst.sh Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Работаем, иммитируем сбойНа боевой Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Ну и собственно, сам failoverСтендбай Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2017, 07:35 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
MacDuckд0kХвам надо делать приблизительно так : LOG_ARCHIVE_DEST_X='SERVICE=standydb LGWR SYNC AFFIRM'; Зачем SYNC? что бы стимулировать ТС НЕ создавать велосипеды , которые при реальном сбое никогда не сработают. А выбрать наиболее подходящий для него Protection Mode. Вся эта ручная накатка - представляет интерес для понимания процессов восстановления но как рабочий план восстановления продуктива никуда не годится, потому что ничего не гарантирует. Тут нельзя быть умным и красивым одновремено ТС упрямо движется в сторону ансаппортед конфигурации за деньги ТСО., за что , в конечном итоге, может получить по шапке. Это не выбор между умный и красивый, Я понимаю если бы у него небыло саппорта , можно было бы придумвывать велосипеды но создавать ансаппортед конфигурацию и считать TCO - выбор между глупым и уродливым. ps ничего личного . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.03.2017, 20:09 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Ставить SYNC с одним стендбаем -- это однозначно поиметь проблем Два стендбая -- это уже другие денежки У ТС один стендбай, да и тот будет недоступен на время перетрубаций Конечно, лучший вариант -- второй стендбай, но тут могут быть вопросы как лицензионного плана, так и просто наличие свободной железяки соответствующей мощности. По поводу "велосипеды , которые при реальном сбое никогда не сработают" -- это как раз самый настоящий штатный механизм ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2017, 08:49 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
господа, всем спасибо за помощь! при сравнении различных вариантов отказоустойчивости обязательно буду докладывать руководству кроме ТСО и RPO/RTO еще и поддержку вендора по этому вопросу и связанные с этим риски решение принимает руководство - далее в рабочем порядке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.03.2017, 11:10 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровСтавить SYNC с одним стендбаем -- это однозначно поиметь проблем Два стендбая -- это уже другие денежки У ТС один стендбай, да и тот будет недоступен на время перетрубаций Конечно, лучший вариант -- второй стендбай, но тут могут быть вопросы как лицензионного плана, так и просто наличие свободной железяки соответствующей мощности. По поводу "велосипеды , которые при реальном сбое никогда не сработают" -- это как раз самый настоящий штатный механизм Мне лень повторять, но с 2 мя стендбаями активация одного из стендбаев alter database activate standby database с resetlogs делает второй стендбай не валидным. Второй стендбай путается какой же инкарнации он стендбай . Велосипед состоит в том что прежде чем делать alter database activate standby database параметры LOG_ARCHIVE_CONFIG нужно приветти в правильное состояние, в результате второй стендбай тоже должен resetlogs - нуться. Там не все так тривиально как кажется.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2017, 11:39 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Сейчас (с 10.2, вроде) стендбай вполне себе проскакивает RESETLOGS без дополнительных приседаний. Только перепустить накат надо Лень повторять ему... Ну-ну ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2017, 12:31 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровСтавить SYNC с одним стендбаем -- это однозначно поиметь проблем Можно подробней? Годами работает стендбай с SYNC, переживал и switchover и upgrade версий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.03.2017, 16:36 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Имеется ввиду, что стендбай (единственный) может стать недоступен и тогда подвиснет боевая Все-таки за стендбайной машинкой пригляда поменьше и ее часто используют для всяких тестовых и т.п. Если у вас не так -- то только приветствую и естественно, к вам такое не относится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2017, 02:06 |
|
||
|
накат online redo с primary на standby
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудровстендбай (единственный) может стать недоступен и тогда подвиснет боевая net_timeout=(1|10|100) + max availability, а не max protection ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.03.2017, 11:47 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39422051&tid=1886251]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
172ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
41ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 453ms |

| 0 / 0 |
