|
|
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Он там будет в любом случае размещен (если не будет создаваться сервис через srvctl со специальным указание куда класть/брать spfile) Этот параметр скорее для всяких %_file_dest (да и %_file_name_convert, если не задано), чтоб менять все одним махом Вообще, тут какое-то уже переобувание в полете -- то не нужен стендбай, то нужен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2018, 12:34 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Вячеслав, стендбай нужен. автор как продолжать накатывать stby, если живые-генерящие-редо ноды недоступны? Сейчас идея такая: погасить ту ноду кластера RAC к которой нет доступа. Будет деградация RAC, но в целом работать же будет? И тогда настраивать Rman duplicate указав в качестве target не scan адрес (параметр remote_listener=oracledb-scan:1521) а адрес только той ноды, к которой есть доступ. Насколько в целом будет корректна такая схема? Вот так вот у меня примерно получается скрипт: Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2018, 12:58 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Зачем что-то гасить? Цепляешься к ноде, до которой достукиваешься, по любому адресу (лучше если там статическая регистрация) Доступ ко всем редо-журналам есть у всех нод ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2018, 13:16 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровЗачем что-то гасить? Цепляешься к ноде, до которой достукиваешься, по любому адресу (лучше если там статическая регистрация) Доступ ко всем редо-журналам есть у всех нод Вячеслав, спасибо! Ещё вопросик по статическому листнеру. Код: plsql 1. 2. 3. 4. 5. Когда я запускаю listner, то сразу после запуска у меня 1 instance в состоянии UNKNOWN. Но спустя пару минут появляется второй: BLOCKED Так и должно быть? Это на клоне, куда буду переезжать. oracle там запущен в режиме nomount из pfile, в котором всего один параметр:DB_NAME=oracledb Сам конфиг листнера следующий: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2018, 17:56 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
BigBuddaКогда я запускаю listner, то сразу после запуска у меня 1 instance в состоянии UNKNOWN. Но спустя пару минут появляется второй: BLOCKED Так и должно быть? Да. Тот что UNKNOWN - это статическая регистрация (из listener.ora), данный хендлер не зависит от наличия и статуса экземпляра. Тот что появляется спустя несколько секунд - это регистрируется экземпляр (динамическая регистрация). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.10.2018, 19:10 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Выполнил дубликат БД RAC для standby: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. В алерт.логе на клоне ошибки: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Код: plsql 1. 2. 3. 4. 5. 6. файлы такие есть... Могли бы объяснить почему возникают эти ошибки и что нужно сделать? Может быть причина в том, что archive log destination на syandby не определён? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.11.2018, 19:50 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Подскажите, как включить накат логов на стендбай после дубликата? Возможно ли это сделать без настройки брокера dmgrl? Делал так: Код: plsql 1. 2. В логе ошибки Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Вижу, что на стендбай во FRA архивлоги приходят. Но не применяются: На основной БД переключаю журналы: Код: plsql 1. На стендбае появляются новые записи, где APPLIED=NO Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Пробовал: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL: Код: plsql 1. 2. 3. 4. 5. 6. 7. В алерт логе стендбая БД сообщения: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Файлы есть: Код: plsql 1. 2. Почему же тогда: Linux-x86_64 Error: 2: No such file or directory ? В v$standby_log на стендбае я вижу только одну активную группу, которая НЕ переключается при переключении журналов на основной БД. При том, что журналы то есть другие на стендбае... Помогите, пожалуйста, решить данный вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 12:36 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Все у тебя накатывается, просто 3 и 4 логи 1 потока еще не доехали (на момент публикации) А в v$standby_log без нагрузки и не будет по кругу бегать Вот только проверь, что они у тебя для обоих потоков есть (т.е. у тебя должно быть ДВА активных) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 13:01 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
автор(т.е. у тебя должно быть ДВА активных) У меня один активный. Как решить проблему? В каком параметре и что указать? Похоже проблема в том, что со второй ноды/второго потока не прилетают архивные журналы. Я проверил FRA, там все файлы с префиксом 1_ Файла /u02/fast_recovery_area/2_21_990888700.dbf действительно нет! Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 13:14 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Ну так настрой на второй ноде соответствующий LOG_ARCHIVE_DEST на этот стендбай ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 13:18 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровНу так настрой на второй ноде соответствующий LOG_ARCHIVE_DEST на этот стендбай Вячеслав, у меня на обоих нодах прописан LOG_ARCHIVE_DEST_2 на этот стендбай: Архивлоги идут только с первого.... и один активный лог в стендбай лог Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 13:49 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
А теперь файл параметров стендбая И выборку из v$standby_log (тоже со стендбая) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 14:16 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Вячеслав ЛюбомудровА теперь файл параметров стендбая И выборку из v$standby_log (тоже со стендбая) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. Код: plsql 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. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 14:22 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
BigBudda Код: plsql 1. 2. Второй должен показывать на примари (на случай переключения), т.е. SERVICE и DB_UNIQUE_NAME должны быть tns-alias и db_unique_name от Primary Возможно и в этом проблема Первый вроде тоже достаточно, он по умолчанию должен брать VALID_FOR=(ALL_LOGFILES, ALL_ROLES) Но я бы таки прописал полностью все атрибуты (и VALID_FOR и DB_UNIQUE_NAME) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 14:38 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Как корректно прописать thread в скрипт rman? Код: plsql 1. выдаёт ошибку Или не получится отказаться от второго треда на стендбай? Цель: настроить стендбай, после чего его активировать. swithover/failover использоваться не будут. Стал пинговать с первой ноды вторую и наоборот..пинга нет..и Tnsping перестал проходить... очень странно. Возможно дело в этом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 14:57 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Пересоздал стендбай. Та же самая проблема. даже с учётом параметров log_archive_dest Код: plsql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 15:16 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Опечатался в предыдущем сообщении. Удалите предыдущее, пожалуйста. Код: plsql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 15:19 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
права-то проверил? Сам файлик там создать можешь (из-под владельца оракла)? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 15:20 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Вячеслав Любомудровправа-то проверил? Сам файлик там создать можешь (из-под владельца оракла)? Да, сам файл создаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 16:10 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Создал запись в tnsnames для подключения к target database. tnsping проходит, а вот подключение нет. Какие адреса использовать для подключения к target? Код: xml 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. где адреса ниже являются публичными адресами. 172.24.23.135 172.24.23.136 Или обязательно использовать VIP адреса для rman target duplicate? Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 19:10 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Накат так и не идёт.... Что сделал: На первой ноде кластера поднял ещё один листнер на порту 1525. На второй ноде кластера поднял ещё один листнер на порту 1526. Проверил статусы на обеих нодах. Оба листнера подняты на публичных eth0 Public Network адресах. Проверил, что прописана статика для листнеров. Код: plsql 1. 2. Код: plsql 1. 2. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Добавил записи в tnsnames.ora и попробовал подключиться к этим листнерам с клона: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. И тут возник вопрос: а что указывать в set log_archive_dest_2='SERVICE? Может быть указать явно три адреса? Один локальный и по одному (SERVICE) для каждой из нод? Типа так: Код: plsql 1. 2. 3. Или указать один destination, с указанием VIP интерфейсов на порту 1521? Типо так Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. В результате в select * from v$standby_log по прежнему доступна только одна группа... Подскажите, пожалуйста.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 19:57 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Кстати..новая ошибка ещё для брокера нарисовалась.. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 19:59 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Со второй ноды RAC не пингуется и не доступен scan адрес... с первой ноды доступ есть. Может быть в этом причина? Подскажите последовательность шагов для предоставления доступа к скану с каждой из нод. спасибо! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 20:24 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
В огороде бузина... 1) Прочитайте что такое статическая, и динамическая регистрация экземпляра в listener. В чем разница в (CONNECT_DATA=(SID|SERVICE_NAME=xxx)) для чего используется GLOBAL_DBNAME, и насколько она обязательна 2) Проверьте состояние вашего RAC, где какие ресурсы srvctl status listener|scan|vip 3) Чтобы работал транспорт, нужно чтобы у Вас с каждого узла master проходило соединение на standby sqlplus -l sys/pass@tns_alias as sys где tns_alias - параметр (SERVICE=tns_alias ...) Именно используя такое TNS соединение работает транспорт redo с master на standby ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.11.2018, 22:55 |
|
||
|
RMAN Duplicate RAC ASM => Single Filesystem 11.2.0.4
|
|||
|---|---|---|---|
|
#18+
Vadim LejninВ огороде бузина... 1) Прочитайте что такое статическая, и динамическая регистрация экземпляра в listener. В чем разница в (CONNECT_DATA=(SID|SERVICE_NAME=xxx)) для чего используется GLOBAL_DBNAME, и насколько она обязательна 2) Проверьте состояние вашего RAC, где какие ресурсы srvctl status listener|scan|vip 3) Чтобы работал транспорт, нужно чтобы у Вас с каждого узла master проходило соединение на standby sqlplus -l sys/pass@tns_alias as sys где tns_alias - параметр (SERVICE=tns_alias ...) Именно используя такое TNS соединение работает транспорт redo с master на standby По-первому пункту не ясно, какой листнер, из какого дома. В обычной ситуации с Single Database у нас один листер из oracle_home. В случае с кластером у нас появляется ещё и grid_home. Это вносит дополнительную путаницу. sqlplus -l sys/pass@tns_alias as sys - проверил с каждой ноды. Работает. VIP node1-vip is not running - Не запущен vip адрес на первой ноде. Как его поднять? Код: plsql 1. 2. 3. 4. Хотел перезапустить, но выдал ошибку: Код: plsql 1. 2. 3. 4. Пробовал так: Код: plsql 1. 2. После рестарта crs статус: OFFLINE для первой ноды. Может быть моя проблема связана с этим? или причина в чём-то другом? И проблема со скан адресом. Он доступен и пингуется только с одной ноды. Как обеспечить доступ к скан-адресу со всех нод? Код: plsql 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.11.2018, 18:05 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39727186&tid=1883222]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
156ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
65ms |
get tp. blocked users: |
2ms |
| others: | 204ms |
| total: | 470ms |

| 0 / 0 |
