Re: 8.1.7.4 upgrade - 10g or 11
- From: Robyn <robyn.sands@xxxxxxxxx>
- To: jkstill@xxxxxxxxx
- Date: Wed, 16 Apr 2008 17:44:55 -0400
We ran into multiple bugs with upgrades to 10.2.0.2 and 10.2.0.3, but they
were related to a prior conversion from 32 bit to 64 bit at version 8.0.6.
Are non-converted databases subject to similar issues?
In our case, we were able to get through the upgrade with multiple patches
and workarounds with two major caveats:
1. If upgrade had been started without all of the patches and workarounds
applied to the new executables, the upgrade would have to be restarted from
the beginning - i.e. apply more patches and restore the database from backup
kind of start over, not just restart the upgrade script start over.
2. Subsequent upgrades and patch sets continued to be affected by similar
bugs.
In the end, we created new instances and migrated the data to avoid dealing
with the issue on future upgrades. (Since SAP moves the data to a shadow
instance for the application of the upgrade, new instances were a byproduct
of the process for a few databases.) I've got a fair amount of information I
can share on upgrading previously converted databases if that is indeed the
issue under discussion. However, if the instance was created at 64 bit, I
don't think these same bugs are a concern.
Robyn
On Wed, Apr 16, 2008 at 1:38 PM, Jared Still <jkstill@xxxxxxxxx> wrote:
> On Wed, Apr 9, 2008 at 10:27 AM, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx>
> wrote:
>
> >
> > I'd recommend you create a new database and migrate via exp/imp rather
> > than doing an in-place upgrade. There is at least one nasty bug with
> > upgrades to 10.2.0.3 and last time I checked the only solution was to
> > use exp/imp or just stay on 10.2.0.2 instead, although it may be fixed
> > in 10.2.0.4 now.
> >
> >
> I'll go along with that.
>
> We have SAP databases that we are migrating from 9i to 10g.
>
> We've run into some rather nasty bugs for which there is no fix in
> 10.2.0.2
> We were waiting for a backport of the bug fix from 10.2.0.3, but we are
> now going to exp/imp the data into a new database.
> (SAP is not certified for 10.2.0.3, and never will be 10.2.0.4 not yet
> available
> for SAP)
>
> These particular SAP databases were migrated from 8i to 9i previously.
> This just complicates problems.
>
> SAP support has documented that databases migrated from 8i to 10g are
> fraught with problems.
>
> If at all possible, consider building a new database.
>
> We are going to use the SAP utilities for this (forget the name) which are
> more
> like unload/load via SQL Loader than exp/imp.
>
> An 800 gig database would take a very long time to export and import with
> exp/imp.
>
> On other thing to note: if you have created any views in the sys schema on
> X$ tables,
> drop them before the migration.
>
> Here's what can happen:
>
> View created on x$ table in 8i database
> migrate db to 9i
> some x$ tables no longer exist on the newly migrated db
> the views on the now defunct $x tables remain
> attempts to drop the views will result in ORA-600 [16206]
> all attempts to drop the view will fail.
>
> Not fatal, but rather annoying.
>
> --
> Jared Still
> Certifiable Oracle DBA and Part Time Perl Evangelist
>
--
I may not have gone where I intended to go, but I think I have ended up
where I needed to be.
Douglas Adams
Other related posts:
