Skip to content

How to Resolve ORA-16541: database is not enabled

  • by

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.

Leave a Reply

Your email address will not be published. Required fields are marked *