Oracle10g Release1 Upgrade to 10204
-
Upload
qadeer-riaz -
Category
Documents
-
view
188 -
download
4
Transcript of 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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
- 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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
- 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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
$ 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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-
- 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
- Applies to
- Goal
- Solution
- References
- Applies to
- 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
-