Здравствуйте! Столкнулся с достаточно интересной для себя историей.

Есть 2 базы, PRIMARY и STANDBY, на них настроен broker (dgmgrl), т.е. переход на резерв осуществляется командой switchover to XXX, или failover to XXX.

У меня 500 баз так настроено, всё прекрасно работает, т.е. как настраивать dataguard опыт имеется.
Применение логов в реальном времени.

Но, тут вот на 11 Оракле настроил 2 базы, брокер настроил, но switchover выполнить не даёт, причина:

на стендбайной базе всегда 1 последний архивный лог находится в статусе IN-MEMORY и применять она его начинает только тогда, когда на стендбай приходит новый архивный лог. Т.е. в реальном времени по факту мы имеем всегда рассинхрон в 1 лог. Он ругается что датафайлы неконсистентны и этой действительно так.

На металинке я нашел The Latest Archivelog On Standby Database Keep The Status Of In-Memory (Doc ID 1384371.1), в целом там написано что это нормальная история, но по факту это не совсем так, ведь я не могу выполнить свитчовер без шаманства, на всех моих базах если архивные лог попадает на стендбай - он его сразу применяет и к датафайлам, а не держит в памяти.

Как заставить стендбай применять лог сразу, не ждать пока попадёт следующий?

standby redo log естественно есть, пробовал их пересоздавать на стендбайном сервере.

ситуация пока совершенно непонятная, учитывая что логе датагарда нет совершенно никаких ошибок, все передаётся, применяется. но только после того как на стендбай попадает новый арх лог.

на primary: select switchover_status from v$database; --TO STANDBY
на standby: select switchover_status from v$database; --NOT ALLOWED

DGMGRL> show configuration verbose

Configuration - dg1

Protection Mode: MaxAvailability
Databases:
host1- Primary database
host2 - Physical standby database

Properties:
FastStartFailoverThreshold = '30'
OperationTimeout = '30'
FastStartFailoverLagLimit = '30'
CommunicationTimeout = '180'
FastStartFailoverAutoReinstate = 'TRUE'
FastStartFailoverPmyShutdown = 'TRUE'
BystandersFollowRoleChange = 'ALL'

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS
--------------------
primary:
log_archive_dest_1 string LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=host1
log_archive_dest_2 string service="host2", LGWR SYNC AFFIRM delay=0 optional compression=disable max_failure=0 max_connections

standby:
log_archive_dest_1 string location=USE_DB_RECOVERY_FILE_DEST, valid_for=(ALL_LOGFILES, ALL_ROLES)
log_archive_dest_2 string service="host1", LGWR SYNC AFFIRM delay=0 optional compression=disable max_failure=0 max_connect

log drcHOST1:

07/19/2019 00:09:42
SWITCHOVER TO host2
Notifying Oracle Clusterware to teardown primary database for SWITCHOVER
07/19/2019 00:10:24
Switchover operation failed with status ORA-16751
Target standby sblrg failed to become a primary database.
To recover, return the original primary, host1, to the primary role
using SQL*plus. Then correct the errors that prevented sblrg from becoming
a primary database, and retry the switchover operation.
For more information, please check the Troubleshooting Chapter of the Data Guard
Broker documentation.
Command SWITCHOVER TO host2 completed
07/19/2019 00:11:13
Process RSM0, PID = 28750, will be killed
07/19/2019 00:11:15
Creating process RSM0
07/19/2019 00:11:19
Process RSM0 re-created with PID = 2527
Error detected: one or more instances do not have log transport turned on.
Data Guard Broker Status Summary:
Type Name Severity Status
Configuration dg1 Warning ORA-16607
Primary Database host1 Error ORA-16810
Physical Standby Database host2 Error ORA-16766

drcHOST2.log:

07/19/2019 00:08:40
SQL Execution error=604, sql=[ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WAIT WITH SESSION SHUTDOWN]. See error stack below.
ORA-00604: error occurred at recursive SQL level 1
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/u01/oracle/oradata/host2/system01.dbf'
Sswitchover to primary command failed
Database Resource SetState Error (16751)
07/19/2019 08:52:17
Notifying DMON of db close
Notifying RSM0 of db close
07/19/2019 08:52:21
Data Guard Broker shutting down
posting shutdown message to primary database 0x01001000
RSM0 successfully terminated

А редактировать сообщения здесь нельзя? :)

Собственно, на стендбае вот так картина по логам выглядит:

SELECT sequence#, first_time, next_time, applied FROM v$archived_log order by first_time desc

SEQUENCE# FIRST_TIME NEXT_TIME APPLIED
221 2019-07-23 15:48:53 2019-07-23 15:48:59 IN-MEMORY
220 2019-07-23 15:48:17 2019-07-23 15:48:53 YES
219 2019-07-23 15:34:59 2019-07-23 15:48:17 YES
218 2019-07-23 15:03:59 2019-07-23 15:34:59 YES

BYTES
5368709120
5368709120
5368709120
5368709120
5368709120

Они одинаковы и на праймари и на стендбае.

Вячеслав Любомудров,
триггеров каких-то специфических нет.

Дело в том, что полная история такая:

Был хост, без стендбая. Я сделал для него стендбай. УСПЕШНО перешел на него switchover to XXX.

Затем у теперешнего стендбайного хоста заменилась "железка", т.е. тачка была заново переделана, настроен стендбай. Только вот ОБРАТНЫЙ переход на НОВУЮ тачку не получается из-за этого отставания в 1 лог.

Я к чему - эта база не менялась и не так давно я эту же базу переводил успешно на резерв, а теперь, с заменой хоста - столкнулся с такой ерундой странной. Сверяю уж все настройки - один в один, что мешает - непонятно пока.

Oleg M.Ivanov,

Спасибо за ценную мысль! На хостах в 1-2 минуты различается время примерно, на уровне ОС, разберемся с этим вопросом и проверим.

Oleg M.Ivanov,

в общем, со временем разобрались, но история еще не закончена.

Запрос на оставание наката показывает всё красиво:




Один лог пока остаётся in-memory, если смотреть CHECKPOINT_CHANGE у датафайлов, то как раз видим различия в один лог:




на прайме: 132083242186
на стендбае: 132083237301

По идее у них должны быть одинаковые CHECKPOINT_CHANGE на праймари и стендбае после применения всех логов. Когда мы запустим свитчовер он опять будет говорить о неконсистентности между датафайлами праймари и стендбая.

1. Почему, я вышел отвечал про редо:

select bytes from v$log

BYTES
5368709120
5368709120
5368709120
5368709120
5368709120

Они одинаковы и на праймари и на стендбае.

2. Активных транзакций нет по запросу

3. ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

Это прод, я не могу это просто так вот запустить сейчас.
Я пробовал только свитчовер через dgmgrl и тогда ругнулся на консистентность собсна

SELECT SWITCHOVER_STATUS FROM V$DATABASE;

да, на праймари статус - TO STANDBY
на стендбае - NOT ALLOWED

да, это уже последний вариант.

просто я делал на этой базе раньше свитчовер и проблем не было, но на другой хост переходил. теперь тот хост заменили, всё переделал и появилась вот такая история.

Совершенно пока не объяснимая с т.з. БД, учитывая что все проверочный запросы и конфигурации не показывают никаких ошибок ДО перехода.
Да и текущая ситуация в целом не ошибочна и чёрт бы с ней, но она мешает переходу.

Дело в том что у меня ни на одной базе нет этой фигни с IN-MEMORY и чтобы он ждал переключения лога.

Сейчас уже хочу включить старый хост (он пока жив), и перенести стендбай туда, проверить как там будет обстановка, ибо с текущим я просто не знаю что делать.

Собственно вот, 276 находится в IN-MEMORY на стендбае