Release 8.1.5
A67774-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Migration Release 8.1.5 A67774-01 |
|
This chapter contains information about upgrading your current release of Oracle to the new Oracle8i release. The information in this chapter only applies to release 8.0 and higher installations of Oracle. If your current release is pre-release 8.0, such as Oracle7 or version 6, and you want to migrate to Oracle8i, follow the instructions at the beginning of this book, starting with Chapter 1, "Overview".
This chapter covers the following topics:
The path that you must take to upgrade your database to the new release depends on the release you are currently using. Table 7-1 contains the upgrade path required for each old release of Oracle. Use the upgrade path and the documentation specified for the release you are running currently.
| Old Release | Upgrade Path |
|---|---|
|
8.0.1 |
Direct upgrade is not supported. Complete the following steps to upgrade to the new release:
|
|
8.0.4S |
Direct upgrade is not supported. Complete the following steps to upgrade to the new release:
|
|
8.1.4 |
Direct upgrade is supported. Upgrade to the new release using the instructions in "Upgrading the Database to the New Oracle8i Release". |
|
8.1.2 |
Upgrading to the new release is not supported. |
This section guides you through the process of upgrading your database to the new Oracle8i release.
|
Note: If you are upgrading from Oracle8i Enterprise Edition to Oracle8i (formerly Workgroup Server), before you upgrade, modify any applications that use the advanced features of Oracle8i Enterprise Edition so that they do not use these advanced features. See Getting to Know Oracle8i for more information about the differences between the editions. |
Complete the following steps to begin the upgrade process:
Oracle8i Utilities for information about exporting and importing Java source, class, and resource objects.
See Also:
To determine if there are any existing release 8.1 compatible queue tables in the database, issue the following SQL statement:
SELECT owner, queue_table FROM dba_queue_tables where compatible like '8.1%';
For example, you might see the following table as a result of issuing the above query:
OWNER QUEUE_TABLE ------------------------------ ------------------------------ AQUSER1 RAW_MSG_TABLE 1 row selected.
You can drop the queue tables listed by using DBMS_AQADM.DROP_QUEUE_TABLE, as in the following example:
EXECUTE dbms_aqadm.drop_queue_table(queue_table=>'AQUSER1.RAW_MSG_TABLE', force => TRUE);
"The DB_DOMAIN Parameter" for more information about setting this initialization parameter.
See Also:
SVRMGR> CONNECT INTERNAL
If you are upgrading from an 8.1 release, you do not need to perform this check because the OUTLN user should have been created when you installed the previous 8.1 release. Therefore, if you are upgrading from an 8.1 release, skip to Step 7. Do not drop the OUTLN user if you are upgrading from a previous 8.1 release.
Note:
To check for a user with the name OUTLN, enter the following SQL statement:
SELECT username FROM dba_users WHERE username = 'OUTLN';
If you do not have a user named OUTLN, zero rows are selected.
To check for a role with the name OUTLN, enter the following SQL command:
SELECT role FROM dba_roles WHERE role = 'OUTLN';
If you do not have a role named OUTLN, zero rows are selected.
Upgrading to a new release requires more space in your SYSTEM tablespace and in the tablespaces where you store rollback segments. If you have enough space on your system, consider adding more space to these tablespaces. If you run out of space during the upgrade, you will need to perform the upgrade again.
The following SQL statement illustrates how to add more space to a tablespace:
ALTER TABLESPACE system ADD DATAFILE '/home/user1/mountpoint/oradata/db1/system02.dbf' SIZE 50M;
SVRMGR> SHUTDOWN IMMEDIATE
If you are using Oracle Parallel Server, shutdown all instances.
Choose an upgrade method and then follow the instructions for upgrading using the method you have chosen.
There are two ways to upgrade your database to release 8.1. You can either use the Oracle Data Migration Assistant to complete the upgrade, or you can perform the upgrade manually.
The Oracle Data Migration Assistant provides a completely automated upgrade of your database. You use a graphical user interface (GUI), which guides you through each step of the process. In addition, the Oracle Data Migration Assistant includes extensive online help. The Oracle Data Migration Assistant runs the appropriate upgrade script for your current release, deletes any obsolete initialization parameters from your initsid.ora file, and optionally configures your listener.ora file. See Appendix B, "Changes to Initialization Parameters" for lists of obsolete initialization parameters.
On the other hand, you lose some flexibility and control by using the Oracle Data Migration Assistant. If you want complete control over the upgrade process, especially with regard to setting initialization parameters, you may want to perform the upgrade manually.
Decide which method you want to use to upgrade your database, and then complete the steps in one of the following sections accordingly:
Complete the following steps to upgrade the database using the Oracle Data Migration Assistant:
If you need help at any screen or want to consult more documentation about the Oracle Universal Installer, click the Help button to open the online help.
If you chose Custom, respond to the screens that enable you to specify your custom installation settings until you reach the "Upgrading or Migrating an Existing Database" screen.
Make sure you install all of the options you installed with the Oracle7 database, assuming you do not want to discontinue use of a particular option. For example, if you installed Advanced Replication in Oracle7, you should install it in Oracle8i.
When installation is complete, one or more assistants may be started. When the Oracle Data Migration Assistant is started, you are ready to proceed with the upgrade.
If you need help at any screen or want to consult more documentation about the Oracle Data Migration Assistant, click the Help button to open the online help.
The database you choose must be release 8.0 or higher. If the database is an Oracle7 or lower database, you must complete a migration of the database, not an upgrade. If the database is an Oracle7 database, exit the Oracle Data Migration Assistant, and see Chapter 1 to start the migration process.
Note:
initsid.ora file specified is the complete path to the initsid.ora file of the database that you are upgrading.
If you chose Custom, respond to the screens that enable you to specify your custom migration settings until you reach the "Confirm Backup" screen.
The Oracle Data Migration Assistant performs the upgrade. If the COMPATIBLE initialization parameter was not set prior to upgrading, the assistant sets COMPATIBLE to 8.0.5. However, if COMPATIBLE was set prior to upgrading, the original setting is retained after the migration. See Chapter 8, "Compatibility and Interoperability" for information about resetting the COMPATIBLE initialization parameter.
You may encounter a series of messages similar to the following during the upgrade:
ORA-00604: error occurred at eecursive SQL level 1 ORA-00001: unique constraint (SYSTEM.AQ$_QUEUES_CHECK) violated ORA-06512: at "SYS.DBMS_AQADM", line 2023 ORA-06512: at line 2
You can ignore these messages.
listener.ora file automatically, or click the No button if you do not want the assistant to modify the listener.ora file.
Certain modifications are required to the listener.ora file for your database to work properly with Oracle Enterprise Manager. If you plan to use Oracle Enterprise Manager, you should click the Yes button to automatically modify the listener.ora file. However, if you do not plan to use Oracle Enterprise Manager, click the No button.
If you click the Yes button, the Oracle Data Migration Assistant modifies the listener.ora file in the following way:
listener.ora in one of the following ways:
A simple case: Suppose the old listener.ora has the following SID_DESC entry:
... (SID_DESC = (SID_NAME = ORCL) ) ...
If the database name is SAL, the domain name is COM, and the Oracle home is /oracle/product/8.1, the assistant adds the following entry:
... (SID_DESC = (GLOBAL_DBNAME = sal.com) (ORACLE_HOME = /oracle/product/8.1) (SID_NAME = SAL) ) ...
A more complicated case: Suppose the old listener.ora has the following SID_DESC entry:
...
(SID_DESC =
(GLOBAL_DBNAME = an_entry)
(SID_NAME = ORCL)
)
...
If an_entry does not match the GLOBAL_DBNAME of the migrated database, and if the database name is SAL, the domain name is COM, and the Oracle home is /oracle/product/8.1, the assistant adds the following entry:
... (SID_DESC = (GLOBAL_DBNAME = sal.com) (ORACLE_HOME = /oracle/product/8.1) (SID_NAME = SAL) ) ...
This entry is the same as the entry in the simple case, but the assistant also adds the entry an_entry to the SERVICE_NAMES parameter. Therefore, the assistant changes the SERVICE_NAMES parameter to the following:
SERVICE_NAMES = sal.com, an_entry
listener.ora file. The assistant does not perform this action on UNIX operating systems.
If you installed Oracle8i without specifying that you are migrating or upgrading an existing database, you can run the Oracle Data Migration Assistant independently after the Oracle8i installation is complete.
Complete the following steps to run the Oracle Data Migration Assistant independently:
On UNIX, enter the following command at a system prompt:
odma
On Windows NT, select:
Start > Programs > Oracle - ORACLE_HOME_NAME > Migration Utilities > Oracle Data Migration Assistant
When you start the Oracle Data Migration Assistant, its welcome screen appears (see Figure 7-1).
Step 8 to Step 15 in "Upgrade the Database Using the Oracle Data Migration Assistant" for more information.
See Also:
Complete the following steps to upgrade the database manually:
If you are upgrading a system with Oracle Parallel Server installed, see the Oracle8i Parallel Server Setup and Configuration Guide for additional installation instructions.
If you need help at any screen or want to consult more documentation about the Oracle Universal Installer, click the Help button to open the online help.
After you make your selection, click Next.
If you chose Custom, respond to the screens that enable you to specify your custom installation settings until you reach the "Upgrading or Migrating an Existing Database" screen.
Make sure you install all of the options you installed with the Oracle7 database, assuming you do not want to discontinue use of a particular option. For example, if you installed Advanced Replication in Oracle7, you should install it in Oracle8i.
If you select the "Upgrade or Migrate an Existing Database" checkbox, the Oracle Data Migration Assistant is started automatically after installation. Because you are following the instructions for upgrading the database manually, you should not start the Oracle Data Migration Assistant.
When installation is completed successfully, click the Exit button to close the Universal Installer.
initsid.ora file resides within the old environment's Oracle home, copy it to a location outside of the old environment's Oracle home. In past releases, the default location for the initsid.ora file was $ORACLE_HOME/dbs on UNIX and $ORACLE_HOME\database on Windows NT, but in release 8.1, the default location is $ORACLE_BASE/admin/sid/pfile, where sid is the Oracle instance ID. The initsid.ora file can reside anywhere you wish, but it should not reside in the old environment's Oracle home after you upgrade to the new release.
If your initsid.ora file has an IFILE (include file) entry and the file specified in the IFILE entry resides within the old environment's Oracle home, then copy the file specified by the IFILE entry to a location outside of the old environment's Oracle home. The file specified in the IFILE entry has additional initialization parameters. After you copy this file, make the same edits to it as you do to the initsid.ora file, as specified in the next step.
initsid.ora file for use with the new release.
Certain initialization parameters are obsolete in the new 8.1 release. Remove all obsolete parameters from any initialization parameter file that will start a new release 8.1 instance. Obsolete parameters may cause errors. Also, alter any parameter whose syntax has changed in the new 8.1 release; refer to Appendix B, "Changes to Initialization Parameters" for lists of new, renamed, and obsolete parameters. Also, if you are using Oracle Parallel Server, see Oracle8i Parallel Server Concepts and Administration for more information about obsolete Oracle Parallel Server initialization parameters.
If you are updating snapshots automatically by using the JOB_QUEUE_PROCESSES initialization parameter, comment out this parameter in the initsid.ora file. Also, if you are using Advanced Queuing and have propagation schedules, comment out both the JOB_QUEUE_PROCESSES and AQ_TM_PROCESSES initialization parameters. After upgrading your database, you can remove the comments to use these parameters normally.
In release 8.1, the LARGE_POOL_SIZE setting may be calculated automatically by Oracle. If the automatic setting is too large, it may increase the time required to perform your upgrade. See "Parallel Execution Allocated from Large Pool" for more information.
If the initsid.ora file contains an IFILE entry, change the IFILE entry in the initsid.ora file to point to the new location you copied it to in Step 2.
If you are using Oracle Parallel Server, modify the initdb_name.ora file in the same way that you modified the initsid.ora file.
Make sure you save all of the files you modified after making these adjustments.
$ORACLE_HOME/rdbms/admin directory.
SVRMGR> CONNECT INTERNAL
SVRMGR> STARTUP RESTRICT
You may need to use the PFILE option to specify the location of your initsid.ora file.
You may see error messages listing obsolete parameters. If so, shut down the database, edit the initsid.ora file to remove the parameters listed, and then run STARTUP RESTRICT again.
SVRMGR> SPOOL catoutu.log
If you want to see the output of the script you will run on your screen, you also can issue a SET ECHO ON statement:
SVRMGR> SET ECHO ON
uold_release.sql where old_release refers to the release you had installed prior to upgrading. See Table 7-2 to choose the correct script. Each script provides a direct upgrade from the release specified in the "Old Release" column. The "Old Release" is the release from which you are upgrading.
To run a script, enter the following:
SVRMGR> @uold_release.sql
| Old Release | Run Script |
|---|---|
|
8.0.1 |
Direct upgrade is not supported. See "Upgrade Paths" for more information. |
|
8.0.2 |
Direct upgrade is not supported. See "Upgrade Paths" for more information. |
|
8.0.3 |
|
|
8.0.4 |
|
|
8.0.4S |
Direct upgrade is not supported. See "Upgrade Paths" for more information. |
|
8.0.5 |
|
|
8.1.1 |
Upgrading to the new release is not supported. |
|
8.1.2 |
Upgrading to the new release is not supported. |
|
8.1.3 |
|
|
8.1.4 |
u0801040.sql |
|
Note: If the old release you had installed prior to upgrading is not listed in Table 7-2, see the readme files in the new installation for the correct upgrade script to run. |
Make sure you follow these guidelines when you run the script:
u0800040.sql.
The script you run creates and alters certain dictionary tables. It also runs the catalog.sql and catproc.sql scripts that come with the release to which you are upgrading, which create the system catalog views and all the necessary packages for using PL/SQL.
If you encounter any problems when you run the script, or any of the scripts in the remaining steps, correct the causes of the problems and rerun the script. You can rerun any of the scripts described in this chapter as many times as necessary.
|
See Also:
"Running Scripts" for information about the types of errors to look for when you run a script. |
You may encounter a series of messages similar to the following during the upgrade:
ORA-00604: error occurred at eecursive SQL level 1 ORA-00001: unique constraint (SYSTEM.AQ$_QUEUES_CHECK) violated ORA-06512: at "SYS.DBMS_AQADM", line 2023 ORA-06512: at line 2
You can ignore these messages.
|
Note:
If the upgrade script runs for an inordinately long time, it may be caused by a setting for LARGE_POOL_SIZE that is too large for your installation. Use the V$PARAMETER view to check the setting for LARGE_POOL_SIZE, and if it is too large, set it to a smaller value in your |
SVRMGR> SPOOL OFF
Then, check the spool file and verify that the packages and procedures compiled successfully. You named the spool file in Step 9; the suggested name was catoutu.log. Correct any problems you find in this file.
If you specified SET ECHO ON, you may want to SET ECHO OFF now:
SVRMGR> SET ECHO OFF
SVRMGR> ALTER SYSTEM DISABLE RESTRICTED SESSION;
SVRMGR> SHUTDOWN IMMEDIATE
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 upgraded Oracle8i database.
Your database is now upgraded to the new 8.1 release.
Some components of the Oracle database server require an upgrade operation separate from the general database upgrade operation. This section contains information about upgrading specific components. You should perform the actions described in these sections only after you have upgraded the database by following the instructions in "Upgrading the Database to the New Oracle8i Release".
Some of the upgrading procedures below involve Export/Import. See Oracle8i Utilities for Export/Import instructions.
If the Oracle system has Advanced Replication installed, complete the following steps:
SVRMGR> SHUTDOWN IMMEDIATE
$ORACLE_HOME/rdbms/admin directory.
SVRMGR> CONNECT INTERNAL
SVRMGR> STARTUP RESTRICT
You may need to use the PFILE option to specify the location of your initsid.ora file.
SVRMGR> SPOOL catoutrep.log
If you want to see the output of the script you will run on your screen, you also can issue a SET ECHO ON statement:
SVRMGR> SET ECHO ON
catrep.sql:
SVRMGR> @catrep.sql
rold_release.sql script where old_release refers to the release you had installed prior to upgrading. See Table 7-3 to choose the correct script. Each script provides a direct upgrade for Advanced Replication from the release specified in the "Old Release" column. The "Old Release" is the release from which you are upgrading
To run a script enter the following:
SVRMGR> @rold_release.sql
| Old Release | Run Script |
|---|---|
|
8.0.1 |
Direct upgrade is not supported. See "Upgrade Paths" for more information. |
|
8.0.2 |
Direct upgrade is not supported. See "Upgrade Paths" for more information. |
|
8.0.3 |
|
|
8.0.4 |
|
|
8.0.4S |
Direct upgrade is not supported. See "Upgrade Paths" for more information. |
|
8.0.5 |
|
|
8.1.1 |
Upgrading to the new release is not supported. |
|
8.1.2 |
Upgrading to the new release is not supported. |
|
8.1.3 |
No upgrade script is required. Advanced Replication will work with the new release 8.1 database. |
|
8.1.4 |
No upgrade script required. Advanced Replication will work with the new release 8.1 database. |
|
Note: If the old release you had installed prior to upgrading is not listed in Table 7-3, see the readme files in the new installation for the correct upgrade script to run for Advanced Replication. |
Make sure you follow these guidelines when you run the script:
r0800040.sql.
SVRMGR> SPOOL OFF
Then, check the spool file and verify that the packages and procedures compiled successfully. You named the spool file in Step 6; the suggested name was catoutrep.log. Correct any problems you find in this file.
If you specified SET ECHO ON, you may want to SET ECHO OFF now:
SVRMGR> SET ECHO OFF
SVRMGR> ALTER SYSTEM DISABLE RESTRICTED SESSION
Advanced Replication is upgraded to the new release.
If the Oracle system has Oracle Parallel Server installed, complete the following steps:
SVRMGR> SHUTDOWN IMMEDIATE
$ORACLE_HOME/rdbms/admin directory.
SVRMGR> CONNECT INTERNAL;
SVRMGR> STARTUP RESTRICT
You may need to use the PFILE option to specify the location of your initsid.ora file.
SVRMGR> SPOOL catoutpar.log
If you want to see the output of the script you will run on your screen, you also can issue a SET ECHO ON statement:
SVRMGR> SET ECHO ON
catparr.sql:
SVRMGR> @catparr.sql
SVRMGR> SPOOL OFF
Then, check the spool file and verify that the packages and procedures compiled successfully. You named the spool file in Step 6; the suggested name was catoutpar.log. Correct any problems you find in this file.
If you specified SET ECHO ON, you may want to SET ECHO OFF now:
SVRMGR> SET ECHO OFF
SVRMGR> ALTER SYSTEM DISABLE RESTRICTED SESSION
Oracle Parallel Server is upgraded to the new release.
Snapshots upgraded from release 8.0 or imported from a release 8.0 database cannot use the new summary management features available in release 8.1. If you want to use these new features, complete the following steps for each upgraded snapshot and for each snapshot imported from release 8.0:
For example, on a snapshot named SSORDERS, issue the following command:
ALTER SNAPSHOT ssorders ENABLE QUERY REWRITE;
The following sections describe the actions required to upgrade the Advanced Queuing (AQ) option.
|
Note: This section only applies to systems that were upgraded from release 8.0.3 of Oracle. If you never ran release 8.0.3 of Oracle on your current system, you do not need to perform the procedure in this section, and you can move on to "Upgrade Your Queue Tables". |
Release 8.0.4 introduced an extended address field in the AQ$_AGENT datatype; the address field was extended to 1024 bytes. If you installed release 8.0.3, you must perform the procedure in this section to use the extended address field.
Also, if you installed release 8.0.3 but performed the steps described in this section to extend the address field when you upgraded to a prior release, such as release 8.0.4, you need not perform the steps below. Or, if you do not plan to use the AQ, you need not perform these steps.
However, if you installed release 8.0.3, you have not performed these steps in a prior release, and you want to use the extended address field, you should perform this procedure now. Oracle Corporation recommends using the extended address field.
To use the extended address field, complete the following steps:
SVRMGR> SHUTDOWN IMMEDIATE
initsid.ora file, comment out the JOB_QUEUE_PROCESSES and AQ_TM_PROCESSES initialization parameters. You can remove the comments on these parameters after this procedure is complete.
$ORACLE_HOME/rdbms/admin directory.
SVRMGR> CONNECT INTERNAL;
SVRMGR> STARTUP RESTRICT
You may need to use the PFILE option to specify the location of your initsid.ora file.
SVRMGR> SPOOL catoutaq.log
If you want to see the output of the script you will run on your screen, you also can issue a SET ECHO ON statement:
SVRMGR> SET ECHO ON
To determine the existing queue tables in the database, issue the following SQL statement:
SELECT owner, queue_table FROM dba_queue_tables;
You also must export the SYSTEM.DEF$_AQCALL and SYSTEM.DEF$_AQERROR queue tables and then import them in Step 12. These default queue tables are used by Advanced Replication.
|
See Also:
Oracle8i Application Developer's Guide - Advanced Queuing for more information about the required procedure for exporting queue tables. |
Oracle8i Application Developer's Guide - Advanced Queuing for information about the DBMS_AQADM.DROP_QUEUE_TABLE procedure.
See Also:
catnoqueue.sql to drop the existing AQ dictionary tables:
@catnoqueue.sql
catqueue.sql to redefine the new types and dictionary tables:
@catqueue.sql
SELECT owner, queue_table FROM dba_queue_tables;
The following is an example of the output you should see when you issue this SQL statement:
OWNER QUEUE_TABLE ------------------------------ ------------------------------ SYSTEM DEF$_AQCALL SYSTEM DEF$_AQERROR AQUSER1 QUEUE_TABLE1 AQUSER2 QUEUE_TABLE2
SVRMGR> SPOOL OFF
Then, check the spool file and verify that the packages and procedures compiled successfully. You named the spool file in Step 7; the suggested name was catoutaq.log. Correct any problems you find in this file.
If you specified SET ECHO ON, you may want to SET ECHO OFF now:
SVRMGR> SET ECHO OFF
SVRMGR> ALTER SYSTEM DISABLE RESTRICTED SESSION;
You can now use the extended address field.
The following release 8.1 AQ enhancements are available only if you upgrade your existing queue tables:
To upgrade an existing queue table, run the DBMS_AQADM.MIGRATE_QUEUE_TABLE procedure, specifying 8.1 for the COMPATIBLE option. For example, for a queue table named TB_QUEUE owned by SCOTT user, run the following procedure:
EXECUTE dbms_aqadm.migrate_queue_table ( queue_table => 'scott.tb_queue', compatible => '8.1');
To create a new queue table that is release 8.1 compatible, connect as the owner of the queue table and run the DBMS_AQADM.CREATE_QUEUE_TABLE procedure, specifying 8.1 for the COMPATIBLE option, as in the following example:
EXECUTE dbms_aqadm.create_queue_table( queue_table => 'scott.tkaqqtpeqt', queue_payload_type =>'message', sort_list => 'priority,enq_time', multiple_consumers => true, comment => 'Creating queue with priority and enq_time sort order', compatible => '8.1');
When you upgrade your database from release 8.0 to release 8.1, the existing user-defined datatypes (such as object types, nested tables, and varrays) retain the release 8.0 representation format. The representation format is changed in release 8.1 to optimize disk space utilization for better performance.
You can continue to use the release 8.0 format in release 8.1, but then you will not benefit from the improved representation format. Therefore, upgrading your existing user-defined datatypes is not required, but it is recommended.
To use the new format for existing user-defined datatypes, complete the following steps:
Your recovery catalog schema for the upgraded database resides in a database that is separate from the database you upgraded. If you upgraded the Recovery Manager executable to release 8.1, you must upgrade the recovery catalog to release 8.1 as well.
Also, if you have multiple databases of different releases managed by a single recovery catalog, you need to consider compatibility issues between a particular Recovery Manager release and the recovery catalog release. For example, release 8.1.3 and 8.1.4 of Recovery Manager cannot access a release 8.1.5 or higher recovery catalog. Therefore, in this case, you must upgrade all of the databases managed by the recovery catalog to release 8.1.5 or higher. For more information about recovery catalog compatibility with Recovery Manager, see "Recovery Manager".
Complete the following steps to upgrade the recovery catalog:
For example, if RCAT/RCAT is the user name and password for the recovery catalog owner, and RECDB is the network service name, enter the following:
rman rcvcat rcat/rcat@recdb
The first time you connect to an older recovery catalog with the 8.1 release of Recovery Manager, you will see message RMAN-06186, indicating that the recovery catalog must be upgraded.
Here is the log from a session that upgrades the recovery catalog from release 8.0.4:
Recovery Manager: Release 8.1.5.0.0 RMAN-06008: connected to recovery catalog database RMAN-06186: PL/SQL package rcat.DBMS_RCVCAT version 08.00.04 in RCVCAT database is too old RMAN> upgrade catalog RMAN-06435: recovery catalog owner is rcat RMAN-06442: enter UPGRADE CATALOG command again to confirm catalog upgrade RMAN> upgrade catalog RMAN-06408: recovery catalog upgraded to version 08.01.05
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.
To run the utlrp.sql script, complete the following steps:
$ORACLE_HOME/rdbms/admin directory.
SVRMGR> CONNECT INTERNAL;
utlrp.sql:
SVRMGR> @utlrp.sql
Oracle Corporation highly recommends running utlrp.sql.
The following sections provide information about actions you may need to perform after you upgrade to the new 8.1 release.
In release 8.1, a new SQL operator, TO_LOB, copies data from a LONG column in one table to a LOB in another table.
A bad date constraint involves invalid date manipulation, which is a date manipulation 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.
To run the utlconst.sql script, complete the following steps:
$ORACLE_HOME/rdbms/admin directory.
SVRMGR> CONNECT INTERNAL;
SVRMGR> SPOOL utlresult.log SVRMGR> @utlconst.sql SVRMGR> SPOOL OFF
After you run the script, the utlresult.log file includes all the constraints that have invalid date constraints. The utlconst.sql script does not correct bad constraints, but instead disables them. You should either drop the bad constraints or recreate them after you make the necessary changes.
Beginning with release 8.1, parallel execution message buffers can be allocated from large pool. In past releases, this allocation was from shared pool. To avoid problems resulting from this change, you may need to adjust the following parameters in your initsid.ora file:
"Parallel Execution Allocated from Large Pool" for information about adjusting these parameters.
See Also:
Each new release of Oracle introduces new initialization parameters, changes some parameters, and obsoletes some parameters. You should adjust your initsid.ora file to account for these changes and to take advantage of new initialization parameters that may be beneficial to your system.
|
See Also:
Appendix B, "Changes to Initialization Parameters" for lists of the new, changed, and obsoleted initialization parameters in release 8.1, and see Oracle8i Reference for detailed information about each parameter. |
The COMPATIBLE initialization parameter controls the compatibility level of your database. Set the COMPATIBLE initialization parameter in your initsid.ora file based on the compatibility level you want for your upgraded database.
The OUTLN user is created automatically during installation of Oracle8i. This user has DBA privileges. Use the ALTER USER command to change the password for this user. Oracle8i adds the OUTLN user schema to support Plan Stability. The OUTLN user acts as a place to centrally manage metadata associated with stored outlines.
If you are using Oracle Enterprise Manager to manage database objects, your listener.ora file must be configured with information about the database in the following manner:
sid_list_listener_name = (sid_list = (sid_desc = (global_dbname = global_database_name) (oracle_home = oracle_home) (sid_name = sid) ) )
GLOBAL_DBNAME identifies the global database name, which is a name comprised of the database name and domain name of the database. ORACLE_HOME identifies the directory where your Oracle software is installed, and SID_NAME identifies the Oracle System Identifier of the database instance.
For example, the following information is for a database with a listener name of LISTENER. The global database name of SAL.COM is referenced by an instance with a SID of SAL, using the software installed in the /oracle/product/8.1 directory:
sid_list_listener = (sid_list = (sid_desc = (global_dbname = sal.com) (oracle_home = /oracle/product/8.1) (sid_name = sal) ) )
If you are not using Oracle Enterprise Manager, you do not need to configure information about the database, because an Oracle8i database instance registers itself with the listener automatically.
|
See Also:
Net8 Administrator's Guide for more information about configuring the |
If you upgraded from release 8.1.4, and you created Java objects before upgrading, you must drop these objects. The Java format changed in release 8.1.5, causing incompatibilities between release 8.1.4 Java objects and release 8.1.5 and higher Java objects. If you upgraded from an 8.0 release, you do not need to complete this procedure.
To drop the Java objects created in release 8.1.4, complete the following steps:
$ORACLE_HOME/rdbms/admin directory.
SQL> SPOOL utljavaout.log SQL> @utljavarm.sql SQL> SPOOL OFF
Check the spool file and verify that the statements executed successfully.
$ORACLE_HOME/javavm/install directory.
SQL> SPOOL initjvmout.log SQL> @initjvm.sql SQL> SPOOL OF Check the spool file and verify that the statements executed successfully.
If you exported your Java source, class, and resource objects before you upgraded, you can import them using the Import utility after you have completed all of the steps in the above procedure.
|
See Also:
Oracle8i Utilities for information about exporting and importing Java source, class, and resource objects. |
The instructions in this section guide you through changing the word-size of your current release (switching from 32-bit software to 64-bit software or vice versa).
Complete the following steps to change the word-size of your current release:
SVRMGR> CONNECT INTERNAL;
SVRMGR> SHUTDOWN IMMEDIATE
$ORACLE_HOME/rdbms/admin directory.
SVRMGR> CONNECT INTERNAL;
SVRMGR> STARTUP RESTRICT
You may need to use the PFILE option to specify the location of your initsid.ora file.
SVRMGR> SPOOL catoutw.log
If you want to see the output of the script you will run on your screen, you also can issue a SET ECHO ON statement:
SVRMGR> SET ECHO ON
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.
SVRMGR> SPOOL OFF
Then, check the spool file and verify that the packages and procedures compiled successfully. You named the spool file in Step 10; the suggested name was catoutw.log. Correct any problems you find in this file.
If you specified SET ECHO ON, you may want to SET ECHO OFF now:
SVRMGR> SET ECHO OFF
SVRMGR> ALTER SYSTEM DISABLE RESTRICTED SESSION
The word-size of your database is changed. You can open the database for normal use.
