3 Upgrading to the New Release

Relocating Existing Data Files to the New Oracle Database Environment

Before you remove the old Oracle environment, you must relocate any data files in that environment to the new Oracle Database environment.

To relocate data files to the new Oracle Database environment 

• Use Database Upgrade Assistant (DBUA) and select the Move Database Files option during the upgrade.

About Upgrading PL/SQL Packages That Are Not Installed by Default

Packages that were previously installed on the database for which you are preparing to upgrade to the current release may not be upgraded automatically. You may need to separately check if the package is available in the current release and reinstall that package to ensure you have the latest version.

About Upgrading Oracle ASM Installed with Oracle Grid Infrastructure

Oracle ASM is upgraded as part of the Oracle Grid Infrastructure upgrade. You cannot upgrade ASM before you upgrade Oracle Grid Infrastucture.

Considerations for Upgrading Oracle Clusterware and Oracle ASM Instances

Starting with Oracle Database 11g Release 2 (11.2.0.1), Oracle Clusterware and Oracle Real Application Clusters (Oracle RAC) must be installed into a separate, new home from the existing installation. This reduces the downtime required to upgrade a node in the cluster and facilitates the provisioning of clusters within an enterprise. The reduction in planned outage time required for cluster upgrades helps in meeting availability service levels and also makes it easier to provide a standard installation across the enterprise.

The following considerations pertain to upgrading Oracle Clusterware and Oracle ASM instances:

• For releases earlier than Oracle Database 11g, either all Oracle software installations were owned by the Oracle user, typically oracle, or Oracle Database software was owned by the user oracle, and Oracle Clusterware software was owned by a separate user, typically crsuser.

• Starting with Oracle Database 11g, the user account that is designated as owner of the release 10g Cluster Ready Services (CRS) software must perform the Oracle Clusterware 11g upgrade. The user account that is performing this upgrade must also be the user that owns the ASM home of the earlier release (that is, previous to release 11.2). If the pre-11.2 ASM home has a different owner, then the owner account must be changed before performing the upgrade.

• As of Oracle Database 11g release 2 (11.2), the Oracle Clusterware software must be upgraded to a new home location in the Oracle Grid Infrastructure home. Additionally, Oracle ASM and Oracle Clusterware (and Oracle Restart for single-instance databases) must run in the same Oracle Grid Infrastructure home. When upgrading Oracle Clusterware to release 11.2, OUI automatically calls Oracle ASM Cluster Assistant (ASMCA) to perform the upgrade into the Oracle Grid Infrastructure home.

• To upgrade to Oracle Database release 11.2.0.2, you must install the Oracle Grid Infrastructure and Oracle Database software into a new Oracle home instead of into the existing Oracle home.

• For a single-instance configuration, Oracle ASM and Oracle Restart run from the Oracle Grid Infrastructure home, and the cluster synchronization services daemon (CSS) runs from this same home. Thus, Oracle ASM and CSS are upgraded to Oracle Database 11g Release 2 (11.2) at the same time.

• For Oracle Database release 11.1 and earlier releases, if your configuration does not include Oracle ASM, then you must shut down the CSS daemon and delete the CSS service from the system by running the localconfig command with the delete option. For example:

  ORACLE_HOME/bin/localconfig delete
  

select count(*) from v$asm_client where status = 'CONNECTED';

CREATE USER user_name IDENTIFIED BY password;

About Upgrading with Read-Only and Offline Tablespaces

Oracle Database 11g Release 1 (11.1) and later releases can read file headers created in previous releases, so you are not required to do anything to them during the upgrade. The only exception to this is if you want to transport tablespaces created previously than Oracle Database 11g Release 1 (11.1) 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 data files 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. You are never required to make read-only tablespaces read/write in any other circumstance.

About Upgrading Using Standby Databases

To upgrade the Oracle Database software when standby databases are present in an Oracle Data Guard configuration, see Oracle Data Guard Concepts and Administration. To upgrade or downgrade Oracle Database and Oracle Enterprise Manager software in an Oracle Data Guard broker configuration, see Oracle Data Guard Broker.

During a rolling upgrade, you can run different releases of Oracle Database software on the primary and standby databases while you upgrade them, one at a time, incurring minimal downtime on the primary database by using either of the following methods:

• SQL Apply and logical standby databases

  Starting with Oracle Database 10g Release 1 (10.1.0.3), you can use Oracle Data Guard SQL Apply on a logical standby database to perform a rolling upgrade to the new Oracle Database 11g release. For example, you can upgrade the Oracle Database software from patch set release 10.1.0.n to the next database 10.1.0.(n+1) patch set release, or upgrade Oracle Database 10g Release 1 (10.1) to Oracle Database 11g Release 2 (11.2).

• Use of physical standby database for rolling upgrades

  A physical standby database can now take advantage of the rolling upgrade feature provided by a logical standby. Through the use of the new KEEP IDENTITY clause option to the SQL ALTER DATABASE RECOVER TO LOGICAL STANDBY statement, a physical standby database can be temporarily converted into a logical standby database for the rolling upgrade, and then reverted back to the original configuration of a primary database and a physical standby database when the upgrade is done.

About Upgrading Your Operating System

When you upgrade to a new release of Oracle software, the operating system requirements may have changed. If required, upgrade the operating system before upgrading Oracle Database.

Migrating Data to a Different Operating System

When using DBUA or when performing a manual upgrade, you cannot migrate data in a database on one operating system to a database on another operating system. For example, you cannot migrate data in an Oracle9i database on Solaris to an Oracle 11g database on Windows using DBUA.

To migrate Oracle Database software to a different operating system 

1. Upgrade to the new Oracle Database 11g release on your current operating system platform following the instructions in this guide.

2. Test the upgraded database on your current operating system platform.

3. Use Oracle Data Guard and physical standby databases to migrate between operating systems.

   See Also:

   Note 413484.1 on My Oracle Support (formerly OracleMetaLink) at https://support.oracle.com/ for more information on Oracle Data Guard support for heterogeneous primary and standby systems in the same Oracle Data Guard configuration

4. If cross-platform physical standby database is not available for the platform combination to be migrated, then you can use the Oracle Database 11g cross-platform transportable tablespace feature or the Oracle Data Pump Export and Import utilities to migrate the upgraded database to the different operating system.

   Note:

   Transportable tablespaces do not support migrating SYSTEM or SYSAUX tablespaces. All non-segment user data, such as roles, triggers, views, and procedures, must be moved to the new operating system with scripts or export/import.

5. If the two operating systems are in the same endianness group, then you can use the Oracle Database 11g cross-platform transportable database feature to migrate the entire database.

6. You can also use Oracle Streams to migrate data between operating systems. Oracle Streams has data type limitations and restrictions, such as for advanced queues and object types, and it requires additional administrative overhead.

About Upgrading Databases That Use Oracle Streams Downstream Capture

In an Oracle Streams replication environment, downstream captures means that a capture process runs on a database other than the source database. When you upgrade the databases in such an environment, upgrade the database with the downstream capture process before you upgrade the source database. Upgrading the databases in this order ensures that the downstream capture database can continue to function after the source database is upgraded.

About Upgrading Databases That Use Oracle Database Vault

When upgrading from Oracle Database release 10.2, if you have enabled Oracle Database Vault in your current Oracle home, then you must disable Oracle Database Vault in the target Oracle home where the new release 11.2.0.2 software is installed. You must do this before upgrading the database. Enable Oracle Database Vault again once the upgrade is complete.

Pre-Upgrade Information Tool Miscellaneous Warnings

Before upgrading to the new Oracle Database 11g release, Oracle recommends analysis of the information and warnings displayed by the Pre-Upgrade Information Tool. The following topics describe warnings and the appropriate actions to take.

• Updating the CONNECT Role from Earlier Releases

• Managing and Updating Access Control Lists and Network Utility Packages

• About Database Links with Passwords from Earlier Releases

• About Warnings for TIMESTAMP WITH TIME ZONE Data Type

• Decreasing Downtime for Gathering Optimizer Statistics (Optional)

• Identifying Invalid Objects

• Saving Database Control Files and Data with the emdwgrd Utility

• Verifying That Materialized View Refreshes Have Completed

• Ensuring That No Files Need Media Recovery

• Ensuring That No Files Are in Backup Mode

• Resolving Outstanding Distributed Transactions

• Synchronizing a Standby Database with the Primary Database

• Purging the Database Recycle Bin

Sat Apr 28 08:49:45 2010 - Verify EM DB Control files ... pass
Sat Apr 28 08:49:45 2010 - Validating DB Connection to DB102 ... pass
Sat Apr 28 08:49:51 2010 - creating directory ... created
Sat Apr 28 08:49:51 2010 - Stopping DB Control ... stopped
Sat Apr 28 08:50:01 2010 - Saving DB Control files ... saved
Sat Apr 28 08:50:14 2010 - recompiling invalid objects ... recompiled
Sat Apr 28 08:50:18 2010 - Exporting sysman schema for DB102 ... exported
Sat Apr 28 08:51:36 2010 - Starting DB Control ... started
Sat Apr 28 08:53:21 2010 - DB Control was saved successfully.

$ /scratch/oracle/product/11.1.0/db_1/bin/emdwgrd -srcOracleHome $ORACLE_HOME -sid DB102 -path /scratch/rpattabh/ravi/tmp/dbcdir5 –save  -cluster
 
Enter sys password for database DB102?
*****
 
Database Unique Name : DB102
Sat Apr 28 08:49:45 2010 - Verify EM DB Control files ... pass
Sat Apr 28 08:49:45 2010 - Validating DB Connection to DB102 ... pass
Sat Apr 28 08:49:51 2010 - creating directory ... created
Sat Apr 28 08:49:51 2010 - Stopping DB Control on all Nodes
 
Please Execute '/tmp/racdwgrd_dbctl.sh' on Node1, Node2. 
 
Press yes to continue when the operations are successful. 
Continue (yes/no) ?
y 
 
... stopped
Sat Apr 28 08:50:01 2010 - Saving DB Control files 
Executing save directories from node Node1
Executing save directories from node Node2
 
... saved
Sat Apr 28 08:50:14 2010 - Recompiling invalid objects ... recompiled
Sat Apr 28 08:50:18 2010 - Exporting sysman schema for DB102 ... exported
Sat Apr 28 08:53:21 2010 - DB Control was saved successfully.
Sat Apr 28 08:51:36 2010 - Starting DB Control on all nodes
 
Please Execute '/tmp/racdwgrd_dbctl.sh' on Node1, Node2. 
 
Press yes to continue when the operations are successful. 
Continue (yes/no) ?
y
 
... started
Sat Apr 28 08:57:26 2010 - Dump directory was dropped successfully.

SQL> PURGE DBA_RECYCLEBIN

Considerations for Using DBUA

• Important: If you terminate the upgrade, but do not restore the database, then you cannot restart DBUA. Instead, you must continue with a manual (command line) upgrade as described in "Manually Upgrading the Database".

• DBUA can be used to upgrade from earlier Oracle Database 11g patch releases as well as from earlier major Oracle Database releases on both Oracle RAC databases and Oracle Database single-instance databases. The procedure to upgrade patch releases is no different from the normal upgrade procedure.

• You must run the Oracle Net Configuration Assistant before running DBUA. See "Using the Oracle Net Configuration Assistant".

  If you are upgrading an existing Oracle Enterprise Manager Database Control or if you are configuring a new Oracle Enterprise Manager Database Control for the new Oracle Database 11g release, then the listener must be running before upgrading Oracle Enterprise Manager. If DBUA detects that an Oracle Enterprise Manager upgrade or configuration is requested, and DBUA does not see a listener running, then it prompts you and starts the default listener in either of these cases.

• If you upgrade a cluster database using DBUA, then you must make sure the CLUSTER_DATABASE initialization parameter is set to TRUE.

• If the database instance is not running, then DBUA tries to start the instance with the default initialization parameter file. If that fails, then DBUA prompts you to provide the name of the correct initialization parameter file or to start the instance. If the instance is up and running, then DBUA connects to it.

• If you terminate the upgrade, but do not restore the database, then you cannot restart DBUA until you start up the existing database in UPGRADE mode using the new Oracle Database 11g server. You cannot go back to the original server unless you restore your database.

  For Oracle RAC, you cannot re-run DBUA once you terminate the upgrade. If you need to re-run the upgrade, then you must run DBUA from the restored backup of the database you are upgrading.

• If you restore your database manually (not using DBUA), then remove the Welcome_SID.txt file, which is located in the ORACLE_HOME/cfgtoollogs/dbua/logs/ directory, before starting DBUA. The presence of this file indicates to DBUA that this is a re-run operation.

About the DBUA Graphical User Interface

If you installed Oracle Database 11g Release 2 (11.2) and specified that you are upgrading an existing database, then DBUA starts automatically. However, if you did not specify that you are upgrading an existing database, then you can start DBUA independently after installation is complete.

While the upgrade is in process, DBUA shows the upgrade progress for each component. DBUA writes detailed trace and log files and produces a complete HTML report for later reference. To enhance security, DBUA automatically locks new user accounts in the upgraded database. DBUA then proceeds to create new configuration files (parameter and listener files) in the new Oracle home.

DBUA does not begin the upgrade until all of the pre-upgrade steps are completed.

These topics provide additional information about DBUA:

• Checks Performed by DBUA

• Upgrade Scripts Invoked by DBUA

Using DBUA to Upgrade the Database on Linux, UNIX, and Windows Systems

Complete the following steps to upgrade a database using the DBUA graphical user interface. These steps are performed from within the new Oracle home where the latest database software has been installed as described in "Installing the New Oracle Database Software" of Oracle Database Upgrade Guide.

To upgrade a database using DBUA on Linux, UNIX, and Windows

1. Start DBUA from the Oracle home where the new database software has been installed:

   • On Linux or UNIX platforms, enter the following command at a system prompt in the new Oracle Database 11g Release 2 (11.2) home:

     dbua
     

     Note:

     The dbua executable is usually located in the ORACLE_HOME/bin directory.

   • On Windows operating systems, select Start > Programs > Oracle - HOME_NAME > Configuration and Migration Tools > Database Upgrade Assistant.

   The DBUA Welcome screen displays.

   
   Description of the illustration dbua01.jpg
   
   

2. If you need help at any screen or want to consult more documentation about DBUA, then click Help to open the online help.

   Click Next.

   The Select Database page appears, listing the databases available for upgrade.

   
   Description of the illustration dbua02.jpg
   
   

3. Select the database you want to upgrade to Oracle Database 11g Release 2 (11.2).

   You can select only one database at a time. If you do not see the database that you want, then make sure an entry with the database name exists in the oratab file in the etc directory.

   If you are running DBUA from a user account that does not have SYSDBA privileges, then you must enter the user name and password credentials to enable SYSDBA privileges for the selected database.

   Click Next.

   DBUA analyzes the database, performing pre-upgrade checks and displaying warnings as necessary. Examples of DBUA database checks include:

   • Redo log files whose size is less than 4 MB. If such files are found, then DBUA gives the option to drop/create new redo log files.

   • Obsolete or deprecated initialization parameters.

   When DBUA finishes its checks, the Upgrade Options screen displays.

   
   Description of the illustration dbua03.jpg
   
   

4. The Upgrade Options screens allows you to set the following options:

   Recompile invalid objects at the end of upgrade

   Select Recompile invalid objects at the end of upgrade if you want DBUA to recompile all invalid PL/SQL modules after the upgrade is complete.

   When you upgrade a database to Oracle Database 11g Release 2 (11.2), many of the PL/SQL modules in your database become invalid. As a result, all existing PL/SQL modules in an INVALID state must be recompiled, such as packages, procedures, types, and so on.

   By default, Oracle Database recompiles invalid PL/SQL modules as they are used. The time it takes to recompile the module can result in poor performance when you begin to use your newly upgraded database.

   To eliminate these performance issues, select Recompile invalid objects at the end of upgrade. When you select this option, DBUA recompiles all the invalid PL/SQL modules immediately after the upgrade is performed. This ensures that you do not experience any performance issues later, as you begin using your newly upgraded database.

   Note:

   Selecting Recompile invalid objects at the end of upgrade is equivalent to running the utlrp.sql script, located in the ORACLE_HOME/rdbms/admin directory, which is used to recompile stored PL/SQL and Java code.

   The task of recompiling all the invalid PL/SQL modules in your database can take a significant amount of time and increase the time it takes to complete your database upgrade. If you have multiple CPUs, then you can reduce the time it takes to perform this task by taking advantage of parallel processing on your available CPUs. If you have multiple CPUs available, then DBUA automatically adds an additional section to the Recompile Invalid Objects screen and automatically determines the number of CPUs you have available.

   Degree of Parallelism

   DBUA also provides a recommended degree of parallelism, which determines how many parallel processes are used to recompile your invalid PL/SQL modules. Specifically, DBUA sets the degree of parallelism to one less than the number of CPUs you have available. For example, if you have three CPUs available for processing, then DBUA selects 2 from the Degree of Parallelism menu. You can adjust this default value by selecting a new value from the Degree of Parallelism menu.

   Backup Database

   Select Backup database if you want DBUA to back up your database for you.

   Important:

   Oracle strongly recommends that you back up your database before starting the upgrade. If errors occur during the upgrade, then you might be required to restore the database from the backup.

   If you use DBUA to back up your database, then it makes a copy of all your database files in the directory you specify in the Backup Directory field. DBUA performs this cold backup automatically after it shuts down the database and before it begins performing the upgrade procedure. The cold backup does not compress your database files, and the backup directory must be a valid file system path. You cannot specify a raw device for the cold backup files.

   In addition, DBUA creates a batch file in the specified directory. You can use this batch file to restore the database files:

   • On Windows operating systems, the file is called db_name_restore.bat.

   • On Linux or UNIX platforms, the file is called db_name_restore.sh.

   If you choose not to use DBUA for your backup, then Oracle assumes you have backed up your database using your own backup procedures.

   Note:

   DBUA does not back up Oracle ASM databases. You must manually back them up on your own.

   Click Next.

   If you are upgrading a single-instance database or Oracle Express Edition (XE), then the Move Database Files screen appears. If you are upgrading an Oracle Real Application Clusters database, then the Move Database Files screen does not display.

   
   Description of the illustration dbua04.jpg
   
   

5. Select one of the following options:

   • Do Not Move Database Files as Part of Upgrade

   • Move Database Files during Upgrade

   If you choose to move database files, then you must also make one of the following selections:

   • File System

     Your database files are moved to the host file system.

   • Oracle Automatic Storage Management (Oracle ASM)

     Your database files are moved to Oracle ASM storage, which must currently exist on your system. If you do not have an Oracle ASM instance, then you can create one using Automatic Storage Management Configuration Assistant (ASMCA) from the Oracle Grid Infrastructure home and then restart DBUA.

     See Also:

     • Oracle Grid Infrastructure Installation Guide for information about installing and configuring Oracle ASM

     • "Managing Oracle ASM Instances With ASM Configuration Assistant" in Oracle Database Storage Administrator's Guide

     Click Next.

     The Recovery and Diagnostic Locations screen displays, where you can designate a flash recovery area for your database.

     
     Description of the illustration dbua05.jpg
     
     

   Flash recovery area is an Oracle managed disk location used for storing backup and recovery related files. Oracle strongly recommends configuring a flash recovery area, because it significantly enhances speed, reliability, and manageability of the database recovery process. The location of the flash recovery area is also used by Enterprise Manager if you enable local management and daily backups on the Management Options screen.

   If you selected the Move Database Files during Upgrade option in step 5, or if an Oracle Express Edition database is being upgraded to Oracle Enterprise Edition, then you must configure a flash recovery area. If a flash recovery area is currently configured, then the current settings are retained but the screen displays to allow you to override these values.

6. Do one of the following:

   • Accept the default flash recovery area location

   • Enter the full path to a different location in the Flash Recovery Area field

   • Click Browse and select a different flash recovery area location

   Do one of the following:

   • Accept the default size for the flash recovery area

   • Enter a different value in the Flash Recovery Area Size field

   • Click the up or down arrows to adjust the flash recovery area size

   See Also:

   Oracle Database 2 Day DBA for more information about configuring the flash recovery area

   Click Next.

   If no other database is currently being monitored with Enterprise Manager, then the Management Options screen displays.

   
   Description of the illustration dbua06.jpg
   
   

   At the Management Options screen, you have the option of setting up your database so it can be managed with Enterprise Manager. Enterprise Manager provides Web-based management tools for managing individual database instances, as well as central management tools for managing your entire Oracle environment, including multiple databases, hosts, application servers, and other components of your network.

   Before you can register the database with Oracle Enterprise Manager Grid Control, an Oracle Enterprise Manager Agent must be configured on the host computer.

7. To set up your database to be managed with Enterprise Manager, select Configure the Database with Enterprise Manager and then select one of the following options:

   • Register with Grid Control for centralized management

     If you select this option, then you must also select an Oracle Management Service from the Management Service drop-down list. When you run DBUA, it checks to see if the Oracle Management Agent has been installed on the host computer. If no Oracle Management Agent is found, then the Grid Control option is not available.

     When you finish installing the Oracle Database software, the database is automatically available as a managed target within Oracle Enterprise Manager Grid Control.

   • Configure Oracle Enterprise Manager Database Control for local management

     If you are not centrally managing your Oracle environment, then you can still use Enterprise Manager to manage your database. When you install Oracle Database, you automatically install Oracle Enterprise Manager Database Control, which provides Web-based features for monitoring and administering the single-instance or cluster database you are installing.

     Do the following steps if you want the SYSMAN user (the default Super Administrator and owner of the Management Repository schema) to receive E-mail notification when a metric for a specified condition reaches a critical or warning threshold:

     • Select Enable Alert Notifications

     • Enter the name of the e-mail server you want to use for notifications in the Outgoing Mail (SMTP) Server field

     • Enter the e-mail address of the SYSMAN user in the Recipient Email Address field

     For example, Enterprise Manager can send an e-mail when a target goes down or when there are database space usage problems. E-mail notifications are enabled immediately upon installation.

     Do the following steps to use the Oracle suggested backup strategy to back up your entire database with a minimum amount of configuration:

     • Select Enable Daily Disk Backup to Recovery Area

     • Enter a start time in the Backup Start Time field

     • Enter host credentials in the OS Username and Password fields

     If you select the Enable Daily Disk Backup to Recovery Area option, then Enterprise Manager is configured to back up your database immediately after you finish upgrading Oracle Database. Enterprise Manager backs up the database to the flash recovery area. Later, you can use Enterprise Manager to customize your backup strategy further.

     On Windows the user whose credentials you enter for the backup must be granted the Logon as a batch job privilege in the Local Security Policies of Windows. If the chosen user does not have this privilege, then the backup job fails.

   Click Next.

   The Database Credentials screen displays.

   
   Description of the illustration dbua07.jpg
   
   

8. Select one of the following options:

   • Use Different Passwords

     If you choose to use different passwords, then you must enter a password in the Password and Confirm Password columns for each account in the table.

   • Use the Same Password for All Accounts

     If you choose to use the same password, then you must enter that password in the Password and Confirm Password fields.

     Note:

     If the default Oracle Database 11g Release 2 (11.2) security settings are in place, then new passwords must be at least eight characters, and passwords such as welcome and oracle are not allowed. See Oracle Database Security Guide for more information.

   Click Next.

   The Summary screen appears.

   
   Description of the illustration dbua08.jpg
   
   

9. The Summary screen shows the following information about the upgrade before it starts:

   • Name, version, and Oracle home of the old and new databases

   • Database backup location, available space, and space required

   • Warnings ignored

   • Database components to be upgraded

   • Initialization parameters changes

   • Database files location

   • Listener registration

   See Also:

   "Setting the COMPATIBLE Initialization Parameter" for information about setting the COMPATIBLE initialization parameter after the upgrade

   Check all of the specifications. Then do one of the following:

   • Click Back if anything is incorrect until you reach the screen where you can correct it.

   • Click Finish if everything is correct.

   The Progress screen displays and DBUA begins the upgrade.

10. After the upgrade has completed, the following message is displayed on the Progress screen:

    Upgrade is complete. Click "OK" to see the results of the upgrade.
    

11. The Upgrade Results screen displays a description of the original and upgraded databases and changes made to the initialization parameters. The screen also shows the directory where various log files are stored after the upgrade. You can examine these log files to obtain more details about the upgrade process.

    Note:

    An HTML version of the Upgrade Results is also saved in the log files directory.

    1. Click Configure Database Passwords to display the Password Management dialog box.

       The Password Management dialog box enables you to change the default password for a user after you upgrade the database. For security reasons, all users are locked except for the following users:

       • SYS

       • SYSTEM

       If you have enabled Local Management with Enterprise Manager, then the SYSMAN and DBSNMP accounts are also unlocked. These accounts provide Enterprise Manager with access to the database so it can gather monitoring data and so you can perform administration tasks with Enterprise Manager.

       If you have enabled Central Management with Enterprise Manager, then the DBSNMP account is unlocked, as well as the SYS and SYSTEM user accounts.

       Note:

       To prevent unauthorized use of the database, Oracle recommends that you change all user passwords immediately after you upgrade your database.

       If the default Oracle Database 11g Release 2 (11.2) security settings are in place, then passwords must be at least eight characters, and passwords such as welcome and oracle are not allowed. See Oracle Database Security Guide for more information.

    2. Click Restore Database if you are not satisfied with the upgrade results.

       Depending on the method you used to back up your database, the Restore operation performs one of two tasks:

       • If you used DBUA to back up your database, then clicking Restore restores the original database and the original database settings from the backup.

       • If you used your own backup procedure to back up the database, then clicking Restore restores only the original database settings. To restore the database itself, you must restore the backup you created with your own backup utilities.

    If you are satisfied with the upgrade results, then click Exit to quit DBUA and use your newly upgraded database.

    1. DBUA modifies the SID_DESC entry for the upgraded database in the Oracle Database listener.ora file in one of the following ways:

       A simple case: Suppose the old listener.ora has the following SID_DESC entry:

       ...
          (SID_DESC =
             (SID_NAME = ORCL)
          )
       ...
       

       If the database name is SAL, the domain name is COM, and the Oracle home is /oracle/product/9.2, then the assistant adds the following entry:

       ...
          (SID_DESC =
              (GLOBAL_DBNAME = sal.com)
                 (ORACLE_HOME = /oracle/product/9.2)
                 (SID_NAME = SAL)
           )
       ...
       

       A more complicated case: Suppose the old listener.ora has the following SID_DESC entry:

       ...
          (SID_DESC =
              (GLOBAL_DBNAME = an_entry)
              (SID_NAME = ORCL)
           )
       ...
       

       If an_entry does not match the GLOBAL_DBNAME of the migrated database, and if the database name is SAL, the domain name is COM, and the Oracle home is /oracle/product/9.2, then the assistant adds the following entry:

       ...
          (SID_DESC =
              (GLOBAL_DBNAME = sal.com)
                 (ORACLE_HOME = /oracle/product/9.2)
                 (SID_NAME = SAL)
           )
       ...
       

       This entry is the same as the entry in the simple case, but DBUA also adds the entry an_entry to the SERVICE_NAMES parameter in the initialization parameter file. Therefore, DBUA changes the SERVICE_NAMES parameter to the following:

       SERVICE_NAMES = sal.com, an_entry
       

    2. DBUA removes the entry of the upgraded database from the old listener.ora file.

    3. DBUA reloads the listener.ora file in both the old and new Oracle Database environments.

12. >>The following steps were deleted, either because the screens no longer appear or because they have been replaced with rewritten steps covering the same screens, as per IOUG presentation by Ravi Pattabhi 3/26/07. CBF 3/30/07

    Specify the attributes for the SYSAUX tablespace, which is added automatically to all new Oracle Database 11g Release 1 (11.1) databases you create.

    See Also:

    Oracle Database Administrator's Guide for more information about the SYSAUX tablespace

    Many of the attributes of the SYSAUX tablespace are set automatically and cannot be modified. For example, the SYSAUX tablespace is set to use Automatic Segment-Space Management. However, you can specify the location of the data file, the default size of the SYSAUX tablespace, and its autoextend attributes.

    Note:

    If you specify an existing datafile for the SYSAUX tablespace, then you must select Reuse Existing File Name. Otherwise, DBUA alerts you to the fact that the file currently exists.

    Click Next.

    The Recompiling Invalid Objects screen appears.

13. Secure your database with passwords for the Enterprise Manager accounts. You can set a single password, which is applied to each of the listed Enterprise Manager user accounts, or enhance the security of the accounts by providing unique passwords for each user.

    Click Next.

    The Recovery Configuration screen appears.

14. Specify a flash recovery area and enable archiving. When you are managing your database, it is important to configure the database so you can recover your data in the event of a system failure.

    The Flash Recovery Area can be used to recover data that would otherwise be lost during a system failure. This location is also used by Enterprise Manager if you enabled local management and daily backups on the Management Options screen.

    Click Next.

    The Network Configuration screen appears.

15. At the Upgrade Operations page, do one of the following:

    • Select the option to upgrade only the Oracle ASM instance

    • Select the option to upgrade the database

      If you choose to upgrade the database, and the database is using Oracle ASM, then DBUA asks if you want to upgrade the Oracle ASM instance along with the database. Oracle recommends that you upgrade the database and Oracle ASM in separate DBUA sessions, in separate Oracle homes.

    Click Next.

    The Selecting a Database Instance screen appears.

16. At the Changes in Default Behavior screen, DBUA displays some changes in the behavior of Oracle Database 11g Release 1 (11.1) from that of previous releases. In some cases the default values of some initialization parameters have changed. In other cases some new behavior/requirement has been introduced that might affect current scripts or applications.

17. Complete the procedures described in Chapter 4, "After Upgrading to the New Release".

In-Place Upgrade on Windows

The following topics discuss how to perform an upgrade into an existing Oracle home on Windows platforms:

• Considerations for In-Place Upgrade on Windows Platforms

• Performing an In-Place Upgrade on Windows

Using DBUA in Silent Mode

When invoked with the -silent command line option, DBUA operates in silent mode. In silent mode, DBUA does not present a user interface. It also writes any messages (including information, errors, and warnings) to a log file in ORACLE_HOME/cfgtoollogs/dbua/SID/upgraden, where n is the number of upgrades that DBUA has performed as of this upgrade.

To upgrade a database with DBUA in silent mode 

• Issue the following command

  dbua -silent -sid ORCL &
  

  where the database is named ORCL in this example.

  Additional information is provided in these topics:

• DBUA Command Line Options for Silent Mode

• DBUA Command Line Syntax for Silent Mode

dbua [ -silent ] [ -sid SID ] [-oracleHome home_name] [-oracleBase base_name]
[-diagnosticDest diagnostic_destination]
[-sysDBAUserName SYSDBA_user] [-sysDBAPassword SYSDBA_pwd]
[-upgradeASM] [-autoextendFiles] [-newGlobalDbName db_name] [-newSid new_SID]
[-generateMapFile] [-useASM] [-commonFileLocation common_files]
[-omfLocation omf_area] [-databaseMapFile map_file_name]
[-newRecoveryArea recover_area] [-newRecoveryAreaSize recover_size]
[-apexAdminPassword apex_pwd] [-disableUpgradeScriptLogging ] 
[-backupLocation directory]
[-sysauxTablespace -datafileName name -datafileSize size 
  -datafileSizeNext size -datafileSizeMax size]
[-postUpgradeScripts script [, script ] ... ]
[-initParam parameter=value [, parameter=value ] ... ]
[-disableArchiveLogMode] [-recompile_invalid_objects true | false]
[-degree_of_parallelism cpu_number]
[-emConfiguration {CENTRAL|LOCAL|ALL|NOBACKUP|NOEMAIL|NONE}
  -dbsnmpPassword password -sysmanPassword password -asmPassword password 
  -hostUserName hostname -hostUserPassword password -backupSchedule hh:mm
  [-smtpServer server_name -emailAddress address]
  [-centralAgent location] [-localRacSid SID]]
[-recoveryAreaDestination directory] [-h|-help]

Backing Up the Database

After running the Pre-Upgrade Information Tool and cleanly shutting down the instance, Oracle recommends that you back up the database as described in this section. If you encounter problems with the upgrade and wish to abandon the upgrade completely, then you must restore the database from this backup. Therefore, Oracle recommends that you back up your database now as a precaution.

To perform a full backup of the database to be upgraded

1. Sign on to RMAN:

   rman "target / nocatalog"
   

2. 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 FORMAT 'controlfile location and name';
   }
   

Preparing the New Oracle Home

After backing up the database to be upgraded, prepare the new Oracle home in a new location. Do this for any release of Oracle Database for which you are upgrading, whether the database is release 11.2 or earlier. Starting with Oracle Database 11g Release 2 (11.2.0.2), you install the Oracle Grid Infrastructure and Oracle Database software into a new Oracle home instead of applying a patch set to the existing Oracle home.

To prepare the new Oracle home 

1. Copy configuration files from the Oracle home of the database being upgraded to the new Oracle Database 11g Release 2 (11.2) Oracle home:

   1. 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 parameter file in the ORACLE_HOME/dbs directory on Linux or UNIX platforms and in the ORACLE_HOME\database directory on Windows operating systems. The parameter file can reside anywhere you wish, but it should not reside in the old environment's Oracle home after you upgrade to Oracle Database 11g Release 2 (11.2).

      Note:

      It might be necessary to create a text initialization parameter file (PFILE) from the server parameter file (SPFILE) so that you can edit the initialization parameters.

   2. If your parameter file resides within an Oracle ASM instance, then back up the parameter file using the following command:

      CREATE pfile FROM spfile;
      

      If you must downgrade the database and your SPFILE resided within Oracle ASM, then the parameter file must be restored before the downgrade.

   3. 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 environment's 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.

   4. If you have a password file that resides within the old environment's Oracle home, then move or copy the password file to the Oracle Database 11g Release 2 (11.2) Oracle home.

      The name and location of the password file are operating system-specific. On Linux or UNIX platforms, the default password file is orapwsid, located in the ORACLE_HOME/dbs directory. On Windows operating systems, the default password file is pwdsid.ora, located in the ORACLE_HOME\database directory. In both cases, sid is your Oracle instance ID.

   5. If you are upgrading a cluster database and your initdb_name.ora file resides within the old environment's Oracle home, then move or copy the initdb_name.ora 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.

2. Adjust your parameter file in Oracle Database 11g Release 2 (11.2) by completing the following steps:

   1. Remove obsolete initialization parameters and adjust deprecated initialization parameters. Certain parameters are obsolete in Oracle Database 11g Release 2 (11.2), while other parameters have become deprecated. Remove all obsolete parameters from any parameter file that starts an Oracle Database 11g Release 2 (11.2) instance. Obsolete parameters might cause errors in Oracle Database 11g Release 2 (11.2). Also, alter any parameter whose syntax has changed in the new release.

      The Pre-Upgrade Information Tool displays any deprecated parameters and obsolete parameters it finds in the Deprecated Parameters and Obsolete Parameters sections, respectively.

      See Also:

      Appendix A, "Behavior Changes" for a list of initialization parameters that have been deprecated or have become obsolete, and for information on initialization parameters that have changed in ways that raise compatibility issues between different releases of Oracle Database software

   2. Make sure the COMPATIBLE initialization parameter is properly set for Oracle Database 11g Release 2 (11.2). The Pre-Upgrade Information Tool displays a warning in the Database section if COMPATIBLE is not properly set.

   3. Adjust the values of the initialization parameters to at least the minimum values indicated by the Pre-Upgrade Information Tool.

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

   5. If the parameter file contains an IFILE entry, then change the IFILE entry in the parameter file to point to the new location of the include file that you specified in Step 1. c. Then, edit the file specified in the IFILE entry in the same way that you edited the parameter file in Step a through Step d.

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

   Make sure you save all of the files you modified after making these adjustments.

   Note:

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

3. If you are upgrading a cluster database, then set the CLUSTER_DATABASE initialization parameter to false. After the upgrade, you must set this initialization parameter back to TRUE.

Manually Upgrading the Database

After preparing the new Oracle home, you are ready to proceed with the manual upgrade.

To manually upgrade the database 

1. Shut down the instance:

   SQL> SHUTDOWN IMMEDIATE
   

2. If your operating system is Windows, then complete the following steps:

   1. 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:

      C:\> NET STOP OracleServiceORCL
      

   2. Delete the Oracle service at a command prompt using ORADIM.

      If your SID is ORCL, then enter the following command:

      C:\> ORADIM -DELETE -SID ORCL
      

   3. Create the Oracle Database 11g Release 2 (11.2) service at a command prompt using the ORADIM command of the new Oracle Database release:

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

      This syntax includes the following variables:

      Variable	Description
      SID	The same SID name as the SID of the database you are upgrading.
      PASSWORD	The password for the new Oracle Database 11g Release 2 (11.2) database instance. This is the password for the user connected with SYSDBA privileges. The -SYSPWD option is not required. If you do not specify it, then operating system authentication is used, and no password is required. If the default Oracle Database 11g Release 2 (11.2) security settings are in place, then passwords must be at least eight characters, and passwords such as welcome and oracle are not allowed. See Oracle Database Security Guide for more information.
      USERS	The maximum number of users who can be granted SYSDBA and SYSOPER privileges.
      ORACLE_HOME	The Oracle Database 11g Release 2 (11.2) Oracle home directory. Ensure that you specify the full path name with the -PFILE option, including the drive letter of the Oracle home directory.

      
      

      For example, if your SID is ORCL, your password (SYSPWD) is TWxy5791, the maximum number of users (MAXUSERS) is 10, and the ORACLE_HOME directory is C:\ORACLE\PRODUCT\11.2.0\DB, then enter the following command:

      C:\> ORADIM -NEW -SID ORCL -SYSPWD TWxy5791 -MAXUSERS 10
      -STARTMODE AUTO -PFILE C:\ORACLE\PRODUCT\11.2.0\DB\DATABASE\INITORCL.ORA
      

      ORADIM writes a log file to the ORACLE_HOME\database directory.

3. If your operating system is Linux or UNIX, then perform the following checks:

   1. Your ORACLE_SID is set correctly

   2. The oratab file points to your Oracle Database 11g Release 2 (11.2) Oracle home

   3. The following environment variables point to the Oracle Database 11g Release 2 (11.2) directories:

      • ORACLE_HOME

      • PATH

   4. Any scripts that clients use to set the ORACLE_HOME value must point to the new Oracle home.

   Note:

   If you are upgrading a cluster database, then perform these checks on all nodes in which this cluster database has instances configured.

   See Also:

   Your operating system-specific Oracle Database installation documents for information about setting other important environment variables on your operating system.

4. Log in to the system as the owner of the Oracle Database 11g Release 2 (11.2) Oracle home directory.

5. At a system prompt, change to the ORACLE_HOME/rdbms/admin directory.

6. Start SQL*Plus.

7. Connect to the database instance as a user with SYSDBA privileges.

8. Start the instance by issuing the following command:

   SQL> STARTUP UPGRADE
   

   Note:

   The UPGRADE keyword enables you to open a database based on an earlier Oracle Database release. It also restricts logons to AS SYSDBA sessions, disables system triggers, and performs additional operations that prepare the environment for the upgrade.

   You might be required to use the PFILE option to specify the location of your initialization parameter file.

   Once the database is started in upgrade mode, only queries on fixed views execute without errors until after the catupgrd.sql script is run. Before running catupgrd.sql, queries on any other view or the use of PL/SQL returns an error.

   The following are common errors that might occur when attempting to start the new Oracle Database 11g Release 2 (11.2) database. Some of these errors are written to the alert log and not to your session. If you receive any of these errors, then issue the SHUTDOWN ABORT command to shut down the database and correct the problem.

   • ORA-00401: the value for parameter compatible is not supported by this release

     The COMPATIBLE initialization parameter is set to a value less than 10.0.0.

   • ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE

     The CLUSTER_DATABASE initialization parameter is set to TRUE instead of FALSE.

   • ORA-39700: database must be opened with UPGRADE option

     The STARTUP command was issued without the UPGRADE keyword.

   • ORA-00336: log file size xxxx blocks is less than minimum 8192 blocks

     A redo log file size is less than 4 MB:

   If errors appear listing obsolete initialization parameters, then make a note of the obsolete initialization parameters and continue with the upgrade. Remove the obsolete initialization parameters the next time you shut down the database.

9. Perform this step only if you are upgrading from Oracle9i Release 2 (9.2). Otherwise, skip to the next step.

   Create a SYSAUX tablespace. In the new Oracle Database 11g release, 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 Pre-Upgrade Information Tool provides an estimate of the minimum required size for the SYSAUX tablespace under the SYSAUX Tablespace section. Table 3-4 can be used to determine an optimal size for the SYSAUX tablespace.

   Table 3-4 Guidelines for Sizing the SYSAUX Tablespace

   Factor	Small	Medium	Large
   Number of CPUs	2	8	32
   Number of concurrently active sessions	5	20	100
   Number of user objects (tables and indexes)	500	5,000	50,000
   Estimated SYSAUX size at steady state with default configuration	500 MB	2 GB	5 GB

   
   

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

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

   See Also:

   Oracle Database Administrator's Guide for more information about the SYSAUX tablespace

10. Set the system to spool results to a log file for later verification of success:

    SQL> SPOOL upgrade.log
    

11. Run the Pre-Upgrade Information Tool by executing the utlu112i.sql script:

    SQL> @utlu112i.sql
    

12. Run the catupgrd.sql script:

    SQL> @catupgrd.sql
    

    Note:

    If you did not run the Pre-Upgrade Information Tool, the catupgrd.sql script terminates with one of the following errors:

    ORA-00942: table or view does not exist
    ORA-00904: "TZ_VERSION": invalid identifier
    ORA-01722: invalid number 
    

    If you receive any of these errors, issue the SHUTDOWN ABORT statement, revert to the original Oracle home directory, and run the Pre-Upgrade Information Tool (utlu112i.sql) as described in "Using the Pre-Upgrade Information Tool".

    The catupgrd.sql script determines which upgrade scripts must be run, runs them, and then shuts down the database. You must run the script in the Oracle Database 11g Release 2 (11.2) environment.

    The upgrade script creates and alters certain data dictionary tables. It also upgrades or installs the following database components in the new Oracle Database 11g Release 2 (11.2) database:

    • Oracle Database Catalog Views

    • Oracle Database Packages and Types

    • JServer JAVA Virtual Machine

    • Oracle Database Java Packages

    • Oracle XDK

    • Oracle Real Application Clusters

    • Oracle Workspace Manager

    • Oracle Multimedia

    • Oracle XML Database

    • OLAP Analytic Workspace

    • Oracle OLAP API

    • OLAP Catalog

    • Oracle Text

    • Spatial

    • Oracle Data Mining

    • Oracle Label Security

    • Messaging Gateway

    • Oracle Expression Filter

    • Oracle Rules Manager

    • Oracle Enterprise Manager Repository

    • Oracle Database Vault

    • Oracle Application Express

13. Restart the instance to reinitialize the system parameters for normal operation.

    SQL> STARTUP
    

    This restart, following the database shutdown performed as part of the catupgrd.sql script, flushes all caches, clears buffers, and performs other housekeeping activities. These measures are an important final step to ensure the integrity and consistency of the newly upgraded Oracle Database software.

    Note:

    If you encountered a message listing obsolete initialization parameters when you started the database in Step 8, 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. See the chapter about managing initialization parameters using a server parameter file in Oracle Database Administrator's Guide.

14. Run utlu112s.sql, the Post-Upgrade Status Tool, which provides a summary of the upgrade at the end of the spool log. You must run utlu112s.sql only immediately after running catupgrd.sql. See "About the Post-Upgrade Status Tool" for more information.

    Run utlu112s.sql to display the results of the upgrade as follows:

    SQL> @utlu112s.sql
    

    If the Post-Upgrade Status Tool returns errors or shows components that are not VALID or not the most recent release, then see "Troubleshooting the Upgrade" for more information.

15. 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> @rdbms/admin/catuppst.sql
    

    This may generate the following informational messages:

    Generating apply and rollback scripts...
    Check the following file for errors:
    Apply script: .*
    Rollback script: .*
    Executing script file...
    Updating registry...
    Check the following log file for errors: 
    
    Generating apply and rollback scripts...
    Check the following file for errors:
    .../cfgtoollogs/catbundle/catbundle_PSU_*.log
    Apply script:
    .../rdbms/admin/catbundle_PSU_*_APPLY.sql
    Rollback script:
    .../rdbms/admin/catbundle_PSU_*_ROLLBACK.sql
    Executing script file... 
    
    Updating registry...
    Check the following log file for errors:
    .../cfgtoollogs/catbundle/catbundle_PSU_*.log 
    

16. 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:

    SQL> SELECT count(*) FROM dba_invalid_objects;
    SQL> SELECT distinct object_name FROM dba_invalid_objects;
    

    Note:

    If the pre-upgrade information tool detected INVALID objects and populated the registry$sys_inv_objs and registry$nonsys_inv_objs tables, then execute ORACLE_HOME/rdbms/admin/utluiobj.sql to display only those objects which are newly invalid because of the upgrade process. The utluiobj.sql script only displays objects that are now INVALID but which were VALID before the upgrade.

17. Exit SQL*Plus.

18. If you are upgrading a cluster database from releases 10.2, 11.1, or 11.2.0.1, then upgrade the database configuration in Oracle Clusterware using the following command:

    $ srvctl upgrade database -d db-unique-name -o oraclehome
    

    where db-unique-name is the database name assigned to it (not the instance name), and oraclehome is the Oracle home location in which the database is being upgraded.

Your database is now upgraded to the new Oracle Database 11g release. You are ready to complete the procedures described in Chapter 4, "After Upgrading to the New Release".

Oracle Database 11.2 Post-Upgrade Status Tool         10-18-2010 22:48:55
.
Component                                Status         Version  HH:MM:SS
.
Oracle Server
.                                         VALID      11.2.0.2.0  00:17:31
JServer JAVA Virtual Machine
.                                         VALID      11.2.0.2.0  00:02:32
Oracle Workspace Manager
.                                         VALID      11.2.0.2.0  00:01:02
Messaging Gateway
.                                         VALID      11.2.0.2.0  00:00:46
OLAP Analytic Workspace
.                                         VALID      11.2.0.2.0  00:03:20
OLAP Catalog
.                                         VALID      11.2.0.2.0  00:05:56
Oracle OLAP API
.                                         VALID      11.2.0.2.0  00:00:48
Oracle Label Security
.                                         VALID      11.2.0.2.0  00:00:37
Oracle Enterprise Manager
.                                         VALID      11.2.0.2.0  00:12:02
Oracle XDK
.                                         VALID      11.2.0.2.0  00:00:42
Oracle Text
.                                         VALID      11.2.0.2.0  00:01:02
Oracle XML Database
.                                         VALID      11.2.0.2.0  00:04:24
Oracle Database Java Packages
.                                         VALID      11.2.0.2.0  00:00:27
Oracle Multimedia
.                                         VALID      11.2.0.2.0  00:05:44
Spatial
.                                         VALID      11.2.0.2.0  00:08:24
Oracle Expression Filter
.                                         VALID      11.2.0.2.0  00:00:38
Oracle Rules Manager
.                                         VALID      11.2.0.2.0  00:00:21
Oracle Application Express
.                                         VALID     3.2.1.00.12  00:23:25
Gathering Statistics
.       00:05:12
Total Upgrade Time: 01:29:03

SELECT COMP_NAME,VERSION,STATUS FROM DBA_REGISTRY;

Resource Limits

If you run out of resources during the upgrade, then increase the resource allocation. After increasing the resource allocation, you should perform a SHUTDOWN ABORT and restart the instance (in UPGRADE mode) before rerunning the catupgrd.sql script or restarting DBUA.

The resources that generally require increases for a new Oracle Database release are as follows:

• SYSTEM and SYSAUX tablespaces

  Typically you receive one of the following messages during the upgrade if your SYSTEM tablespace size is insufficient:

  ORA-01650: unable to extend rollback segment string by string in tablespace string
  ORA-01651: unable to extend save undo segment by string for tablespace string
  ORA-01652: unable to extend temp segment by string in tablespace string
  ORA-01653: unable to extend table string.string by string in tablespace string
  ORA-01654: unable to extend index string.string by string in tablespace string
  ORA-01655: unable to extend cluster string.string by string in tablespace string
  

  To avoid these errors, set AUTOEXTEND ON MAXSIZE UNLIMITED for the SYSTEM and SYSAUX tablespaces.

• Shared memory

  You might require larger shared memory pool sizes in some cases. The error message indicates which shared memory initialization parameter must be increased.

  ORA-04031: unable to allocate string bytes of shared memory ("string","string","string","string")
  

  See Also:

  Oracle Database Reference for information about shared memory initialization parameters.

• Rollback segments/undo tablespace

  If you are using rollback segments, then you must have a single large (100 MB) PUBLIC rollback segment online while the upgrade scripts are being run. Smaller public rollback segments should be taken offline during the upgrade. Typically you get the following error if your rollback segment size is insufficient:

  ORA-01562: failed to extend rollback segment number string
  

  If you are using an undo tablespace, then be sure it is at least 400 MB.

• Flash Recovery Area

  If you are using a Flash Recovery Area and it fills up during the upgrade, then the following error appears in the alert log, followed by suggestions for recovering from the problem:

  ORA-19815: WARNING: db_recovery_file_dest_size of string bytes is 98.99%
  used, and has string remaining bytes available.
  

  Identify the root cause of the problem and take appropriate actions to proceed with the upgrade. To avoid issues during the upgrade, increase the amount of space available in your Flash Recovery Area before starting the upgrade.

Edition Session Startup Error

If an upgrade script or command running in SQL*Plus set the EDITION parameter, then Oracle Database cannot start properly afterwards and error SP2-1540: "Oracle Database cannot startup in an Edition session" is thrown. To avoid this problem, after running catugrd.sql or any SQL*Plus session where this parameter is changed, exit the SQL*Plus session and restart the instance in a different session.

Manual Workaround for ORA-01408

The ORA-01408 error on the index is a known problem with Oracle Application databases, because the same index exists with a different name in these databases.

SQL> create index system.repcat$_audit_column_f2_idx on
2  system.repcat$_audit_column(base_sname,base_oname,base_conflict_type_id,
3  base_reference_name)
4  /
system.repcat$_audit_column(base_sname,base_oname,base_conflict_type_id,
                          *ERROR at line 2:
ORA-01408: such column list already indexed

The workaround is to drop the REPCAT$_AUDIT_COLUMN_IDX1 index and rerun the upgrade as described in "Rerunning the Upgrade".

Running the DBMS_DST Package After Upgrade Can Result in ORA-01822

Running the DBMS_DST package after upgrading to Oracle Database 11g Release 2 (11.2) can result in the ORA-01882: time zone region not found error.

This error is returned if the user sets the time zone file version incorrectly, which results in the region IDs of several time zone regions being stored incorrectly in the database. For example:

ERROR at line 1:
@  ORA-01882: time zone region not found
@  ORA-06512: at "SYS.DBMS_DST", line 113
@  ORA-06512: at "SYS.DBMS_DST", line 1101
@  ORA-06512: at line 1

To fix this problem, update the time zone version as described in "About Warnings for TIMESTAMP WITH TIME ZONE Data Type" and rerun the upgrade as described in "Rerunning the Upgrade".

Component Status

The Post-Upgrade Status Tool should report VALID status for all components at the end of the upgrade. The following list shows and briefly describes other status values that you might see:

• NO SCRIPT

  The component upgrade script was not found in ORACLE_HOME. Check the install logs, install the component software, and then rerun catupgrd.sql.

• OPTION OFF

  The server option required for the component was not installed or was not linked with the server. Check the V$OPTION view as well as the install logs. Install the component or relink the server with the required option, and then rerun catupgrd.sql.

• REMOVED

  The component was not upgraded because it was removed from the database.

• INVALID

  Some objects for the component were invalid at the completion of the upgrade. If there were no errors during the component upgrade, then running utlrp.sql might change the status to VALID without rerunning the entire upgrade. Check the DBA_REGISTRY view after running utlrp.sql.

• UPGRADING

  The component upgrade did not complete. Resolve the problem and rerun catupgrd.sql.

DBUA May Mark Invalid Components with an X Before Entire Upgrade is Done

DBUA may mark invalid components with an X on the Upgrade Progress window as the upgrade is progressing. An invalid component could be re-validated after a recompile is performed. Please check the final component status on the Upgrade Result page after utlrp.sql recompiles have been run.

Rerunning the Upgrade

You can rerun the upgrade with the catupgrd.sql script as described in the following steps.

To rerun the upgrade 

1. Shut down the database as follows:

   SQL> SHUTDOWN IMMEDIATE
   

2. Restart the database in UPGRADE mode:

   SQL> STARTUP UPGRADE
   

3. Set the system to spool results to a log file for later verification of success:

   SQL> SPOOL upgrade.log
   

4. Rerun catupgrd.sql:

   SQL> @catupgrd.sql
   

   Note:

   You can rerun the catupgrd.sql script as many times as necessary. The first time you run the script, there should be no error messages returned. If you rerun the script, then the ORA-00001 message is displayed. You can safely ignore this message.

5. Rerun utlu112s.sql:

   SQL> @utlu112s.sql
   

Cancelling the Upgrade

If you completed the steps in "Backing Up the Database" to back up your database, then the easiest way to cancel the upgrade is to restore that backup as described in the following procedure.

To cancel the upgrade by restoring the previous backup 

1. Log in to the system as the owner of the Oracle home directory of the previous release.

2. Sign on to RMAN:

   rman "target / nocatalog"
   

3. Issue the following RMAN commands:

   STARTUP NOMOUNT
   RUN
   {
       RESTORE CONTROLFILE FROM 'save_controlfile_location';
       ALTER DATABASE MOUNT;
       RESTORE DATABASE FROM TAG before_upgrade
       ALTER DATABASE OPEN RESETLOGS;
   }