This article is about the steps which require recovery when we retrieve the DATABASE IDENTIFIER dumping it from datafiles or online and archived redo logs . DBID stands for database identifier, which is a unique identifier for each Oracle database running. It is found in control files as well as datafile header. If the database is open you can directly be querying the v$database and find the DBID.

These are some conditions when do we require DBID for database recovery

The set dbid command is useful for restoring the control file when each of these conditions is met:

  •     The control file has been lost and must be restored from a backup.
  •     You are using a recovery catalog.
  •     Multiple databases registered in the recovery catalog share a database name.
  •     You receive the “RMAN-20005: target database name is ambiguous” message when you attempt to restore the control file.
  •     you don’t have even a flash recovery area configured OR you have it but you didn’t specify the %F in the RMAN autobackup option;

I think it’s very difficult today to be in a situation where it’s required to know your database identifier to recover the database.
But according to an OP (original poster), it seems it could happen: indeed on that Oracle forum’s thread it was asked how it could be possible to determine a database identifier (DBID) when:

  1. an instance is already crashed and no control files are available
  2. No one saved the RMAN output of daily backup
  3. You are using a flash recovery area and your autobackup are saved using OMF syntax.

So if your instance is down and control files are unavailable you cannot open the database and query the V$DATABASE to know the DBID.
I mean you can’t execute a query like this:

Then when you connect to your instance using RMAN it will show you the database identifier

…but as long as you didn’t redirect RMAN output to some logs and preserved them in a safe directory or simply email it to you during daily backup, when instance is down and without control files RMAN could not help you anymore:

Moreover, if you didn’t specify the %F format to your autobackup control file option, I mean something like:

…your database will save it using the OMF format. As you can read on the Oracle documentation at this link
“All files in the fast recovery area are maintained by Oracle Database and associated file names are maintained in the Oracle Managed Files (OMF) format” indeed your autobackup control file won’t be useful to deduct your DBID using the desired format c-IIIIIIIIII-YYYYMMDD-QQ (where IIIIIIIIII would be your database identifier).

So then how can you proceed? Is it no more possible to know the database identifier?

My suggestion was to simply use the “ALTER SYSTEM DUMP” command.
As long as you can dump any datafiles, redo logs and even archived redo logs the instance could be in NOMOUNT mode: to obtain the desired DBID you have only to know the exact path of your file.

Have a look at the following samples:

Command to dump the SYSTEM datafile:

Under the trace directory I found a new trace file which content is not so clear, but at least our database identifier (Db ID=1229390655) is showed.

Command to dump the UNDO datafile:

Again on the same trace file Oracle appends the dump of the UNDO datafile requested and the same DBID.

What about to dump an online redo log?

Always on the same trace file you can find the DBID.

Finally even dumping an ARCHIVED redo log…

… and looking at the trace file, the DBID is showed again.

You have no excuse to be not able retrieving a specific database identifier.

Once the update is done, Follow the same process of upgrading agents.

Thank you for giving your valuable time to read the above information.


For More Detail , You can join us follow:

LinkedIn Group: Oracle Cloud DBAAS

Facebook Page: OracleHelp

About The Author

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.