Re: Datafiles 32 & 64 compatibility

Steve Howard wrote:
> joel garry wrote:
> > Steve Howard wrote:
> > > Actually, they are, depending on the processor endian type. If the
> > > Oracle version is the same, and the processor endian is the same, all
> > > you must do is run the utlirp.sql script to invalidate and recompile
> > > all packages (converts internal format from 32 to 64 bit). We did this
> > > a couple of years ago when we are on 9.2.0.6.
> > >
> >
> > So are you lucky or smart?
> >
> > It works because most of the data is in oracle's own format: number,
> > date, varchar2, rownum. But have you completely tested everything? I
> > don't think you can. The types of things that would blow up are
> > numeric format, if anything uses that, you are potentially toast. What
> > happens is that some commercial packages wrap numeric data into Oracle
> > datatypes. When that stuff gets pulled out of the db and into a
>
> It's still running today. Oracle supports it, as long as the Oracle
> version is the same and the endian of the processor is the same. We
> did the migration by taking a split mirror of the 32 bit database,
> opening it on the other host with 64 bit software, recovering it with
> the 64 bit software, opening it, and running the utlirp.sql script.
> While testing for the migration, we received several ORA-600's before
> we ran that script. After we ran it, we have been in production ever
> since.
>
> See...
>
> http://download-east.oracle.com/docs/cd/B10501_01/server.920/a96530/migaftrm.htm#1009682
>
> We also opened an SR with Oracle at the time to confirm the above was
> true, and they confirmed there were no issues as long as the criteria
> mentioned above held true.
>

Ah yes, startup migrate. Forgot all about that for the word-size change thing. Thanks!
(I always wound up importing because of other things, like DMT or general reorganizing for new hardware).

jg

-- 
@home.com is bogus.
http://emptybottle.org/bullshit/