10 g upgrade

7/30/2019 10 g Upgrade

1/21

This document helps you to up gradation of database from lower version to 10gr2.

Complete checklist for manual upgrades to 10gR2

This version database are directly convertible to 10gr2

Oracle 10g Release 28.1.7.4 -> 10.2.X.X.X9.0.1.4 or 9.0.1.5 -> 10.2.X.X.X9.2.0.4 or higher -> 10.2.X.X.X10.1.0.2 or higher -> 10.2.X.X.X

This version database are required indirect conversion to 10gr2

7.3.3 (or lower) -> 7.3.4 -> 8.1.7 -> 8.1.7.4 -> 10.2.X.X.X7.3.4 -> 8.1.7 -> 8.1.7.4 -> 10.2.X.X.X8.0.n -> 8.1.7 -> 8.1.7.4 -> 10.2.X.X.X8.1.n -> 8.1.7 -> 8.1.7.4 -> 10.2.X.X.X

STEPS FOR UPGRADING THE DATABASE TO 10G RELEASE 2

Step 1:~~~~~~~Log in to the system as the owner of the new 10gR2 ORACLE_HOME and copy the following ffrom the 10gR2 ORACLE_HOME/rdbms/admin.

ORACLE_HOME/rdbms/admin/utlu102i.sqlORACLE_HOME/rdbms/admin/utltzuv2.sqlsNote: copy this file to your lower version database,keep any where in lower versiondatabase. their is no mandatory to keep in ORACLE_HOME/rdbms/admin

Step 2:

~~~~~~~After copying the above file log to your lower version of database as a system user or (ex 9.2.0.1 database) and run the below script.

Sql> spool database_info.logSql>@/ORACLE_HOME/rdbms/admin/utlu102i.sqlSql>spool off

Then, check the spool file and examine the output of the upgrade informationtool. The sections which follow, describe the output of the UpgradeInformation Tool (utlu102i.sql).

Then check the above spool file(database_info.log).this will give you the complete detaof requirements and changes as to made before upgradation to 10gr2.This file is divided into below sections.please carefully go through below info.

Database:

This section displays global database information about the current database suchas the database name, release number, and compatibility level. A warning is displayedif the COMPATIBLE initialization parameter needs to be adjusted before the database isupgraded.

7/30/2019 10 g Upgrade

2/21

Logfiles:

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

Tablespaces:

This section displays a list of tablespaces in the current database. For eachtablespace,the tablespace name and minimum required size is displayed. In addition, amessage is displayed if the tablespace is adequate for the upgrade. If the tablespace dnot have enough free space, then space must be added to the tablespace in the currentdatabase.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 thecurrent database that must be adjusted before the database is upgraded. The adjustmentsneed to be made to the parameter file after it is copied to the new Oracle Database10grelease.

Deprecated Parameters:

This section displays a list of initialization parameters in the parameter file of thecurrent 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 thecurrent database that are obsolete in the new Oracle Database 10g release. Obsoleteinitialization parameters need to be removed from the parameter file before the databas

upgraded.

Components:

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

Miscellaneous Warnings:

This section provides warnings about specific situations that may require attention befand/or after the upgrade.

SYSAUX Tablespace:

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

Step 3:~~~~~~~Check for the deprecated CONNECT Role

7/30/2019 10 g Upgrade

3/21

After upgrading to 10gR2, the CONNECT role will only have the CREATE SESSIONprivilege; the other privileges granted to the CONNECT role in earlier releases will berevoked during the upgrade. To identify which users and roles in your database are granthe CONNECT role, use the following query:

SELECT grantee FROM dba_role_privs WHERE granted_role = 'CONNECT' andgrantee NOT IN ( SYS,SYSTEM)

If users or roles require privileges other than CREATE SESSION, then grantthe specific required privileges prior to upgrading. The upgrade scriptsadjust the privilegesfor the Oracle-supplied users.

In Oracle 9.2.x and 10.1.x CONNECT role includes the following privileges:

SELECT GRANTEE,PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE='CONNECT'

GRANTEE PRIVILEGE------------------------------ ---------------------------

CONNECT CREATE VIEWCONNECT CREATE TABLECONNECT ALTER SESSIONCONNECT CREATE CLUSTERCONNECT CREATE SESSIONCONNECT CREATE SYNONYMCONNECT CREATE SEQUENCECONNECT CREATE DATABASE LINK

In Oracle 10.2 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 encryptedpasswords must be dropped prior to the downgrade. Consequently, the database links willexist in the downgraded database. If you anticipate a requirement to be able to downgraback to your original release, then save the information about affected database links the SYS.LINK$ table,so that you can recreate the database links after the downgrade.

Following script can be used to construct the dblink.

SELECT'create '||DECODE(U.NAME,'PUBLIC','public ')||'database link '||CHR(10)||DECODE(U.NAME,'PUBLIC',Null, U.NAME||'.')|| L.NAME||chr(10)

||'connect to ' || L.USERID || ' identified by '''||L.PASSWORD||''' using ''' || L.host || ''''||chr(10)||';' TEXTFROM sys.link$ L,sys.user$ UWHERE L.OWNER# = U.USER#;

COLLECT ALL DBLINKS DDLS AND RECREATE AFTER UPGRADE TO 10GR2

7/30/2019 10 g Upgrade

4/21

Step 5:( The may affect existing data of TIMESTAMP WITH TIME ZONE datatype in lowerversion)~~~~~~~Check for the TIMESTAMP WITH TIMEZONE Datatype. Please this step is only required for t10gR1 .For example, if users enter TIMESTAMP '2003-02-17 09:00:00 America/Sao_Paulo',we convert the data to UTC based on the transition rules in the time zone fileand store them on the disk. So '2003-02-17 11:00:00' along with the time zone idfor 'America/Sao_Paulo' is stored because the offset for this particular time is '-02:0Now the transition rules are modified and the offset for this particulartime is changed to '-03:00'. when users retrieve the data, they will get'2003-02-17 08:00:00 America/Sao_Paulo'. There is one hour difference compared to theoriginal value.

Connect to your lower version database and run the below script.

$ sqlplus '/as sysdba'

SQL> spool TimeZone_Info.logSQL> @utltzuv2.sqlSQL> spool off

This above script will create table called sys.sys_tzuv2_temptab then query this tableThis will give you columns contain the datatype which get affected ,if it return no rowto next step.If the utltzuv2.sql script identifies columns with time zone data affectedby a database upgrade, then there two ways of solving this problem.If your databasecontains the above datatype the look the below solution. Otherwise go to step 6.

Solution--------create tables with the time zone information in character format(for example, TO_CHAR(column, 'YYYY-MM-DD HH24.MI.SSXFF TZR'), and recreatethe TIMESTAMP data from these tables after the upgrade.

For example, user scott has a table tztab:create 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 isdefined as VARCHAR2 to preserve the original value.

create table tztab_back(x number primary key, y varchar2(256));insert into tztab_back select x,to_char(y, 'YYYY-MM-DD HH24.MI.SSXFF TZR') from tztab;

After upgrade, you need update the data in the table tztab using the value in tztab_bacupdate tztab t set t.y = (select to_timestamp_tz(t1.y,

'YYYY-MM-DD HH24.MI.SSXFF TZR') from tztab_back t1 where t.x=t1.x);

Step 6:~~~~~~~Starting in Oracle 9i the National Characterset (NLS_NCHAR_CHARACTERSET) will belimited to UTF8 and AL16UTF16.

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

7/30/2019 10 g Upgrade

5/21

Any other NLS_NCHAR_CHARACTERSET will no longer be supported.When upgrading to 10g the value of NLS_NCHAR_CHARACTERSET is basedon value currently used in the Oracle8 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 AL16UTF16and -if used- N-type data (= data in columns using NCHAR, NVARCHAR2 orNCLOB )may need to be converted.

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

If you are NOT using N-type columns *for user data* then simply go to next step.No further action required.

Use this below query to check

select distinct OWNER, TABLE_NAME from DBA_TAB_COLUMNS whereDATA_TYPE in ('NCHAR','NVARCHAR2', 'NCLOB') and OWNER not in('SYS','SYSTEM'); returns no rows, go to next step.)

If you have N-type columns *for user data* then check:

SQL> select * from nls_database_parameters where parameter='NLS_NCHAR_CHARACTERSET';

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

JA16SJISFIXED , JA16EUCFIXED , JA16DBCSFIXED , ZHT32TRISFIXEDKO16KSC5601FIXED , 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 37

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


(your current NLS_NCHAR_CHARACTERSET is for example US7ASCII, WE8ISO8859P1,CL8MSWIN1251 ...)then you have to:

* change the tables to use CHAR, VARCHAR2 or CLOB instead the N-typeor* use export/import the table(s) containing N-type columnsand truncate those tables before migrating to 9i.The recommended NLS_LANG during export is simply the NLS_CHARACTERSET,not the NLS_NCHAR_CHARACTERSET

Step 7:~~~~~~~

7/30/2019 10 g Upgrade

6/21

When upgrading to Oracle Database 10g, optimizer statistics are collectedfor dictionary tables that lack statistics. This statistics collection canbe time consuming for databases with a large number of dictionary tables,but statistics gathering only occurs for those tables that lack statisticsor 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 10.1, Oracle recommends that you usethe DBMS_STATS.GATHER_DICTIONARY_STATS procedure to gather these statistics.You can enter the following:


SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

In Case of the 9.0.1 or 9.2.0 release, then you should use theDBMS_STATS.GATHER_SCHEMA_STATS procedure to gather statistics.

Backup the existing statistics as follow

$ sqlplus '/as sysdba'SQL>spool sdict

SQL>grant analyze any to sys;

SQL>exec dbms_stats.create_stat_table('SYS','dictstattab');

SQL>exec dbms_stats.export_schema_stats('WMSYS','dictstattab',statown => 'SYS');SQL>exec dbms_stats.export_schema_stats('MDSYS','dictstattab',statown => 'SYS');SQL>spool off

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

For example, the following PL/SQL subprograms import the statistics for the SYS schemaafterdeleting the existing statistics:

exec dbms_stats.delete_schema_stats('SYS');exec dbms_stats.import_schema_stats('SYS','dictstattab');

To gather statistics run this script, connect to the database AS SYSDBA using SQL*Plus.


SQL>spool gdict

SQL>grant analyze any to sys;

SQL>exec dbms_stats.gather_schema_stats('WMSYS',options=>'GATHER',estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,- method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

SQL>exec dbms_stats.gather_schema_stats('MDSYS',options=>'GATHER',estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,- method_opt => 'FOR ALL COLUMNS SIZE AUTO', cascade => TRUE);

7/30/2019 10 g Upgrade

7/21

SQL>spool off

Step 8:~~~~~~~Check for invalid objects invalid objects.

spool invalid_pre.lstselect substr(owner,1,12) owner,substr(object_name,1,30) object,substr(object_type,1,30) type, status fromdba_objects where status 'VALID';spool off

Run the following script and then requery invalid objects:

This script must be run as a user with SYSDBA privs using SQL*Plus:$ cd $ORACLE_HOME/rdbms/admin$ sqlplus '/as sysdba'

SQL> @utlrp.sql

This last query will return a list of all objects that cannot be recompiledbefore the upgrade in the file 'invalid_pre.lst'

Step 9:~~~~~~~~Check for corruption in the dictionary, use the following commands in sqlplusconnected as sys:

Set verify offSet space 0Set line 120Set heading offSet feedback offSet pages 1000Spool analyze.sql

Select 'Analyze cluster "'||cluster_name||'" validate structure cascade;'from dba_clusterswhere owner='SYS'unionSelect '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 analyze.sql.Now execute the following steps.

7/30/2019 10 g Upgrade

8/21

$ sqlplus '/as sysdba'SQL> @$ORACLE_HOME/rdbms/admin/utlvalid.sqlSQL> @analyze.sql

This script (analyze.sql) should not return any errors.

Step 10:~~~~~~~~Ensure that all Snapshot refreshes are successfully completed, and thatreplication is stopped.

$ sqlplus '/as sysdba'SQL> select distinct(trunc(last_refresh)) from dba_snapshot_refresh_times;

Step 11:~~~~~~~~Stop the listener for the database:

$ lsnrctlLSNRCTL> stop

Ensure no files need media recovery:

$ sqlplus '/ as sysdba'SQL> select * from v$recover_file;

This should return no rows.

Step 12:~~~~~~~~Ensure no files are in backup mode:

SQL> select * from v$backup where status!='NOT ACTIVE';

This should return no rows.

Step 13:~~~~~~~~Resolve any outstanding unresolved distributed transaction:

SQL> select * from dba_2pc_pending;

If this returns rows you should do the following:

SQL> select local_tran_id from dba_2pc_pending;SQL> execute dbms_transaction.purge_lost_db_entry('');SQL> commit;

Step 14:~~~~~~~~Disable all batch and cron jobs.

Step 15:~~~~~~~~Ensure the users sys and system have 'system' as their default tablespace.

SQL> select username, default_tablespace from dba_userswhere username in ('SYS','SYSTEM');

7/30/2019 10 g Upgrade

9/21

To modify use:

SQL> alter user sys default tablespace SYSTEM;SQL> alter user system default tablespace SYSTEM;

Step 16:~~~~~~~~Ensure that the aud$ is in the system tablespace when auditing is enabled.

SQL> select tablespace_name from dba_tables where table_name='AUD$';

Step 17:~~~~~~~~Note down where all control files are located.

SQL> select * from v$controlfile;

Step 18:~~~~~~~~

Shutdown the database

$ sqlplus '/as sysdba'SQL> shutdown immediate;

Step 19:~~~~~~~~PERFORM a Full cold backup!!!!!!!

You can either do this by manually copying the files orsign on to RMAN:

$rman "target / nocatalog"

And issue the following RMAN commands:

RUN{ALLOCATE CHANNEL chan_name TYPE DISK;BACKUP DATABASE FORMAT 'some_backup_directory%U' TAG before_upgrade;BACKUP CURRENT CONTROLFILE TO 'save_controlfile_location';}

Upgrading to the New Oracle Database 10g Release 2

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

~~~~~~~~Update the init.ora file:

- Make a backup of the init.ora file.

- Comment out obsoleted parameters(list in appendix A).

7/30/2019 10 g Upgrade

10/21

- Change all deprecated parameters(list in appendix B).

- Set the COMPATIBLE initialization parameter to an appropriate value. If you areupgrading from 8.1.7.4 then set the COMPATIBLE parameter to 9.2.0 until after theupgrade has been completed successfully. If you are upgrading from 9.2.0 or 10.1.0then leave the COMPATIBLE parameter set to it's current value until the upgradehas 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 10.2 objects that have not yet been created)

- If you have set the parameter NLS_LENGTH_SEMANTICS to CHAR, change the valueto BYTE during the upgrade (to avoid the issue in

- Verify that the parameter DB_DOMAIN is set properly.- set streams_pool_size=50mb minimum is required.

- Make sure the PGA_AGGREGATE_TARGET initialization parameter is set toat least 24 MB.

- Ensure that the SHARED_POOL_SIZE and the LARGE_POOL_SIZE are at least 150Mb.

Please alos 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_DESTinitialization parameters that point to RDBMS80 or any other environment variableto point to the following directories instead:

BACKGROUND_DUMP_DEST to ORACLE_BASE\oradata\DB_NAME

and

USER_DUMP_DEST to ORACLE_BASE\oradata\DB_NAME\archive

- Comment out any existing AQ_TM_PROCESSES parameter setting, and enter a new onethat explicitly sets AQ_TM_PROCESSES=0 for the duration of the upgrade

- Set the parameter UNDO_MANAGEMENT=AUTO

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

- If you are using a cluster database, set the parameter CLUSTER_DATABASE=FALSEduring the upgrade.

- If you are upgrading a cluster database, then modify the initdb_name.orafile in the same way that you modified the parameter file.

Step 21 :~~~~~~~~~Check for adequate freespace on archive log destination file systems.

Step 22 :~~~~~~~~~Ensure the NLS_LANG variable is set correctly:

7/30/2019 10 g Upgrade

11/21

$ env | grep $NLS_LANG

Step 23:~~~~~~~~If needed copy the SQL*Net files like (listener.ora,tnsnames.ora etc)to the new location (when no TNS_ADMIN env. Parameter is used)

$ cp $OLD_ORACLE_HOME/network/admin/*.ora /network/admin

Step 24:~~~~~~~~If your Operating system is Windows NT, delete your servicesWith 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 enterthe following at a command prompt:

C:\> NET STOP OracleServiceORCL

For Oracle 8.0 this is:C:\ORADIM80 -DELETE -SID

For Oracle 8i or higher this is:C:\ORADIM -DELETE -SID

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

C:\> ORADIM -NEW -SID SID -INTPWD PASSWORD -MAXUSERS USERS-STARTMODE AUTO -PFILE ORACLE_HOME\DATABASE\INITSID.ORA

Step 25:~~~~~~~~Copy configuration files from the ORACLE_HOME of the database being upgradedto the new Oracle Database 10g ORACLE_HOME:

If your parameter file resides within the old environment's ORACLE_HOME,then copy it to the new ORACLE_HOME. By default, Oracle looks for the parameterfile in ORACLE_HOME/dbs on UNIX platforms and in ORACLE_HOME\database onWindows operating systems. The parameter file can reside anywhere you wish,but it should not reside in the old environment's ORACLE_HOME after youupgrade to Oracle Database 10g.

If your parameter file is a text-based initialization parameter file witheither an IFILE (include file) or a SPFILE (server parameter file) entry,

and the file specified in the IFILE or SPFILE entry resides within the oldenvironment's ORACLE_HOME, then copy the file specified by the IFILE orSPFILE entry to the new ORACLE_HOME. The file specified in the IFILE or SPFILEentry contains additional initialization parameters.

If you have a password file that resides within the old environmentsORACLE_HOME, then move or copy the password file to the new Oracle Database10g ORACLE_HOME.

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

7/30/2019 10 g Upgrade

12/21

On UNIX platforms, the default password file is ORACLE_HOME/dbs/orapwsid.On Windows operating systems, the default password file isORACLE_HOME\database\pwdsid.ora. In both cases, sid is your Oracle instance ID.

If you are upgrading a cluster database and your initdb_name.ora file resideswithin the old environment's ORACLE_HOME, then move or copy the initdb_name.orafile to the new ORACLE_HOME.

Note:If you are upgrading a cluster database, then perform this step on all nodesin which this cluster database has instances configured.

Step 26:~~~~~~~~Update the oratab entry, to set the new ORACLE_HOME and disable automaticstartup:::N

Step 27:

~~~~~~~~Update the environment variables like ORACLE_HOME and PATH

$. oraenv

Step 28:~~~~~~~~Make sure the following environment variables point to the newRelease 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 environmentvariable, so you may need to unset ORA_NLS33 and set ORA_NLS10.

Step 29:

7/30/2019 10 g Upgrade

13/21

~~~~~~~~Startup upgrade the database:

$ cd $ORACLE_HOME/rdbms/admin$ sqlplus / as sysdbaUse Startup with the UPGRADE option:SQL> startup upgrade

Step 30:~~~~~~~~

Create a SYSAUX tablespace. In Oracle Database 10g, the SYSAUX tablespace isused to consolidate data from a number of tablespaces that were separate inprevious 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(utlu102i.sql in step 4) provides an estimate ofthe minimum required size for the SYSAUX tablespace in the SYSAUX Tablespacesection.

The following SQL statement would create a 500 MB SYSAUX tablespacefor the database:

SQL> CREATE TABLESPACE sysaux DATAFILE 'sysaux01.dbf'SIZE 500M REUSEEXTENT MANAGEMENT LOCALSEGMENT SPACE MANAGEMENT AUTOONLINE;

Step 31:~~~~~~~~If table XDB.MIGR9202STATUS exists in the database, drop it before upgradingthe database (to avoid the issue described in )

Step 32:~~~~~~~~Spool the output so you can take a look at possible errors after the upgrade:

SQL> spool upgrade.logSQL> @catupgrd.sql

The catupgrd.sql script determines which upgrade scripts need to be run and then runseach necessary script. You must run the script in the new release 10.2 environment.

The upgrade script creates and alters certain data dictionary tables. It also upgradesand configures the following database components in the new release 10.2 database (ifthe components were installed in the database before the upgrade)

Oracle Database Catalog ViewsOracle Database Packages and Types

7/30/2019 10 g Upgrade

14/21

JServer JAVA Virtual MachineOracle Database Java PackagesOracle XDKOracle Real Application ClustersOracle Workspace ManagerOracle interMediaOracle XML DatabaseOLAP Analytic WorkspaceOracle OLAP APIOLAP CatalogOracle TextSpatialOracle Data MiningOracle Label SecurityMessaging GatewayExpression FilterOracle Enterprise Manager Repository

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

SQL> SPOOL OFF

Step 33:~~~~~~~~Run utlu102s.sql, specifying the TEXT option:

SQL> @utlu102s.sql TEXT

This is the Post-upgrade Status Tool displays the status of the databasecomponents in the upgraded database. The Upgrade Status Tool displays outputsimilar to the following:

Oracle Database 10.2 Upgrade Status Utility 04-20-2005 05:18:40

Component Status Version HH:MM:SSOracle Database Server VALID 10.2.0.1.0 00:11:37JServer JAVA Virtual Machine VALID 10.2.0.1.0 00:02:47Oracle XDK VALID 10.2.0.1.0 00:02:15Oracle Database Java Packages VALID 10.2.0.1.0 00:00:48Oracle Text VALID 10.2.0.1.0 00:00:28Oracle XML Database VALID 10.2.0.1.0 00:01:27Oracle Workspace Manager VALID 10.2.0.1.0 00:00:35Oracle Data Mining VALID 10.2.0.1.0 00:15:56Messaging Gateway VALID 10.2.0.1.0 00:00:11OLAP Analytic Workspace VALID 10.2.0.1.0 00:00:28OLAP Catalog VALID 10.2.0.1.0 00:00:59

Oracle OLAP API VALID 10.2.0.1.0 00:00:53Oracle interMedia VALID 10.2.0.1.0 00:08:03Spatial VALID 10.2.0.1.0 00:05:37Oracle Ultra Search VALID 10.2.0.1.0 00:00:46Oracle Label Security VALID 10.2.0.1.0 00:00:14Oracle Expression Filter VALID 10.2.0.1.0 00:00:16Oracle Enterprise Manager VALID 10.2.0.1.0 00:00:58

Note - in RAC environments, this script may suggest that the status of theRAC component is INVALID when in actual fact it is VALID (as shown in the

7/30/2019 10 g Upgrade

15/21

output from DBA_REGISTRY)

Step 34:~~~~~~~~Restart the database:SQL> shutdown immediate (DO NOT USE SHUTDOWN ABORT!!!!!!!!!)SQL> startup restrict

Executing this clean shutdown flushes all caches, clears buffers and performsother database housekeeping tasks. Which is needed if you want to upgradespecific components.

Step 35:~~~~~~~~Run olstrig.sql to re-create DML triggers on tables with Oracle Label Security policiesThis step is only necessary if Oracle Label Security is in your database.(Check from Step 33).

SQL> @olstrig.sql

Step 36:~~~~~~~~Run utlrp.sql to recompile any remaining stored PL/SQL and Java code.

SQL> @utlrp.sql

Verify that all expected packages and classes are valid:

If there are still objects which are not valid after running the script runthe following:spool invalid_post.lstSelect substr(owner,1,12) owner,

substr(object_name,1,30) object,substr(object_type,1,30) type, status

fromdba_objects where status 'VALID';

spool off

Now compare the invalid objects in the file 'invalid_post.lst' with the invalidobjects in the file 'invalid_pre.lst' you create in step 9.

NOTE: If you have upgraded from version 9.2 to version 10.2 and find that thefollowing views are invalid, the views can be safely ignored (or dropped):

SYS.V_$KQRPDSYS.V_$KQRSD

SYS.GV_$KQRPDSYS.GV_$KQRSD

After Upgrading a Database--------------------------

Step 37:~~~~~~~~Shutdown the database and startup the database.

7/30/2019 10 g Upgrade

16/21

$ sqlplus '/as sysdba'SQL> shutdownSQL> startup restrict

Step 38:~~~~~~~~Complete the Step 38 only if you upgraded your database from release 8.1.7Otherwise skip to Step 40.

A) IF you are NOT using N-type columns for *user* data:

select distinct OWNER, TABLE_NAME from DBA_TAB_COLUMNS whereDATA_TYPE in ('NCHAR','NVARCHAR2', 'NCLOB') and OWNER not in('SYS','SYSTEM');did not return rows in Step 7 of this note.

then:$ sqlplus '/as sysdba'SQL> shutdown immediateand 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'SQL> shutdown immediateand 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:


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

To upgrade user tables with N-type columns to AL16UTF16 run thescript utlnchar.sql:

$ sqlplus '/as sysdba'SQL> @utlnchar.sqlSQL> 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:


7/30/2019 10 g Upgrade

17/21

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'SQL> shutdown immediate;go to step 40.

Step 39:~~~~~~~~If your database has TIMESTAMP WITH TIMEZONE data, you must updatethe data so that it is converted and stored based on the new timezone 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 tablesback into your database. The import utility will update the timestampdata as it imports.

If you used the manual script method, you will need to update the affectedtimestamp data based on your backed up table. For example, if you previouslybacked up your table, you need to run an update statement similar to theone below to update your timestamp data.

UPDATE tztab t SET t.y =(SELECT to_timestamp_tz(t1.y,'YYYY-MM-DD HH24.MI.SSXFF TZR')FROM tztab_back t1WHERE t.x=t1.x);

Step 40:~~~~~~~~Now edit the init.ora:- If you change the value for NLS_LENGTH_SEMANTICS prior to the upgrade put thevalue back to CHAR.

- If you changed the CLUSTER_DATABASE parameter prior the upgrade set it back to TRUE

Step 41:~~~~~~~~Startup the database:SQL> startup

Create a server parameter file with a initialization parameter fileSQL> create spfile from pfile;

This will create a spfile as a copy of the init.ora file located in the$ORACLE_HOME/dbs directory.

Step 42:~~~~~~~~Modify the listener.ora file:For the upgraded intstance(s) modify the ORACLE_HOME parameterto point to the new ORACLE_HOME.

Step 43:~~~~~~~~

7/30/2019 10 g Upgrade

18/21

Start the listener$ lsnrctlLSNRCTL> start

Step 44:~~~~~~~~Enable cron and batch jobs

Step 45:~~~~~~~~Change oratab entry to use automatic startupSID:ORACLE_HOME:Y

Step 46:~~~~~~~~Upgrade the Oracle Cluster Registry (OCR) ConfigurationIf you are using Oracle Cluster Services, then you must upgrade theOracle Cluster Registry (OCR)keys for the database.

* Use srvconfig from the 10g ORACLE_HOME. For example:

% srvconfig -upgrade -dbname db_name -orahome pre-10g_Oracle_home

USEFUL HINTS-------------

** Upgrading With Read-Only and Offline Tablespaces

The Oracle database can read file headers created prior to Oracle 10g, so you do notneed to do anything to them during the upgrade. The only exception to this is ifyou 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 transpHowever, 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 maderead-write sometime after the upgrade. In any other circumstance, read-only tablespacenever have to be made read-write.

It is a good idea to OFFLINE NORMAL all tablespacesexcept for SYSTEM and those containing rollback/UNDO tablespace prior to migration.This way if migration fails only the SYSTEM and rollback datafiles need to berestored rather than the entire database.

Note: You must OFFLINE the TABLESPACE as migrate does not allow OFFLINE filesin an ONLINE tablespace.

** Converting Databases to 64-bit Oracle Database Software

If you are installing 64-bit Oracle Database 10g software but were previouslyusing a 32-bit Oracle Database installation, then the databases will automaticallybe converted to 64-bit during the upgrade to Oracle Database 10g except whenupgrading from Release 1 (10.1) to Release 2 (10.2).

The process is not automatic for the release 1 to release 2 upgrade, but is automaticfor all other upgrades. This is because the utlip.sql script is not run during therelease 1 to release 2 upgrade to invalid all PL/SQL objects. You must run the utlip.s

7/30/2019 10 g Upgrade

19/21

script as the last step in the release 10.1 environment, before upgrading to release 1

** If error occurs while executing the catupgrd.sql

If an error occurs during the running of the catupgrd.sql script, once the problem isfixedyou can simply rerun the catupgrd.sql script to finish the upgrade process and completthethe upgrade process.

Appendix A: Initialization Parameters Obsolete in 10g-----------------------------------------------------

ENQUEUE_RESOURCESDBLINK_ENCRYPT_LOGINHASH_JOIN_ENABLEDLOG_PARALLELISMMAX_ROLLBACK_SEGMENTS

MTS_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_PATHPARTITION_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_SIZE

7/30/2019 10 g Upgrade

20/21

LOCK_NAME_SPACELOG_ARCHIVE_STARTMAX_ENABLED_ROLESPARALLEL_AUTOMATIC_TUNINGPLSQL_COMPILER_FLAGS (replaced by PLSQL_CODE_TYPE and PLSQL_DEBUG)

KNOWN ISSUES------------

1)While doing a upgrade from 9iR2 to 10.2.0.X.X, on running the utlu102i.sqlscript as directed in step 2Its output informs to add streams_pool_size=50331648 to the init.ora file.While adding the parameter Oracle gives streams_pool_size as invalid parameter.

STREAMS_POOL_SIZE, was introduced in release 10gR1This 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,catmeta.sql fails with insuffient shared memory during the processingof view KU$_PHFTABLE_VI.

Please set the shared_pool_size at 200M.

3)While upgrade following error was encountered.create 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 spfile/init file 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

Note 170282.1

Title: PLSQL_V2_COMPATIBLITY=TRUE causes STANDARD andDBMS_STANDARD to Error at Compile

4)

sqlplus crashes with OCI-21500 error and a core dumpwhen "set serveroutput on"is run in the same session where startup command is executed.

This issue is reported in BUG:4860003

Always disconnect from the session which issues the STARTUP andconnect as a fresh session before doing any further SQL.eg: On upgrade to 10.2 startup the instance with the upgrade option,exit sqlplus , reconnect a fresh SQLPLUS session as SYSDBA
https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=170282.1&blackframe=1https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=170282.1&blackframe=1

7/30/2019 10 g Upgrade

21/21

and then run the upgrade scripts.

RELATED NOTES--------------

Note 263809.1 Complete checklist for manual upgrades to 10g

Note 159657.1 Complete Upgrade Checklist for Manual Upgrades from 8.X / 9.0.1 to Oracle9iOracle Database Upgrade Guide 10g Release 2 (10.2)Part Number B14238-01http://download.oracle.com/docs/cd/B19306_01/server.102/b14238/toc.htm

note number =Note:316889.1Note.421191.1Note.316889.1 10g details on 10gorarect/ixdr#256Note:316889.1 ------10g upgradation
https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=263809.1&blackframe=1https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=159657.1&blackframe=1https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=263809.1&blackframe=1https://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=159657.1&blackframe=1

10 g upgrade

Documents