ORA-16548: database not enabled

PROBLEM

The standby DB is/stays disabled (cannot be enabled)

DGMGRL> show configuration;

Configuration - MYDB

  Protection Mode: MaxAvailability

  Databases:

    MYDB_PRIMARY - Primary database

    MYDB_STANDBY - Physical standby database (disabled)

Fast-Start Failover: DISABLED

OR

DGMGRL> edit database MYDB_STANDBY . . .

Error: ORA-16548: database not enabled

and the . . .

DGMGRL> enable database MYDB_STANDBY;

Enabled.

. . . does not work. Despite showing "Enabled." the DB is not really enabled.

The DataGuard Log file drc<SID>.log(cd /u00/app/oracle/diag/rdbms/mydb_primary/mydb/trace
or - withTrivadis Baseenv:  cdd; cd trace) 

shows:

. . .

ENABLE DATABASE MYDB_STANDBY

Warning, database MYDB_STANDBY that was marked for re-creation

      will be re-enabled. There may be errors or warnings

      if the database was not properly re-created. See this

      log and the alert log for more details.

Metadata Resync failed. Status = ORA-16603

. . .

POSSIBLE CAUSE

I caused the problem myself, because I've tried to solve a Data Guard problem by re-creating the configuration using a configuration name in upper case letters instead of re-using the same name as before (with lower case letters).

POSSIBLE SOLUTION

On the STANDBY DB

DGMGRL> connect sys/<Pwd>@MYDB_PRIMARY

Connected.

DGMGRL> remove configuration;

Error: ORA-16627: operation disallowed since no standby databases would remain to support protection mode

Failed.

DGMGRL> disable configuration;

Disabled.

DGMGRL> remove configuration;

Removed configuration

On the PRIMARY DB

DGMGRL> connect sys/<Pwd>@MYDB_PRIMARY

DGMGRL> enable database MYDB_STANDBY;

Enabled.

Handling "org.gradle.api.GradleException: Lint found fatal errors while assembling a release target"

If the following error occurs when building the app . . .

org.gradle.api.GradleException: Lint found fatal errors while assembling a release target.

To proceed, either fix the issues identified by lint, or modify your build script as follows:

...

android {

    lintOptions {

        checkReleaseBuilds false

        // Or, if you prefer, you can continue to check for errors in release builds,

        // but continue the build even when errors are found:

        abortOnError false

    }

}

. . .

Instead of simply adding the android block as suggested by the message, perform a manual lint check as follows

"Analyze" -> "Inspect code .."

Most of the time the problems I had, were that some translation was missing.

Solving the Problem: Former Primary DB cannot Flashback/Reinstate to Become Standby (ORA-38754)

The following error is listed in the DB alert log file:

2018-08-10T14:26:35.511435+02:00

FLASHBACK DATABASE TO SCN 3991690

ORA-38754 signalled during: FLASHBACK DATABASE TO SCN 3991690...

Look at the DataGuard log file

${ORACLE_BASE}/diag/rdbms/<DB_UNIQUE_NAME>/${ORACLE_SID}/trace/drc${ORACLE_SID}.log

(If you are using Trivadis' BaseEnv: cdd; cd trace; view drc${ORACLE_SID}.log)

. . .

Flashback SCN is 3991690; DB checkpoint SCN is 3991507. Flashback to SCN 3991690.

SQL Execution error=604, sql=[FLASHBACK DATABASE TO SCN 3991690]. See error stack below.

  ORA-00604: error occurred at recursive SQL level 1

  ORA-38754: FLASHBACK DATABASE not started; required redo log is not available

  ORA-38762: redo logs needed for SCN 3988974 to SCN 3991690

  ORA-38761: redo log sequence 817 in thread 1, incarnation 1 could

viability check: standby database is not viable

Unable to flashback old primary database to SCN 3991690, error = ORA-38761

Reinstatement is not possible if there are insufficient flashback logs

This database may need be to be re-created from a copy

 of the new primary database if the flashback issue cannot be resolved.

. . .

"Logon" with RMAN . . .

rman target / catalog /@<TNS-Alias to RMAN-Catalog>

. . . and restore the archive logs

RUN {

  ALLOCATE CHANNEL ch1 TYPE 'sbt_tape' PARMS="SBT_LIBRARY=/opt/hds/Base/libobk.so";

  # ALLOCATE CHANNEL ch1 TYPE disk;

  RESTORE ARCHIVELOG SCN BETWEEN 3988974 AND 3991690;

}

The DB should automatically detect the restored archive logs and be able to flashback/reinstate becoming the new standby DB.