RMAN-06495: must explicitly specify DBID with SET DBID command

Your backup strategy doesn’t take advantage of either a flash recovery area or a recovery catalog.
You are trying to restore a control file as follows, and you receive an error message stating
that you must explicitly set the database identifier (DBID):

RMAN> connect target /
RMAN> startup nomount;
RMAN> restore controlfile from autobackup;


Error : RMAN-06495: must explicitly specify DBID with SET DBID command


You don’t know the DBID for your database, and you aren’t sure how to find the DBID.
Without a control file for your database, you can’t mount the database and query the DBID
value from the V$DATABASE view.

Solution

RMAN> connect target /
RMAN> startup nomount;
RMAN> set dbid 2601506593;

RMAN> restore controlfile from autobackup;

You can determine the DBID of your database in one of the following ways:

• You can derive the DBID from an autobackup file.
• You can retrieve the DBID from RMAN output.
• You can write the DBID to the alert.log file.
• You can derive DBID from a file dump.

Description of %F Format Variable
------------------------------------------------

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F';

c-IIIIIIIIII-YYYYMMDD-QQ

Retrieving the DBID from RMAN Output

RMAN> connect target /
connected to target database: BRDSTN(DBID=2601506593)

Writing the DBID to the Alert.log File

Another way of recording the DBID is to make sure that it is written to the alert.log file on a
regular basis using the DBMS_SYSTEM package. For example, you could have this SQL code
execute as part of your backup job:

COL dbid NEW_VALUE hold_dbid
SELECT dbid FROM v$database;
exec dbms_system.ksdwrt(2,'DBID: '||TO_CHAR(&hold_dbid));

After running the previous code, you should see a text message in your target database
alert.log file that looks like this:
DBID: 2601506593

The KSDWRT procedure writes a text message to your database alert.log file. In this case,
the hold_dbid SQL variable is populated with the DBID. If you write your target database DBID
to the alert.log file on a regular basis, you should be able to identify it easily should the need
arise.

Dumping Files

If any of the datafiles, online redo log files, or archived redo log files are physically available,
you can use the SQL alter system dump statement to write the DBID to a trace file. Your database
does not have to be mounted for this to work. For example, here is the syntax for taking a
datafile dump:

SQL> connect / as sysdba
SQL> startup nomount;
SQL> alter system dump datafile '/<PATH>/system01.dbf' block min 1 block max 10;

Use this syntax to take a dump of an archived redo log file or online redo log file:

SQL> alter system dump logfile '<log file name>';
The trace file with the DBID will be in your user dump destination. If you search for the
string “Db ID,” you should find something similar to this output:
Db ID=2601506593=0x9b0fd721, Db Name='BRDSTN'

Every Oracle database has an internal unique DBID that can be queried from V$DATABASE
as follows:

SQL> select dbid from v$database;
DBID
------------------------------
2601506593