Re: Moving to new Server and upgrading Oracle

One other thing I just found out about, that solidifies the export/import method even further, is that we are moving from Solaris 2.7 to Solaris 2.6, since Sun Clustering isn't supported on 2.7.
From what I have read, moving datafiles from one OS version to another is not supported by Oracle.
Anyone heard differently?

Bob Fazio wrote:

> 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 Mon Jun 26 2000 - 00:00:00 CDT