My Oracle Support Banner

How to Migrate Oracle 10.2 32bit to 10.2 64bit on Microsoft Windows (Doc ID 403522.1)

Last updated on FEBRUARY 22, 2019

Applies to:

Oracle Database - Enterprise Edition - Version to [Release 10.2]
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Microsoft Windows x64 (64-bit)
z*OBSOLETE: Microsoft Windows Server 2003
Microsoft Windows 2000Microsoft Windows Server 2003Microsoft Windows Server 2003 (64-bit AMD64 and Intel EM64T)


How to Migrate Oracle 10.2 32bit to Oracle 10.2 64bit on Microsoft Windows. 

These are the steps used to successfully migrate Oracle 32bit on Windows 2000, to Oracle 64bit on Windows 2003 (64bit):

NOTE: It does not matter what patchset level you are currently at (ie.,,, or

These instructions will work for all Oracle 10.2.0.x versions. You must make sure that you migrate to the same level or higher (eg. to This example uses the patchset on the 64bit machine.

Install Oracle 32bit on Windows 2000 (32bit).
Create a default Database (ORCL).
Verify there are NO invalid objects.
Verify all components in the DBA_REGISTRY are Valid.

NOTE: It is EXTREMELY important to make sure there are NO Invalid objects in the Database, prior to the migration.

Install Oracle 64bit, on Windows 2003 64bit (either AMD64 or EM64T processors).
You do NOT need to install a new Database, since you will be migrating an existing Database.

NOTE: If you wish to apply a patchset, you can do that now. For this test, the patchset was applied to the 64bit installation.

The same directory structure was used for both machines.

Copy the Database files from the 32bit machine, to the 64bit machine.
(Datafiles, Logfiles, Controlfiles, init.ora, tnsnames.ora, listener.ora, etc..)

NOTE: If a different directory structure will be used, then you will need to recreate the controlfiles, before starting the migration process.

Create the Oracle service on the 64bit system, using the ORADIM command.
(eg., oradim –new –sid orcl –startmode auto –pfile <full path\init.ora> )

Run Sqlplus
Issue the command: startup upgrade.

Run the script:
(This script invalidates all the objects. This is needed in order to change the word size.)

(NOTE:  You can also run the \utlirp.sql script.  This script will invalidate and recompile the objects.  For this particular test, the utlip.sql was used to invalidate the objects.  Recompiling the objects is done later in the Note).

Handling for JVM during Migration
When migrating a database from 32 to 64bit (or vice versa) additional actions
are required for java.  In theory the format of java shared data objects (SRO)
is not compatible between 32 and 64 bit and so these objects need to be dropped
and regenerated.  In practice it may be the case prior to release 11 such
objects could interoperate but if so this would only be by chance and should
not be relied on.

The steps to do the regeneration are as follows.  These should be done
immediately after running utlirp.  They may take several minutes to complete.
They must be done connected as SYS.

  update obj$ set status=5 where obj#=(select obj# from obj$,javasnm$ 
    where owner#=0 and type#=29 and short(+)=name and 
    cursor C1 is select
       'DROP JAVA DATA "' || || '"."' || || '"'
       from obj$ o,user$ u where o.type#=56 and u.user#=o.owner#;
    ddl_statement varchar2(200);
    iterations number;
    previous_iterations number;
    loop_count number;
    my_err     number;
    previous_iterations := 10000000;
      -- To make sure we eventually stop, pick a max number of iterations
      select count(*) into iterations from obj$ where type#=56;
      exit when iterations=0 or iterations >= previous_iterations;
      previous_iterations := iterations;
      loop_count := 0;
      open C1;
          fetch C1 into ddl_statement;
          exit when C1%NOTFOUND or loop_count > iterations;
        exception when others then
           my_err := sqlcode;
           if my_err = -1555 then -- snapshot too old, re-execute fetch query
           end if;
        loop_count := loop_count + 1;
      end loop;
      close C1;
    end loop;
  initjvmaux.drp('delete from java$policy$shared$table');
  update obj$ set status=1 where obj#=(select obj# from obj$,javasnm$ 
    where owner#=0 and type#=29 and short(+)=name and 

create or replace java system

Then run the CATUPGRD.SQL script.
NOTE: If you are migrating to the same version (ie., 32bit to 64bit), then you
do not need to run the catupgrd.sql script. This should only be run if you are going to a newer patchset
version (ie., 32bit to 64bit, or 64bit).
If you do run the catupgrd.sql script going to the same version, you could end up with the errors:
ORA-20000: Upgrade re-run not supported from version
ORA-06512: at "SYS.VERSION_SCRIPT", line 45
This finished with some invalid objects, and some of the components were still marked as invalid (in the dba_registry).

Run the UTLRP.SQL script.
This recompiled all the invalid objects.

NOTE: If you have the OLAP option installed, you should review the following Notes:

<Note 386990.1> DB CONVERSION: 32 bit -->64 Bit Broke OLAP OPTION
<Note 352306.1> Upgrading OLAP from 32 to 64 bits

When this was all done, there should be 0 (zero) invalid objects.
Also, ALL of the Components in DBA_REGISTRY should be valid.

Questions and Answers

To view full details, sign in with your My Oracle Support account.

Don't have a My Oracle Support account? Click to get started!

In this Document
Questions and Answers

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.