PURPOSE -------
This document is created to provide all the details for changing word
size from 32bit to 64bit. This document is a "cut/paste" of applicable
sections from the 9i Database Migration guide to quickly provide the needed
details and steps to change the word-size. This note is also applicable to
Oracle 8 and Oracle 8i.
SCOPE & APPLICATION
-------------------
CHANGING WORD-SIZE
You can change the word-size of your Oracle database server during a migration,
upgrade, or downgrade operation. A change in word-size includes the following
scenarios:
You have 32-bit Oracle software installed on 64-bit hardware and want to
change to 64-bit Oracle software.
You have 64-bit Oracle software installed on 64-bit hardware and want to
change to 32-bit Oracle software.
If you are changing word-size during a migration, upgrade, or downgrade
operation, then no additional action is required. The word-size is changed
automatically during any of these operations. However, if you want to change
the word-size within the same release, then follow the instructions in
"Changing the Word-Size of Your Current Release" below. For example, if you
have the 32-bit version of Oracle release 9.0.1 and you want to switch to the
64-bit version of Oracle release 9.0.1, then you must complete this procedure.
The following information applies if you are upgrading or downgrading your
hardware from 32-bit to 64-bit or from 64-bit to 32-bit:
If you want to upgrade your hardware, then you should be able to switch
from 32-bit hardware to 64-bit hardware and still use your existing
32-bit Oracle software without encountering any problems.
If you want to downgrade your hardware from 64-bit to 32-bit, then you
must first downgrade your Oracle software to 32-bit software before
downgrading your hardware.
The on-disk format for database data, redo, and undo is identical for the
32-bit and 64-bit installations of Oracle. The only internal structural
differences between the 32-bit and 64-bit Oracle installations are the
following:
The compiled format of PL/SQL is different. The instructions for how and
when to recompile PL/SQL are provided in the appropriate chapters of
the Migration book. The storage format of user-defined types is based on the
release of Oracle that created the database. The existing storage format will
be converted to the correct format transparently when necessary. User-defined
types include object types, REFs, varrays, and nested tables.
Note: For Oracle 9.2
Changing word size during an upgrade or downgrade is not supported. For example,
if you have the 32-bit installation of release 9.2 on 32-bit hardware and you
want to switch to the 64-bit installation of release 9.2 on 64-bit hardware,
then complete the following steps:
a. Install the 32-bit installation of release 9.2 on 64-bit hardware.
b. Upgrade the database.
c. Follow next steps in this note.
CHANGING THE WORD-SIZE OF YOUR CURRENT RELEASE
----------------------------------------------
The instructions in this section guide you through changing the word-size of
your current release (switching from 32-bit software to 64-bit software or
vice versa).
Complete the following steps to change the word-size of your current release:
1. Start SQL*Plus.
2. Connect to the database instance AS SYSDBA.
3. Run SHUTDOWN IMMEDIATE on the database:
SQL> SHUTDOWN IMMEDIATE
Issue the command for all instances if you are running Oracle Parallel
Server.
=============================================================================
Note:
NCHAR columns in user tables are not changed during the upgrade.
To change NCHAR columns in user tables, see "Upgrade User NCHAR
Columns" in the Migration guide.
=============================================================================
4. Perform a full offline backup of the database (Optional, but highly
recommended)
See Also:
Oracle9i User-Managed Backup and Recovery Guide for more information.
5. If you are using the same Oracle home for your current release and the
release to which you are switching, then deinstall your current release
using the Oracle Installer. You do not need to deinstall your current
release if you are using separate Oracle home directories.
6. If you currently have a 32-bit installation, then install the 64-bit
version of the same release. Or, if you currently have a 64-bit
installation, then install the 32-bit version of the same release.
=============================================================================
Note:
Installation and deinstallation are operating system-specific. For
installation and deinstallation instructions, see your
Oracle9i operating system-specific installation documentation and
the Oracle9i README for your operating system.
Installation documentation can also be found at technet.oracle.com
=============================================================================
7. Copy configuration files to a location outside of the old Oracle home:
a. If your initialization parameter file resides within the old
environment's Oracle home, then copy it to a location outside of the
old environment's Oracle home. The initialization parameter file can
reside anywhere you wish, but it should not reside in the old
environment's Oracle home after you switch to the new release.
b. If your initialization parameter file has an IFILE (include file)
entry and the file specified in the IFILE entry resides within the
old environment's Oracle home, then copy the file specified by the
IFILE entry to a location outside of the old environment's Oracle
home. The file specified in the IFILE entry has additional
initialization parameters. After you copy this file, edit the IFILE
entry in the initialization parameter file to point to its new
location.
c. If you have a password file that resides within the old Oracle home,
then move or copy the password file to the Oracle9i Oracle home.
The name and location of the password file are operating
system-specific; for example, on UNIX operating systems, the default
password file is ORACLE_HOME/dbs/orapwsid, but on Windows platforms,
the default password file is ORACLE_HOME\database\pwdsid.ora.
In both cases, sid is your Oracle instance ID.
=============================================================================
Note:
For Oracle9i Real Application Clusters, perform this step on
all nodes. Also, if your initdb_name.ora file resides within
the old environment's Oracle home, then move or copy the
initdb_name.ora file to a location outside of the old
environment's Oracle home.
=============================================================================
8. Change your environment to point at the new 64Bit ORACLE_HOME.
Note: Check with platform specific documentation if other env variables
need to be changed e.g. LD_LIBRARY_PATH
9. In 64-bit ORACLE_HOME/dbs edit init.ora to set the following parameter
for migration:
aq_tm_processes=0
This will avoid problems as detailed in Bug 1421476.
10. Set _system_trig_enabled = false in init.ora
The parameter should be set to FALSE for scripts which perform dictionary
operations as the objects on which the triggers depend may become
invalid or be dropped, causing the triggers to fail and thus preventing
the scripts from running successfully.
See note 149948.1 'IMPORTANT: Set "_SYSTEM_TRIG_ENABLED=FALSE" When
Upgrading / Downgrading / Applying Patch Sets' for more info.
11. When migrating from a 32-bit Oracle version to a 64-bit Oracle version,
Oracle recommends doubling the size of parameters such as:
SHARED_POOL_SIZE
SHARED_POOL_RESERVED_SIZE
LARGE_POOL_SIZE
This is mainly due to an increase in the size of internal data structures.
For an in-depth explanation of this, please see note 209766.1
'Memory Requirements of Databases Migrated from 32-bit to 64-bit'
12. At a system prompt, change to the ORACLE_HOME/rdbms/admin directory.
13. Start SQL*Plus.
14. Connect to the database instance AS SYSDBA.
15. Run STARTUP RESTRICT:
SQL> STARTUP RESTRICT
You may need to use the PFILE option to specify the location of your
initialization parameter file.
16. Run the following script:
SVRMGR> @/$OH/rdbms/admin/catalog.sql
17. Check for DBMS_PACKAGE validity.
18. If invalid, run "alter package dbms_standard compile;"
19. Run the following script:
SVRMGR> @/$OH/rdbms/admin/catproc.sql
20. Set the system to spool results to a log file for later verification of
success:
SQL> SPOOL catoutw.log
If you want to see the output of the script you will run on your screen,
then you can also issue a SET ECHO ON statement:
SQL> SET ECHO ON
21. Run utlirp.sql:
SQL> @/$OH/rdbms/admin/utlirp.sql
The utlirp.sql script recompiles existing PL/SQL modules in the format
required by the new database. This script first alters certain
dictionary tables. Then, it reloads package STANDARD and DBMS_STANDARD,
which are necessary for using PL/SQL. Finally, it triggers a
recompile of all PL/SQL modules, such as packages, procedures, types,
and so on.
22. Turn off the spooling of script results to the log file:
SQL> SPOOL OFF
Then, check the spool file and verify that the packages and procedures
compiled successfully. You named the spool file in Step 12; the suggested
name was catoutw.log. Correct any problems you find in this file.
If you specified SET ECHO ON, then you may want to SET ECHO OFF now:
SQL> SET ECHO OFF
23. Run ALTER SYSTEM DISABLE RESTRICTED SESSION:
SQL> ALTER SYSTEM DISABLE RESTRICTED SESSION;
24. Shutdown database and remove the following parameter from init.ora
aq_tm_processes=0
25. Set _system_trig_enabled = true in init.ora
The word-size of your database is changed. You can open the database for normal
use.
RELATED DOCUMENTS
-----------------
Migration Release 3 (8.1.7)
Database Migration Release 1 (9.0.1)
