Complete Checklist for Manual Upgrades to 11gR2 [ID 837570.1]

Applies to:

Oracle Server - Standard Edition - Version 9.2.0.8 to 11.2.0.3 [Release 9.2 to 11.2]Oracle Server - Enterprise Edition - Version 9.2.0.8 to 11.2.0.3 [Release 9.2 to 11.2]Information in this document applies to any platform.

Purpose

This document is created for use as a guideline and checklist when manually upgrading from Oracle 9iR2 (9.2), Oracle 10gR1 (10.1), Oracle 10gR2 (10.2) or Oracle 11gR1 (11.1) to  Oracle 11gR2 (11.2).

Scope

Database Administrators, Support

Details

Recommendations for Source database

1) Ensure that all database components/objects provided by Oracle are VALID  in the source database  prior to starting the upgrade.

2) Ensure that you do not have duplicate objects in the SYS and SYSTEM schema.

The following objects are permissible duplicate objects:

 OBJECT_NAME OBJECT_TYPE

------------------------------ -------------------AQ$_SCHEDULES TABLEAQ$_SCHEDULES_PRIMARY INDEXDBMS_REPCAT_AUTH PACKAGEDBMS_REPCAT_AUTH PACKAGE BODY

 Please refer to the following article for complete instructions to remove any other duplicates.

NOTE.1030426.6 HOW TO CLEAN UP DUPLICATE OBJECTS OWNED BY SYS AND SYSTEM

Note: All these checks are done when you execute step 3 (dbupgdiag.sql)

Pre-Upgrade Steps

In this section all the steps need to be performed after having set the environment of the previous version of the Oracle Database. Note that the database must be running in normal mode in the old release.

To download and use the latest Pre-Upgrade Information Tool see the following:How to Download and Run Oracle's Database Pre-Upgrade Utility Note 884522.1

or 

Run the Pre-Upgrade Information Tool for Collecting Pre-Upgrade Information

 Step1

Log into the system as the owner of the Oracle Database 11g Release 2 (11.2) Oracle Home directory.

Copy the Pre-Upgrade Information Tool (utlu112i.sql) from the Oracle Database 11g Release 2 (11.2) ORACLE_HOME/rdbms/admin directory to a directory outside of the Oracle Home, such as the temporary directory on your system.

 

$ORACLE_HOME/rdbms/admin/utlu112i.sql

Failure to run the pre-upgrade tool (utlu112i.sql) will result in the following error while running the catupgrd.sql script :

SQL> SELECT TO_NUMBER('MUST_BE_SAME_TIMEZONE_FILE_VERSION')2 FROM registry$database3 WHERE tz_version != (SELECT version from

v$timezone_file);SELECT TO_NUMBER('MUST_BE_SAME_TIMEZONE_FILE_VERSION')*ERROR at line 1:ORA-01722: invalid number

It is  required to restore the database back to previous version in order to run the preupgrade tool (utlu112i.sql ) .

Step 2

Change to the directory where utlu112i.sql had been copied in the previous step.

Start SQL*Plus and connect to the database instance as a user with SYSDBA privileges. Then run and spool the utlu112i.sql file. Please note that the database should be started using the source Oracle Home .

$ sqlplus '/ as sysdba' SQL> spool upgrade_info.logSQL> @utlu112i.sqlSQL> spool offSQL>

Check the spool file and examine the output of the Upgrade Information Tool.

Preparing Database for Upgrade

Step3

Check for the integrity of the source database.

Check for the integrity of the source database prior to starting the upgrade by downloading and running the  dbupgdiag.sql script from the My Oracle Support article below:

Note 556610.1  Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)

If the dbupgdiag.sql script reports any invalid objects, run $ORACLE_HOME/rdbms/admin/utlrp.sql (multiple times) to validate the invalid objects in the database until there is no change in the number of invalid objects.

$ cd $ORACLE_HOME/rdbms/admin$ sqlplus "/ as sysdba"SQL> @utlrp.sql

After validating the invalid objects, re-run dbupgdiag.sql in the database once again and make sure that everything is fine.

Step 4

Deprecated CONNECT Role

After upgrading to Oracle Database 11g Release 2 (11.2) from Oracle Database9i Release 2 (9.2) or Oracle Database 10g Release 1 (10.1), the CONNECT role has only the CREATE SESSION privilege; the other privileges granted to the CONNECT role in earlier releases are 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', 'DBSNMP','LOGSTDBY_ADMINISTRATOR', 'ORDSYS','ORDPLUGINS', 'OEM_MONITOR', 'WKSYS', 'WKPROXY','WK_TEST', 'WKUSER', 'MDSYS', 'LBACSYS', 'DMSYS','WMSYS', 'EXFSYS', 'SYSMAN', 'MDDATA','SI_INFORMTN_SCHEMA', 'XDB', 'ODM');

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

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

SELECT GRANTEE,PRIVILEGEFROM 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

From Oracle 10.2, 'CONNECT' role only includes 'CREATE SESSION' privilege.

Step 5

Create script for DBLINK (in case the database has to be downgraded again).

During the upgrade to Oracle Database 11g Release 2 (11.2) from Oracle Database 9i Release 2 (9.2) or Oracle Database 10g Release 1 (10.1), any passwords in database links are encrypted. To downgrade to the original release, all of the database links with encrypted passwords must be dropped prior to the downgrade. Consequently, the database links do not exist in the downgraded database. If you anticipate a requirement to be able to downgrade to your original release, then save the information about affected database links from the SYS.LINK$ table, so that you can re-create the database links after the downgrade.

SELECT 'CREATE '||DECODE(U.NAME,'PUBLIC','public ')||'DATABASE LINK '||CHR(10)||DECODE(U.NAME,'PUBLIC',Null, 'SYS','',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#;

Step 6

Check for TIMESTAMP WITH TIMEZONE Datatype

The RDBMS DST patching has been greatly improved in 11gR2.Unlike upgrading for older versions (upgrading 10.2.0.4 to 11.1.0.7 for example) there is no need anymore to apply "dst patches" on the old version *before* the upgrade.

If you upgrade from an older RDBMS version to 11gR2 the DST version in 11gR2 after the upgrade will be simply the same as the DST version that was used in the older RDBMS version.

There are however a few situations where some extra steps are needed, so please do check below notes before upgrading to 11gR2., depending on to what 11gR2 version you upgrade to

Note 815679.1 :  Actions For DST Updates When Upgrading To 11.2.0.1 Base ReleaseNote 1201253.1 : Actions For DST Updates When Upgrading To Or Applying The 11.2.0.2 PatchsetNote 1358166.1 : Actions For DST Updates When Upgrading To Or Applying The 11.2.0.3 Patchset

Simply follow above note ( depending on to what 11gR2 version you upgrade to ) in most cases there will be no action to take before the upgrade, but better be safe than sorry.

If the note say's to apply a RDBMS DST patch to the 11gR2 then do so.

Make sure that

SQL> select TZ_VERSION from registry$database;

returns the RDBMS DST version of your old version.( = the value found in step 1 of the above notes)

If this select gives an error or a different value then re-run the utlu112i.sql (Pre-Upgrade Information Tool) script and check again.

Step 7

Check that the National Characterset (NLS_NCHAR_CHARACTERSET) is UTF8 or AL16UTF16.

select value from NLS_DATABASE_PARAMETERS where parameter = 'NLS_NCHAR_CHARACTERSET';

If this is UTF8 or AL16UTF16 then no action is needed.If is not UTF8 or AL16UTF16 then refer to the following article:

Note 276914.1 The National Character Set in Oracle 9i and 10g.

Step 8

Optimizer Statistics

When upgrading to Oracle Database 11g Release 2 (11.2), 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 determine the schemas which lack statistics, either review the output of the utlu112i.sql script or download and run the script from the below article:

Note 560336.1 Script to Check Schemas with Stale Statistics

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 1 (10.1), Oracle recommends that you use the DBMS_STATS.GATHER_DICTIONARY_STATS procedure to gather these statistics. For example, you can enter the following:

$ sqlplus "/as sysdba"

SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

If you are using Oracle Database 9i Release 2 (9.2), then you should use the DBMS_STATS.GATHER_SCHEMA_STATS procedure to gather statistics. To do this, you can run the scripts provided in Appendix B.

Appendix B has a sample script, which creates the table dictstattab and exports the statistics for the RDBMS component schema into it. The statistics collection might give errors if a particular component schema does not exist in the database or if a component is not installed or is invalid.

Backup the existing statistics to revert/import back the statistics, once the upgrade is successful.

For example, the following PL/SQL subprograms import the statistics for the SYS schema after deleting the existing statistics:

SQL> EXEC DBMS_STATS.DELETE_SCHEMA_STATS('SYS');SQL> EXEC DBMS_STATS.IMPORT_SCHEMA_STATS('SYS','dictstattab');

Step 12

This optional check is introduced to spot any logical corruption in underlying objects and their dependencies. This proactive check is introduced to avoid any failure in database upgrade at a later stage due to such corruption. If there is corruption the upgrade will most likely fail.

To check for corruption in the dictionary, use the following commands in SQL*Plus (connected 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 str

ucture 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_rows;'FROM dba_tablesWHERE owner='SYS'AND partitioned='YES';

spool off

This creates a script called analyze.sql.Now execute the following steps:

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

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

Note:1. ORA-30657 might occur if there is any external table validated, which can be safely ignored as per Note 209355.1 ORA-30657: Using ANALYZE TABLE for an External Table

2. Errors shown below when executing analyze.sql can be ignored:SP2-0734: unknown command beginning "SQL> SELEC..." - rest of line ignored.SP2-0042: unknown command "SQL>" - rest of line ignored.SP2-0734: unknown command beginning "SQL> spool..." - rest of line ignored.

3. "ORA-00054: resource busy and acquire with NOWAIT specified" may be returned when analyzing AWR tables (WRH$_...)    to workaround this error AWR can be temporarily disabled :

3.a) get current value for snapshot interval :

       select snap_interval,retention from dba_hist_wr_control;

3.b) set this interval to zero to temporarily disable AWR :

    exec dbms_workload_repository.modify_snapshot_settings(interval=>0);

3.c) Analyze the WRH$ tables

3.d) Revert back to initial value :    

  exec dbms_workload_repository.modify_snapshot_settings(interval=><value in mn of snap_interval returned at 3.a>);

 

Step 13

Ensure that all snapshot refreshes are successfully completed, and that replication is stopped.

SELECT DISTINCT(TRUNC(last_refresh))FROM dba_snapshot_refresh_times;

Step 14

Ensure that no files need media recovery and that no files are in backup mode.

SELECT * FROM v$recover_file;SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';

This should return no rows.

Step 16

Resolve outstanding distributed transactions prior to the upgrade.

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 17

To check if a standby database exists, issue the following query:

SELECT SUBSTR(value,INSTR(value,'=',INSTR(UPPER(value),'SERVICE'))+1)FROM v$parameterWHERE name LIKE 'log_archive_dest%' AND UPPER(value) LIKE 'SERVICE%';

If this query returns a row, then sync the standby database with the primary database.1. Make sure all the logs are transported to the standby server after a final log switchin the primary.2. Start the recovery of the standby database with the NODELAY option.

Step 18

Disable all batch and cron jobs. About jobs initiated with Oracle the packages DBMS_JOB, DBMS_SCHEDULER can be used , regarding cron jobs (external jobs controlled at the OS level), this is a task for your Unix administrator

Step 19

Ensure the users SYS and SYSTEM have 'SYSTEM' as their default tablespace.

You must have sufficient space in the tablespace or be set to extents unlimited.

SQL> SELECT username, default_tablespace     FROM dba_users     WHERE username in ('SYS','SYSTEM'); 

If DEFAULT_TABLESPACE is anything other than SYSTEM tablespace, modify the default tablespace to SYSTEM by using the below command.

SQL> ALTER user SYS default tablespace SYSTEM;SQL> ALTER user SYSTEM default tablespace SYSTEM;

Step 20

Ensure that if the aud$ table exists that it is in the SYS schema and in the SYSTEM tablespace.

SQL> SELECT owner,tablespace_name     FROM dba_tables     WHERE table_name='AUD$';

If the AUD$ table is not in SYSTEM tablespace and not owned by the SYS user then before doing the upgrade put it back to the SYSTEM tablespace and it should be owned by SYS .

Note: If the AUD$ table exists and is in use, upgrade performance can be effected depending on the number of records in the table.

Step 21

Check whether database has any externally authenticated SSL users.

SQL> SELECT name FROM sys.user$     WHERE ext_username IS NOT NULL     AND password = 'GLOBAL';

If any SSL users are found then Step 34 has to be followed after the upgrade.

Step 22

Note down the location of datafiles, redo logs and control files. Also take a backup of all configuration files like listener.ora, tnsnames.ora, etc. from $ORACLE_HOME.

SQL> SELECT name FROM v$controlfile;SQL> SELECT file_name FROM dba_data_files;SQL> SELECT group#, member FROM v$logfile;.

Step 23

a) Stop the listener for the database.

$ lsnrctl stop

Step 24

Shutdown the database.

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

Back up the Database

1. Perform Cold Backup

Step 25

Make a backup of the init<SID>.ora file.Comment out obsoleted parameters (Appendix A) and change all deprecated parameters (Appendix A).

* The DIAGNOSTIC_DEST initialization parameter replaces the USER_DUMP_DEST, BACKGROUND_DUMP_DEST.

According to Bug 8937877, CORE_DUMP_DEST is not deprecated.

Upgrading Database to 11gR2

Step 28

At the operating system prompt, change to the $ORACLE_HOME/rdbms/admin directory of 11gR2 Oracle Home.

$ cd $ORACLE_HOME/rdbms/admin$ sqlplus "/ as sysdba"SQL> startup UPGRADE

Note: If you are upgrading from 9.2 and the SYSAUX table already exists then drop the existing SYSAUX tablespace. Create the SYSAUX tablespace only if you are upgrading from Oracle Database9i Release 2 (9.2) with the following mandatory attributes:

ONLINEPERMANENTREAD WRITEEXTENT MANAGEMENT LOCALSEGMENT SPACE MANAGEMENT AUTO

The Pre-Upgrade Information Tool provides an estimate of the minimum required size for the SYSAUX tablespace in the SYSAUX Tablespace section. Refer to the output generated by the utlu112i.sql script in Step 1. The following SQL statement would create a 500 MB SYSAUX tablespace for the database:

SQL> CREATE TABLESPACE SYSAUX     DATAFILE '<location>/sysaux01.dbf'     SIZE 500M REUSE     EXTENT MANAGEMENT LOCAL     SEGMENT SPACE MANAGEMENT AUTO     ONLINE;

Set the system to spool results to a log file for later verification after the upgrade is completed and start the upgrade script.

SQL> set echo onSQL> SPOOL upgrade.logSQL> @catupgrd.sqlSQL> spool off

These measures are an important final step to ensure the integrity and consistency of the newly upgraded Oracle Database software. Also, if you encountered a message listing obsolete initialization parameters when you started the database for upgrade, then remove the obsolete initialization parameters from the parameter file before restarting. If necessary, convert the SPFILE to a PFILE so you can edit the file to delete parameters.

Run the Post-Upgrade Status Tool $ORACLE_HOME/rdbms/admin/utlu112s.sql which provides a summary of the upgrade at the end of the spool log. It displays the status of the database components in the upgraded database and the time required to complete each component upgrade. Any errors that occur during the upgrade are listed with each component and must be addressed.

$ sqlplus "/as sysdba"SQL> STARTUPSQL> @utlu112s.sql

Run catuppst.sql, located in the $ORACLE_HOME/rdbms/admin directory, to perform upgrade actions that do not require the database to be in UPGRADE mode.

SQL> @catuppst.sql

This script can be run concurrently with utlrp.sql. Run utlrp.sql to recompile any remaining stored PL/SQL and Java code in another session.

SQL> @utlrp.sql

Check for the integrity of the upgraded database by running dbupgdiag.sql script from the below article:

Note 556610.1  Script to Collect DB Upgrade/Migrate Diagnostic Information (dbupgdiag.sql)

If the dbupgdiag.sql script reports any invalid objects, run $ORACLE_HOME/rdbms/admin/utlrp.sql (multiple times) to validate the invalid objects in the database, until there is no change in the number of invalid objects.

After validating the invalid objects, re-run dbupgdiag.sql in the upgraded database once again and make sure that everything is fine.

Post Upgrade Steps

Step 29

Modify the listener.ora file.

For the upgraded instance(s) modify the ORACLE_HOME parameter to point to the new ORACLE_HOME. Start the listener.

lsnrctl start

Step 31

After the upgrade

note : this simply repeats the same actions as given in the "DST" notes referenced in step 6 of this note.

Check the current version of the Oracle time zone definitions in the upgraded database:

SQL> conn / as sysdbaConnected.SQL>SELECT version FROM v$timezone_file;

VERSION----------4