|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Добрый день! Подскажите несколько вопросов по работе с physical standby. Ситуация следующая: Судя по всему не применяются файлы архивлогов, они накопились в каталоге в большом количестве 500 Гб. Судя по дате создания файлов, логи эти копятся уже с лета прошлого года. Если пытаться делать delete archivelog all; - получаю ошибку RMAN-08120. Потом смотрю на primary сервере – делаю DGMGRL / потом show configuration и получаю ORA-16525: the Data Guard broker is not yet available Правильно я понимаю, что у меня не настроен DataGuard? Что мне делать в этой ситуации, пытаться применять логи вручную? Дело в том, что на standby сервере осталось 100 ГБ места, когда оно было в 0, то упал и primary сервер. Удалось почистить на 100 ГБ места, но в день прибывает по 2-3 гб архивлогов. Как грамотно выйти из этой ситуации? Со standby до этого дела не имел. Заранее спасибо! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 11:37 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Oracle 11g на Windows 2008R2 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 11:37 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Ondayl, Apply-то запущен? На standby: SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY; А вообще, почитайте мануал сначала, а то наделаете сейчас дел и придётся делать новый стендбай. https://docs.oracle.com/cd/E11882_01/server.112/e41134/manage_ps.htm#SBYDB00700 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 12:16 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
PuM256, запрос выдал следующий результат: PROCESS STATUS --------- --------- ARCH CONNECTED ARCH CONNECTED ARCH CONNECTED ARCH CONNECTED RFS IDLE RFS IDLE RFS IDLE На самом деле, потерять стендбай мне не страшно, главное чтобы primary работал. И тем более, с таким отставанием (с июля прошлого года) стендбай наверное лучше пересоздать? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 13:20 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Apply не запущен. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 13:25 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
PuM256, можно несколько пояснений? DataGuard это же автоматика, т.е логи должны сами применяться? Второе, Apply сложно запустить, подготовительные работы для этого нужны? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 13:39 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Автоматика, именно этим и занимается процесс redo apply. Только вот совсем не гарантировано, что в случае аврии (а она у вас была, когда закончилось свободное пространство) ничего не упадёт или восстановится само. Попытаться запустить можно - я уже кидал ссылку на мануал. https://docs.oracle.com/cd/E11882_01/server.112/e41134/log_apply.htm#i1020855 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 13:47 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
PuM256, если оно упадет, упадет оно вместе с праймари? Я так понял, судя из мануала, мне нужна команда: alter database recover managed standby database using current logfile disconnect; Я боюсь primary уронить. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 14:08 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
При попытке ручной накатки recover standby database; получил сообщение: SQL> recover standby database; ORA-00279: change 30069422983 generated at 10/20/2018 09:51:29 needed for thread 1 ORA-00289: suggestion : D:\ORACLE\PRODUCT\11.2.0.4\RDBMS\SVS11_119792_1_893242096.ARC ORA-00280: change 30069422983 for thread 1 is in sequence #119792 Specify log: {<RET>=suggested | filename | AUTO | CANCEL} AUTO ORA-00308: cannot open archived log 'D:\ORACLE\PRODUCT\11.2.0.4\RDBMS\SVS11_119792_1_893242096.ARC' ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. ORA-00308: cannot open archived log 'D:\ORACLE\PRODUCT\11.2.0.4\RDBMS\SVS11_119792_1_893242096.ARC' ORA-27041: unable to open file OSD-04002: unable to open file O/S-Error: (OS 2) The system cannot find the file specified. Посмотрел на primary, SVS11_119792_1_893242096.ARC - этого лога нет нигде на файловой системе. Все, standby потерян? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 14:32 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Для запуска apply нужно выполнить SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; Real-time apply - это дополнительный функционал, который вам, скорее всего, не нужен. Покажите ещё select max(sequence#), max(first_time), max(next_time) from v$archived_log where applied='YES'. Но что-то мне кажется, что мы там увидим 2018 год... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 15:11 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
PuM256, что-то пусто все. SQL> select max(sequence#), max(first_time), max(next_time) from v$archived_log where applied='YES'; MAX(SEQUENCE#) MAX(FIRST MAX(NEXT_ -------------- --------- --------- ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 15:35 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Ondayl PuM256, что-то пусто все. SQL> select max(sequence#), max(first_time), max(next_time) from v$archived_log where applied='YES'; MAX(SEQUENCE#) MAX(FIRST MAX(NEXT_ -------------- --------- --------- То, что тебе рекомендовали, выполнил? Код: plsql 1.
Какие результаты? Процесс MRP0 появился? В alert.log файлe сообщения, содержащие фразу Media recovery, появились? Что возвращает: Код: plsql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 19:19 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Ondayl этого лога нет нигде на файловой системе. Ondayl Все, standby потерян? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.05.2021, 19:43 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
flexgen, да, выполнил, процесс появился. SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY; PROCESS STATUS --------- ------------ ARCH CONNECTED ARCH CONNECTED ARCH CONNECTED ARCH CONNECTED RFS IDLE RFS IDLE RFS IDLE RFS IDLE MRP0 WAIT_FOR_GAP В alert.log на данный момент сообщение: Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT Media Recovery Waiting for thread 1 sequence 119792 Fetching gap sequence in thread 1, gap sequence 119792-119891 Fri May 21 09:26:21 2021 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 119792-119891 DBID 2173781982 branch 893242096 FAL[client]: All defined FAL servers have been attempted. ------------------------------------------------------------ Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is defined to a value that's sufficiently large enough to maintain adequate log switch information to resolve archivelog gaps. ------------------------------------------------------------ v$dataguard_stats: SQL> select * from v$dataguard_stats; NAME -------------------------------- VALUE ---------------------------------------------------------------- UNIT TIME_COMPUTED ------------------------------ ------------------------------ DATUM_TIME ------------------------------ transport lag day(2) to second(0) interval 05/21/2021 09:48:31 NAME -------------------------------- VALUE ---------------------------------------------------------------- UNIT TIME_COMPUTED ------------------------------ ------------------------------ DATUM_TIME ------------------------------ apply lag +943 23:55:58 day(2) to second(0) interval 05/21/2021 09:48:31 05/21/2021 09:47:27 NAME -------------------------------- VALUE ---------------------------------------------------------------- UNIT TIME_COMPUTED ------------------------------ ------------------------------ DATUM_TIME ------------------------------ apply finish time day(2) to second(3) interval 05/21/2021 09:48:31 NAME -------------------------------- VALUE ---------------------------------------------------------------- UNIT TIME_COMPUTED ------------------------------ ------------------------------ DATUM_TIME ------------------------------ estimated startup time 16 second 05/21/2021 09:48:31 ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2021, 08:54 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Ondayl flexgen, да, выполнил, процесс появился. SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY; PROCESS STATUS --------- ------------ ARCH CONNECTED ARCH CONNECTED ARCH CONNECTED ARCH CONNECTED RFS IDLE RFS IDLE RFS IDLE RFS IDLE MRP0 WAIT_FOR_GAP В alert.log на данный момент сообщение: Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT Media Recovery Waiting for thread 1 sequence 119792 Fetching gap sequence in thread 1, gap sequence 119792-119891 Fri May 21 09:26:21 2021 FAL[client]: Failed to request gap sequence GAP - thread 1 sequence 119792-119891 DBID 2173781982 branch 893242096 FAL[client]: All defined FAL servers have been attempted. ------------------------------------------------------------ Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter is defined to a value that's sufficiently large enough to maintain adequate log switch information to resolve archivelog gaps. ------------------------------------------------------------ v$dataguard_stats: SQL> select * from v$dataguard_stats; NAME -------------------------------- VALUE ---------------------------------------------------------------- UNIT TIME_COMPUTED ------------------------------ ------------------------------ DATUM_TIME ------------------------------ transport lag day(2) to second(0) interval 05/21/2021 09:48:31 NAME -------------------------------- VALUE ---------------------------------------------------------------- UNIT TIME_COMPUTED ------------------------------ ------------------------------ DATUM_TIME ------------------------------ apply lag +943 23:55:58 day(2) to second(0) interval 05/21/2021 09:48:31 05/21/2021 09:47:27 NAME -------------------------------- VALUE ---------------------------------------------------------------- UNIT TIME_COMPUTED ------------------------------ ------------------------------ DATUM_TIME ------------------------------ apply finish time day(2) to second(3) interval 05/21/2021 09:48:31 NAME -------------------------------- VALUE ---------------------------------------------------------------- UNIT TIME_COMPUTED ------------------------------ ------------------------------ DATUM_TIME ------------------------------ estimated startup time 16 second 05/21/2021 09:48:31 Теперь проверь в базе Primary конфигурацию соответствующего аrchive destination: Код: plsql 1. 2.
где <N> номер destination, соответствующий твоей базе Standby. Далее, проверь параметр DG_CONFIG, здесь должны быть прописаны твои базы Primary и Standby. Код: plsql 1.
Далее, проверь что файл password file на Primary соответствует файлу на Standby. Так же убедись что в файле tnsnames.ora на Primary и Standby существуют записи для обеих баз. Теперь проверь статус твоего аrchive destination Код: plsql 1.
где <N> номер destination, соответствующий твоей базе Standby. Если все настроено правильно, то Primary будет создавать файлы archived log на стороне Standby. Смотри сообщения в alert.log на Primary. Если файлы не создаются для начала попробуй перезапустить процесс: Код: plsql 1. 2.
И опять смотри сообщения в alert.log на Primary. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.05.2021, 21:11 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
У ТС насколько я понял - архивлоги передаются на стендбай. Проблема у него в том, что Код: plsql 1.
Т е потерян(ы) архивлоги и накат новых архивлогов не идет(спотыкается на отсутствующих) Т е ему нужно синхронизировать стендбай(ссылку тут уже давали) или по новой его создать, а уже потом все остальное настраивать, если потребуется ... |
|||
:
Нравится:
Не нравится:
|
|||
22.05.2021, 09:11 |
|
Несколько вопросов о работе со Standby
|
|||
---|---|---|---|
#18+
Судя по ответам выше, архивлога пропущенного нигде нет, на на примари, ни в бэкапе, значит стэндбай вы потеряли. Что мешает пересоздать его, RMAN это делает просто, шаги такие: 1. на стэндбае останавливаете экземпляр, удаляете все датафайлы и делаете pfile с одной строчкой db_name='primary', далее запускаете экземпляр в NOMOUNT c pfile='указываете путь до pfile с одной строчкой'. В листенере экземпляр должен быть указан явно, т.к. nomount с пустым pfile не регистрируется там сам. 2. на primary сервере: создаете файл rman.txt с таким примерно содержимым: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
3. на primary set ORACLE_SID=primary rman connect target sys connect auxiliary sys@primarystb @rman.txt ... |
|||
:
Нравится:
Не нравится:
|
|||
26.05.2021, 10:39 |
|
|
start [/forum/topic.php?fid=52&msg=40071846&tid=1880165]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
63ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 242ms |
total: | 409ms |
0 / 0 |