ReSQL.ru
     
powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Непонятки со standby
20 сообщений из 20, страница 1 из 1
Непонятки со standby
    #39836327
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
Oracle 10g

Очень непонятная ситуация. Обычно проверял применяемость логов на standby по запросу на primary

Код: plsql
1.
2.
 SELECT SEQUENCE#,l.NAME,APPLIED FROM V$ARCHIVED_LOG l 
  ORDER BY RESETLOGS_ID,SEQUENCE# desc;




Если стоит APPLIED YES , то считал , что все нормально. Со вчерашнего дня в данном запросе YES перестал появляться. Начал копать глубже. На standby те же самые SEQUENCE# применены, а на основной базе этой информации нет. В alert.log ошибок тоже не наблюдаю. Единственно - прерывалась связь на некоторое время. Опять таки - судя по информации в alert.log все файлы позже передались.

Получается на V$ARCHIVED_LOG не стоит ориентироваться? или все же проблемы со standby?
...
Рейтинг: 0 / 0
11.07.2019, 13:06
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836344
Oleg M.Ivanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Oleg M.Ivanov
Гость
Я таким запросом смотрю на примари:
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
SELECT 
    (SELECT MAX(SEQUENCE#)
       FROM V$ARCHIVED_LOG 
      WHERE RESETLOGS_CHANGE# IN 
            (SELECT RESETLOGS_CHANGE# FROM V$DATABASE)
        AND STANDBY_DEST = 'NO') ON_PRIMARY,
    (SELECT MAX(SEQUENCE#) 
       FROM V$ARCHIVED_LOG 
      WHERE RESETLOGS_CHANGE# IN 
            (SELECT RESETLOGS_CHANGE# FROM V$DATABASE)
        AND APPLIED = 'YES' AND STANDBY_DEST = 'YES') APPLIED_ON_STANDBY
  FROM DUAL;



Плюс, на стендбае:
Код: plsql
1.
select process, status, thread#, sequence#, block#, blocks from v$managed_standby;
...
Рейтинг: 0 / 0
11.07.2019, 13:22
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836357
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
Oleg M.Ivanov,

Вот в том то и проблема

На primary выдает
ON_PRIMARY APPLIED_ON_STANDBY 148494 148181

А на standby
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS--------- ------------ ---------- ---------- ---------- ----------ARCH CLOSING 1 148485 1001473 1189ARCH CLOSING 1 148486 974849 316ARCH CLOSING 1 148487 999425 17ARCH CLOSING 1 148488 978945 206ARCH CLOSING 1 148489 976897 276ARCH CLOSING 1 148490 987137 874ARCH CLOSING 1 148491 972801 2009ARCH CLOSING 1 148492 987137 348ARCH CLOSING 1 148493 974849 729ARCH CLOSING 1 148494 974849 202MRP0 WAIT_FOR_LOG 1 148495 0 0RFS IDLE 0 0 0 0RFS IDLE 0 0 0 0RFS IDLE 1 148495 825596 4191RFS IDLE 0 0 0 0

т.е. primary не ведает про то, что делается на standby
...
Рейтинг: 0 / 0
11.07.2019, 13:34
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836359
Oleg M.Ivanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Oleg M.Ivanov
Гость
sev_brOracle 10g
... или все же проблемы со standby?
Очень может быть. Если связь прерывалась, а в этот момент делался бекап на примари, плюс, в рмане не настроно, чтобы не удалять архлоги, пока не применятся на стендбае, то можно "потерять" один или парочку логов, которые уйдут в архив и не передадутся, тогда накат встанет. Выше представленные селекты покажут что применилось на стендбае и какой лог он ждет. Если произошло, как я описал, то лог придется достать из архива.
...
Рейтинг: 0 / 0
11.07.2019, 13:37
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836366
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
Oleg M.Ivanov,
Логи все есть - я RMAN остановил.
Вот такой запрос на standbay говорит что лог применился

Код: plsql
1.
2.
3.
SELECT SEQUENCE#,l.FIRST_TIME,APPLIED FROM V$ARCHIVED_LOG l 
where sequence# = 148181 or sequence# = 148182
 ORDER BY RESETLOGS_ID,SEQUENCE# desc;



SEQUENCE# FIRST_T APP 148182 10-JUL-19 YES 148181 10-JUL-19 YES



или я не прав?
...
Рейтинг: 0 / 0
11.07.2019, 13:45
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836373
Oleg M.Ivanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Oleg M.Ivanov
Гость
На примари гляньте, возможно, покажет ошибку. Смотреть надо строчку вашего LOG_ARCHIVE_DEST_...
Код: plsql
1.
select * from v$archive_dest_status;
...
Рейтинг: 0 / 0
11.07.2019, 13:55
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836384
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
Oleg M.Ivanov,
Не могу найти ошибку, все логи перекопал, только в V$ARCHIVED_LOG говорит, что логи не применены

v$archive_dest_status

LOG_ARCHIVE_DEST_1 VALID 148503 0LOG_ARCHIVE_DEST_2 VALID 148476 148476


148476 - это же не 148181 :)

Запрос

Код: plsql
1.
select current_scn from v$database;



на обоих серверах так же выдает похожую информацию.

Так что я в полных непонятках.
...
Рейтинг: 0 / 0
11.07.2019, 14:16
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836389
Oleg M.Ivanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Oleg M.Ivanov
Гость
Да, странно.
До кучи можно еще вот эту вьюху глянуть:
Код: plsql
1.
select * from v$recovery_progress;
...
Рейтинг: 0 / 0
11.07.2019, 14:23
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836396
Фотография andrey_anonymous
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrey_anonymous
Участник
sev_brНе могу найти
Просто спросить: у Вас единственный destination?
...
Рейтинг: 0 / 0
11.07.2019, 14:37
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836403
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
andrey_anonymoussev_brНе могу найти
Просто спросить: у Вас единственный destination?

нет, не единственный. но на нем все так же - и применение пропало и отчеты на самом standby показывают, что все хорошо
...
Рейтинг: 0 / 0
11.07.2019, 14:51
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836405
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
Oleg M.IvanovДа, странно.
До кучи можно еще вот эту вьюху глянуть:
Код: plsql
1.
select * from v$recovery_progress;



Спасибо, глянул, вроде ничего криминального
...
Рейтинг: 0 / 0
11.07.2019, 14:53
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836410
Oleg M.Ivanov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Oleg M.Ivanov
Гость
LOG_ARCHIVE_DEST_1 VALID 148503 0LOG_ARCHIVE_DEST_2 VALID 148476 148476
Какие-то тут странные расхождения, локальный DEST далеко вперед убежал.

У меня, к примеру, там максимум на единицу бывает разница. Задержка наката, случаем, не настроена?

И, надо бы, повнимательней изучить вывод этого селекта на проблемных последовательностях, в том числе и раскомментарить фильтр на удаленные логи :
Код: plsql
1.
2.
3.
4.
select sequence#,thread#,first_time, next_time, name ,creator,archived,applied,deleted,status
     from v$archived_log where 1=1 
     --and applied ='NO' and deleted ='YES'
order by sequence# desc;
...
Рейтинг: 0 / 0
11.07.2019, 15:00
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836447
Фотография Viewer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Viewer
Участник
на всякий случай на стендбае:
Код: plsql
1.
select * from v$archive_gap;
...
Рейтинг: 0 / 0
11.07.2019, 15:47
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836449
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
Viewerна всякий случай на стендбае:
Код: plsql
1.
select * from v$archive_gap;



Так тоже проверял, чисто
...
Рейтинг: 0 / 0
11.07.2019, 15:49
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836583
flexgen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
flexgen
Участник
sev_brViewerна всякий случай на стендбае:
Код: plsql
1.
select * from v$archive_gap;



Так тоже проверял, чисто

Посмотри на Standby в v$managed_standby наличие процесса MRP0 а также количество и статус процессов RFS.
В v$dataguard_stats посмотри transfer lag и apply lag.

Смотри alert.log на Primary и на Standby - есть ли в логе на primary сообщения об ошибках архивирования, на standby проверь принимаются ли файлы и накатываются ли. Местонахождение alert.log файлов смотри в v$diag_info.

Проверь выставлен ли параметр fal_server на стороне standby, значение параметра должно быть определено как дескриптор подключения к primary в файле tnsnames.ora.

Проверь в файле tnsnames.ora на primary и standby наличие и правильность дескрипторов подключений для primary и standby, также убедись что password files на primary и standby идентичны. В случае Oracle RAC проверять надо на всех нодах кластера.

Несколько раз сталкивался с таким - если по какой-то причине прерывалась связь primary со standby то прекращалось архивирование на standby destination. Решалось выполнением следующих команд на primary:
Код: plsql
1.
2.
alter system set LOG_ARCHIVE_DEST_STATE_2=defer;
alter system set LOG_ARCHIVE_DEST_STATE_2=enable;
...
Рейтинг: 0 / 0
11.07.2019, 21:46
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836628
Вячеслав Любомудров
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Вячеслав Любомудров
Участник
До 11.2 этот столбец на Primary в большинстве случаев погоду показывал (например, Bug 7417614 - APPLIED column in V$ARCHIVED_LOG can erroneously indicate a log was not applied (Doc ID 7417614.8))
Да и после на него сильно полагаться тоже не стоит.

Кстати, из-за SRL, RTA оно может врать и на Standby -- вот это уже засада. Вроде, как с 12 починили, но оно такое...
...
Рейтинг: 0 / 0
12.07.2019, 04:03
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836670
alexkir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alexkir
Гость
sev_br,

Посмотри
http://orabliss.blogspot.com/2013/01/applied-column-on-varchivedlog-when_61.html

APPLIED - Column not updated if Heartbeat-ARCH hangs [ID 1369630.1]
Bug 6113783 - Arch processes can hang indefinitely on network [ID 6113783.8]
...
Рейтинг: 0 / 0
12.07.2019, 09:42
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836695
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
flexgenПосмотри на Standby в v$managed_standby наличие процесса MRP0 а также количество и статус процессов RFS.
В v$dataguard_stats посмотри transfer lag и apply lag.

Смотри alert.log на Primary и на Standby - есть ли в логе на primary сообщения об ошибках архивирования, на standby проверь принимаются ли файлы и накатываются ли. Местонахождение alert.log файлов смотри в v$diag_info.

Проверь выставлен ли параметр fal_server на стороне standby, значение параметра должно быть определено как дескриптор подключения к primary в файле tnsnames.ora.

Проверь в файле tnsnames.ora на primary и standby наличие и правильность дескрипторов подключений для primary и standby, также убедись что password files на primary и standby идентичны. В случае Oracle RAC проверять надо на всех нодах кластера.

Несколько раз сталкивался с таким - если по какой-то причине прерывалась связь primary со standby то прекращалось архивирование на standby destination. Решалось выполнением следующих команд на primary:
Код: plsql
1.
2.
alter system set LOG_ARCHIVE_DEST_STATE_2=defer;
alter system set LOG_ARCHIVE_DEST_STATE_2=enable;




Проверил все , ошибок нет . архивирование происходит, применение тоже происходит. а вот в таблице V$ARCHIVED_LOG информации нет. За alter system отдельное спасибо :) , совсем забыл про него, хотя так же выручал.
...
Рейтинг: 0 / 0
12.07.2019, 10:29
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836699
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
Вячеслав ЛюбомудровДо 11.2 этот столбец на Primary в большинстве случаев погоду показывал (например, Bug 7417614 - APPLIED column in V$ARCHIVED_LOG can erroneously indicate a log was not applied (Doc ID 7417614.8))
Да и после на него сильно полагаться тоже не стоит.

Кстати, из-за SRL, RTA оно может врать и на Standby -- вот это уже засада. Вроде, как с 12 починили, но оно такое...

На standby пока показывает правильно
Вчера просмотрел внимательно все логи, нашел, что во время передачи лога, с которого начинается "сбой" в V$ARCHIVED_LOG было прерывание связи. Но на standby лог применился. Открыл базу - данные актуальные. Так что, думаю, все нормально. Спасибо.
...
Рейтинг: 0 / 0
12.07.2019, 10:35
| Ответить | Цитировать | Написать  
Непонятки со standby
    #39836701
sev_br
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
sev_br
Гость
alexkirsev_br,

Посмотри
http://orabliss.blogspot.com/2013/01/applied-column-on-varchivedlog-when_61.html

APPLIED - Column not updated if Heartbeat-ARCH hangs [ID 1369630.1]
Bug 6113783 - Arch processes can hang indefinitely on network [ID 6113783.8]


Похоже, что это оно, спасибо!
...
Рейтинг: 0 / 0
12.07.2019, 10:37
| Ответить | Цитировать | Написать  
20 сообщений из 20, страница 1 из 1
Форумы / Oracle [игнор отключен] [закрыт для гостей] / Непонятки со standby
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=52&fpage=72&tid=1882311]:
 0ms
get settings:
 11ms
get forum list:
 12ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 32ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 63ms
get tp. blocked users:
 2ms
others: 264ms
total:  405ms
созд. / загр.: 405ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]