Migrating from 32-bit to 64-bit HP-UX

[Kevin Eady_1]

I have a development box running 32-bit 11.00 and want to convert it to 64-bit. (for Oracle9)
As the advice on this forum seems to be to do a fresh install, I was wondering if I could still use any info on the disks, other than the O/S disk, or have I got to backup the whole lot to tape and restore ?
BTW I will still need to build software for Oracle8.

Any help would be appreciated.

[Leif Halvarsson_2]

Hi,

The OS disk will be completly rebuilt during the install, anything on that disk you have to backup/restore.

Other disks (volumegroups) is possible to export/import but, of course, it is not wrong to perform a backup of all disks before reinstalling.

[Zygmunt Krawczyk]

Hi Kevin,

read the doc:

"HP-UX 11.0 Installation and Update Guide" - page 152+

http://www.docs.hp.com/hpux/pdf/5990-6721.pdf

Regards,
Zygmunt

[John Carr_2]

Kevin

a fresh install is a fresh one all your present data will be lost. It would be sensible to backup yout system and then check your backup media before migrating. ie restore a file from the backup.

John.

[Pete Randall]

Kevin,

Leif is on the right track. Of course you'll want to make sure you have a complete backup before you attempt anything - just in case!

Then, run
vgexport -p -s -m /tmp/vg01map /dev/vg01
substituting your vgnames and repeat for any other non-root vg's

Copy the maps produced (/tmp/vg01map) to a location where you can get to it after the new install (tape, another system you can access via nfs, or something).

Then install the new version of the OS, copy your maps back in and import the vg's like this:

mkdir /dev/vg01
mknod /dev/vg01/group c 64 0x010000
vgimport -s -m /tmp/vg01map /dev/vg01
vgchange -a y /dev/vg01


Having said all that, I think you can upgrade directly from 32 bit to 64 bit. Have a look at the installation guide:
http://docs.hp.com/hpux/os/11i/index.html#Installing%20and%20Updating

Good luck,


Pete

[Steven E. Protter · Accepted solution]

You also have to do a data conversion. Thats a 21 step process with lots of minefields to skirt.

Here is a document, based on one my DBA did for Oracle. Maybe its based on an oracle doc, not sure any more.

SCOPE & APPLICATION

-------------------

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.

LIMITATIONS OF USE

--------------------

This note is not applicable for Databases having JVM installed or

Oracle applications installed on an oracle 8i environment.

If that is the case please check [NOTE:183649.1]

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

In the first release of the migration guide it is said that changing the

wordsize during upgrade or migration is not supported. This is incorrect

a documentation bug has been logged for this. Bug 2590998 explains the

error in the documentation. This has been fixed in the second release of

Oracle 9I release 2 (9.2) Migration guide where it is correctly written

that changing wordsize during the migration or the upgrade is supported.

It is recomended to apply the latest patchset BEFORE the wordsize conversion.

This would avoid some bugs and also some steps in this note during the wordsize

conversion, like [BUG:1867501] and [BUG:1926809].

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

After running this script, check for invalid objects and recompile them

to avoid problems during the script utlirp.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

-----------------

[NOTE:214242.1] ORA-600 [17069] while running utlirp.sql converting to

8.1.7.4 64-Bit

Oracle 9i Database Migration Release 2 (9.2) Part Number A96530-01 (HTML) -

http://download.oracle.com/docs/cd/B10501_01/server.920/a96530/toc.htm

Oracle 9i Datbase Migraiton Release 1 (9.0.1) Part Number A90191-02 (HTML) -

http://download.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90191/toc.htm

Oracle8i Migration Release 3 (8.1.7) Part Number A86632-01 (HTML) -

http://download.oracle.com/docs/cd/A87860_01/doc/server.817/a86632/toc.htm

Oracle8 Migration Release 8.0 Part Number A58243-01 (HTML) -

http://download.oracle.com/docs/cd/A64702_01/doc/server.805/a58243/toc.htm

Oracle Documentation Master Index -

http://www.oracle.com/technology/documentation/index.html

[Sridhar Bhaskarla]

Kevin,

I did update from 11.0 32bit to 64bit couple of years back. It was not as bad as updating from 10.x to 11.0.

If you are going to fresh-install and if you have sometime (since this is only development), I suggest you can try the update option. If it doesn't work, you have plan B anyway. Backups and make_tape_recovery tapes are very important.

Look at the following document.

http://docs.hp.com/hpux/onlinedocs/5990-6721/5990-6721.html

"Troubleshooing" -> "Updating between 32bit and 64bit".

I wouldn't try anything on production unless I am confident by doing it on non-production. I wouldn't have suggested it if you didn't mention that this is a development system.

-Sri

[Kevin Eady_1]

Thanks for all your help.

I have all my backups, so here goes.