ORA-16541
If you met ORA-16541 either on the primary or the standby side like this:
DGMGRL> show configuration
ORA-16541: database is not enabled
Configuration details cannot be determined by DGMGRL
DGMGRL> disable configuration
ORA-16541: database is not enabled
Configuration details cannot be determined by DGMGRL
DGMGRL> remove configuration
Error: ORA-16541: database is not enabled
Failed.
Don't worry about it, you may try to show configuration on any other server which is also under the same data guard infrastructure, it could succeed. But the fact is that the configuration has already been unusable.
In some cases like incomplete switchover, the broker has switched their roles, but the configuration has not been updated before interruption. In other word, the configuration cannot match current primary and standby roles, so it still need to be fixed soon or later.
Try Other Endpoints
Let's say, you got the error on the primary side, then you can try to connect to the standby's DGMGRL, or vice versa.
DGMGRL> show configuration
Configuration - COMPDR
Protection Mode: MaxPerformance
Databases:
primdb - Primary database
standb - Snapshot standby database
Fast-Start Failover: DISABLED
Configuration Status:
DISABLED
DGMGRL> show database standb
Database - standb
Role: SNAPSHOT STANDBY
Intended State: APPLY-OFF
Transport Lag: (unknown)
Apply Lag: (unknown)
Instance(s):
standb1 (apply instance)
standb2
Database Status:
DISABLED
I met this error after I converted a snapshot standby back to the physical standby laboriously. And I think it could also happen in semi-manually switchover or failover.
In such case, trying to wake up the broker by issuing enable configuration or enable database xxxx command under DGMGRL may NOT be helpful. But you can try due to their low cost.
Recreate Broker Configuration
The real solution is to recreate the broker configuration on the available endpoint like the following:
DGMGRL> disable configuration
Disabled.
DGMGRL> remove configuration
Removed configuration
Then we create a new and current configuration for the broker.
DGMGRL> CREATE CONFIGURATION 'COMPDR' AS PRIMARY DATABASE IS 'primdb' CONNECT IDENTIFIER IS 'primdb';
Configuration "COMPDR" created with primary database "primdb"
DGMGRL> ENABLE CONFIGURATION;
Enabled.
DGMGRL> ADD DATABASE standb AS CONNECT IDENTIFIER IS standb MAINTAINED AS PHYSICAL;
Database "standb" added
DGMGRL> ENABLE DATABASE standb;
Enabled.
DGMGRL> show configuration
Configuration - COMPDR
Protection Mode: MaxPerformance
Databases:
primdb - Primary database
standb - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
DGMGRL> show database standb
Database - standb
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
Real Time Query: ON
Instance(s):
standb1 (apply instance)
standb2
Database Status:
SUCCESS
DGMGRL>
It's back to normal.
Backup Literal Creation Statement
One lesson that I learned from this issue is to save the literal statements of configuration creation in advance by myself in order to recreate the configuration someday in the future.
If you're interested in converting a snapshot standby back and forth, you may refer to following post: Converting Standby Database to Snapshot (0/4) - An Overview.