Още една мотика. Случва се следното
– конфигурация от 4 БД (1 primary и 3 standby)
– рестартираме единия standby. Всичко минава по план
– dgmgrl обаче мисли друго:
DGMGRL> show configuration
Configuration - DG
Protection Mode: MaxAvailability
Databases:
primary - Primary database
standby1 - Physical standby database
standby2 - Physical standby database (disabled)
standby3 - Logical standby database (disabled)
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
(disabled) – WTF? трябва да уточня, че сме рестартирали standby1 – другите не сме ги и пипали.
Хайде да опитаме най-лесното
DGMGRL> enable database standby2;
Следва изненада:
ORA-16631: Operation requires shutdown of database/instance ""
Ъъъ… кой, точно, инстанс да рестартирам?
Единственото хубаво на тази грешка е, че води до правилната нота в металинк:
Metalink note 1258074.1
Ora-16631: Operation Requires Shutdown Of Database Or Instance „“ On Physical Standby
Applies to:
Oracle Server – Enterprise Edition – Version: 11.1.0.7 and later [Release: 11.1 and later ]
Information in this document applies to any platform.Symptoms
ORA-16631: Operation requires shutdown of database/instance „“
Cause
Both the primary and standby were shutdown in an graceful fashion.
Since standby is shutdown before primary, standby is marked as shutdown disabled
standby is restarted first and then the primary.
standby sends a bootstrap request to the primary but since it’s not started yet,
it’s request goes unanswered. When primary is then started and as part of
its bootstrap processing the primary intentionally leaves the standby in a
shutdown disabled state. The FSFO state then transitions to an unsynchronized
state since the standby is not available.Solution
— on primary –-dgmgrl / edit database 'standby db unique name here' set state='ONLINE'; show configuration; exit( or )
–- on standby —
sqlplus / as sysdba shu immediate startup mount
Е, вярно, при нас проблема е и при physical, и при logical standby. Освен това не съм рестартирал нито тях, нито primary базата. Мога само да предполагам, че когато standby1 е казал на primary „аз си заминавам“, primary някак се е объркал и е отписал всичките БД. После standby1 е изгрял и е изпратил bootstrap сигнал. Тогава primay го е вписал в конфигурацията, оставяйки другите два на сухо.
Но поне Solution-а работи. Естествено избрах първия като много по-малко инвазивен. Че знам ли като рестартирам standby2 какво ще стане със standby1… 🙂