---------------------------------------------------------------
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.