Quick solution for ORA-01665: control file is not a standby control file

Hi.

From time to time when I’m creating standby databases manually, I’m facing next annoying message when starting managed recovery of standby database:

ORA-01665: control file is not a standby control file

It means that I have restored not standby control file

To cope with this situation I have to CREATE STANDBY CONTROLFILE on primary, copy it to standby, then restore it(better read full store here), depending on disk configuration rename data, log-files…, but… I’m quite lazy… and prefer quick solutions if they are present.

So, the quick solution for ORA-01665 will be:

ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Lets see the small example:

SQL> STARTUP MOUNT

ORACLE instance started.


Database mounted.

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ERROR at line 1:
ORA-01665: control file is not a standby control file

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE
—————-
PRIMARY

SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

Database altered.

SQL> STARTUP MOUNT

ORACLE instance started.


Database mounted.

SQL> SELECT database_role FROM v$database;

DATABASE_ROLE
—————-
PHYSICAL STANDBY

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

Database altered.

So, now I have control file for Physical Standby database and I’m able to start Managed Recovery and I think that it is much easyer/quicker than using standart procedure or making new standby controlfile on primary, copying it to standby host, restoring, etc.

 

Oleksandr

Advertisements

22 thoughts on “Quick solution for ORA-01665: control file is not a standby control file

  1. Pingback: ORA-38870: cannot backup a control file that may have incorrect data file structure. « Oleksandr Denysenko's Blog

  2. Thanks so much! Excellent Topic I was facing the same problem…
    It has save me lot of time

  3. Hi,

    I am able to bring up my standby database but the archived log sequence differs with primary database and new logs are not applying to stand by.
    Please suggest.

    standby database:
    SEQUENCE# TO_CHAR(FIRST_TIME,’DD-MON- TO_CHAR(NEXT_TIME,’DD-MON-Y APPLIED
    ———- ————————— ————————— ———
    1 08-APR-14 03:30:51 08-APR-14 03:50:40 NO
    2 08-APR-14 03:50:40 08-APR-14 03:50:42 NO
    3 08-APR-14 03:50:42 08-APR-14 03:51:59 NO
    4 08-APR-14 03:51:59 08-APR-14 03:55:34 NO
    5 08-APR-14 03:55:34 08-APR-14 03:55:36 NO
    6 08-APR-14 03:55:36 08-APR-14 04:14:56 NO
    37 08-APR-14 12:53:59 08-APR-14 03:30:42 NO

    7 rows selected.

    Note: I used failover method and then tried your solution for ORA-01665 error to bring up the primary database as standby database;

    • Hi.

      The main reason is because of mentioned workaround will not work for failovered environment.
      Actually, it will work, but not for your goals
      when you do failover(activate) – you receive new branch from old standby database
      and they are no more compatible to redo stream with old primary db – just two DIFFERENT databases.
      You have to reinstantiate new standby database,
      by doing flashback(if one was enabled) database to activation SCN
      or recreating standby from new primary.

      Oleksandr Denysenko

  4. it don’t work

    Standby database ID mismatch

    ARC3: Archivelog destination LOG_ARCHIVE_DEST_2 disabled: standby database identifier mismatch

    • It works!
      You have another problem – just read documentation for addtitional info:

      Error: ORA-16012 (ORA-16012)
      Text: Archive log standby database identifier mismatch
      —————————————————————————
      Cause: The database identifiers of the Primary and Standby database do
      not match. Remote archival of redo log files is not allowed to
      incompatible STANDBY database instances.
      Action: Take the necessary steps to create the required compatible
      STANDBY database before retrying the ARCHIVE LOG processing.

  5. Thank you very much for the last piece of the puzzle, I have been able to apply it and it works. Very grateful

  6. Very useful command, if you aware what you are doing.
    Always wanted to check if “CREATE STANDBY CONTROLFILE” does cleaning up of unnecessary sections, so:
    –on the source
    SQL> select name from v$archived_log;
    NAME
    ——————————————————————————–
    /home/rus/mintest/fra/MINTEST/archivelog/2017_08_31/o1_mf_1_152_dtjvo66o_.arc
    SQL> ALTER DATABASE CREATE STANDBY CONTROLFILE AS ‘/tmp/cf1’;
    Database altered.

    –on the target
    SQL> startup mount
    SQL> select name from v$archived_log;
    no rows selected
    SQL> sho parameter control_files
    NAME TYPE VALUE
    ———————————— ———– ——————————
    control_files string /tmp/cf1

    Anyway it’s all pretty much the same, but Oracle creates documentation with a reason, sometimes not so obvious.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s