Why is important to write down the DBID in Oracle DB

oraclerestorerman

I've always heard that one of the first things you should do in Oracle DB is to write down the DBID, so in case you lost the controlfile you'll need to set it in RMAN, and then you will be able to restore from autobackup. (Just like documentation said)

RMAN> SET DBID 320066378;
RMAN> RUN {
    SET CONTROLFILE AUTOBACKUP FORMAT 
          FOR DEVICE TYPE DISK TO 'autobackup_format';
    RESTORE CONTROLFILE FROM AUTOBACKUP;
    }

But then I've realized that some weeks ago, when we had to do an emergency DB restore in a different server at work, I didn't use the DBID at all. Even more, I've realized that I've never use the DBID.

All our backups are controlfile based, with CONTROLFILE AUTOBACKUP ON, and we do not use the "Flash/Fast Recovery Area" for them.
When I restore a controlfile I do it with RESTORE CONTROLFILE FROM '/file/name';, whitout setting up any DBID.

Here is a simple example where I add a datafile, move controlfiles physically, truncate a table and insert a row, commit it, shutdown abort, restore controlfile from the last autobackup, recover db and open:

[oracle@localhost rman]$ sqlplus '/as sysdba'

SQL*Plus: Release 11.2.0.1.0 Production on Mié Nov 27 11:39:03 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select file_name from dba_data_files where tablespace_name = 'TS_PRUEBA';

FILE_NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/data/ts_prueba.dbf

SQL> alter tablespace ts_prueba add datafile '/u01/app/oracle/oradata/data/ts_prueba02.dbf' size 10M;

Tablespace altered.

SQL> show parameter control_files;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /u01/app/oracle/oradata/system
                                                 /control01.ctl, /u01/app/oracl
                                                 e/oradata/system/control02.ctl
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@localhost rman]$ mv /u01/app/oracle/oradata/system/control01.ctl /u01/app/oracle/oradata/system/control01.ctl.dead
[oracle@localhost rman]$ mv /u01/app/oracle/oradata/system/control02.ctl /u01/app/oracle/oradata/system/control02.ctl.dead
[oracle@localhost rman]$ sqlplus '/as sysdba'

SQL*Plus: Release 11.2.0.1.0 Production on Mié Nov 27 11:51:24 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> truncate table prueba.test;

Table truncated.

SQL>  insert into prueba.test values (1,'Helo world');

1 row created.

SQL> commit;

Commit complete.

SQL> shutdown abort;
ORACLE instance shut down.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@localhost rman]$ pwd
/mnt/rman
[oracle@localhost rman]$ ls -lthar
total 366M
drwxr-xr-x 5 root   root     4.0K Apr 15  2013 ..
-rw-r----- 1 oracle oinstall 9.7M Nov 27 11:27 c-1340618388-20131127-00
drwxr-xr-x 5 oracle oinstall 4.0K Nov 27 11:31 .
-rw-r----- 1 oracle oinstall 9.7M Nov 27 11:31 c-1340618388-20131127-01
[oracle@localhost rman]$ rman target /

Recovery Manager: Release 11.2.0.1.0 - Production on Mié Nov 27 11:57:01 2013

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database (not started)

RMAN> startup nomount;

Oracle instance started

Total System Global Area     418484224 bytes

Fixed Size                     1336932 bytes
Variable Size                314575260 bytes
Database Buffers              96468992 bytes
Redo Buffers                   6103040 bytes

RMAN> restore controlfile from '/mnt/rman/c-1340618388-20131127-01';

Starting restore at 27-NOV-2013 11:57:33
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK

channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/system/control01.ctl
output file name=/u01/app/oracle/oradata/system/control02.ctl
Finished restore at 27-NOV-2013 11:57:35

RMAN> alter database mount;

database mounted
released channel: ORA_DISK_1

RMAN> recover database;

Starting recover at 27-NOV-2013 11:57:55
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK

starting media recovery

archived log for thread 1 with sequence 1 is already on disk as file /home/oracle/redolog/redo01b.log
archived log file name=/home/oracle/redolog/redo01b.log thread=1 sequence=1
creating datafile file number=6 name=/u01/app/oracle/oradata/data/ts_prueba02.dbf
archived log file name=/home/oracle/redolog/redo01b.log thread=1 sequence=1
media recovery complete, elapsed time: 00:00:02
Finished recover at 27-NOV-2013 11:57:58

RMAN> alter database open resetlogs;

database opened

RMAN> exit


Recovery Manager complete.
[oracle@localhost rman]$ sqlplus '/as sysdba'

SQL*Plus: Release 11.2.0.1.0 Production on Mié Nov 27 11:58:21 2013

Copyright (c) 1982, 2009, Oracle.  All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select file_name from dba_data_files where tablespace_name ='TS_PRUEBA';

FILE_NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/data/ts_prueba.dbf
/u01/app/oracle/oradata/data/ts_prueba02.dbf

SQL> select * from prueba.test;

    NUMERO FRASE
---------- --------------------------------------------------
         1 Helo world

If this is right, In what cases I need the DBID then?

Regards

Best Answer

If you use global RMAN catalog and some backup SW like TSM or NetBackup. Then DBID is the unique database identifier. This is needed especially to cross-site (DR) restores.

If each database uses it's own disk backup directory then importance of DBID is not so visible.

PS: it is also handy to keep output of REPORT SCHEMA rman command. This will tell you expected sizes of the datafiles after restore. And also their locations. This will help you to prepare storage for database when being cloned.