Re: Changing DBID
Date: Tue, 15 Jul 2008 16:15:27 -0700 (PDT)
Message-ID: <73fe768b-1b0b-4ca8-97e7-6fb3eb837d90@r66g2000hsg.googlegroups.com>
On Jul 15, 9:36 pm, Chuck <chuckh1958_nos..._at_gmail.com> wrote:
> Charles Hooper wrote:
> > On Jul 14, 1:13 pm, joel garry <joel-ga..._at_home.com> wrote:
> >> Charles' post is the only one he has made that I've seen, where my
> >> reaction was "Egad! Don't tell people to do that!" Different
> >> experiences make different fears, I guess. I've seen bigtime screwups
> >> when people start getting cute with misdirecting tnsnames entries.
> >> I've seen even bigger screwups where they can't get it right in the
> >> first place. I've even been feeling a little guilty the past few days
> >> because I have an update I wrote where I named the script based on the
> >> particular location it is updating, and then added another location to
> >> it (kind of the downside of "if you want to get something done fast,
> >> give it to a busy person").
>
> >> jg
> >> --
>
> > Joel,
>
> > Based on your response, and the others that appeared after my post in
> > this thread, I may have misunderstood what the OP is attempting to
> > accomplish. I assumed the following:
> > Server 1 (running production)
> > Client 1 (running production)
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Server 2 (running some sort of a copy of the production database)
> > Client 2 (used for connecting to the copy of the production database
> > only)
>
> > Testing was needing to be performed by Client 2 against Server 2
> > without modifying the scripts or programs used by Client 1 against
> > Server 1. There is a potential for problems with the above, just as
> > there would be with someone accidentally forgetting to change from the
> > default production connection string to the non-default test
> > connection string before dropping a couple tables. The above change
> > limits the chances of someone asking - "oh, was I supposed to specify
> > a different database name" an hour after a conversion script starts
> > taking the "test" database from version X to version Y.
>
> > Joel, I trust your experience. As you find the approach that I
> > suggested in this thread dangerous, I suggest that it be considered
> > that way, and not implemented. Thanks for raising the red flag.
>
> > Charles Hooper
> > IT Manager/Oracle DBA
> > K&M Machine-Fabricating, Inc.
>
> Actually my original question is much simpler. Is it possible to change
> a dbid and specify the new dbid rather than have nid pick one for you?
>
> I'm gathering that there's no way to do it.
I'm not an expert but I think that isn't possible to specify a new
dbid.
I don't read all the posts but if you want to remain with the same
dbid, you can manually clone the database, instead of using rman
duplicate command.
Metalink notes :
Note:360962.1 - Manual Completion of a Failed RMAN Duplicate
Note:562556.1 - How to Manually Clone a Database to Another Node
Dany Received on Tue Jul 15 2008 - 18:15:27 CDT