How to change Oracle wordsize from 32-bit to 64-bit

Another test case scenario (in addition to one described here) for Oracle Word size change, from 32-bit to 64-bit.

We want source database (32-bit Oracle 10.2.0.2, Windows 2003 SP1, 32-bit) to convert to target database
(64-bit Oracle 10.2.0.3 + Patch 12, Windows 2003 SP2, x64). Basically we’re changing the word size of the database and patching the database at the same time. This scenario was tested in test environment and will be used shortly on one of our production database.

We already installed 64-bit Oracle Software (10.2.0.3 + Patch 12) on our new machine and made necessary configuration of the storage, directories, spfile, password file etc. We also copied all database/ctl files from production server to the new, x64 machine (after shutdown normal).

You must be aware of the following:

  • it’s important that target (64-bit) Oracle10g is of the proper release (minimum 10.2.0.3 + Patch 5, in our case is Patch 12, otherwise known as CPUOCT2007) or you might hit ORA-600 error that I wrote about.
  • make sure SQLNET.ORA is present on target database and that contains NAMES.DIRECTORY_PATH= (TNSNAMES), or you might hit another bug.
  • don’t even think of using Oracle on Windows 2003 with SP1 and large amount of memory! Read this before you decide what to do.
  • make sure you read Metalink Note:62290.1 “Changing between 32-bit and 64-bit Word Sizes”
  • read and understand patchset readme (10.2.0.3) as well as readme that comes with Patch 12.
  • this test scenario is for single, non-RAC, Oracle instance

From here on the steps are:

1) create service on x64:

set ORACLE_SID=ORCL
D:\oracle\ORA10\bin\oradim.exe -new -sid ORCL -startmode manual -spfile 
D:\oracle\ORA10\bin\oradim.exe -edit -sid ORCL -startmode auto -srvcstart system 

2) start the instance in upgrade mode

I’m intentionally using pfile for the sake of simplicity of editing; after migration spfile is used)

startup upgrade pfile=D:\ORACLE\ORA10\database\initorcl.ora

3) invalidate PL/SQL packages

spool CATOUT_32_64.log
@D:\ORACLE\ORA10\RDBMS\ADMIN\UTLIRP.SQL
spool off

Check CATOUT_32_64.log.

Do not shutdown and restart the database!

4) Upgrade

SPOOL CATUPGRD.LOG
@D:\ORACLE\ORA10\RDBMS\ADMIN\CATUPGRD.SQL
SPOOL OFF

Check CATUPGRD.LOG for errors – some errors can be ignored, refer to readme that comes with Patchset 10.2.0.3.

5) Check status for the package DBMS_STANDARD

select status from dba_objects where object_name='DBMS_STANDARD'
and object_type='PACKAGE' and owner='SYS';

Recompile if package is invalid:
alter package dbms_standard compile;

6) Check the number of invalid objects for SYS and recompile if needed

select count(*) from dba_objects where owner='SYS' and status='INVALID';

@D:\ORACLE\ORA10\RDBMS\ADMIN\UTLRP.SQL

7) Check status of database components

column comp_name format a40
column version format a10
select comp_name, version, status from dba_registry;

COMP_NAME                                VERSION    STATUS
---------------------------------------- ---------- -----------
Oracle interMedia                        10.2.0.3.0 VALID
Oracle Enterprise Manager                10.2.0.3.0 VALID
Oracle XML Database                      10.2.0.3.0 VALID
Oracle Text                              10.2.0.3.0 VALID
Oracle Expression Filter                 10.2.0.3.0 VALID
Oracle Rule Manager                      10.2.0.3.0 VALID
Oracle Workspace Manager                 10.2.0.1.0 VALID
Oracle Data Mining                       10.2.0.3.0 VALID
Oracle Database Catalog Views            10.2.0.3.0 VALID
Oracle Database Packages and Types       10.2.0.3.0 VALID
JServer JAVA Virtual Machine             10.2.0.3.0 VALID
Oracle XDK                               10.2.0.3.0 VALID
Oracle Database Java Packages            10.2.0.3.0 VALID
SQL>

8) Apply CPUOCT2007

In addition of running CATUPGRD.SQL we have to run CATCPU script as well, in our case for CPUOct2007.

cd %ORACLE_HOME%\CPU\CPUOct2007
sqlplus /nolog 
CONNECT / AS SYSDBA 
@catcpu.sql
QUIT 


The script will end with report similar as:

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP CPU_END    2008-01-18 20:22:54

No. of Invalid Objects is :575
Please refer to README.html to for instructions on validating these objects

PL/SQL procedure successfully completed.

Logfile for the current catcpu.sql session is : APPLY_ORAX_18Jan2008_20_18_52.log

Check log file mentioned in catcpu.sql report - some errors can be ignored (refer to CPU readme)!

At this stage you can check dba_registry again:

SQL> column comp_name format a40
SQL> column version format a10
SQL> select comp_name, version, status from dba_registry;

COMP_NAME                                VERSION    STATUS
---------------------------------------- ---------- -----------
Oracle interMedia                        10.2.0.3.0 VALID
Oracle Enterprise Manager                10.2.0.3.0 VALID
Oracle XML Database                      10.2.0.3.0 VALID
Oracle Text                              10.2.0.3.0 VALID
Oracle Expression Filter                 10.2.0.3.0 VALID
Oracle Rule Manager                      10.2.0.3.0 VALID
Oracle Workspace Manager                 10.2.0.1.0 VALID
Oracle Data Mining                       10.2.0.3.0 VALID
Oracle Database Catalog Views            10.2.0.3.0 VALID
Oracle Database Packages and Types       10.2.0.3.0 UPGRADED
JServer JAVA Virtual Machine             10.2.0.3.0 VALID

COMP_NAME                                VERSION    STATUS
---------------------------------------- ---------- -----------
Oracle XDK                               10.2.0.3.0 VALID
Oracle Database Java Packages            10.2.0.3.0 VALID

13 rows selected.

9) Run UTLRP.SQL once again…

@D:\ORACLE\ORA10\RDBMS\ADMIN\UTLRP.SQL 

## WELCOME TO 64-bit World – END OF TEST CASE ##

Posted on 23.01.2008, in Oracle and tagged . Bookmark the permalink. 2 Comments.

  1. The day after…
    we migrated our production server in a way described above everything looks normal. (In a way I’m not that comfortable with the end result – everything was done without a hitch and in our business it usually means … to good to be true … so we ask ourselves “Did we overlook something?” In another words, it’s too early to celebrate with a cold beer ;-)

  2. Five days later…
    we hit bug that was not present in 10.2.0.2. You can read about it in this thread.