Re: Recovery through new DBID?

  • From: Jeremiah Wilton <jeremiah@xxxxxxxxxxx>
  • To: Mark Bole <makbo@xxxxxxxxxxx>
  • Date: Mon, 5 Sep 2005 08:30:44 -0700 (PDT)

On Mon, 5 Sep 2005, Mark Bole wrote:

why on earth would someone change the DBID of a primary (along with
the subesquent required RESETLOGS) in the first place, and then, why
would they not simply re-create the physical standby or perform a
full backup...?

Hi Mark,

I'm asking for exactly the reasons you cite.  The documented way
requires a lot of work that would be unnecessary if you could specify
the new DBID in nid.

- If there is no easy way to recover through new DBID, then you are in
an unrecoverable state until a new full backup is completed.  Any
catastrophic failure that occurs between DBNEWID and completion of the
backup is not recoverable.  For some organizationss, this would be

- Some organizations have very large databases and very slow
connections between their primary and standby.  It can be very onerous
to re-create a standby.  It seems like an omission on Oracle's part
not to have provided for specifying the new DBID in nid.  It kind of
seems like being back in the same boat as when Oracle did not support
recovery through resetlogs.  Every time we reset logs, the DBA would
be in nail-biting mode until a full backup was completed, and the
standby would have to be refreshed.

Jeremiah Wilton
ORA-600 Consulting
Emergencies - Seminars - Hiring

Jeremiah Wilton wrote:
I am aware of ways to recover a database through resetlogs.  What if a
large standby (or any recovery) must be recovered through the
resetting of the primary's DBID, either using the DBNEWID (nid)
utility, or other means?  Can anyone think of a way to make the
standby take on the correct DBID, short of patching datafile headers

Running nid on the standby just creates a different DBID from the

Other related posts: