Oracle10g Release1 Upgrade to 10204

Oracle10g Release 10101 upgrade to Oracle10g Release 10204

1010X0 TO 102040

1 Install 102010 software The software can be downloaded from the following link

httpwwworaclecomtechnologysoftwareproductsdatabaseindexhtml Note 1697061 Oraclereg Database Installation and Configuration Requirements Quick Reference (805 to 111)

2 Install the 102040 patchset on top of 102010 ORACLE_HOMEPatchset number is 6810189

httpupdatesoraclecomdownload6810189html

3 Upgrade the database to 102040 Note 4195501 Different Upgrade Methods For Upgrading Your Database

Note 3168891 Complete checklist for manual upgrades to 10gR2

REFERENCE List of fixes included in 10204 Note 4014361

Known issues and alerts affecting 10204 Note 5555791

SubjectDifferent Upgrade Methods For Upgrading Your Database Doc ID4195501 Type HOWTO Modified Date 13-JUL-2008 Status MODERATED

In this Document Goal Solution References

This document is being delivered to you via Oracle Supports Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review

Applies to

Oracle Server - Enterprise Edition - Version 9201 to 11106Information in this document applies to any platform

Goal

What are thedifferent upgrade methods for upgrading your database (This note applies to all the database upgrades to 9iR2 10gR110gR211gR1 )

Solution

The different upgrade methods you can use to upgrade your database to the new Oracle Database 9i10g11g release are

1) Database Upgrade Assistant (DBUA) 2) Manual Upgrade 3) ExportImport 4) Data Copying

1) DBUA (Database Upgrade Assistant)

The Database Upgrade Assistant (DBUA) interactively steps you through the upgrade process and configures the database for the new Oracle Database 10g release The DBUA automates the upgrade process by performing all of the

tasks normally performed manually The DBUA makes appropriate recommendations for configuration options such as tablespaces and redo logs You can then act on these recommendations This method is very easy and user friendly But if any error occurs it will take time to diagnose the error as the upgrade process is automatically by the upgrade assistant For more informationrefer to the following link 102=gt httpdownload-eastoraclecomdocscdB19306_01server102b14238upgradehtmi1011482 111=gthttpdownloadoraclecomdocscdB28359_01server111b28300upgradehtmi1011482

Note 5564771 Complete Checklist for Upgrades to 11gR1 using DBUA

2) Manual upgrade

A manual upgrade consists of running SQL scripts and utilities from a command line to upgrade a database to the new Oracle Database 10g release A manual upgrade gives you finer control over the upgrade process as it is done step by step manually So if any error occurs it is easy to diagnose the error While a manual upgrade gives you finer control over the upgrade process it is more susceptible to error if any of the upgrade or pre-upgrade steps are either not followed or are performed out of order When manually upgrading a database perform the following pre-upgrade steps

bull Analyze the database using the Pre-Upgrade Information Tool The Upgrade Information Tool is SQL script that ships with the new Oracle Database 10g release and must be run in the environment of the database being upgraded The Upgrade Information Tool displays warnings about possible upgrade issues with the database It also displays information about required initialization parameters for the new Oracle Database 10g release

bull Prepare the new Oracle Home bull Perform a backup of the database

Depending on the release of the database being upgraded you may need to perform additional pre-upgrade steps (adjust the parameter file for the upgrade remove obsolete initialization parameters and adjust initialization parameters that might cause upgrade problems) Refer the metalink notes for manual upgrade Note 4298251( Complete Checklist for Manual Upgrades to 11gR1 )Note 2638091(Complete checklist for manual upgrades to 10gR1 (1010x)) Note 3168891(Complete checklist for manual upgrades to 10gR2) Note 466181110g Upgrade Companion

3) ExportImport

The ExportImport upgrade method does not change the current database which enables the database to remain available throughout the upgrade process However if a consistent snapshot of the database is required (for data integrity or other purposes) then the database must run in restricted mode or must otherwise be protected from changes during the export procedure Because the current database can remain available you can for example keep an existing production database running while the new Oracle Database 10g database is being built at the same time by ExportImport During the upgrade to maintain complete database consistency changes to the data in the database cannot be permitted without the same changes to the data in the new Oracle Database Most importantly the ExportImport operation results in a completely new database Although the current database ultimately contains a copy of the specified data the upgraded database may perform differently from the original database For example although ExportImport creates an identical copy of the database other factors such as disk placement of data and unset tuning parameters may cause unexpected performance problems Upgrading an entire database by using ExportImport can take a long time especially compared to using the DBUA or performing a manual upgrade Therefore you may need to schedule the upgrade during non-peak hours or make provisions for propagating to the new database any changes that are made to the current database during the upgrade For more information refer to the following link httpdownload-eastoraclecomdocscdB19306_01server102b14238expimphtmi262247

4) Data Copying

You can copy data from one Oracle Database to another using database links For example you can create new tables and fill the tables with data by using the INSERT INTO statement and the CREATE TABLE AS statementCopying data and ExportImport offer the same advantages for upgrading Using either method you can defragment data files and restructure the database by creating new tablespaces or modifying existing tables or tablespaces In addition you can copy only specified database objects or users Copying data however unlike ExportImport enables the selection of specific rows of tables to be placed into the new database Copying data is a good method for copying only part of a database table In contrast using ExportImport you can copy only entire tables

Oraclereg Database Upgrade Guide 10g Release 2 (102) Part Number B14238-01 httpdownload-eastoraclecomdocscdB19306_01server102b14238upgradehtm

References

Note 3168891 - Complete Checklist for Manual Upgrades to 10gR2Note 4298251 - Complete Checklist for Manual Upgrades to 11gR1Note 4661811 - 10g Upgrade Companion

SubjectComplete Checklist for Manual Upgrades to 10gR2 Doc ID3168891 Type BULLETIN Modified Date 29-SEP-2008 Status PUBLISHED

In this Document Purpose Scope and Application Complete Checklist for Manual Upgrades to 10gR2 Steps for Upgrading the Database to 10g Release 2 Preparing to Upgrade Upgrading to the New Oracle Database 10g Release 2 After Upgrading a Database Useful Hints Appendix A Initialization Parameters Obsolete in 10g Appendix B Initialization Parameters Deprecated in 10g Known issues Revision History References

Applies to

Oracle Server - Enterprise Edition - Version 8174 to 10201Information in this document applies to any platform

Purpose

This document is created for use as a guideline and checklist when manually upgrading Oracle 8i Oracle 9i or Oracle 10gR1 to Oracle 10gR2

This document is divided into three major sections-- Preparing to Upgrade -- Upgrading to the New Oracle Database 10g Release 2-- After Upgrading a Database

Please read the whole article before starting to perform an upgrade

Scope and Application

Database administrators

Complete Checklist for Manual Upgrades to 10gR2

Prerequisites and recommendations

bull Install Oracle 10g Release 2 in a new Oracle Home bull Install JAccelerator (NCOMP) into the home from the Companion media to avoid the issue in

Note 2936581 101 or 102 Patchset Install Getting ORA-29558 JAccelerator (NCOMP) And ORA-06512

bull Download and install the latest available 1020x patchset Review the following note for a list of available patchsets and details of any well known issues

Note 3169001 ALERT Oracle 10g Release 2 (102) Support Status and Alerts

bull Install the latest available Critical Patch Update

Note 2907381 Oracle Critical Patch Update Program General FAQ

bull If you are upgrading to 10203 review the following alerts before performing the upgrade and apply any required patches

Note 4064721 Mandatory Patch 5752399 for 10203 on Solaris 64-bit and Filesystems Managed By Veritas or Solstice Disk Suite software

Note 4122711 ORA-600 [22635] and ORA-600 [KOKEIIX1] Reported While Upgrading or Patching Databases to 10203

NOTE If your database was originally created as 32-bit even if it is 64-bit now apply the patches recommended in Note 4122711

bull If you are upgrading to any 1020x version review the following alert before performing the upgrade and apply any required patch

Note 4714791 IOT Corruptions After Upgrade from COMPATIBLE lt= 92 to COMPATIBLE gt= 101

bull If you are upgrading to any 1020x version on AIX5L review the following note before upgrading

Note 5572421 Upgrade Gives Ora-29558 Error Despite of JAccelerator Has Been Installed

bull If you are upgrading to 10204 review the following notes before upgrading

Note 5656001 Error in Catupgrd ORA-00904 In DBMS_SQLPANote 6037141 10204 Catupgrdsql Fails With ORA-03113 Creating SYSKU$_XMLSCHEMA_VIEW

bull If you are upgrading a 32-bit database to 1020x 64-bit review the following note and remove the use_indirect_data_buffers=TRUE parameter setting before performing the upgrade

Note 4659511 ORA-600 [kcbvmap_1] or Ora-600 [Kcliarq_2] On Startup Upgrade Moving From a 32-Bit To 64-Bit Release

bull Either take a cold or hot backup for your database bull Make sure to take a backup of Oracle Home and Central Inventory Central inventory can be located by the

contents of oraInstloc files oraInstloc is available in the following locations on various platforms

varoptoracleoraInstloc -- SolarisetcoraInstloc -- other operating systemsHKEY_LOCAL_MACHINESOFTWAREORACLEinst_loc -- On windows Platform

bull Verify kernel parameters are set according to the 10gR2 Installation Guide bull Verify that all OS packages and patches are installed as per the Installation Guide

Please also note that Oracle have made an Oracle10g Upgrade Companion available For further information please review

Note 4661811 10g Upgrade Companion

The above document is continually updated as new information becomes available

Compatibility Matrix

Minimum Version of the database that can be directly upgraded to Oracle 10g Release 2 8174 -gt 102XXX9014 or 9015 -gt 102XXX

9204 or higher -gt 102XXX10102 or higher -gt 102XXX

The following database version will require an indirect upgrade path

733 (or lower) -gt 734 -gt 817 -gt 8174 -gt 102XXX734 -gt 817 -gt 8174 -gt 102XXX80n -gt 817 -gt 8174 -gt 102XXX81n -gt 817 -gt 8174 -gt 102XXX

Steps for Upgrading the Database to 10g Release 2

Preparing to Upgrade

In this section all the steps need to be performed to the previous version of Oracle Please note that the database must be running in normal mode in the old release

Step 1

Log in to the system as the owner of the new 10gR2 ORACLE_HOME and copy the following files from the 10gR2 ORACLE_HOMErdbmsadmin directory to a directory outside of the Oracle home such as the tmp directory on your system

ORACLE_HOMErdbmsadminutlu102isqlORACLE_HOMErdbmsadminutltzuv2sql

Make a note of the new location of these files

Step 2

Change to the temporary directory that you copied files to in Step 1

Start SQLPlus and connect to the database instance as a user with SYSDBA privileges Then run and spool the utlu102isql file sqlplus as sysdba

SQLgt spool Database_InfologSQLgt utlu102isqlSQLgt spool off

Then check the spool file and examine the output of the upgrade information tool The sections which follow describe the output of the Upgrade Information Tool (utlu102isql)

NOTE If you are upgrading from 8174 the utlu102isql script will fail with an ORA-1403 error Please follow the workaround in Note 56405278 (or Note 4070311) to enable utlu102isql to run

Database

This section displays global database information about the current database such as the database name release number and compatibility level A warning is displayed if the COMPATIBLE initialization parameter needs to be adjusted before the database is upgraded

Logfiles

This section displays a list of redo log files in the current database whose size is less than 4 MB For each log file the file name group number and recommended size is displayed New files of at least 4 MB (preferably 10 MB) need to be created in the current database Any redo log files less than 4 MB must be dropped before the database is upgraded

Tablespaces

This section displays a list of tablespaces in the current database For each tablespace the tablespace name and minimum required size is displayed In addition a message is displayed if the tablespace is adequate for the upgrade If the tablespace does not have enough free space then space must be added to the tablespace in the current database Tablespace adjustments need to be made before the database is upgraded

Update Parameters

This section displays a list of initialization parameters in the parameter file of the current database that must be adjusted before the database is upgraded The adjustments need to be made to the parameter file after it is copied to the new Oracle Database 10g release

Deprecated Parameters

This section displays a list of initialization parameters in the parameter file of the current database that are deprecated in the new Oracle Database 10g release

Obsolete Parameters

This section displays a list of initialization parameters in the parameter file of the current database that are obsolete in the new Oracle Database 10g release Obsolete initialization parameters need to be removed from the parameter file before the database is upgraded

Components

This section displays a list of database components in the new Oracle Database 10g release that will be upgraded or installed when the current database is upgraded

Miscellaneous Warnings

This section provides warnings about specific situations that may require attention before andor after the upgrade

SYSAUX Tablespace

This section displays the minimum required size for the SYSAUX tablespace which is required in Oracle Database 10g The SYSAUX tablespace must be created after the new Oracle Database 10g release is started and BEFORE the upgrade scripts are invoked

Step 3

Check for the deprecated CONNECT Role

After upgrading to 10gR2 the CONNECT role will only have the CREATE SESSION privilege the other privileges granted to the CONNECT role in earlier releases will be revoked during the upgrade To identify which users and roles in your database are granted the CONNECT role use the following query

SELECT grantee FROM dba_role_privsWHERE granted_role = CONNECT andgrantee NOT IN (SYS OUTLN SYSTEM CTXSYS DBSNMPLOGSTDBY_ADMINISTRATOR ORDSYS ORDPLUGINS OEM_MONITOR WKSYS WKPROXYWK_TEST WKUSER MDSYS LBACSYS DMSYSWMSYS OLAPDBA OLAPSVR OLAP_USER OLAPSYS EXFSYS SYSMAN MDDATASI_INFORMTN_SCHEMA XDB ODM)

If users or roles require privileges other than CREATE SESSION then grant the specific required privileges prior to upgrading The upgrade scripts adjust the privileges for the Oracle-supplied users

In Oracle 92x and 101x CONNECT role includes the following privileges

SELECT GRANTEEPRIVILEGE FROM DBA_SYS_PRIVSWHERE GRANTEE=CONNECT

GRANTEE PRIVILEGE ------------------------------ ---------------------------CONNECT CREATE VIEWCONNECT CREATE TABLECONNECT ALTER SESSIONCONNECT CREATE CLUSTERCONNECT CREATE SESSIONCONNECT CREATE SYNONYMCONNECT CREATE SEQUENCECONNECT CREATE DATABASE LINK

In Oracle 102 the CONNECT role only includes CREATE SESSION privilege

Step 4

Create the script for dblink incase of downgrade of the database

During the upgrade to 10gR2 any passwords in database links will be encrypted To downgrade back to the original release all of the database links with encrypted passwords must be dropped prior to the downgrade Consequently the database links will not exist in the downgraded database If you anticipate a requirement to be able to downgrade back to your original release then save the information about affected database links from the SYSLINK$ table so that you can recreate the database links after the downgrade

Following script can be used to construct the dblink

SELECTcreate ||DECODE(UNAMEPUBLICpublic )||database link ||CHR(10)||DECODE(UNAMEPUBLICNull UNAME||)|| LNAME||chr(10)||connect to || LUSERID || identified by ||LPASSWORD|| using || Lhost || ||chr(10)|| TEXTFROM syslink$ Lsysuser$ UWHERE LOWNER = UUSER

Step 5

Check for the TIMESTAMP WITH TIMEZONE Datatype Please this step is only required for the 10gR1 The may affect existing data of TIMESTAMP WITH TIME ZONE datatype For example if users enter TIMESTAMP 2003-02-17 090000 AmericaSao_Paulo we convert the data to UTC based on the transition rules in the time zone file and store them on the disk So 2003-02-17 110000 along with the time zone id for AmericaSao_Paulo is stored because the offset for this particular time is -0200 Now the transition rules are modified and the offset for this particular time is changed to -0300 when users retrieve the data they will get 2003-02-17 080000 AmericaSao_Paulo There is one hour difference compared to the original value

Change to the temporary directory that you copied files to in Step 1

Start SQLPlus and connect to the database instance as a user with SYSDBA privileges Then run and spool the utltzuv2sql file

$ sqlplus as sysdba

SQLgt spool TimeZone_InfologSQLgt utltzuv2sqlSQLgt spool off

If the utltzuv2sql script identifies columns with time zone data affected by a database upgrade then use the solution to solve this problem

create tables with the time zone information in character format (for example TO_CHAR(column YYYY-MM-DD HH24MISSXFF TZR) and recreate the TIMESTAMP data from these tables after the upgrade

For example user scott has a table tztabcreate table tztab(x number primary key y timestamp with time zone)insert into tztab values(1 timestamp )

Before upgrade you can create a table tztab_back note column y here is defined as VARCHAR2 to preserve the original value

create table tztab_back(x number primary key y varchar2(256))insert into tztab_back select xto_char(y YYYY-MM-DD HH24MISSXFF TZR) from tztab

After upgrade you need update the data in the table tztab using the value in tztab_backupdate tztab t set ty = (select to_timestamp_tz(t1yYYYY-MM-DD HH24MISSXFF TZR) from tztab_back t1 where tx=t1x)

Step 6

Starting in Oracle 9i the National Characterset (NLS_NCHAR_CHARACTERSET) will be limited to UTF8 and AL16UTF16 Any other NLS_NCHAR_CHARACTERSET will no longer be supported

For more details refer to Note 2769141 The National Character Set in Oracle 9i and 10g

NOTE If you are upgrading from Oracle9i to 10g skip to step 7

When upgrading from Oracle8i to 10g the value of NLS_NCHAR_CHARACTERSET is based on value currently used in the Oracle8i version

If the NLS_NCHAR_CHARACTERSET is UTF8 then new it will stay UTF8 In all other cases the NLS_NCHAR_CHARACTERSET is changed to AL16UTF16 and -if used- N-type data (= data in columns using NCHAR NVARCHAR2 or NCLOB ) may need to be converted

The change itself is done in step 38 by running the upgrade script

To check whether there are any N-type objects in a database run the following query

select distinct OWNER TABLE_NAME from DBA_TAB_COLUMNS where DATA_TYPE in (NCHARNVARCHAR2 NCLOB) and OWNER not in (SYSSYSTEMXDB)

If no rows are returned it should mean that the database is not using N-type columns for user data so simply go to the next step

If you have N-type columns for user data then run the following query

SQLgt select from nls_database_parameters where parameter =NLS_NCHAR_CHARACTERSET

If you are using N-type columns AND your National Characterset is UTF8 or is in the following list

JA16SJISFIXED JA16EUCFIXED JA16DBCSFIXED ZHT32TRISFIXED

KO16KSC5601FIXED KO16DBCSFIXED US16TSTFIXED ZHS16CGB231280FIXEDZHS16GBKFIXED ZHS16DBCSFIXED ZHT16DBCSFIXED ZHT16BIG5FIXEDZHT32EUCFIXED

then also simply go to point next step The conversion of the user data itself will then be done in step 38

If you are using N-type columns AND your National Characterset is NOT UTF8 or NOT in the following list

JA16SJISFIXED JA16EUCFIXED JA16DBCSFIXED ZHT32TRISFIXEDKO16KSC5601FIXED KO16DBCSFIXED US16TSTFIXED ZHS16CGB231280FIXEDZHS16GBKFIXED ZHS16DBCSFIXED ZHT16DBCSFIXED ZHT16BIG5FIXEDZHT32EUCFIXED

(your current NLS_NCHAR_CHARACTERSET is for example US7ASCII WE8ISO8859P1 CL8MSWIN1251 )

then you have to

bull change the tables to use CHAR VARCHAR2 or CLOB instead the N-typeor

bull use exportimport the table(s) containing N-type column and truncate those tables before migrating to 10g

The recommended NLS_LANG during export is simply the NLS_CHARACTERSET not the NLS_NCHAR_CHARACTERSET

Step 7

When upgrading to Oracle Database 10g optimizer statistics are collected for dictionary tables that lack statistics This statistics collection can be time consuming for databases with a large number of dictionary tables but statistics gathering only occurs for those tables that lack statistics or are significantly changed during the upgrade

To decrease the amount of downtime incurred when collecting statistics you can collect statistics prior to performing the actual database upgrade

As of Oracle Database 10g Release 101 Oracle recommends that you use the DBMS_STATSGATHER_DICTIONARY_STATS procedure to gather these statistics You can enter the following

$ sqlplus as sysdba

SQLgt EXEC DBMS_STATSGATHER_DICTIONARY_STATS

For Oracle8i and Oracle9i use the DBMS_STATSGATHER_SCHEMA_STATS procedure to gather statistics

Backup the existing statistics as follows

$ sqlplus as sysdbaSQLgtspool sdict

SQLgtgrant analyze any to sys

SQLgtexec dbms_statscreate_stat_table(SYSdictstattab)

SQLgtexec dbms_statsexport_schema_stats(WMSYSdictstattabstatown =gt SYS)SQLgtexec dbms_statsexport_schema_stats(MDSYSdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(CTXSYSdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(XDBdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(WKSYSdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(LBACSYSdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(OLAPSYSdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(DMSYSdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(ODMdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(ORDSYSdictstattabstatown =gt SYS)

SQLgtexec dbms_statsexport_schema_stats(ORDPLUGINSdictstattabstatown =gt SYS)SQLgtexec dbms_statsexport_schema_stats(SI_INFORMTN_SCHEMAdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(OUTLNdictstattabstatown =gt SYS)SQLgtexec dbms_statsexport_schema_stats(DBSNMPdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(SYSTEMdictstattabstatown =gt SYS) SQLgtexec dbms_statsexport_schema_stats(SYSdictstattabstatown =gt SYS)

SQLgtspool off

This data is useful if you want to revert back the statistics

For example the following PLSQL subprograms import the statistics for the SYS schema after deleting the existing statistics

exec dbms_statsdelete_schema_stats(SYS)exec dbms_statsimport_schema_stats(SYSdictstattab)

To gather statistics run this script connect to the database AS SYSDBA using SQLPlus

$ sqlplus as sysdba

SQLgtspool gdict

SQLgtgrant analyze any to sys

SQLgtexec dbms_statsgather_schema_stats(WMSYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(MDSYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(CTXSYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(XDBoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(WKSYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(LBACSYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(OLAPSYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(DMSYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(ODMoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(ORDSYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(ORDPLUGINSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(SI_INFORMTN_SCHEMAoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(OUTLNoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(DBSNMPoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE

- method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(SYSTEMoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE) SQLgtexec dbms_statsgather_schema_stats(SYSoptions=gtGATHER estimate_percent =gt DBMS_STATSAUTO_SAMPLE_SIZE - method_opt =gt FOR ALL COLUMNS SIZE AUTO cascade =gt TRUE)

SQLgtspool off

Step 8

Check for invalid objects in the database

spool invalid_prelstselect substr(owner112) ownersubstr(object_name130) objectsubstr(object_type130) type status fromdba_objects where status ltgt VALIDspool off

Run the following script as a user with SYSDBA privs using SQLPlus and then requery invalid objects

sqlplus as sysdbaSQLgt rdbmsadminutlrpsql

This last query will return a list of all objects that cannot be recompiled before the upgrade in the file invalid_prelst

If you are upgrading from Oracle9iR2 (92) verify that the view dba_registry contains data If the view is empty run the following scripts from the 92 home

sqlplus as sysdba SQLgt rdbmsadmincatalogsql SQLgt rdbmsadmincatprocsql SQLgt rdbmsadminutlrpsql

and verify that the dba_registry view now contains data

Step 9

Check for corruption in the dictionary use the following commands in sqlplus connected as sys

Set verify offSet space 0Set line 120Set heading offSet feedback offSet pages 1000Spool analyzesql

Select Analyze cluster ||cluster_name|| validate structure cascadefrom dba_clusterswhere owner=SYSunionSelect Analyze table ||table_name|| validate structure cascade from dba_tableswhere owner=SYS and partitioned=NO and (iot_type=IOT or iot_type is NULL)unionSelect Analyze table ||table_name|| validate structure cascade into invalid_rowsfrom dba_tableswhere owner=SYS and partitioned=YES

spool off

This creates a script called analyzesql Now execute the following steps

$ sqlplus as sysdbaSQLgt $ORACLE_HOMErdbmsadminutlvalidsqlSQLgt analyzesql

This script (analyzesql) should not return any errors

Step 10

Ensure that all Snapshot refreshes are successfully completed and that replication is stopped

$ sqlplus as sysdba SQLgt select distinct(trunc(last_refresh)) from dba_snapshot_refresh_times

Step 11

Stop the listener for the database

$ lsnrctl LSNRCTLgt stop

Ensure no files need media recovery

$ sqlplus as sysdba SQLgt select from v$recover_file

This should return no rows

Step 12

Ensure no files are in backup mode

SQLgt select from v$backup where status=NOT ACTIVE

This should return no rows

Step 13

Resolve any outstanding unresolved distributed transaction

SQLgt select from dba_2pc_pending

If this returns rows you should do the following

SQLgt select local_tran_id from dba_2pc_pendingSQLgt execute dbms_transactionpurge_lost_db_entry() SQLgt commit

Step 14

Disable all batch and cron jobs

Step 15

Ensure the users sys and system have system as their default tablespace

SQLgt select username default_tablespace from dba_users where username in (SYSSYSTEM)

To modify use

SQLgt alter user sys default tablespace SYSTEM SQLgt alter user system default tablespace SYSTEM

Step 16

Ensure that the aud$ is in the system tablespace when auditing is enabled

SQLgt select tablespace_name from dba_tables where table_name=AUD$

Step 17

Note down where all control files are located

SQLgt select from v$controlfile

Step 18

If table XDBMIGR9202STATUS exists in the database drop it before upgrading the database (to avoid the issue described in Note 3560821)

Step 19

Shutdown the database

$ sqlplus as sysdba SQLgt shutdown immediate

Step 20

Perform a full cold backup (or an online backup using RMAN)

You can either do this by manually copying the files or sign on to RMAN

$ rman target nocatalog

And issue the following RMAN commands

RUNALLOCATE CHANNEL chan_name TYPE DISKBACKUP DATABASE FORMAT some_backup_directoryU TAG before_upgradeBACKUP CURRENT CONTROLFILE TO save_controlfile_location

Upgrading to the New Oracle Database 10g Release 2

Step 21

Update the initora file

- Make a backup of the old initora file

- Copy it from the old (pre-102) ORACLE_HOME to the new (102) ORACLE_HOME

On UnixLinux the default location of the file is the $ORACLE_HOMEdbs directory

- Comment out any obsoleted parameters (listed in appendix A)

- Change all deprecated parameters (listed in appendix B)

- Set the COMPATIBLE initialization parameter to an appropriate value If you are upgrading from 8174 then set the COMPATIBLE parameter to 920 until after theupgrade has been completed successfully If you are upgrading from 920 or 1010then leave the COMPATIBLE parameter set to its current value until the upgrade has been completed successfully This will avoid any unnecessary ORA-942 errorsfrom being reported in SMON trace files during the upgrade (because the upgradeis looking for 102 objects that have not yet been created)

- If you have the parameter NLS_LENGTH_SEMANTICS currently set to CHAR change the valueto BYTE during the upgrade (to avoid the issue described in Note 46385508)

- Verify that the parameter DB_DOMAIN is set properly

- Make sure the PGA_AGGREGATE_TARGET initialization parameter is set to at least 24 MB

- Ensure that the SHARED_POOL_SIZE and the LARGE_POOL_SIZE are at least 150Mb Please also the check the KNOWN ISSUES section

- Make sure the JAVA_POOL_SIZE initialization parameter is set to at least 150 MB

- Ensure there is a value for DB_BLOCK_SIZE

- On Windows operating systems change the BACKGROUND_DUMP_DEST and USER_DUMP_DEST initialization parameters that point to RDBMS80 or any other environment variableto point to the following directories instead

BACKGROUND_DUMP_DEST to ORACLE_BASEoradataDB_NAME

and

USER_DUMP_DEST to ORACLE_BASEoradataDB_NAMEarchive

- Comment out any existing AQ_TM_PROCESSES and JOB_QUEUE_PROCESSES parameter settings and add new lines in the initoraspfileora that explicitly set AQ_TM_PROCESSES=0 and JOB_QUEUE_PROCESSES=0 for the duration of the upgrade The startup upgrade command (see step 30) should ensure that these settings are used but its worth making sure

- If you have defined an UNDO tablespace set the parameter UNDO_MANAGEMENT=AUTO (otherwise either unset the parameter or explicitly set it to MANUAL) See Note 1350901 for further information about the Automatic Undo Management feature

- Make sure all path names in the parameter file are fully specified You should not have relative path names in the parameter file

- If you are using a cluster database set the parameter CLUSTER_DATABASE=FALSE during the upgrade

- If you are upgrading a cluster database then modify the initdb_nameora file in the same way that you modified the parameter file

Step 22

Check for adequate freespace on archive log destination file systems

Step 23

Ensure the NLS_LANG variable is set correctly

$ env | grep $NLS_LANG

Step 24

If needed copy the SQLNet files like (listeneroratnsnamesora etc) to the new location (when no TNS_ADMIN env Parameter is used)

$ cp $OLD_ORACLE_HOMEnetworkadminora networkadmin

Step 25

If your Operating system is Windows (NT 2000 XP or 2003) delete your services With the ORADIM of your old oracle version

Stop the OracleServiceSID Oracle service of the database you are upgrading where SID is the instance name For example if your SID is ORCL then enter the following at a command prompt

Cgt NET STOP OracleServiceORCL

For Oracle 80 this is CORADIM80 -DELETE -SID

For Oracle 8i or higher this is CORADIM -DELETE -SID

Also create the new Oracle Database 10gR2 service at a command prompt using the ORADIM command of the new Oracle Database release

Cgt ORADIM -NEW -SID SID -INTPWD PASSWORD -MAXUSERS USERS-STARTMODE AUTO -PFILE ORACLE_HOMEDATABASEINITSIDORA

Step 26

Copy configuration files from the ORACLE_HOME of the database being upgraded to the new Oracle Database 10g ORACLE_HOME

If your parameter file resides within the old environments ORACLE_HOME then copy it to the new ORACLE_HOME By default Oracle looks for the parameter file in ORACLE_HOMEdbs on UNIX platforms and in ORACLE_HOMEdatabase on Windows operating systems The parameter file can reside anywhere you wish but it should not reside in the old environments ORACLE_HOME after you upgrade to Oracle Database 10g

If your parameter file is a text-based initialization parameter file with either an IFILE (include file) or a SPFILE (server parameter file) entry and the file specified in the IFILE or SPFILE entry resides within the old environments ORACLE_HOME then copy the file specified by the IFILE or SPFILE entry to the new ORACLE_HOME The file specified in the IFILE or SPFILE entry contains additional initialization parameters

If you have a password file that resides within the old environments ORACLE_HOME then move or copy the password file to the new Oracle Database 10g ORACLE_HOME

The name and location of the password file are operating system-specific

On UNIX platforms the default password file is ORACLE_HOMEdbsorapwsid On Windows operating systems the default password file is ORACLE_HOMEdatabasepwdsidora In both cases sid is your Oracle instance ID

If you are upgrading a cluster database and your initdb_nameora file resides within the old environments ORACLE_HOME then move or copy the initdb_nameora file to the new ORACLE_HOME

Note If you are upgrading a cluster database then perform this step on all nodes in which this cluster database has instances configured

Step 27

Update the oratab entry to set the new ORACLE_HOME and disable automatic startup

SIDORACLE_HOMEN

Step 28

Update the environment variables like ORACLE_HOME and PATH

$ oraenv

Step 29

Make sure the following environment variables point to the new release (10g) directories

- ORACLE_HOME - PATH - ORA_NLS10- ORACLE_BASE - LD_LIBRARY_PATH - LD_LIBRARY_PATH_64 (Solaris only)- LIBPATH (AIX only)- SHLIB_PATH (HPUX only)- ORACLE_PATH

$ env | grep ORACLE_HOME $ env | grep PATH $ env | grep ORA_NLS10$ env | grep ORACLE_BASE $ env | grep LD_LIBRARY_PATH $ env | grep ORACLE_PATH

AIX$ env | grep LIBPATH

HP-UX$ env | grep SHLIB_PATH

Note that the ORA_NLS10 environment variable replaces the ORA_NLS33 environment variable so you should unset ORA_NLS33 and set ORA_NLS10

As per Note 774421 you should set ORA_NLS10 to point to $ORACLE_HOMEnlsdata

Step 30

Startup upgrade the database

$ cd $ORACLE_HOMErdbmsadmin $ sqlplus as sysdba Use Startup with the UPGRADE optionSQLgt startup upgrade

Step 31

Create a SYSAUX tablespace In Oracle Database 10g the SYSAUX tablespace is used to consolidate data from a number of tablespaces that were separate in previous releases

The SYSAUX tablespace must be created with the following mandatory attributes

- ONLINE- PERMANENT- READ WRITE- EXTENT MANAGEMENT LOCAL- SEGMENT SPACE MANAGEMENT AUTO

The Upgrade Information Tool(utlu102isql in step 4) provides an estimate of the minimum required size for the SYSAUX tablespace in the SYSAUX Tablespace section

The following SQL statement would create a 500 MB SYSAUX tablespace for the database

SQLgt CREATE TABLESPACE sysaux DATAFILE sysaux01dbfSIZE 500M REUSEEXTENT MANAGEMENT LOCALSEGMENT SPACE MANAGEMENT AUTOONLINE

Step 32

NOTE Before performing the next action disable any third party procedures that check the complexity of schema passwords During the upgrade new schemas may be created and these may initially have an insecure password (but only for a very short period of time because the SQL script that creates the new schema will then immediately expire the password and lock the schema) If procedures are in place to enforce password complexity the create user statement may fail and cause configuration of a component to fail

Run the catupgrdsql script spooling the output so you can check whether any errors occured and investigate them

SQLgt spool upgradelogSQLgt catupgrdsql

The catupgrdsql script determines which upgrade scripts need to be run and then runs each necessary script You must run the script in the new release 102 environment

The upgrade script creates and alters certain data dictionary tables It also upgrades and configures the following database components in the new release 102 database (if the components were installed in the database before the upgrade)

Oracle Database Catalog ViewsOracle Database Packages and TypesJServer JAVA Virtual Machine Oracle Database Java PackagesOracle XDKOracle Real Application ClustersOracle Workspace ManagerOracle interMediaOracle XML DatabaseOLAP Analytic WorkspaceOracle OLAP API

OLAP CatalogOracle TextSpatialOracle Data MiningOracle Label SecurityMessaging GatewayExpression Filter Oracle Enterprise Manager Repository

Turn off the spooling of script results to the log file

SQLgt SPOOL OFF

Then check the spool file and verify that the packages and procedures compiled successfully You named the spool file earlier in this step the suggested name was upgradelog Correct any problems you find in this file and rerun the appropriate upgrade script if necessary You can rerun any of the scripts described in this note as many times as necessary

Step 33

Run utlu102ssql specifying the TEXT option

SQLgt utlu102ssql TEXT

This is the Post-upgrade Status Tool displays the status of the database components in the upgraded database The Upgrade Status Tool displays output similar to the following

Oracle Database 102 Upgrade Status Utility 04-20-2005 051840

Component Status Version HHMMSSOracle Database Server VALID 102010 001137JServer JAVA Virtual Machine VALID 102010 000247Oracle XDK VALID 102010 000215Oracle Database Java Packages VALID 102010 000048Oracle Text VALID 102010 000028 Oracle XML Database VALID 102010 000127Oracle Workspace Manager VALID 102010 000035 Oracle Data Mining VALID 102010 001556Messaging Gateway VALID 102010 000011OLAP Analytic Workspace VALID 102010 000028OLAP Catalog VALID 102010 000059Oracle OLAP API VALID 102010 000053Oracle interMedia VALID 102010 000803Spatial VALID 102010 000537 Oracle Ultra Search VALID 102010 000046Oracle Label Security VALID 102010 000014Oracle Expression Filter VALID 102010 000016Oracle Enterprise Manager VALID 102010 000058 Note - in RAC environments this script may suggest that the status of the RAC component is INVALID when in actual fact it is VALID (as shown in the output from DBA_REGISTRY)

NOTE As per Note 4568451 the output from the utlu102ssql script may differ from the output from DBA_REGISTRY To check the current status of each component run the following SQL statement

SQLgt select comp_name status version from dba_registry

Step 34

Restart the database

SQLgt shutdown immediate (DO NOT use shutdown abort ) SQLgt startup restrict

Executing this clean shutdown flushes all caches clears buffers and performs other database housekeeping tasks Which is needed if you want to upgrade specific components

Step 35

Run olstrigsql to re-create DML triggers on tables with Oracle Label Security policies This step is only necessary if Oracle Label Security is in your database(Check from Step 33)

SQLgt olstrigsql

Step 36

Run utlrpsql to recompile any remaining stored PLSQL and Java code

SQLgt utlrpsql

Verify that all expected packages and classes are valid

If there are still objects which are not valid after running the script run the following

spool invalid_postlst Select substr(owner112) owner substr(object_name130) object substr(object_type130) type status from dba_objects where status ltgtVALID spool off

Now compare the invalid objects in the file invalid_postlst with the invalid objects in the file invalid_prelst you create in step 9

NOTE If you have upgraded from version 92 to version 102 and find that the following views are invalid the views can be safely ignored (or dropped)

SYSV_$KQRPDSYSV_$KQRSDSYSGV_$KQRPDSYSGV_$KQRSD

NOTE If you have used OPatch to apply a CPU patch to the 1020x home you now need to follow the post-installation steps in the README file of the CPU patch to apply the CPU patch to the upgraded database This normally means running the catcpusql script

After Upgrading a Database

Step 37

Shutdown the database and startup the database

sqlplus as sysdba SQLgt shutdown SQLgt startup restrict

Step 38

Complete the Step 38 only if you upgraded your database from release 817Otherwise skip to Step 40

A) If you are not using N-type columns for user data ie the query

select distinct OWNER TABLE_NAME from DBA_TAB_COLUMNS where DATA_TYPE in (NCHARNVARCHAR2 NCLOB) and OWNER not in (SYSSYSTEMXDB)

did not return rows in Step 6 of this note then

sqlplus as sysdba SQLgt shutdown immediate

and go to step 40

B) IF your version 8 NLS_NCHAR_CHARACTERSET was UTF8

You can look up your previous NLS_NCHAR_CHARACTERSET using this select

select from nls_database_parameters where parameter =NLS_SAVED_NCHAR_CS

then

sqlplus as sysdba SQLgt shutdown immediate

and go to step 40

C) IF you are using N-type columns for user data AND your previous NLS_NCHAR_CHARACTERSET was in the following list

JA16SJISFIXED JA16EUCFIXED JA16DBCSFIXED ZHT32TRISFIXEDKO16KSC5601FIXED KO16DBCSFIXED US16TSTFIXED ZHS16CGB231280FIXEDZHS16GBKFIXED ZHS16DBCSFIXED ZHT16DBCSFIXED ZHT16BIG5FIXEDZHT32EUCFIXED

then the N-type columns data need to be converted to AL16UTF16

To upgrade user tables with N-type columns to AL16UTF16 run the script utlncharsql

sqlplus as sysdba SQLgt utlncharsql SQLgt shutdown immediate

go to step 40

D) IF you are using N-type columns for user data AND your previous NLS_NCHAR_CHARACTERSET was NOT in the following list

JA16SJISFIXED JA16EUCFIXED JA16DBCSFIXED ZHT32TRISFIXEDKO16KSC5601FIXED KO16DBCSFIXED US16TSTFIXED ZHS16CGB231280FIXEDZHS16GBKFIXED ZHS16DBCSFIXED ZHT16DBCSFIXED ZHT16BIG5FIXEDZHT32EUCFIXED

then import the data exported in point 8 of this note The recommended NLS_LANG during import is simply the NLS_CHARACTERSET not the NLS_NCHAR_CHARACTERSET

After the import

sqlplus as sysdba SQLgt shutdown immediate

go to step 40

Step 39

If your database has TIMESTAMP WITH TIMEZONE data you must update the data so that it is converted and stored based on the new time zone rules that come with the upgrade (Step 6)

If you used the export utility to export a copy of the affected tables you should now use the import utility to import your data from these tables back into your database The import utility will update the timestamp data as it imports

If you used the manual script method you will need to update the affected timestamp data based on your backed up table For example if you previously backed up your table you need to run an update statement similar to the one below to update your timestamp data

UPDATE tztab t SET ty = (SELECT to_timestamp_tz(t1yYYYY-MM-DD HH24MISSXFF TZR)FROM tztab_back t1 WHERE tx=t1x)

Step 40

Now edit the initora

- If you changed the value for NLS_LENGTH_SEMANTICS from CHAR to BYTE prior to the upgrade (see step 21) set it back to CHAR Otherwise do not change the value of the parameter to CHAR without careful evaluation and testing Switching to CHAR semantics can break application code See Note 1448081 for further information about the usage of this parameter

- If you changed the value for CLUSTER_DATABASE from TRUE to FALSE prior to the upgrade set it back to TRUE

Step 41

Startup the databaseSQLgt startup

Create a server parameter file with a initialization parameter fileSQLgt create spfile from pfile

This will create a spfile as a copy of the initora file located in the $ORACLE_HOMEdbs directory

Step 42

Modify the listenerora file For the upgraded intstance(s) modify the ORACLE_HOME parameter to point to the new ORACLE_HOME

Step 43

Start the listener $ lsnrctl

LSNRCTLgt start

Step 44

Enable cron and batch jobs

Step 45

Change oratab entry to use automatic startup SIDORACLE_HOMEY

Step 46

Upgrade the Oracle Cluster Registry (OCR) ConfigurationIf you are using Oracle Cluster Services then you must upgrade the Oracle Cluster Registry (OCR)keys for the database

Use srvconfig from the 10g ORACLE_HOME For example

srvconfig -upgrade -dbname ltdb_namegt -orahome ltpre-10g_Oracle_homegt

If the output from the $ORACLE_HOMEbinocrdump command references the pre-10g home it may be necessary to do the following

From the pre-10g home run the command

svrctl remove database -d ltdb_namegt

From the 10g home run the commands

srvctl add database -d ltdb_namegt -o lt10g_Oracle_homegt srvctl add instance -d ltdb_namegt -i ltinstance1_namegt -n ltnode1gt srvctl add instance -d ltdb_namegt -i ltinstance2_namegt -n ltnode2gt

Step 47

Use the DBMS_STATS package to gather new statistics for your user objects Using statistics collected from a previous Oracle version may lead CBO to generate less optimal execution plans

References

Note 1146711 Gathering Statistics for the Cost Based OptimizerNote 2625921 How to tune your Database after MigrationUpgrade

Step 48

Enterprise Manager Grid Control (EMGC) will show that the upgraded database does not have an inventory To re-discover the database do the following

1 Go to EMGC =gt Targets =gt Databases

2 Select the upgraded database and remove it

3 Click Add enter the name of the host and click Continue to allow EMGC to re-discover the database in the correct home with the correct inventory

Useful Hints

Upgrading With Read-Only and Offline Tablespaces

The Oracle database can read file headers created prior to Oracle 10g so you do not need to do anything to them during the upgrade The only exception to this is if you want to transport tablespaces created prior to Oracle 10g to another platform In this case the file headers must be made read-write at some point before the transport However there are no special actions required on them during the upgrade

The file headers of offline datafiles are updated later when they are brought online and the file headers of read-only tablespaces are updated if and when they are made read-write sometime after the upgrade In any other circumstance read-only tablespaces never have to be made read-write

It is a good idea to OFFLINE NORMAL all tablespaces except for SYSTEM and those containing rollbackUNDO tablespace prior to migration This way if migration fails only the SYSTEM and rollback datafiles need to be restored rather than the entire database

Note You must OFFLINE the TABLESPACE as migrate does not allow OFFLINE files in an ONLINE tablespace

Note If you are upgrading from Oracle9i the CWMLITE tablespace (which contains OLAP objects) will need to be ONLINE during the upgrade (so that the OLAP objects can be upgraded to 10g and moved to the SYSAUX tablespace)

Converting Databases to 64-bit Oracle Database Software

If you are installing 64-bit Oracle Database 10g software but were previously using a 32-bit Oracle Database installation then the databases will automatically be converted to 64-bit during the upgrade to Oracle Database 10g except when upgrading from Release 1 (101) to Release 2 (102)

The process is not automatic for the release 1 to release 2 upgrade but is automatic for all other upgrades This is because the utlipsql script is not run during the release 1 to release 2 upgrade to invalid all PLSQL objects You must run the utlipsql script as the last step in the release 101 environment before upgrading to release 102

If error occurs while executing the catupgrdsql

If an error occurs during the running of the catupgrdsql script once the problem is fixed you can simply rerun the catupgrdsql script to finish the upgrade process and complete the the upgrade process

Appendix A Initialization Parameters Obsolete in 10g

ENQUEUE_RESOURCESDBLINK_ENCRYPT_LOGINHASH_JOIN_ENABLEDLOG_PARALLELISMMAX_ROLLBACK_SEGMENTSMTS_CIRCUITSMTS_DISPATCHERSMTS_LISTENER_ADDRESSMTS_MAX_DISPATCHERSMTS_MAX_SERVERSMTS_MULTIPLE_LISTENERSMTS_SERVERSMTS_SERVICEMTS_SESSIONSOPTIMIZER_MAX_PERMUTATIONSORACLE_TRACE_COLLECTION_NAMEORACLE_TRACE_COLLECTION_PATHORACLE_TRACE_COLLECTION_SIZEORACLE_TRACE_ENABLEORACLE_TRACE_FACILITY_NAMEORACLE_TRACE_FACILITY_PATH

PARTITION_VIEW_ENABLEDPLSQL_NATIVE_C_COMPILERPLSQL_NATIVE_LINKERPLSQL_NATIVE_MAKE_FILE_NAMEPLSQL_NATIVE_MAKE_UTILITYROW_LOCKINGSERIALIZABLETRANSACTION_AUDITINGUNDO_SUPPRESS_ERRORS

Appendix B Initialization Parameters Deprecated in 10g

LOGMNR_MAX_PERSISTENT_SESSIONSMAX_COMMIT_PROPAGATION_DELAYREMOTE_ARCHIVE_ENABLESERIAL_REUSESQL_TRACEBUFFER_POOL_KEEP (replaced by DB_KEEP_CACHE_SIZE)BUFFER_POOL_RECYCLE (replaced by DB_RECYCLE_CACHE_SIZE)GLOBAL_CONTEXT_POOL_SIZELOCK_NAME_SPACELOG_ARCHIVE_STARTMAX_ENABLED_ROLESPARALLEL_AUTOMATIC_TUNING PLSQL_COMPILER_FLAGS (replaced by PLSQL_CODE_TYPE and PLSQL_DEBUG)

Known issues

1) While doing a upgrade from 9iR2 to 1020XX on running the utlu102isql script as directed in step 2Its output informs to add streams_pool_size=50331648 to the initora file While adding the parameter Oracle gives streams_pool_size as invalid parameter

STREAMS_POOL_SIZE was introduced in release 10gR1 This message may be ignored for database version 9iR2 or less

2) One of the customer has reported on keeping the shared_pool_size at 150 MB catmetasql fails with insuffient shared memory during the processing of view KU$_PHFTABLE_VI

Please set the shared_pool_size at 200M

3) While upgrade following error was encounteredcreate or replace ERROR at line 1 ORA-06553 PLS-213 package STANDARD not accessible ORA-00955 name is already used by an existing object

Please make sure to set the following init parameters as below in the spfileinit file or comment them out to their default values at the time of upgrading the database

PLSQL_V2_COMPATIBILITY = FALSEPLSQL_CODE_TYPE = INTERPRETED Only applicable to 10gR1PLSQL_NATIVE_LIBRARY_DIR = PLSQL_NATIVE_LIBRARY_SUBDIR_COUNT = 0

Refer to Note 1702821 PLSQL_V2_COMPATIBLITY=TRUE causes STANDARD and DBMS_STANDARD to Error at Compile

Always disconnect from the session which issues the STARTUP and connect as a fresh session before doing any further SQL eg On upgrade to 102 startup the instance with the upgrade option exit sqlplus reconnect a fresh SQLPLUS session as SYSDBA and then run the upgrade scripts

Revision History

Support have been asked to include this new section in the note It is not possible to provide a completely accurate revision history because many changes have been made since the note was first created in 2005 but now that this section exists Support will keep it up-to-date

18-JUL-2005

Article created

31-JUL-2005

Article published

24-JAN-2007

- Explicitly set AQ_TM_PROCESSES=0 in initora (step 21)

29-JAN-2007

- V_$ and GV_$ views can be dropped (step 36)

03-DEC-2007

- Drop table XDBMIGR9202STATUS from the OLD home (step 18) - Full cold backup OR an online backup using RMAN (step 20)

05-FEB-2008

- Added reference to Note 4064721 in the list of prerequisites - N-type columns in tables owned by XDB can be ignored (step 6) - Add workaround to ORA-1403 from utlu102isql (step 2) - Added reference to Note 4714791 in the list of prerequisites

27-FEB-2008

- Added some further commands to step 46 - Added a step about gathering new statistics (step 47) - Added a reference to Note 4070311 in step 2 - Added advice regarding ORA_NLS10 (step 29) - Skip step 6 if upgrading from 9x to 102 - Keep CWMLITE tablespace online (useful hints) - Check that DBA_REGISTRY contains data (step 8) - Added reference to Note 4659511 in the list of prerequisites - Use GATHER_SCHEMA_STATS in 8i and 9i (step 7)

18-APR-2008

- Added this ldquoRevision Historyrdquo section to the note - Clarified when to set UNDO_MANAGEMENT=AUTO in step 21 - Added reference to Note 1350901 in step 21

- Added reference to Note 2936581 in the list of prerequisites - Added reference to Note 3169001 in the list of prerequisites - Added reference to Note 4661811 in the list of prerequisites - Added reference to Note 5572421 in the list of prerequisites - Added some info to step 36 about running catcpusql if a CPU patch is applied to the home - Explicitly set JOB_QUEUE_PROCESSES=0 in initora (step 21) - Added a step about discovering the upgraded database in EMGC (step 48)

21-APR-2008

- Added a note suggesting that password complexity checking procedures are disabled (step 32) - Added a warning about using NLS_LENGTH_SEMANTICS=CHAR (step 40)

29-SEP-2008

- Added reference to Note 5656001 in the list of prerequisites- Added reference to Note 6037141 in the list of prerequisites- Added reference to Note 4568451 in step 33- Clarified step 21

References

Note 1350901 - Managing RollbackUndo Segments in AUM (Automatic Undo Management)Note 1596571 - Complete Upgrade Checklist for Manual Upgrades from 8X 901 to Oracle9iR2 (920)Note 1702821 - PLSQL_V2_COMPATIBLITY=TRUE causes STANDARD and DBMS_STANDARD to Error at CompileNote 2638091 - Complete checklist for manual upgrades to 10gR1 (1010x)Note 2936581 - 101 or 102 Patchset Install Getting ORA-29558 JAccelerator (NCOMP) And ORA-06512Note 3169001 - ALERT Oracle 10g Release 2 (102) Support Status and AlertsNote 3560821 - ORA-7445 [qmeLoadMetadata()+452] During 101 to 102 UpgradeNote 4064721 - Mandatory Patch 5752399 for 10203 on Solaris 64-bit and Filesystems Managed By Veritas or Solstice Disk Suite softwareNote 4070311 - ORA-01403 no data found while running utlu102isqlutlu102xsql on 8174 databaseNote 4122711 - ORA-600 [22635] and ORA-600 [KOKEIIX1] Reported While Upgrading Or Patching Databases To 10203Note 4568451 - UTLU102SSQL May Show Different Results Than Select From DBA_REGISTRYNote 4659511 - ORA-600 [kcbvmap_1] or Ora-600 [Kcliarq_2] On Startup Upgrade Moving From a 32-Bit To 64-Bit ReleaseNote 4661811 - 10g Upgrade CompanionNote 4714791 - IOT Corruptions After Upgrade from COMPATIBLE lt= 92 to COMPATIBLE gt= 101Note 5572421 - Upgrade Gives Ora-29558 Error Despite of JAccelerator Has Been InstalledNote 5656001 - ERROR IN CATUPGRD ORA-00904 IN DBMS_SQLPANote 6037141 - 10204 Catupgrdsql Fails With ORA-03113 Creating SYSKU$_XMLSCHEMA_VIEWOracle Database Upgrade Guide 10g Release 2 (102) Part Number B14238-01httpdownloadoraclecomdocscdB19306_01server102b14238tochtm