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

Oracle8 Migration, Upgrading, and Downgrading

Release 8.0.5

Production

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

Copyright (C) Oracle Corporation 1993, 1998

Author: Randy Urbano

Contributors: Karleen Aghevli, Reema Al-Shaikh, Bill Bridge,

Ben Chang, Maria Chien, David Colello, Sandy Dreskin,

Jeffrey Hebert, Chin Hong, Muralidhar Krishnaprasad, Thomas

Kurian, Paul Lane, Gordon Larimer, Lefty Leverenz, Tracy Lee,

Juan Loaiza, Peter Ogilvie, Bill Maimone, Joan Pearson,

Elizabeth Pitt, Greg Pongracz, N.C. Ramesh, Mary Rhodes,

Richard Sarwal, Usha Sangam, Carol Sexton, Alvin To, Alex

Tsukerman, Douglas Utzig, Peter Vasterd, Lik Wong

This software/documentation contains proprietary information of

Oracle Corporation; it is provided under a license agreement

containing restrictions on use and disclosure and is also protected

by copyright law. Reverse engineering of the software is prohibited.

If this software/documentation is delivered to a U.S. Government

Agency of the Department of Defense, then it is delivered with

Restricted Rights and the following legend is applicable:

RESTRICTED RIGHTS LEGEND:

Use, duplication, or disclosure by the Government is subject to

restrictions as set forth in subparagraph (c)(1)(ii) of

DFARS 252.227-7013, Rights in Technical Data and Computer

Software (October 1988).

If this software/documentation is delivered to a U.S. Government

Agency not within the Department of Defense, then it is delivered

with "Restricted Rights," as defined in FAR 52.227-14, Rights in

Data - General, including Alternate III

(June 1987).

Oracle Corporation, 500 Oracle Parkway, Redwood City, CA 94065.

The information in this document is subject to change without notice.

If you find any problems in the documentation, please report them to

us in writing. Oracle Corporation does not warrant that this

document is error free.

Oracle, CASE*Dictionary, Pro*COBOL, SQL*Connect, SQL*Forms,

SQL*Loader, SQL*Net, and SQL*Plus are registered trademarks of

Oracle Corporation. CASE*Designer, CASE*Method, Net8, Oracle7,

Oracle8, Oracle Call Interface, Oracle Parallel Server, Oracle

Recovery Manager, PL/SQL, Pro*C/C++, SQL*Module, Oracle Server

Manager and Trusted Oracle are trademarks of Oracle Corporation.

All trade names referenced are the service mark, trademark, or

registered trademark of the respective manufacturer.

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

TABLE OF CONTENTS

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

Introduction

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

0.1 Purpose of this README

1.0 OVERVIEW

2.0 MIGRATING A RELEASE 7.x DATABASE TO RELEASE 8.0.5

3.0 UPGRADING A RELEASE 8.0.x DATABASE TO RELEASE 8.0.5

3.1 Upgrading the Advanced Queuing Option

4.0 DOWNGRADING FROM VERSION 8 TO RELEASE 7.X

5.0 DOWNGRADING FROM RELEASE 8.0.5 TO RELEASE 8.0.x

6.0 CHANGING THE WORD-SIZE OF RELEASE 8.0.5

7.0 NOTES ON PARALLEL SERVER ROLLING UPGRADE

8.0 MISCELLANEOUS NOTES

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

**********************

* *

* Introduction *

* *

**********************


0.1 Purpose of this README

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

This README file is relevant only to the delivered Oracle8

Server 8.0.5. This README provides instructions for Migrating

from version 7 to release 8.0.5, for upgrading from

release 8.0.x to release 8.0.5, and for downgrading from

release 8.0.5 to release 8.0.x or version 7.

In addition, this README provides instructions for changing

the word-size of installed release 8.0.5 software, as well

as information about performing rolling upgrades in a

multi-instance Oracle Parallel Server environment.

1.0 OVERVIEW

============

This README includes instructions for migrating, upgrading, and

downgrading your Oracle database, either with or without a change

in word-size. This README also discusses rolling upgrades.

A change in word-size includes the following scenarios:

- You have 32-bit software installed on 64-bit hardware and

would like to change to using 64-bit software.

- You have 64-bit software installed on 64-bit hardware and

would like to change to using 32-bit software.

The "Oracle8 Migration" book for release 8.0.4 (Oracle part

number A58243-01) contains the section "Migrating to a

Different Computer Architecture" on page 3-5. This section

states that you cannot use the Migration Utility to migrate a

database from a 32-bit platform to a 64-bit platform. This

restriction DOES NOT apply to release 8.0.5; it is now possible

to switch the word-size of your Oracle software during a

migration using the Migration Utility.

However, the restriction against using the Migration Utility

to migrate to a different operating system still applies.

General Notes:

- There are new conventions for the names of the upgrade and

downgrade scripts; the scripts no longer use the form

CAT*.SQL. The new naming convention provides direct migration

paths from one release to another, without requiring you to go

through multiple upgrade paths if there were releases in

between yours and the one to which you are upgrading or

downgrading. The new names use the form U*.SQL for upgrading

and D*.SQL for downgrading.

- The U*.SQL and D*.SQL scripts for upgrading and downgrading

are not the same for every release. You must pick the one

that was shipped with the release to which you plan to upgrade

or from which you plan to downgrade.

- The instructions in this README include references to

directory paths within $ORACLE_HOME and references to

starting Oracle executables, such as Server Manager, from

a command line. In some cases, directory structure and

executable names are operating system specific. See the

Oracle documentation and README for your operating system

for information.

The following are notes about upgrading and downgrading your

hardware from 32-bit to 64-bit and vice versa:

- If you want to upgrade your hardware, you should be able to

switch from 32-bit hardware to 64-bit hardware and still use

your existing 32-bit software without encountering any problems.

If you then wish to migrate to 64-bit software, the instructions

to do so are provided below.

- If you want to downgrade your hardware from 64-bit to 32-bit,

you must first downgrade your software before downgrading your

hardware.

The following are notes about the internal structural differences

between the 32-bit and 64-bit Oracle installations. The on-disk

format for database data, redo, and undo is identical for the 32-bit

and 64-bit installations of Oracle. There are only the following two

differences:

- The compiled format of PL/SQL is different. The instructions

for how and when to recompile PL/SQL are provided below in each

of the sections where this is relevant.

- The storage format of objects is based on the version of Oracle

that created the database. The existing storage format will

be converted to the other format transparently when necessary.

Use the following table to identify the relevant section of this

README for your migration, upgrade, downgrade, or word-size change

operation. As indicated in the table, if you want to change the

word-size of your software during any operation, each section

provides optional instructions for doing so. Changing word-size

means switching between 32-bit and 64-bit software.

CURRENT RELEASE OPERATION TARGET RELEASE SECTION

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

Release 7.x Migrate To Release 8.0.5 Section 2.0

(32-bit or 64-bit) (32-bit or 64-bit)

Release 8.0.x Upgrade To Release 8.0.5 Section 3.0

(32-bit or 64-bit) (32-bit or 64-bit)

Release 8.0.5 Downgrade To Release 7.x Section 4.0

(32-bit or 64-bit) (32-bit or 64-bit)

Release 8.0.5 Downgrade To Release 8.0.x Section 5.0

(32-bit or 64-bit) (32-bit or 64-bit)

Release 8.0.5 Word-Size Release 8.0.5 Section 6.0

(32-bit) Change To (64-bit)

Release 8.0.5 Word-Size Release 8.0.5 Section 6.0

(64-bit) Change To (32-bit)

NOTE: If you have Parallel Server instances running on the same

database, and would like to perform rolling upgrades, read

Section 7.0 also.

2.0 MIGRATING A RELEASE 7.x DATABASE TO RELEASE 8.0.5

=====================================================

Before you perform the procedure in this section, complete the

following steps, because these steps apply to release 8.0.5:

1. Read Chapter 1 of the release 8.0.4 "Oracle8 Migration"

book (A58243-01).

2. Read and perform the procedures described in Chapter 2

of this book.

3. If you decided to use the Migration Utility, instead of

export/import, to migrate your database to version 8, read

and perform the procedures described in the beginning of

Chapter 3 on pages 3-1 through 3-14 of this book.

The procedure below replaces the procedure starting on page 3-15

of the "Oracle8 Migration" book in the "Migration Steps in the

Version 8 Environment" section. Perform the procedure below instead

of the procedure in the "Oracle8 Migration" book (A58243-01).

NOTE: If you decided to use export/import, instead of the Migration

Utility, to migrate your version 7 database to version 8, see

Chapter 4, "Migrating Using Export/Import", of the

release 8.0.4 "Oracle8 Migration" book (A58243-01). The

instructions in that chapter also apply to release 8.0.5.

However, if you decided to use the Migration Utility,

complete the procedure below.

Complete the following migration steps in the version 8 environment:

1. Install the version 8 software with the version 8

Installation Utility. Choose the Install/Upgrade option to

avoid the creation of a new database. The procedure for

installing the software is platform-specific.

See Also: Your platform-specific version 8 installation

documents, and read the additions or modifications

in the README.DOC file included with version 8.

2. Make sure that the following environment variables point to

the version 8 executables:

- ORACLE_HOME

- PATH

- ORACLE_PATH

- LD_LIBRARY_PATH

NOTE: If ORACLE_HOME points to the version 7 executable, an

ORA-223 error is displayed when you run the ALTER

DATABASE CONVERT command later in this procedure,

stating "conversion data file is invalid or incorrect

version".

3. Make sure the operating system running the version 8 database

is the same as the operating system used for running the

version 7 database and the version 8 Migration Utility.

4. Adjust the INIT.ORA file for version 8.

Certain version 7 initialization parameters are obsolete in

version 8. Remove all obsolete parameters from any

initialization parameter file that starts a version 8

instance. Obsolete parameters may cause errors if used with

a version 8 database. Also, alter any parameter whose syntax

has changed in version 8; refer to Appendix C, "Version 8

INIT.ORA Changes" of the "Oracle8 Migration" book (A58243-01)

for lists of new, changed, and obsolete parameters.

5. Set the COMPATIBLE parameter in your INIT.ORA file.

See Also: The "COMPATIBLE Parameter" section on page C-2 of

the "Oracle8 Migration" book (A58243-01) for

information.

6. Either remove or rename the database's control files, or use

the CONTROL_FILES parameter in the INIT.ORA file to specify

new control file names.

The ALTER DATABASE CONVERT command automatically creates new

control files. If you do not use the CONTROL_FILES parameter,

this command uses the control file names of your pre-migration

database and returns an error if the control files already

exist. Therefore, in this case, you must remove or rename

the control file(s).

However, if you use the CONTROL_FILES parameter in the INIT.ORA

file, the ALTER DATABASE CONVERT command creates the new

control file(s) with the name(s) you specify, and you do not

need to remove the old control files.

NOTE: CONTROL_FILES specifies one or more names of control

files, separated by commas. Oracle Corporation

recommends using multiple files on different devices

or mirroring the file at the operating system level.

See the "Oracle8 Administrator's Guide" (A58397-01)

for more information.

7. If you installed the version 8 executables in a separate

$ORACLE_HOME directory, move or copy the convert file from the

version 7 environment to the version 8 environment. Skip to

Step 9 if you are using the same $ORACLE_HOME.

On UNIX, the convert file, convSID.dbf (where SID is the

version 8 instance ID), should reside in $ORACLE_HOME/dbs.

If the version 8 instance ID is different from the version 7

instance ID, rename the convSID.dbf file to match the

version 8 instance ID.

8. If you installed the version 8 executables in a separate

$ORACLE_HOME directory and you have a password file, move or

copy the password file from the version 7 to the version 8

environment.

The name and location of the password file is

platform-specific; for example, on UNIX platforms, the

default password file is $ORACLE_HOME/dbs/orapwSID, but on

Windows NT, the default password file is

$ORACLE_HOME\database\pwdSID.ora. In both cases, SID is

your Oracle instance ID.

9. Make sure all online data files are accessible and in the

correct directories. If you are using a raw disk, log files

also must be accessible.

10. At a system prompt, change to the $ORACLE_HOME/rdbms/admin

directory.

11. Start Server Manager by entering the following:

svrmgrl

12. Connect to the version 8 database instance:

SVRMGR> CONNECT INTERNAL;

13. Start a version 8 database instance without mounting the new

version 8 database:

SVRMGR> STARTUP NOMOUNT;

WARNING: Starting the database instance in any other mode

might corrupt the database.

14. Create a new version 8 database control file and convert the

file headers of all online tablespaces to version 8 format

by issuing the following command:

SVRMGR> ALTER DATABASE CONVERT;

Successful execution of this command is the "point of no

return" to version 7 for this database. However, if

necessary, you can restore the version 7 database from

backups.

NOTE: Control files are considerably larger in version 8

than in version 7. Control files in the tens of

kilobytes size range in version 7 could be expanded

into the range of tens of megabytes automatically

during migration to version 8. This size increase

could be important if a control file is on a raw

device or if its available disk space is restricted.

If error(s) occur during this step, correct the condition(s)

that caused the error(s) and rerun the Migration Utility.

Restart at Step 1 on page 3-11 of the "Oracle8 Migration"

book (A58243-01) in the "Migration Steps in the Version 7

Environment" section; otherwise restore the backup you

performed after you ran the Migration Utility.

15. Open the version 8 database with the following command:

SVRMGR> ALTER DATABASE OPEN RESETLOGS;

When the version 8 database is opened, all rollback segments

that are online are converted to the new version 8 format.

16. Set the system to spool results to a log file for later

verification of success:

SVRMGR> SPOOL CATOUT.LOG

17. If your installation involves a change in word-size (switching

between 32-bit and 64-bit software), then perform the following

additional REQUIRED step. This step is optional if your

installation does not involve a change in word-size

(performing this step if it is not necessary could cause

invalidations).

Run UTLIP.SQL:

SVRMGR> @utlip.sql

The UTLIP.SQL script invalidates all existing PL/SQL modules

by altering certain dictionary tables so that subsequent

recompilations will happen in the format required by the new

database. It also reloads package STANDARD and DBMS_STANDARD,

which are necessary for any PL/SQL compilations.

18. Run the version 8 database conversion script, CAT8000.SQL:

SVRMGR> @cat8000.sql

The CAT8000.SQL script creates and alters certain system

tables and drops the "MIGRATE" user. It also runs the

CATALOG.SQL and CATPROC.SQL scripts, which create the system

catalog views and all the necessary packages for using PL/SQL.

See Also: The "Oracle8 Reference" book (A58242-01) for a

complete list and descriptions of available scripts,

if you want to create additional data dictionary

structures.

19. If the Oracle system has Advanced Replication installed, run

the CATREP8M.SQL catalog script:

SVRMGR> @catrep8m.sql

The CATREP8M.SQL script automatically runs the CATREP.SQL

script.

20. If the Oracle system has Parallel Server installed, run the

following catalog script supplied with your new release:

SVRMGR> @catparr.sql

21. Run UTLRP.SQL. This step is optional, and you can complete

it regardless of whether there was a change in word-size:

SVRMGR> @utlrp.sql

The UTLRP.SQL script recompiles all existing PL/SQL modules

that were previously in an INVALID state, such as packages,

procedures, types, etc. These actions are optional; however,

they ensure that the cost of recompilation is incurred during

installation rather than in the future.

Oracle Corporation highly recommends performing this optional

step.

22. Turn off the spooling of script results to the log file:

SVRMGR> SPOOL OFF

Then, check the spool file and verify that every package and

procedure compiled successfully. You named the spool file in

Step 16; the suggested name was CATOUT.LOG. Correct any

problems you find in this file.

23. Run SHUTDOWN on the version 8 database:

SVRMGR> SHUTDOWN NORMAL

WARNING: Use SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE.

Do not use SHUTDOWN ABORT.

Executing this clean shutdown flushes all caches, clears

buffers, and performs other DBMS housekeeping activities.

These measures are an important final step to ensure the

integrity and consistency of the newly migrated version 8

database.

24. Complete the procedures described in Chapter 5, "After

Migrating the Database", of the "Oracle8 Migration"

book (A58243-01).


3.0 UPGRADING A RELEASE 8.0.x DATABASE TO RELEASE 8.0.5

=======================================================

To upgrade from release 8.0.x to release 8.0.5, where x is either

2, 3, 4, or 4S, use the procedure below. This procedure replaces the

procedure in the section "Upgrading to a New Version 8 Release",

starting on page 8-2 in Chapter 8 of the "Oracle8 Migration" book

(A58243-01). Use the procedure below instead of the procedure in

the "Oracle8 Migration" book to upgrade to release 8.0.5.

WARNING: If you are using mutually referencing types, downgrading

back to your current release may not be supported after

you upgrade to release 8.0.5. See Section 5.0 of this

README, "Downgrading From Release 8.0.5 To Release 8.0.x",

for more information.

NOTE: The procedure below is similar to the procedure used to

upgrade to release 8.0.4. In the procedure below, the

steps with two asterisks "**" before the number are the

steps that were changed or added in release 8.0.5.

Complete the following steps to upgrade your current 8.0.x database

to release 8.0.5:

1. Start Server Manager by entering the following:

svrmgrl

2. Run SHUTDOWN NORMAL on the version 8 database:

SVRMGR> SHUTDOWN NORMAL

3. Perform a full offline backup of the database (Optional).

See Also: The "Oracle8 Backup and Recovery Guide" (A58396-01)

for more information.

4. Install the new release 8.0.5 software.

NOTE: Installation is platform-specific. For installation

instructions, see your version 8 platform-specific

installation documentation and the version 8 README for

your platform.

5. Set the COMPATIBLE parameter in your INIT.ORA file.

See Also: The "COMPATIBLE Parameter" section on page C-2

of the "Oracle8 Migration" book (A58243-01) for

information.

**6. At a system prompt, change to the $ORACLE_HOME/rdbms/admin

directory.

7. Run CONNECT INTERNAL:

SVRMGR> CONNECT INTERNAL

8. Run STARTUP RESTRICT:

SVRMGR> STARTUP RESTRICT

NOTE: STARTUP RESTRICT only applies to a single instance,

not to the database. If you are using Oracle Parallel

Server, either use STARTUP RESTRICT to startup one

instance with PARALLEL_SERVER=FALSE, or startup all

instances using STARTUP RESTRICT.

9. Set the system to spool results to a log file for later

verification of success:

SVRMGR> SPOOL CATOUTU.LOG

**10. If your installation involves a change in word-size (switching

between 32-bit and 64-bit software), then perform the following

additional REQUIRED step. This step is optional if your

installation does not involve a change in word-size (performing

this step if it is not necessary could cause invalidations).

Run UTLIP.SQL:

SVRMGR> @utlip.sql

The UTLIP.SQL script invalidates all existing PL/SQL modules by

altering certain dictionary tables so that subsequent

recompilations happen in the format required by the new

database. It also reloads package STANDARD and DBMS_STANDARD,

which are necessary for any PL/SQL compilations.

**11. If you are upgrading from release 8.0.2, then perform the

following steps. Otherwise, skip to Step 12.

a. Run B802803.SQL. This script alters the bootstrap tables

and then shuts down the database. The shutdown is required

because bootstrap tables were changed.

SVRMGR> @b802803.sql

b. Start Server Manager, run CONNECT INTERNAL, and run STARTUP

RESTRICT:

svrmgrl

SVRMGR> CONNECT INTERNAL

SVRMGR> STARTUP RESTRICT

NOTE: STARTUP RESTRICT only applies to a single instance,

not to the database. If you are using Oracle

Parallel Server, either use STARTUP RESTRICT to

startup one instance with PARALLEL_SERVER=FALSE, or

startup all instances using STARTUP RESTRICT.

c. Start spooling to a new file because B802803.SQL shut down

the database.

SVRMGR> SPOOL CATOUTU2.LOG

**12. Run U<current_release>.SQL where <current_release> refers to

the release you currently have installed. See the table below

to choose the correct script.

SVRMGR> @u<current_release>.sql

CURRENT INSTALLED RELEASE UPGRADE SCRIPT

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

8.0.1.0 *** not supported ***

8.0.2.0 U0800020.SQL

8.0.3.0 U0800030.SQL

8.0.4.0 U0800040.SQL

8.0.4.1 U0800040.SQL (same as 8.0.4.0)

8.0.4S U0800040.SQL (same as 8.0.4.0)

NOTE: 1) You must use the version of the script supplied

with the release 8.0.5 installation.

2) You must run the script in the release 8.0.5

environment.

3) You only need to run ONE script, even if your

upgrade spans several releases. For example,

if your current release is 8.0.3.0, then you

need to run only U0800030.SQL.

4) If you currently are running release 8.0.4S,

you MUST upgrade to release 8.0.5.

The script you run creates and alters certain dictionary

tables. It also runs the CATALOG.SQL and CATPROC.SQL

scripts that come with release 8.0.5, which create the

system catalog views and all the necessary packages for

using PL/SQL.

See Also: "Oracle8 Reference" (A58242-01) for a complete

list and description of available scripts if you

want to create additional data dictionary structures.

**13. If you are upgrading from release 8.0.2 and you have

Advanced Replication installed, run the CATREP8U.SQL

script. Otherwise, skip to Step 14.

SVRMGR> @catrep8u.sql

14. If the Oracle system has Advanced Replication installed, run

the following catalog script supplied with your new release:

SVRMGR> @catrep.sql

15. If the Oracle system has Parallel Server installed, run the

following catalog script supplied with your new release:

SVRMGR> @catparr.sql

**16. Run UTLRP.SQL. This step is optional and can be done

regardless of whether there was a change in word-size.

SVRMGR> @utlrp.sql

The UTLRP.SQL script recompiles all existing PL/SQL modules

that were previously in an INVALID state, such as packages,

procedures, types, etc. These actions are optional; however,

they ensure that the cost of recompilation is incurred during

installation rather than in the future.

Oracle Corporation highly recommends performing this optional

step.

17. Turn off the spooling of script results to the log file:

SVRMGR> SPOOL OFF

Then, check the spool file and verify that every package and

procedure compiled successfully. You named the spool file in

Step 9; the suggested name was CATOUTU.LOG. Correct any

problems you find in this file.

NOTE: If you are upgrading from release 8.0.2, also check the

CATOUTU2.LOG spool file.

18. Run ALTER SYSTEM DISABLE RESTRICTED SESSION:

SVRMGR> ALTER SYSTEM DISABLE RESTRICTED SESSION

19. Run UTLCONST.SQL to check for bad date constraints.

Note: If you already ran UTLCONST.SQL after you migrated or

upgraded to a previous version 8 release, you need not

run it again. However, running the script many times

will not damage your system; therefore, if you are unsure

about whether it has been run on your system, you should

run it now.

To run UTLCONST.SQL, issue the following commands:

SVRMGRL> SPOOL UTLRESULT.LOG

SVRMGRL> @utlconst.sql

SVRMGRL> SPOOL OFF

A bad date constraint involves invalid date manipulation. An

invalid date manipulation is one that implicitly assumes the

century in the date, causing problems at the year 2000. The

UTLCONST.SQL script runs through all of the check constraints

in the database and sets constraints as bad if they include

any invalid date manipulation. This script selects all the

bad constraints at the end.

After you run the script, the UTLRESULT.LOG log file includes

all the constraints that have invalid date constraints.

Note: UTLCONST.SQL does not correct bad constraints, but it

does disable them. You should either drop the bad

constraints or recreate them after you make the

necessary changes.

3.1 Upgrading the Advanced Queuing Option

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

The operational interface in Oracle Advanced Queuing (AQ) 8.0.5 is

backward compatible with 8.0.4 and 8.0.3 Oracle AQ interfaces.

NOTE: If you have not started the release 8.0.5 database with a

setting of to 8.0.4.0.0 or higher for the COMPATIBLE parameter,

do so now if you want to use the features described in this

section. See "COMPATIBLE Parameter" on page C-2 of the

"Oracle8 Migration" book (A58243-01) for more information.

3.1.1 The Extended Address Field

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

The address field in the AQ$_AGENT datatype was extended to

1024 bytes in release 8.0.4. If you completed the procedure below

after upgrading or migrating to release 8.0.4 in the past, you do

not need to complete it again.

To use the extended address field, complete the following steps:

1. Export the contents of the existing queue tables using the

Export Utility.

2. Drop all of your queue tables.

3. Run CATNOQUEUE.SQL to drop the existing AQ dictionary

tables:

SVRMGRL> @catnoqueue.sql

4. Run CATQUEUE.SQL to redefine the new types and dictionary

tables:

SVRMGRL> @catqueue.sql

5. Import the queue tables you exported using the Import

Utility.

3.1.2 AQ Features Introduced in Release 8.0.4

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

The following AQ features were introduced in release 8.0.4.

These features are available in release 8.0.4 and higher:

- Message propagation in AQ was introduced in release 8.0.4.

For more information about this feature, see the "Oracle8

Application Developers Guide" (A58241-01).

- The address field is enabled for the AQ$_AGENT datatype.

Consequently, it is possible for this field to be specified

wherever an interface takes an Agent as an argument - such

as in the recipient list of the message properties, and the

DBMS_AQADM.ADD_SUBSCRIBER administrative interface.

- Upgrading to release 8.0.4 or higher creates the following

additional data dictionary tables:

- SYSTEM.AQ$_SCHEDULES

- SYS.AQ$_MESSAGE_TYPES

- SYS.AQ$_QUEUE_STATISTICS


4.0 DOWNGRADING FROM VERSION 8 TO RELEASE 7.X

=============================================

Please refer to the "Oracle8 Migration" book (A58243-01) for

details about downgrading from any version 8 release to

release 7.x.

These instructions apply even if your downgrade involves a change

in word-size (switching between 32-bit and 64-bit software). The

reason PL/SQL modules do not require recompilation is that the

downgrade instructions include restoring the old release 7.x

database, where the compiled PL/SQL modules' format already was

correct. If new PL/SQL modules were created in the version 8

release and are being imported back to the release 7.x database,

these will be automatically recompiled during the import process.

5.0 DOWNGRADING FROM RELEASE 8.0.5 TO RELEASE 8.0.x

===================================================

If you upgraded from release 8.0.x to release 8.0.5, where x is 3,

4, or 4S, you can downgrade from release 8.0.5 to release 8.0.x

using the procedure below. This procedure replaces the procedure

described in the section "Downgrading from Release 8.0.4 to

Release 8.0.3", starting on page 8-7 in Chapter 8 of the "Oracle8

Migration" book (A58243-01). Use the procedure below instead of the

procedure in the "Oracle8 Migration" book to downgrade your database.

WARNING: If you are using mutually referencing types, then

downgrading to release 8.0.3.0 or 8.0.4.0 is not supported.

You have two options for downgrading if you are using

mutually referencing types:

- Drop the mutually referencing types. Then, downgrading

to release 8.0.3.0 or 8.0.4.0 is supported using the

procedure below.

- Downgrade to release 8.0.4.1 instead of release 8.0.3.0

or 8.0.4.0. If you choose this option, contact Oracle

Corporation to get the 8.0.4.1 release.

The following SQL statements provide an example of

mutually referencing types:

> CREATE TYPE MANAGER;

> CREATE TYPE EMPLOYEE AS OBJECT

(EMPNO NUMBER, ENAME VARCHAR2(20),

MGR REF MANAGER);

> CREATE OR REPLACE TYPE MANAGER AS OBJECT

(DEPT NUMBER, EMPNO REF EMPLOYEE);

Explanation:

Due to bug #629468, which exists in release 8.0.3.0 and

8.0.4.0, but is fixed in release 8.0.4.1 and 8.0.5.0,

the existence of mutually referencing types causes the

compilation of package STANDARD to enter a loop and

exit with error ORA-01000: "maximum open cursors

exceeded". Package STANDARD is required for

compilation of PL/SQL code, and is run during a

downgrade operation. This bug causes the downgrade

to fail.

NOTE: The procedure below is similar to the procedure used to

downgrade from release 8.0.4 to release 8.0.3. In the

procedure below, the steps with two asterisks "**" before

the number are the steps that were changed or added in

release 8.0.5.

Complete the following steps to downgrade your release 8.0.5

database to release 8.0.x:

1. Shutdown the release 8.0.5 database by issuing the

following command:

SVRMGR> SHUTDOWN NORMAL

Issue the command for all instances if you are running

Oracle Parallel Server.

2. Perform a full offline backup (Optional).

See Also: The "Oracle8 Backup and Recovery Guide" (A58396-01)

for more information.

**3. Copy the following files from the $ORACLE_HOME/rdbms/admin

directory to a directory outside of $ORACLE_HOME, such as the

TEMP directory on your system:

- catlg803.sql

- utlip.sql

- utlrp.sql

Make a note of the new location of these files. You may need

them later in the downgrade process.

**4. At a system prompt, change to the $ORACLE_HOME/rdbms/admin

directory, if you are not already there.

5. Open the release 8.0.5 database.

6. If you are downgrading to release 8.0.3, complete this step.

If you are downgrading to release 8.0.4 or higher, skip to

Step 12.

Check your COMPATIBLE parameter setting by issuing the

following command:

SVRMGR> SELECT name, value, description FROM v$parameter

WHERE name='compatible';

If COMPATIBLE is set to 8.0.3.0.0 or 8.0.0.0.0, skip to

Step 12, but, if COMPATIBLE is set to 8.0.4.0.0 or higher,

continue with Step 7.

7. If you are using message propagation in the Advanced Queuing

Option, disable propagation. If you are not using message

propagation, move on to Step 8.

To disable propagation in the Advanced Queuing Option,

complete one of the following actions:

- Wait for all messages to be propagated successfully; then,

use DBMS_AQDM.UNSCHEDULE_PROPAGATION() to unschedule all

propagations.

- Use DBMS_AQDM.UNSCHEDULE_PROPAGATION() to unschedule all

propagations; then, delete all messages that are supposed

to be propagated from the queue tables.

See Also: The "Oracle8 Application Developers Guide"

(A58241-01) for information about

DBMS_AQDM.UNSCHEDULE_PROPAGATION().

8. Run ALTER DATABASE RESET COMPATIBILITY:

SVRMGR> ALTER DATABASE RESET COMPATIBILITY

9. Run SHUTDOWN NORMAL:

SVRMGR> SHUTDOWN NORMAL

WARNING: Do not open the database using 8.0.4.0 or higher

compatibility after completing this step.

10. Set the COMPATIBLE parameter in the INIT.ORA file to the

following:

COMPATIBLE=8.0.0.0.0

11. Open the database to ensure that it is compatible with

release 8.0.3. If the database fails to open, the Advanced

Queuing Option message propagation feature still is in use.

**12. If you have mutually referencing views, then drop them.

NOTE: You can either drop the mutually referencing

views before you downgrade or after you downgrade.

They will not affect the downgrade operation.

Mutually referencing views are not supported in release

8.0.3. If you are downgrading to release 8.0.3, drop all

mutually referencing views.

Mutually referencing views are supported in release

8.0.4.0 and higher. However, you still must drop these

views if you are downgrading to release 8.0.4.0 or higher.

After you downgrade, you can recreate the previously dropped

mutually referencing views in your 8.0.4 release. This

action is required because of bug #662863, which is present

in release 8.0.4.0, 8.0.4.1, and 8.0.4S, but is corrected

in release 8.0.5.0 and higher.

Mutually referencing views are views in which the object

views refer to each other through the MAKE_REF operator.

In the following example of mutually referencing views,

husband and wife types have references to each other, and

object views were created with MAKE_REF operators:

> CREATE TYPE husband;

> CREATE TYPE wife AS object

(id2 NUMBER,

name2 CHAR(10),

salary number,

buddy2 REF husband);

> CREATE OR replace TYPE husband AS object

(id NUMBER,

name CHAR(10),

buddy REF wife);

> CREATE TABLE husbandtab

(id NUMBER,

name CHAR(10),

buddy NUMBER);

> CREATE TABLE wifetab

(id2 NUMBER,

name2 CHAR(10),

salary NUMBER,

buddy2 NUMBER);

> CREATE VIEW husbandview OF husband

WITH object OID(id) AS

SELECT id, name, NULL FROM husbandtab;

> CREATE VIEW wifeview OF wife WITH object OID(id2) AS

SELECT id2, name2, salary,

MAKE_REF(husbandview, buddy2)

FROM wifetab;

> CREATE OR replace VIEW husbandview

OF husband WITH object OID(id) AS

SELECT id, name, MAKE_REF(wifeview, buddy)

FROM husbandtab;

**13. Run D<old_release>.SQL where <old_release> refers to the

release to which you are downgrading. See the table

below to choose the correct script.

SVRMGR> @d<old_release>.sql

THE RELEASE TO WHICH

YOU ARE DOWNGRADING DOWNGRADE SCRIPT

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

8.0.1.0 *** not supported ***

8.0.2.0 *** not supported ***

8.0.3.0 D0800030.SQL (see note #5)

8.0.4.0 D0800040.SQL (see note #5)

8.0.4.1 D0800040.SQL (same as 8.0.4.0)

8.0.4S D0800040.SQL (same as 8.0.4.0)

NOTE: 1) You must use the version of the script

included with the release 8.0.5 installation.

2) You must run the script in the release 8.0.5

environment.

3) You only need to run ONE script, even if your

downgrade spans several releases. For example,

if you are downgrading to release 8.0.3.0, then

you need to run only D0800030.SQL.

4) Downgrading from release 8.0.4S to a previous

release using downgrade scripts is NOT

supported.

5) If you are using mutually referencing types,

then downgrading to release 8.0.3.0 or 8.0.4.0

is not supported. See the WARNING before

Step 1 of this downgrading procedure for more

information.

14. Run SHUTDOWN NORMAL:

SVRMGR> SHUTDOWN NORMAL

**15. Install the release to which you are downgrading.

NOTE: 1) Installation is platform-specific. For

installation instructions, see your

platform-specific installation documentation

and the README for your platform.

2) If you are downgrading to release 8.0.4.1,

instead of 8.0.4.0 or 8.0.3.0, because you

are using mutually referencing types, contact

Oracle Corporation to get the 8.0.4.1 release.

**16. Copy the following files to the $ORACLE_HOME/rdbms/admin

directory:

- catlg803.sql

- utlip.sql

- utlrp.sql

You copied these files to a directory outside of

$ORACLE_HOME in Step 3.

**17. At a system prompt, change to the $ORACLE_HOME/rdbms/admin

directory, if you are not already there.

18. Run CONNECT INTERNAL:

SVRMGR> CONNECT INTERNAL

19. Run STARTUP RESTRICT:

SVRMGR> STARTUP RESTRICT

NOTE: STARTUP RESTRICT only applies to a single instance,

not to the database. If you are using Oracle Parallel

Server, either use STARTUP RESTRICT to startup one

instance with PARALLEL_SERVER=FALSE, or startup all

instances using STARTUP RESTRICT.

20. Set the system to spool results to a log file for later

verification of success:

SVRMGR> SPOOL CATOUTD.LOG

**21. If your installation involves a change in word-size

(switching between 32-bit and 64-bit software), then perform

the following additional REQUIRED step. This step is

optional if your downgrade does not involve a change in

word-size (performing this step if it is not necessary

could cause invalidations).

Run UTLIP.SQL:

SVRMGR> @utlip.sql

The UTLIP.SQL script invalidates all existing PL/SQL

modules by altering certain dictionary tables so that

subsequent recompilations will happen in the format

required by the new database. It also reloads package

STANDARD and DBMS_STANDARD, which are necessary for any

PL/SQL compilations.

NOTE: Make sure you perform this step in the old

release's environment.

**22. If you are downgrading to release 8.0.4.0 or higher, run

CATALOG.SQL:

SVRMGR> @catalog.sql

If you are downgrading to release 8.0.3.0, DO NOT run

CATALOG.SQL. Instead, run CATLG803.SQL:

SVRMGR> @catlg803.sql

DO NOT run CATLG803.SQL if you are downgrading to

release 8.0.4.0 or higher.

Explanation:

Due to bug #571546, which exists in release 8.0.3 but is

fixed in release 8.0.4, you should NOT run CATALOG.SQL

after downgrading from release 8.0.5 to release 8.0.3.

The recreation of package STANDARD triggers this bug.

Because CATALOG.SQL recreates package STANDARD, Oracle

has provided a new script (CATLG803.SQL) that effectively

does everything the release 8.0.3 CATALOG.SQL script

does, except for performing a few additional steps to

work around the problem described in bug #571546. You

must run this script instead of the release 8.0.3 version

of CATALOG.SQL.

23. Run CATPROC.SQL:

SVRMGR>@catproc.sql

24. If the Oracle system has Advanced Replication installed, run

the following catalog script:

SVRMGR>@catrep.sql

25. If the Oracle system has Parallel Server installed, run the

following catalog script:

SVRMGR>@catparr.sql

**26. Run UTLRP.SQL. This step is optional and can be done

regardless of whether there was a change in word-size.

Run UTLRP.SQL:

SVRMGR> @utlrp.sql

The UTLRP.SQL script recompiles all existing PL/SQL

modules that were previously in an INVALID state,

such as packages, procedures, types, etc. These

actions are optional; however, they ensure that the

cost of recompilation is incurred during installation

rather than in the future.

Oracle Corporation highly recommends performing this

optional step.

27. Turn off the spooling of script results to the log file:

SVRMGR> SPOOL OFF

Then, check the spool file and verify that every package

and procedure compiled successfully. You named the spool file

in Step 20; the suggested name was CATOUTD.LOG. Correct any

problems you find in this file.

**28. If you removed mutually referencing views in Step 12, and

you downgraded to release 8.0.4.0 or higher, recreate

these views now.

6.0 CHANGING THE WORD-SIZE OF RELEASE 8.0.5

===========================================

The instructions in this section apply only if you currently have

the new release 8.0.5 installed and want to switch to using

release 8.0.5 with a different word-size (switching from 32-bit

software to 64-bit software or vice versa).

Complete the following steps to change the word-size of

release 8.0.5:

1. Start Server Manager by entering the following command:

svrmgrl

2. Run CONNECT INTERNAL:

SVRMGR> CONNECT INTERNAL

3. Run SHUTDOWN NORMAL on the release 8.0.5 database:

SVRMGR> SHUTDOWN NORMAL

Issue the command for all instances if you are running

Oracle Parallel Server.

4. Perform a full offline backup of the database (Optional).

See Also: The "Oracle8 Backup and Recovery Guide" (A58396-01)

for more information.

5. If you currently have a 32-bit installation of release 8.0.5,

install the 64-bit version of release 8.0.5. Or, if you

currently have a 64-bit installation of release 8.0.5, install

the 32-bit version of release 8.0.5.

NOTE: Installation is platform-specific. For installation

instructions, see your platform-specific installation

documentation and the README for your platform.

6. At a system prompt, change to the $ORACLE_HOME/rdbms/admin

directory.

7. Start Server Manager by entering the following:

svrmgrl

8. Run CONNECT INTERNAL:

SVRMGR> CONNECT INTERNAL

9. Run STARTUP RESTRICT:

SVRMGR> STARTUP RESTRICT

NOTE: STARTUP RESTRICT only applies to a single instance,

not to the database. If you are using Oracle Parallel

Server, either use STARTUP RESTRICT to startup one

instance with PARALLEL_SERVER=FALSE, or startup all

instances using STARTUP RESTRICT.

10. Set the system to spool results to a log file for later

verification of success:

SVRMGR> SPOOL CATOUTW.LOG

11. Run UTLIRP.SQL:

SVRMGR> @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, etc.

See Also: "Oracle8 Reference" (A58242-01) for a complete list

and descriptions of available scripts, if you want

to create additional data dictionary structures.

12. Turn off the spooling of script results to the log file:

SVRMGR> SPOOL OFF

Then, check the spool file and verify that every package and

procedure compiled successfully. You named the spool file in

Step 10; the suggested name was CATOUTW.LOG. Correct any

problems you find in this file.

13. Run ALTER SYSTEM DISABLE RESTRICTED SESSION:

SVRMGR> ALTER SYSTEM DISABLE RESTRICTED SESSION

The word-size of your release 8.0.5 database is now changed.

You can open the database for normal use.

7.0 NOTES ON PARALLEL SERVER ROLLING UPGRADE

============================================

Rolling upgrades are supported only between two consecutive

maintenance releases (for example, between 8.0.4 and 8.0.5).

A rolling upgrade from a 32-bit release to a 64-bit release of

Oracle is not supported, and a rolling upgrade from a 64-bit

release to a 32-bit release of Oracle is not supported.

Rolling upgrade requires that the word-sizes of the Oracle

versions involved match. Also, a 32-bit release Oracle

Parallel Server cannot run on the same computer system as a

64-bit release Oracle Parallel Server.

While parallel server rolling upgrade allows simultaneous operation

of multiple Oracle instances running different product versions

against the same database, there are some special considerations

and limitations while the upgrade of the first instance is taking

place.

Part of the upgrade procedure recreates the SQL catalog and

Oracle-supplied PL/SQL packages by running a series of scripts.

While these scripts are being processed, the following problems

may be encountered:

- As upgrade scripts recreate or drop/create objects, they must

acquire exclusive locks on each object. While one or more

parallel server instances are in operation, these object

definitions may be locked in share mode for the duration of a

program interface call. For frequently used objects, therefore,

the upgrade script may proceed more slowly than usual as it

queues for exclusive locks on each object.

- At intermediate points in these scripts, users referencing

catalog views through a public synonym may briefly encounter

"ORA-942 table or view does not exist" as the synonym is dropped

and recreated. If such errors are encountered, the operation may

be retried; the period of invalidation is very brief. If

necessary the errors may be avoided entirely by fully specifying

object names, thereby avoiding the use of the synonyms. This

recommendation applies only to the Oracle-defined synonyms

present in the catalog scripts, not to synonyms present in

application code.

- The upgrade process recreates and recompiles all Oracle-

supplied server-side PL/SQL procedures and packages. Because

all PL/SQL code directly or indirectly depends on package

STANDARD, the effect will be to force recompilation of all

PL/SQL packages, procedures, and functions. All users who have

referenced and instantiated a PL/SQL package will encounter

"ORA-4061 existing state of package has been discarded" at the

next reference to that package, because the entry points and

memory layout of the recreated package may be different from the

old package. Re-executing the same statement will re-instantiate

all of the packages.

- At intermediate points in the upgrade scripts, the Oracle-

supplied server-side PL/SQL procedures and packages may not be

consistent. For example, the number of parameters to a procedure

declared in an internal PL/SQL package can change between

releases. After the procedure declaration is changed, the

procedure implementation and all callers of the procedure must

change to reflect the new declaration. A user submitting a

request that directly or indirectly invokes Oracle-supplied

PL/SQL procedures and packages may encounter "ORA-06550" and

"PLS-00905" exceptions when the request comes across an invalid

object that can not yet be recompiled successfully. Oracle

Corporation strongly recommends that users wait until the

upgrade scripts complete before submitting such a request.

For the reasons described above, Oracle Corporation strongly

recommends that upgrade scripts are run during a period of minimal

activity on all database instances. Once the upgrade scripts have

completed using one instance, they need not be repeated on other

instances as they are upgraded to the newer code version.

ADDENDUM: Release 8.0.4 PL/SQL requires release 8.0.4 packages,

and cannot process release 8.0.3 packages. Similarly,

release 8.0.5 PL/SQL requires release 8.0.5 packages,

and cannot process release 8.0.4 or 8.0.3 packages.

8.0 MISCELLANEOUS NOTES

=======================

- Server/server access across heterogeneous 64-bit platforms

IS supported in release 8.0.5 (in release 8.0.4S, such access

was not supported).

- In release 8.0.5, both 32-bit Oracle clients and 64-bit Oracle

clients can access both 32-bit Oracle servers and 64-bit Oracle

servers (in release 8.0.4S, only 32-bit Oracle clients could

access 64-bit Oracle servers).

- Parallel Server and Data Cartridges are supported in both the

32-bit and 64-bit versions of the 8.0.5 release.