Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Moving to new Server and upgrading Oracle

Re: Moving to new Server and upgrading Oracle

From: Bob Fazio <rfazio_at_home.com.nospam>
Date: 2000/06/22
Message-ID: <ivg45.14492$A%3.167259@news1.rdc2.pa.home.com>#1/1

They are most likely trying to minimize the number of variable in what may go wrong. You do the same types of things when tuning. You only change one or two things at a time to verify what has a positive or a negative effect.

Moving to a new server, can cause problems. If they do all the changes at once, it makes it harder to determine what is actually broke.

Move over to new server, same DB. If it works then the files and config are ok. If not (the new server is the problem) Move datafiles. If still ok continue. if not (the move was the issue) upgrade. If still ok, then continue. If not (the upgrade failed). roll forward. If still ok, then done. If not (roll forward is the problem).

vs.

Do all, and it doesn't work. The question is what went wrong and where?

I have to admit though that I will be surprised if all this does work as expected. The reason is that things that can cause issues are addition of datafiles in between the copy, and the rollforward. Are the files binary compatible?

--
Robert Fazio, Oracle DBA
rfazio_at_home.com
remove nospam from reply address
http://24.8.218.197/
"A" <A_at_yahoo.com> wrote in message news:39500005.E6425D9A_at_yahoo.com...

> Yes, I agree with that aspect of it,
> but why even test an 8.0.5 environment in an old disk configuration
setting
> when you are moving to 8.0.6 with a new disk configuration?
>
> Bob Fazio wrote:
>
> > It's really not bizarre at all.
> >
> > They are doing it to minimize down time on the production server.
> >
> > --
> > Robert Fazio, Oracle DBA
> > rfazio_at_home.com
> > remove nospam from reply address
> > http://24.8.218.197/
> > "A" <A_at_yahoo.com> wrote in message news:394FF92E.AC42A5F9_at_yahoo.com...
> > > Well, just got a high level explanation of their plan to migrate our
databases.
> > >
> > > This involves:
> > >
> > > 1. Copy the 8.0.5.2 Oracle binaries over.
> > > 2. Move the datafiles over (with the identical data structure that we
have
> > > on our E4500's even tho it's changing to an OFA compliant structure
with a
> > > recommended 14 Luns vs. 5 Luns current). Recover the database.
> > > 3. Test the current configuration environment of the 8.0.5.2 software
.
> > > 4. Change the Lun configuration on the new E10K's to reflect the new
> > > environment wanted. Move the datafiles to their new location.
> > > 5. Update the Oracle control files to reflect the new data structure
> > > environment
> > > 6. Upgrade the Oracle software to 8.0.6
> > > 7. Bring over the archive logs from the running instance on the old
server,
> > > and roll forward.
> > > 8. Test the new environment.
> > >
> > > Am I missing something here, or is this the most bizarre plan I have
ever heard
> > > of.
> > >
> > >
>
Received on Thu Jun 22 2000 - 00:00:00 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US