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...?
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 unacceptable.
- 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 http://www.ora-600.net
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 manually?
Running nid on the standby just creates a different DBID from the primary.