A DBID is Oracle’s internal identifier for a database. RMAN uses it to distinguish databases, so a physical clone that retains the source DBID can conflict with the source in the same recovery catalog.
Oracle 9i Release 2 and later
Oracle 9i Release 2 introduced the supported DBNEWID utility. Use nid rather than manually editing datafile headers or recreating control files solely to force a new DBID.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
$ nid TARGET=/After a successful DBID change, open with RESETLOGS, update the recovery catalog, and take a new full backup. Backups and archived logs associated with the old DBID do not belong to the new database incarnation.
Oracle 8i is a historical exception
Oracle 8i predates DBNEWID. Old support notes described an internal DBMS_BACKUP_RESTORE.zeroDbid procedure followed by control-file recreation. That procedure is undocumented application-facing functionality and can render a database unusable. It should not be presented as a routine DBA recipe.
Safer choices for an 8i database
- Keep the clone isolated from the source’s RMAN repository when a DBID change is unnecessary.
- Use a logical export/import into a separately created database when feasible.
- Plan an upgrade to a supported Oracle release and use supported cloning and DBNEWID procedures.
- If business constraints require an 8i header-level change, work from a disposable clone with a verified cold backup and follow an Oracle Support procedure for the exact patch level.
Pre-change checklist
- Confirm why a different DBID is required.
- Record the current
DBID,DBNAME, database version, and recovery-catalog registration. - Verify a complete recoverable backup and a tested rollback path.
- Perform the work only during an approved outage.
- Take a new baseline backup after the change.
Reference
Oracle’s DBNEWID guide explains the supported utility and the consequences of changing a DBID.
Leave a Reply