Skip Headers
Oracle® Database Upgrade Guide
12c Release 1 (12.1)

E17642-14
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 Preparing to Upgrade Oracle Database

Before you upgrade Oracle Database, you must understand the requirements and considerations. This chapter provides information and procedures for the pre-upgrade tasks, including installing the new Oracle software for the upgrade.

This chapter contains the following topics:

2.1 Tasks for Preparing to Upgrade Oracle Database

In preparation for upgrading Oracle Database, you review the new features and determine the best upgrade path and method to use. Oracle recommends that you test the upgrade process and prepare a backup strategy.

Complete the following tasks to prepare to upgrade your database:

2.1.1 Become Familiar with New Oracle Database Features

Before you plan the upgrade process, become familiar with the features of the new Oracle Database release. Oracle Database New Features Guide is a good starting point for learning the differences between Oracle Database releases. Also, check specific guides in the Oracle Database documentation library to find information about new features for a certain component. For example, see Oracle Real Application Clusters Administration and Deployment Guide for changes in Oracle Real Application Clusters.

Note:

Oracle Database training classes are an excellent way to learn how to take full advantage of the features and functions available with Oracle Database. More information can be found at http://education.oracle.com/

2.1.2 Determine the Upgrade Path for Oracle Database

The path that you must take to upgrade to Oracle Database 12c depends on the release number of your current database. You may perform a direct upgrade to the new release if your current Oracle Database is release 10.2.0.5, 11.1.0.7, or release 11.2.0.2 or later.

If your current Oracle Database is a release earlier than 10.2.0.5, or is release 11.2.0.1, then directly upgrading your current release of Oracle Database to the latest release is not supported. In this case, you are required to upgrade to an intermediate release before upgrading to the new Oracle Database 12c release.

For example, if the database from which you are upgrading is running Oracle Database 9i, then follow these steps:

  1. Upgrade release 9.0.1.4 to release 10.2.0.5 using the instructions in Oracle Database Upgrade Guide 10g Release 2 (10.2).

  2. Upgrade Oracle Database 10g Release 2 (10.2.0.5) directly to the new release of Oracle Database 12c using the instructions in Oracle Database Upgrade Guide, which is this book.

Table 2-1 contains the required upgrade path for each release of Oracle Database. Use the upgrade path and the specified documentation to perform an intermediate upgrade of your database before fully upgrading to Oracle Database 12c.

Table 2-1 Examples of Upgrade Paths for Oracle Database 12c

If your Current Release is: Then the Direct or Intermediate Upgrade Path is:

11.2.0.2 or later

11.1.0.7

10.2.0.5

Direct upgrade is supported. Perform the upgrade using the current Oracle Database Upgrade Guide, which is this guide.

11.2.0.1

11.1.0.6

10.2.0.2, 10.2.0.3, and 10.2.0.4

10.1.0.5

9.2.0.8 or earlier

Direct upgrade to Oracle Database 12c is not supported.

Solution: Upgrade to an intermediate Oracle Database release (that can be directly upgraded to release 12.1) before you can upgrade to the new Oracle Database 12c. This does not include upgrading using Oracle Data Pump export/import. When upgrading to an intermediate Oracle Database release, follow the instructions in the intermediate release's documentation. Then, upgrade the intermediate release database to the new Oracle Database 12c release using the instructions in Chapter 3, "Upgrading Oracle Database".

For example:

  • If you are upgrading from 11.2.0.1 or 11.1.0.6, then you must first upgrade to Oracle Database 11g Release 2 (11.2.0.2).

  • If you are upgrading from 10.2.0.2, 10.2.0.3, 10.2.0.4, or 10.1.0.5, then you must first upgrade to 10.2.0.5 or later.

  • For release 9.2.0.8, you must first upgrade to an intermediate Oracle Database release, as follows:

    9.2.0.8 -> 11.2.0.2 or 11.2.0.3 -> 12.1


See Also:

"Supported Releases for Downgrading Oracle Database" for information related to downgrading your database

2.1.3 Choose an Upgrade Method for Oracle Database

Oracle recommends that you use Database Upgrade Assistant (DBUA) as the best method to upgrade your database. However, Oracle offers several methods to fully upgrade your database that support the complexities of your enterprise. See "Overview of Oracle Database Upgrade Tools and Processes" for the definition and description of the differences between upgrading and migrating data.

The upgrade methods that you can use to upgrade your database to the new Oracle Database release are:

2.1.3.1 The Automated (DBUA) Method for Upgrading Oracle Database

Database Upgrade Assistant (DBUA) interactively steps you through the upgrade process and configures the database for the new Oracle Database release. DBUA automates the upgrade process by performing all of the tasks normally performed manually. DBUA makes appropriate recommendations for configuration options such as tablespaces and redo logs. You can then act on these recommendations.

DBUA provides support for Oracle Real Application Clusters (Oracle RAC). In an Oracle RAC environment, DBUA upgrades all the database and configuration files on all nodes in the cluster.

2.1.3.2 The Manual, Command-line Method for Upgrading Oracle Database

A manual upgrade consists of running SQL scripts and utilities from a command line to upgrade a database to the new Oracle Database release.

While a manual upgrade gives you finer control over the upgrade process, it is more susceptible to error if any of the upgrade or pre-upgrade steps are either not followed or are performed out of order.

2.1.3.2.1 Before the Upgrade

The following list provides a high-level summary of the manual upgrade steps:

  • Analyze the database using the Pre-Upgrade Information Tool. The Pre-Upgrade Information Tool is a SQL script that is supplied with Oracle Database, and DBUA uses this tool as part of its upgrade process. Run the Pre-Upgrade Information Tool on the database you are upgrading.

    The Pre-Upgrade Information Tool displays warnings about possible upgrade issues with the database, and generates fixup scripts for you to use to address any issues. It also displays information about required initialization parameters for the new release of Oracle Database.

  • Prepare the new Oracle home.

  • Perform a backup of the database.

Depending on the release of the database being upgraded, you might be required to perform additional pre-upgrade steps (adjust the parameter file for the upgrade, remove desupported initialization parameters and adjust initialization parameters that might cause upgrade problems).

2.1.3.2.2 After the Upgrade

Review the upgrade spool log file and use the Post-Upgrade Status Tool, utlu121s.sql. The Post-Upgrade Status Tool is a SQL script that is included with Oracle Database. You run the Post-Upgrade Status Tool in the environment of the new release. You can run the Post-Upgrade Status Tool any time after upgrading the database.

2.1.3.3 The Export/Import Method for Migrating Data When Upgrading Oracle Database

Unlike DBUA or a manual command-line upgrade, the Oracle Data Pump Export and Import utilities physically migrate a copy of data from your current database to a new database in the new release. Data Pump Export and Import are recommended for higher performance and to ensure support for new datatypes.

The new database must exist, or you must have created the database in the new Oracle home, before the contents of the export dump file(s) can be loaded.

When importing data from an earlier release, the import utility of the new Oracle Database release makes appropriate changes to data definitions as it reads the export dump files from the earlier release.

Note:

  • If your database is earlier than Oracle Database release 10.1, then you can use the original Export and Import utilities to perform a full or partial export from your database, followed by a full or partial import into a new database for the upgraded Oracle Database. Export/Import can copy a subset of the data in a database, leaving the original database unchanged.

  • The original Export utility is no longer being updated to support new datatypes.

2.1.3.3.1 The Effects of Export/Import on Upgraded Oracle Databases

The Export/Import data migration method does not change the current database, which enables the database to remain available throughout the upgrade process. However, if a consistent snapshot of the database is required (for data integrity or other purposes), then the database must run in restricted mode or must otherwise be protected from changes during the export procedure. Because the current database can remain available, you can, for example, keep an existing production database running while the newly upgraded Oracle Database database is being built at the same time by Export/Import. During the upgrade, to maintain complete database consistency, changes to the data in the database cannot be permitted without the same changes to the data in the newly upgraded Oracle database.

Most importantly, the Export/Import operation results in a completely new database. Although the current target database ultimately contains a copy of the specified data that you migrated, the upgraded database might perform differently from the original source database. For example, although Export/Import creates an identical copy of the database, other factors, such as disk placement of data and unset tuning parameters, might cause unexpected performance issues.

2.1.3.3.2 Export/Import Benefits for Migrating Data for Oracle Database

Migrating data when upgrading Oracle Database using Export/Import has benefits, including compressing and restructuring the database for increased performance.

Using Export/Import to migrate data:

  • Defragments the data. You can compress the imported data to improve performance.

  • Restructures the database. You can create new tablespaces or modify existing tables, tablespaces, or partitions to be populated by imported data.

  • Facilitates side-by-side testing of the old and new releases of Oracle Database because an entirely new database is created.

  • Enables the copying of specified database objects or users. Importing only the objects, users, and other items you need is useful for establishing a test environment for the new software on only a subset of the production data. Data Pump Export/Import provides flexible data-subsetting capabilities.

  • Serves as a backup archive. You can use a full database export as an archive of the current database.

  • Enables the upgraded database to be established on an operating system or hardware platform that is different from that which is supporting the database being upgraded.

  • Network-based Data Pump Import allows the new Oracle database to be directly loaded across the network from the old database being upgraded. Thus, no intervening dump files are required.

2.1.3.3.3 Time Requirements for Migrating Data and Upgrading with Export/Import

Migrating data and upgrading an entire Oracle database by using Export/Import can take a long time, especially compared to using DBUA or performing a manual upgrade. Therefore, you might be required to schedule the upgrade during non-peak hours or make provisions for propagating to the new database any changes that are made to the current database during the upgrade.

2.1.4 Choose a New Location for Oracle Home when Upgrading

You must choose a location for Oracle home for the new release of Oracle Database that is separate from the Oracle home of your current release. You cannot install the new software into the same location for Oracle home as your current release.

Using separate installation locations enables you to keep your existing Oracle software installed along with the new Oracle software. This method enables you to test the upgrade process on a test database before replacing your production environment entirely.

2.1.5 Develop a Test Plan for Upgrading Oracle Database

You need a series of carefully designed tests to validate all stages of the upgrade process. Executed rigorously and completed successfully, these tests ensure that the process of upgrading the production database is well understood, predictable, and successful. Perform as much testing as possible before upgrading the production database. Do not underestimate the importance of a complete and repeatable testing process.

The types of tests that you perform are the same whether you use Oracle Real Application Testing features like Database Replay or SQL Performance Analyzer, or perform testing manually.

Your test plan must include these types of tests:

2.1.5.1 Upgrade Testing

Upgrade testing for Oracle Database entails planning and testing the upgrade path from your current software to Oracle Database 12c, whether you use DBUA, perform a manual upgrade, or use Export/Import or other data-copying methods. Regardless of the upgrade method you choose, you must establish, test, and validate an upgrade plan.

2.1.5.2 Minimal Testing

Minimal testing for Oracle Database entails moving all or part of an application from the current database to the new database and running the application without enabling any new database features. Minimal testing might not reveal problems that would appear in an actual production environment. However, minimal testing immediately reveals any application startup or invocation problems.

2.1.5.3 Functional Testing

Functional testing for Oracle Database is a set of tests in which new and existing features and functions of the system are tested after the upgrade. Functional testing includes all database, networking, and application components. The objective of functional testing is to verify that each component of the system functions as it did before upgrading and to verify that new functions are working properly.

2.1.5.4 High Availability Testing

High Availability testing for Oracle Database ensures that the upgraded database system must meet: Recovery Time Objective (RTO) and Recovery Point Objective (RPO) business requirements.

  • In an Oracle RAC environment, injecting node or instance failures during stress testing helps to evaluate if the Oracle RAC recovery capability has changed.

  • To minimize downtime, Oracle recommends that you test your fallback plans and procedures.

  • To ensure that the upgrade process runs within the time that you have allocated, Oracle recommends that you confirm database performance and stability, and resolve performance problems.

See Also:

The Upgrade Companion, Note 1462240.1 on My Oracle Support at http://support.oracle.com/

2.1.5.5 Integration Testing

Integration testing for Oracle Database examines the interactions among components of the system.

Consider the following factors when you plan your integration testing:

  • Pro*C/C++ applications running against Oracle Database 12c instances should be tested to ensure that there are no problems with the new software. See Pro*C/C++ Programmer's Guide for more information about Pro*C/C++ applications.

  • Graphical user interfaces should be tested with other components.

  • Subtle changes in Oracle Database 12c, such as data types, data in the data dictionary (additional rows in the data dictionary, object type changes, and so on) can have an effect all the way up to the front-end application, even if the application is not directly connected to a new Oracle Database 12c instance.

  • If the connection between two components involves Oracle Net or Oracle Net Services, then those connections should also be tested and stress tested. See Oracle Database Net Services Reference for more information about upgrade considerations for Oracle Net Services.

2.1.5.6 Performance Testing

Performance testing for Oracle Database of the new database compares the performance of various SQL statements in the new database with the performance of those same statements in the current database. Before upgrading, you should understand the performance profile of the application under the current database. Specifically, you should understand the calls that the application makes to the database server.

This section describes the following types of performance testing:

2.1.5.6.1 Database Replay

You can use the Database Replay feature to perform real-world testing of a database upgrade on your site's production workload before actually upgrading the production database. This feature captures the actual database workload on the production system and replays it on the test system. Database Replay also provides analysis and reporting to highlight potential problems; for example, errors encountered, divergence in performance, and so forth. In addition, all the regular Enterprise Manager performance monitoring and reporting tools such as Automatic Database Diagnostic Monitor, Automatic Workload Repository (AWR), and Active Session History are available to address any problems.

Note:

You can change the stored procedure logic in the database but the stored PL/SQL procedures that implement the application logic must maintain the same interfaces as before the upgrade. If an upgrade affects the stored procedures of an application, then the workload might not be replayable. By using the Database Replay tool in this way, you have good diagnostics to see if the new application logic in the server is performing as expected after the upgrade.

See Also:

2.1.5.6.2 SQL Performance Analyzer

You can use the SQL Performance Analyzer to forecast the impact of system changes on a SQL workload. SQL Performance Analyzer enables evaluating the impact of a change such as database upgrade by identifying the SQL statements impacted by the upgrade and measuring their performance divergence. The analysis enables you to assess the overall effect of the upgrade on SQL performance and makes it possible to avoid any negative outcome before users can be impacted.

See Also:

Oracle Database Testing Guide for complete information and examples using the SQL Performance Analyzer to perform what-if analysis on potential database changes
2.1.5.6.3 SQL Plan Management

A database upgrade that installs a new optimizer version usually results in plan changes for a small percentage of SQL statements, with most of the plan changes resulting in either no performance change or improvement. However, certain plan changes may cause performance regressions. SQL plan management prevents performance regressions resulting from sudden changes to the execution plan of a SQL statement by providing components for capturing, selecting, and evolving SQL plan information. SQL plan management is a preventative mechanism that records and evaluates the execution plans of SQL statements over time, and builds SQL plan baselines composed of a set of existing plans known to be efficient. The SQL plan baselines are then used to preserve the performance of corresponding SQL statements, regardless of changes occurring in the system.

With SQL plan management, the optimizer automatically manages execution plans and ensures that only known or verified plans are used. When a new plan is found for a SQL statement, the plan is not used until it has been verified by the database to have comparable or better performance than the current plan. Therefore, if you seed SQL plan management with your current execution plan, which is to become the SQL plan baseline for each statement, then the optimizer uses these plans after the upgrade. If the Oracle Database 12c optimizer determines that a different plan is necessary, then the new plan is queued for verification and is not used until it has been confirmed to have comparable or better performance than the current plan.

There are several ways to seed or populate a SQL Management Base (SMB) with execution plans:

Bulk Load a SQL Management Base from the Cursor Cache

Bulk loading of execution plans or SQL plan baselines from the cursor cache is useful when upgrading a database from Oracle Database 11g to the latest release of Oracle Database. The cursor cache is a shared SQL area, and SQL plans that are bulk loaded are automatically accepted and added to existing or new plan histories as SQL plan baselines.

  1. In the source release of Oracle Database, use the DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHE procedure or Oracle Enterprise Manager to load all of the execution plans in the cursor cache into the SQL Management Base.

  2. Upgrade the database.

See Also:

Oracle Database SQL Tuning Guide for more information on how to load plans from the shared SQL area using PL/SQL or Oracle Enterprise Manager

Bulk Load a SQL Management Base with a SQL Tuning Set (STS)

Bulk loading of execution plans or SQL plan baselines may be done with a SQL Tuning Set. This is useful when upgrading from Oracle Database 10g, where no SQL Management Base (SMB) exists to directly load from the cursor cache, or to load historic plans from the Automatic Workload Repository.

  1. In the source release of Oracle Database, create an STS that includes the execution plan for each of the SQL statements.

  2. Load the STS into a staging table and export the staging table into a dump file.

  3. Import the staging table from a dump file into the new release of Oracle and unload the STS.

  4. Use Oracle Enterprise Manager or DBMS_SPM.LOAD_PLANS_FROM_SQLSET to load the execution plans into the SQL Management Base.

See Also:

Oracle Database SQL Tuning Guide for the complete procedure for bulk loading execution plans or SQL plan baselines

Unpack Existing SQL Plan Baselines from a Staging Table

You can test and tune all of your critical SQL queries on an Oracle Database test environment and then move those SQL execution plans to your Oracle Database production environment. Alternatively, you can take plans for SQL queries from your pre-upgrade Oracle Database production environment and move them to your post-upgrade production environment.

  1. On the Oracle Database 12c test system, after completing all testing and tuning, use the DBMS_SPM.LOAD_PLAN_FROM_CURSOR_CACHE procedure or Enterprise Manager to load all of the execution plans in the cursor cache into the SQL Management Base.

  2. Create a staging table using the DBMS_SPM.CREATE_STGTAB_BASELINE procedure.

  3. Pack the SQL plan baselines you created in step 1 into the staging table using the DBMS_SPM.PACK_STGTAB_BASELINE function.

  4. Export the staging table into a flat file using Data Pump.

  5. Transfer this flat file to the target system.

  6. Import the staging table from the flat file using Data Pump.

  7. Unpack the SQL plan baselines from the staging table into the SQL Management Base on the target system using the DBMS_SPM.UNPACK_STGTAB_BASELINE function.

See Also:

2.1.5.7 Volume and Load Stress Testing for Oracle Database Upgrades

Volume and load stress testing tests the entire upgraded Oracle database under high volume and loads. Volume describes the amount of data being manipulated. Load describes the level of concurrent demand on the system. The objective of volume and load testing is to emulate how a production system might behave under various volumes and loads.

Volume and load stress testing is crucial, but is commonly overlooked. Oracle has found that customers often do not conduct any kind of volume or load stress testing. Instead, customers often rely on benchmarks that do not characterize business applications. Benchmarks of the application should be conducted to uncover problems relating to functions, performance, and integration, but they cannot replace volume and load stress testing.

Load testing involves running an application load against the new release of the database to ensure that the application does not encounter problems such as new errors or performance issues under load conditions likely to be encountered in production. Many times, problems manifest under certain load conditions and are normally not seen in functional testing. The Database Replay feature is ideal for such load testing as it enables capturing the system workload from a production environment and replay it in identical fashion on the test system.

See Also:

Oracle Database Testing Guide for information about using Database Replay for stress testing

2.1.6 Prepare a Backup Strategy before Upgrading Oracle Database

The ultimate success of your upgrade depends heavily on the design and execution of an appropriate backup strategy.

To develop a backup strategy, consider the following questions:

  • How long can the production database remain inoperable before business consequences become intolerable?

  • What backup strategy is necessary to meet your availability requirements?

  • Are backups archived in a safe, offsite location?

  • How quickly can backups be restored (including backups in offsite storage)?

  • Have recovery procedures been tested successfully?

Your backup strategy should answer all of these questions and include procedures for successfully backing up and recovering your database.

Tip:

Oracle Database Backup and Recovery User's Guide for information about implementing backup strategies using RMAN

2.2 Considerations and Requirements for Upgrading Oracle Database

Depending on the operating system and Oracle components in your database environment, there are specific information and requirements to be aware of.

The following topics discuss system considerations and requirements for performing an upgrade:

See Also:

2.2.1 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.

See Also:

Oracle Database Administrator's Guide, if you perform a manual upgrade, for information about relocating data files

2.2.2 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 must check separately if the package is available in the current release and reinstall that package to ensure you have the latest version.

2.2.3 Saving Oracle Enterprise Manager Database Control Configuration and Data

If you need to be able to downgrade and then restore Oracle Enterprise Manager Database Control (DB Control) after upgrading to the new release, then you must save your configuration files and data before upgrading your database. Starting with Oracle Database 12c, DB Control is removed as part of the upgrade process. Oracle provides the emdwgrd utility to use before upgrading your database to keep a copy of your DB Control configuration and data. This is necessary if you want to be able to downgrade and restore the DB Control configuration from your earlier database.

The emdwgrd utility resides in the ORACLE_HOME/bin directory in the new Oracle Database 12c release. The emdwgrd utility consists of emdwgrd and emdwgrd.pl for Linux and UNIX, and emdwgrd.bat and emdwgrd.pl for Windows. Before running the utility, you must install the software for Oracle Database 12c, and then invoke the script from the new Oracle home. The emdwgrd utility requires that you set ORACLE_HOME to the Oracle home of the release you are upgrading.

To save DB Control files and data using emdwgrd:

  1. Install the software for the new Oracle Database 12c release.

  2. Set ORACLE_HOME to your old Oracle home.

  3. Set ORACLE_SID to the SID of the database being upgraded.

  4. Set PATH, LD_LIBRARY_PATH, and SHLIB_PATH to point to the Oracle home of the database being upgraded.

  5. Go to the Oracle home of the new Oracle Database 12c release.

  6. Execute emdwgrd as follows:

    • For a single-instance database, run the following command, where old_SID is the SID of the database being upgraded and save_directory is the path to the storage place you have chosen for your database control files and data:

      emdwgrd -save -sid old_SID -path save_directory
      

      Note:

      The script is in emdwgrd.sh on Linux and UNIX platforms. On Windows, the script is in emdwgrd.bat.
    • If the database is an Oracle RAC database, remote copy is required across the cluster nodes. Define an environment variable to indicate which remote copy is configured. For example:

      setenv EM_REMCP /usr/bin/scp
      

      Then, execute emdwgrd as follows:

      emdwgrd -save -cluster -sid old_SID -path save_directory
      

      If the Oracle home is on a shared device, add -shared to the previous command line.

  7. Enter the SYS password for the database to be upgraded.

Note:

The DBUA backup and restore process also enables you to revert to your previous Oracle Enterprise Manager Database Control environment after upgrading your database. However, all user data that is accumulated between the time of upgrade and restore operations is lost. Saving your database control files and data enables you to downgrade both your database and DB Control. All user data is retained even though all DB Control data that is accumulated between the time of upgrade and downgrade is lost.

2.2.4 Manually Removing DB Control with emremove.sql

To minimize downtime during the upgrade process, you can optionally run the emremove.sql script as part of your pre-upgrade preparation. The emremove.sql script drops the Oracle Enterprise Manager-related schemas and objects. This script might take a few minutes to complete as it has six phases in which to complete the process. The script may take longer if you have SYSMAN and related sessions active from SQL*Plus or Oracle Enterprise Manager or other clients.

Important:

You must back up your DB Control configuration and data if you want to downgrade and restore DB Control as described in "Saving Oracle Enterprise Manager Database Control Configuration and Data."

To run emremove.sql to manually remove DB Control:

  1. Shut down the DB Control application immediately.

    $ emctl stop dbconsole
    
  2. Start SQL*Plus and connect to the database using the SYS account AS SYSDBA.

  3. Optional step. Do not set this if you want to run the script in silent mode. To view the progress of emremove.sql while it is running, set the following variables:

    SET ECHO ON;
    SET SERVEROUTPUT ON;
    
  4. Execute emremove.sql. The script is located under ORACLE_HOME/rdbms/admin/ of the new Oracle Database 12c Oracle home.

    $ @emremove.sql
    
  5. After emremove.sql completes, you must manually remove ORACLE_HOME/HOSTNAME_SID and ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SID directories from your file system.

    Note:

    If the DB Control had been upgraded from release 10.2.0.3 to 10.2.0.4, then the following directories also need to be removed from the file system:

    ORACLE_HOME/HOSTNAME_SID.upgrade

    ORACLE_HOME/oc4j/j2ee/OC4J_DBConsole_HOSTNAME_SID.upgrade

  6. On Windows platforms, also delete the DB Console service, generally with the name OracleDBConsoleSID.

2.2.5 About Upgrading an Oracle ASM Instance

The recommended practice is to upgrade an Oracle ASM instance with Oracle Grid Infrastructure Oracle Universal Installer (OUI). OUI automatically defaults to upgrade mode when it detects an Oracle ASM instance at an earlier release level. You can also perform a rolling upgrade to clustered Oracle ASM instances in environments running Oracle Database 11g or later. See your Oracle Grid Infrastructure Installation Guide for step-by-step instructions about performing a rolling upgrade of Oracle ASM.

See Also:

Oracle Grid Infrastructure Installation Guide for information on rolling upgrades for Oracle Clusterware or Oracle Automatic Storage Management

2.2.5.1 Determining If Oracle ASM is Included in the Current Database Configuration

If you do not know whether your configuration includes Oracle ASM, then issue the following SQL statement from the database instance:

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

If this statement returns one or more rows, then the database is actively using an Oracle ASM disk group.

2.2.6 About Upgrading Oracle Grid Infrastructure and Oracle Clusterware

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.

See Also:

Oracle Grid Infrastructure Installation Guide for your operating system and go to the appendix for complete information on how to perform Oracle Clusterware and Oracle Automatic Storage Management upgrades

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

  • To upgrade Oracle Database, you must install the Oracle Grid Infrastructure software into a new Grid home, and install Oracle Database 12c software into the new Oracle home. This also applies to Oracle Grid Infrastructure for a standalone server (Oracle Restart). You can upgrade from supported releases only. See "Determine the Upgrade Path for Oracle Database."

  • On the Windows x64 platform, to upgrade Oracle Clusterware from releases 10.2.0.5 and 11.1.0.7 to release 12.1, you must perform an interim upgrade to 11.2.0.3 for Oracle Clusterware. After upgrading Oracle Clusterware to release 11.2.0.3, you must move the Oracle Cluster Registry (OCR) and voting files (VDSK) to Oracle ASM. You can then upgrade Oracle Clusterware release 11.2.0.3 to release 12.1.

  • If you are upgrading an Oracle Database release 10.2.0.5 or release 11.1.0.7 environment that stores Oracle Clusterware files on OCFS on Windows or RAW devices, then you cannot directly upgrade to Oracle Database 12c. See "About Upgrading Oracle Database Release 10.2 or 11.1 and OCFS and RAW Devices."

  • For Oracle Database release 10.2.0.5, 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 release 11.1, the user account that is designated as owner of the release 10.2.0.5 Oracle Clusterware software must perform the Oracle Clusterware release 11.1.0.7 upgrade. The user account that is performing this upgrade must also be the user that owns the ASM home of the earlier release. If the earlier ASM home has a different owner, then the owner account must be changed before performing the upgrade.

  • For Oracle Database releases 11.1.07 and 10.2.0.5, if your configuration does not include Oracle ASM, then you must shut down the cluster synchronization services (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
    
  • When upgrading Oracle Clusterware, OUI automatically calls Oracle ASM Configuration Assistant (ASMCA) to perform the upgrade into the Oracle Grid Infrastructure home. The Grid Infrastructure home can be local to each node.

  • For a single-instance configuration, Oracle ASM and Oracle Restart run from the Oracle Grid Infrastructure home. Thus, Oracle ASM and Oracle Restart are upgraded to Oracle Grid Infrastructure 12c at the same time.

  • You must ensure that the database compatibility attribute for Oracle ASM disk groups matches the compatibility parameter that is set in init.ora.

See Also:

Oracle Grid Infrastructure Installation Guide for your operating system

2.2.6.1 Oracle Clusterware Must Be Running on Local Node When Upgrading

Starting with Oracle Database 12c, non-rolling upgrades for Oracle Real Application Clusters require Oracle Clusterware on the local node to be up and running. The Oracle Clusterware stack on the local node must be running.

With earlier releases of Oracle Database, non-rolling for the cluster meant that OUI set ISROLLING to false for all stack shutdown before the upgrade process started. If any of the cluster nodes were up, then ISROLLLING was set to true. However, in Oracle Database 12c, rolling means that the local stack is up before upgrade and the other stacks must be shut down. Only in this circumstance OUI sets ISROLLING to false.

To start Oracle Clusterware on the local note:

  1. Run the OUI installer on the node where the Oracle Clusterware stack is running or open a terminal.

  2. Log in as root or Administrator.

  3. Change directory (cd) to the Oracle Clusterware home (Grid home), and start Oracle Clusterware by entering the following command:

    # crsctl start crs
    

2.2.6.2 About Upgrading an Oracle Real Application Clusters (Oracle RAC) Database with DBUA

You can use Database Upgrade Assistant (DBUA) to upgrade an existing Oracle RAC database to the current release of Oracle Database. DBUA guides you through the upgrade process and configures your database for the new release. DBUA automates the upgrade process and makes appropriate recommendations for configuration options such as tablespaces and online redo log files.

If you are manually upgrading an Oracle RAC database, then most of the actions are to be performed on only one node of the system. Actions that must be performed on multiple nodes are indicated in the relevant steps.

See Also:

Oracle Grid Infrastructure Installation Guide for your operating system

2.2.6.3 About Upgrading and Inaccessible Nodes

If you are using the force cluster upgrade command as documented in the upgrade appendix of Oracle Grid Infrastructure Installation Guide, then the information in this section applies.

Starting with Oracle Database 12c, there is a an option to join the inaccessible nodes as an alternative to deleting the nodes, which was required in earlier releases. The new Oracle Database 12c software must already be installed on the nodes.

The following command can be run on the inaccessible or unreachable nodes to upgrade and join them into the cluster.

rootcrs.pl -join -existingNode upgraded_node

In this command, the upgraded_node variable refers to one node in the cluster that has already been upgraded. The -existingNode argument must specify the upgraded node.

2.2.6.4 About Requirements for Time Synchronization on Oracle RAC

Oracle Clusterware for Oracle Database 12c requires time synchronization across all nodes within a cluster when Oracle RAC is deployed.

There are two options for time synchronization:

  • Your operating system-configured network time protocol (NTP)

    or

  • Oracle Cluster Time Synchronization Service

See Also:

Oracle Grid Infrastructure Installation Guide for your operating system for information on configuring NTP and Oracle Cluster Time Synchronization Service

2.2.6.5 Considerations for Upgrading Oracle RAC and Oracle Databases That Use ASM

Oracle ASM is installed when you install the Oracle Grid Infrastructure components. Oracle ASM shares an Oracle home with Oracle Clusterware when installed in a cluster with Oracle RAC or with Oracle Restart on a standalone server. Before the new Oracle Database software can be installed on the system, the root script for upgrading Oracle Grid Infrastructure invokes Oracle ASM Configuration Assistant (ASMCA) to upgrade Oracle ASM to the new release.

If you have an existing Oracle ASM instance, then you can either upgrade it when you install Oracle Grid Infrastructure, or you can upgrade it after the installation, using ASMCA. When you install the new software for Oracle Database 12c, Oracle Universal Installer (OUI) runs the root script root.sh when it detects a cluster. OUI provides an option to automate the root script execution tasks on the nodes of the cluster. You are prompted to provide information and passwords to enable OUI to run the root.sh script automatically. You now have an option to automate the root.sh script execution tasks on the nodes of the cluster.

2.2.6.6 About Upgrading System Authentication for Oracle ASM Instances

For Oracle Automatic Storage Management (Oracle ASM) environments, you can create shared ASM password files. The password file is created by the ORAPWD utility. See Oracle Automatic Storage Management Administrator's Guide for more information about managing a shared password file in a disk group. Oracle recommends that you use the SYSASM privilege to separate database management and storage management responsibilities. Also, you have the option to create separate operating system credentials for Oracle ASM and each database. This separation allows for an even greater division of database management and storage management responsibilities. For instance, if there are n databases using Oracle ASM on a given node, then you can configure n + 1 sets of operating system credentials groups whose members have SYS privileges: one OSDBA group for each database with SYSDBA privileges, and one OSASM group for the Oracle ASM instance with SYSASM privileges.

See Also:

Oracle Automatic Storage Management Administrator's Guide for more information about system authentication for Oracle ASM

2.2.7 About Upgrading with Read-Only and Offline Tablespaces

Oracle Database can read file headers created in earlier releases, so you are not required to do anything to them during the upgrade. During upgrade you may have tablespaces set to read-only or offline mode as long as these tablespaces are not schema-based tablespaces (such as SYSAUX, SYSTEM, XDB, HTMLDB, CTXSYS, etc.); otherwise your upgrade will fail. 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 when they are changed to read/write.

In the rare case where queue tables reside in a tablespace that has been set to read-only for the upgrade, then that tablespace should be set back to read/write. Then the recreation of these queue objects can be tried again after the upgrade.

See Also:

Oracle Database Administrator's Guide for information about transporting tablespaces between databases

2.2.8 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

    You can use Oracle Data Guard SQL Apply on a logical standby database to perform a rolling upgrade to the new Oracle Database release. A logical standby accepts archived logs while the upgrade is in progress. Data protection is maintained during the Data Guard database rolling upgrade process by enabling the standby database that is the target of the upgrade to continue receiving primary database redo while the standby database is open in upgrade mode. Rolling upgrade with SQL Apply provides additional disaster protection.

  • Use of physical standby database for rolling upgrades

    A physical standby database can take advantage of the rolling upgrade feature provided by a logical standby. Through the use of the 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 to the original configuration of a primary database and a physical standby database when the upgrade is done.

  • Rolling Upgrade Using Active Data Guard in Oracle Database 12c

    Oracle Database 12c provides the DBMS_ROLLING PL/SQL package, which enables you to upgrade the database software in a Data Guard configuration in a rolling fashion. Rolling Upgrade Using Active Data Guard uses a Data Guard physical standby database and the SQL Apply process. This is supported for rolling upgrades from Oracle Database release 12.1 onward. See Oracle Data Guard Concepts and Administration for information about using DBMS_ROLLING to perform a rolling upgrade.

Note:

Starting with Oracle Database 12c, Oracle Enterprise Manager Cloud Control provides options to perform a rolling upgrade of databases in a Data Guard configuration. The procedures are described in online help within Cloud Control.

See Also:

2.2.9 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.

See Also:

  • The Oracle Database Installation Guide for your platform to obtain a list of supported operating systems

  • Your operating system-specific documentation for information about how to perform an operating system upgrade

2.2.10 Transporting Data to a Different Operating System

When using DBUA or when performing a manual upgrade for Oracle Database, you cannot directly migrate or transport data in a database on one operating system to a database on another operating system. For example, you cannot migrate data in an Oracle database on Solaris to an Oracle 12c database on Windows using DBUA. You must follow procedures specific to your operating system platforms. For a discussion of transporting data across platforms, see Oracle Database Administrator's Guide.

To see the platforms that support cross-platform data transport, run the following query using SQL*Plus:

SELECT * FROM V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_NAME;

Note:

If the source platform and the target platform are of different endianness, then you cannot use the RMAN CONVERT DATABASE command. This process requires both the source and target platform to be the same endian value. Your available options are Data Pump replication, Data Pump export/import, or Transportable Tablespace, with an RMAN CONVERT TABLESPACE. If the platforms are of the same endianness, then no conversion is necessary and data can be transported as if on the same platform.

See Also:

2.2.11 About Oracle GoldenGate and Online Database Upgrade

In an Oracle GoldenGate replication environment, you can perform an online database upgrade to the current release of Oracle Database. Using an Oracle GoldenGate replication environment minimizes database downtime during upgrading. Oracle GoldenGate is an excellent method to minimize downtime during planned maintenance, including application and database upgrades, in addition to platform migrations. Oracle GoldenGate is an Oracle product sold independently of Oracle Database for Oracle and third-party database management systems.

See Also:

Oracle GoldenGate documentation for more information

2.2.11.1 Overview of Steps for Upgrading Oracle Database Using Oracle GoldenGate

Upgrading to Oracle Database 12c using Oracle GoldenGate consists of the following high-level steps. Unless specified, refer to the Oracle GoldenGate documentation library for procedures.

  1. Set up a standby database running the earlier database software release using an existing database backup.

  2. Upgrade the standby database to Oracle Database 12c. See "Upgrading Oracle Database with Database Upgrade Assistant."

  3. Synchronize the standby database with the production database.

  4. Test your environment in active/live mode.

  5. Switch over the application to the standby database.

  6. Upgrade the primary database to Oracle Database 12c after comprehensive application testing at standby. See Oracle Database Testing Guide for information about testing a database upgrade. After testing, see Chapter 3, "Upgrading Oracle Database."

2.2.12 About Upgrading Oracle Databases That Use Database Vault

When upgrading Oracle Database to Oracle Database 12c, if you have enabled Database Vault in your current Oracle home, then by default Database Vault is disabled in the new target Oracle home. Once the upgrade is complete, enable Database Vault again.

See Also:

Oracle Database Vault Administrator's Guide for instructions about enabling Database Vault

2.2.13 About Upgrading Oracle OLAP Data Security Policies

In Oracle Database 12c, Oracle OLAP uses Oracle Real Application Security (ORAS) to store OLAP data security policies instead of Extensible Data Security (XDS), which it used in Oracle Database 11g releases. When you upgrade Oracle Database from an release 11g to release 12c, any XDS data security policies are automatically converted to ORAS.

Note:

Data security roles defined in a release 11g Oracle Database instance are not automatically converted to ORAS. Before you upgrade an 11g database to Oracle Database 12c, you must delete any data security roles that are defined in the 11g database. After the upgrade, you may use Analytic Workspace Manager 12c to define the data security roles again.

If you upgrade an 11g database to Oracle Database 12c without deleting the 11g data security roles, then any data security policies that include a data security role are invalid in the Oracle Database 12c database.

2.2.14 Requirements for Upgrading Databases That Use Oracle Label Security and Database Vault

If you are upgrading from a database earlier than Oracle Database release 12.1 that uses Oracle Label Security (OLS) and Database Vault, then you must first run the OLS preprocess script, olspreupgrade.sql, to process the aud$ table contents. The OLS upgrade moves the aud$ table from the SYSTEM schema to the SYS schema. The olspreupgrade.sql script is a preprocessing script required for this move.

Caution:

Running the olspreupgrade.sql script before upgrading is mandatory for upgrading databases earlier than Oracle Database release 12.1 that use Oracle Label Security and Database Vault. Once you have upgraded to Oracle Database release 12.1, you do not have to perform the OLS preprocessing procedure going forward to patch or upgrade the database.

The olspreupgrade.sql script creates a temporary table PREUPG_AUD$ in the SYS schema and moves the SYSTEM.aud$ records to SYS.PREUPG_AUD$.

As a safety measure, Oracle recommends that you archive your audit trail as described in Oracle Database Security Guide before running the olspreupgrade.sql script.

If Oracle Label Security is installed on your database, and you are upgrading from an earlier release, then you must run the OLS preprocess script before upgrading, as described in the following sections:

See Also:

Oracle Label Security Administrator's Guide for information about the OLS preprocess script

2.2.14.1 Running olspreupgrade.sql on Oracle Database Release 11.1.0.7

If Oracle Label Security is installed in the earlier release that you are upgrading, then you must run the OLS preprocess olspreupgrade.sql script. If Database Vault is not installed with your release 11.1.0.7 database, then you can skip steps 2, 3, 6, and 7 in this section.

To run the OLS preprocess script on a release 11.1.0.7 database before upgrading:

  1. Copy the ORACLE_HOME/rdbms/admin/olspreupgrade.sql script from the newly installed Oracle home to the Oracle home of the database to be upgraded.

  2. Start SQL*Plus and connect to the database to be upgraded as DVOWNER.

  3. Execute the following statement:

    SQL> EXEC dbms_macadm.add_auth_to_realm('Database Vault','SYS',NULL, 0);
    
  4. At the system prompt, enter:

    CONNECT SYS AS SYSDBA
    
  5. Run the OLS preprocess script:

    ORACLE_HOME/rdbms/admin/olspreupgrade.sql
    

    You can continue running your applications on the database while the OLS preprocess script is running.

  6. After the olspreupgrade.sql has been successfully run, start SQL*Plus and connect to the database as DVOWNER.

  7. Execute the following statement:

    SQL> EXEC dbms_macadm.delete_auth_from_realm('Database Vault','SYS');
    

2.2.14.2 Running olspreupgrade.sql on Oracle Database Release 10.2.0.5 or 11.2

If Oracle Label Security is installed in the earlier release that you are upgrading, then you must run the OLS preprocess olspreupgrade.sql script. If Database Vault is not installed with your release 10.2.0.5 or 11.2 database, then you can skip steps 2, 3, 6, and 7 in this section.

To run the OLS preprocess script on a release 10.2.0.5 or 11.2 database before upgrading:

  1. Copy the ORACLE_HOME/rdbms/admin/olspreupgrade.sql script from the newly installed Oracle home to the Oracle home of the database to be upgraded.

  2. Start SQL*Plus and connect to the database to be upgraded as DVOWNER.

  3. Execute the following statement:

    SQL> GRANT DV_PATCH_ADMIN to SYS;
    
  4. At the system prompt, enter:

    CONNECT SYS AS SYSDBA
    
  5. Run the OLS preprocess script:

    ORACLE_HOME/rdbms/admin/olspreupgrade.sql
    

    You may continue running your applications on the database while the OLS preprocess script is running.

  6. After the olspreupgrade.sql has been successfully run, start SQL*Plus and connect to the database as DVOWNER.

  7. Execute the following statement:

    SQL> REVOKE DV_PATCH_ADMIN from SYS;
    

2.2.15 Requirement for Upgrading Databases that Use Oracle Warehouse Builder (OWB)

OWB is not installed as part of the software for Oracle Database 12c, and OWB components that may exist in earlier releases are not upgraded as part of the Oracle Database upgrade process. However, you can use OWB release 11.2.0.3 with Oracle Database 12c. OWB releases earlier than release 11.2.0.3 do not work with Oracle Database 12c.

You can use OWB release 11.2.0.3 with Oracle Database 12c in the following ways:

2.2.15.1 Add Oracle Database 12c Access to Existing standalone OWB 11.2.0.3 Installation

Oracle provides a patch update that enables OWB 11.2.0.3 to be used with Oracle Database 12c. If you have an existing standalone OWB 11.2.0.3 installation, then you can enable Oracle Database 12c to access OWB.

To add Oracle Database 12c access to an existing standalone OWB 11.2.0.3 installation:

  1. Stop all OWB applications from running: the OWB Runtime service, Browser, and Name Address server.

  2. Install Oracle Database 12c software and follow the database upgrade instructions as described in Chapter 3, "Upgrading Oracle Database."

  3. Apply patch 14872304 to the OWB release 11.2.0.3 installation. (You can patch OWB either before or after installing Oracle Database 12c.)

    To obtain the patch, access the Automated Release Updates (ARU) page at http://support.oracle.com, click Patches, and search for patch request number 14872304.

  4. Follow in-place migration steps in the patch README.txt file.

  5. Continue to run OWB release 11.2.0.3 from the standalone Oracle home.

2.2.15.2 Keep Existing OWB 11.2.0.3 Installation In-place with Oracle Database Release 11.2.0.3

If OWB release 11.2.0.3 is running on a platform where a standalone installation is not available (for example, Solaris, HP, AIX, and so forth), then you must keep the Oracle Database release 11.2.0.3 software in-place after the migration to Oracle Database 12c.

To run OWB integrated with Oracle Database release 11.2.0.3:

  1. Stop all OWB applications from running: the OWB Runtime service, Browser, and Name Address server.

  2. Install Oracle Database 12c software and follow the database upgrade instructions as described in Chapter 3, "Upgrading Oracle Database."

  3. After you have installed Oracle Database 12c, do NOT remove Oracle Database release 11.2.0.3. You run OWB from this Oracle home.

  4. Apply patch 14872304 to the Oracle Database release 11.2.0.3 Oracle home. This patches the OWB installation. (You can patch OWB either before or after installing Oracle Database 12c.)

    To obtain the patch, access the Automated Release Updates (ARU) page at http://support.oracle.com, click Patches, and search for patch request number 14872304.

  5. Follow in-place migration steps in the patch README.txt file.

  6. Run OWB from the integrated Oracle Database release 11.2.0.3 Oracle home.

2.2.15.3 Use the Standalone OWB 11.2.0.3 Installation Where Available

If OWB 11.2.0.3 is running on a platform where a standalone installation is available (on Linux and Windows), you can install the standalone software and then remove the Oracle Database release 11.2.0.3 software.

To convert OWB from an integrated installation to a standalone installation:

  1. Stop all OWB applications from running: the OWB Runtime service, Browser, and Name Address server.

  2. Install the OWB standalone client into its own OWB home directory.

  3. Copy the entire owb/bin/admin directory from the old OWB installation to the new OWB installation's owb/bin/admin directory. This step ensures all files and subdirectories are copied to the new OWB location.

  4. Run the following SQL statement as the OWBSYS user to reset the Control Center home value. Enter from the directory location for the new OWB_HOME when prompted:

    sqlplus OWBSYS/OWBSYS_PASSWORD
    % New_OWB_HOME/owb/UnifiedRepos/reset_owbcc_home.sql
    
  5. Install Oracle Database 12c software and follow the database upgrade instructions as described in Chapter 3, "Upgrading Oracle Database."

  6. Apply ARU patch 14872304 to the OWB standalone release 11.2.0.3 installation. (You can patch OWB either before or after installing Oracle Database 12c.)

    To obtain the patch, access the Automated Release Updates (ARU) site at http://support.oracle.com, click Patches, and search for patch request number 14872304.

  7. Follow in-place migration steps in the patch README.txt file.

  8. Run OWB release 11.2.0.3 from the standalone Oracle home location.

2.2.16 Removing the Unified Auditing Schema and Roles

Remove the AUDSYS schema and the AUDIT_ADMIN and AUDIT_VIEWER roles. At this stage, there should be no AUDSYS schema.

  1. Log into SQL*Plus as user SYS with the SYSDBA system privilege.

    sqlplus sys as sysdba
    Enter password: password
    
  2. Drop the AUDSYS schema (if it does exist) and the AUDIT_ADMIN and AUDIT_VIEWER roles.

    DROP USER AUDSYS CASCADE;
    DROP ROLE AUDIT_ADMIN;
    DROP ROLE AUDIT_VIEWER;
    

2.3 Installing the New Oracle Database Software

The following steps describe how to install the software for the new Oracle Database release.

Important:

You cannot upgrade a database using Database Upgrade Assistant (DBUA) when the source and target Oracle homes are owned by different users. Attempting to do so returns error PRKH-1014. Either ensure that the source and target databases have the same owner, or perform the manual steps described in "Manually Upgrading Oracle Database".

To install the new Oracle Database software for this release:

  1. If you are upgrading an Oracle RAC database, then you must perform the following steps in the order shown:

    1. Upgrade Oracle Clusterware first as described in Oracle Grid Infrastructure Installation Guide for your operating system.

      Note:

      When upgrading a non-Oracle RAC database, you must run Oracle Net Configuration Assistant (NETCA) before running DBUA. See "Considerations for Oracle Net Services When Upgrading Oracle Database". When upgrading an Oracle RAC database, as part of the Oracle Clusterware upgrade, OUI automatically runs NETCA to upgrade the network listener. Therefore, do not separately run NETCA.
    2. Mount the Oracle Grid Infrastructure installation media.

    3. Perform operating system prerequisite checks on each of the nodes that you intend to upgrade, to ensure that they meet the system prerequisites for Oracle Grid Infrastructure (Oracle Clusterware and Oracle ASM).

    4. If necessary, perform patch upgrades of the earlier release of Oracle Clusterware software to the most recent patch version.

    5. Ensure that you are logged in as the user that owns the Oracle Grid Infrastructure installation, and run the Oracle Grid Infrastructure installation. Provide information as prompted by the installer.

    6. When prompted, open a separate terminal session, log in as root, and run root.sh.

      See Also:

  2. After upgrading Oracle Clusterware, follow the instructions in your Oracle operating system-specific documentation to prepare for installation of Oracle Database software and start the Oracle Universal Installer.

    • Oracle recommends that you run the Pre-Upgrade Information Tool before you upgrade using DBUA. You can preview the types of items DBUA checks, and see any issues ahead of time that might be present in the database. The Pre-Upgrade Information Tool helps you fix prerequisite issues that it finds. (See "About the Pre-Upgrade Information Tool for Oracle Database".) You can then run DBUA independently after the installation is complete.

    • If you use Oracle Label Security, Database Vault, or both, then select Enterprise Edition on the Select Database Edition page, click Select Options, and enable one or both components from the components list. See "Requirements for Upgrading Databases That Use Oracle Label Security and Database Vault".

    When installation of Oracle Database software has completed successfully, click Exit to close Oracle Universal Installer.

2.4 Patch Set Updates and Requirements for Upgrading Oracle Database

The software for Oracle Database 12c contains a full release that includes all the latest patches and updates for Oracle Database. After upgrading, Oracle recommends that you check for patches and patch set updates as a part of database administration.

My Oracle Support provides detailed notes on how to obtain the latest patches, plus tools for lifecycle management and automated patching. For information about getting started with My Oracle Support, go to http://support.oracle.com.

See Also:

  • My Oracle Support Note ID 854428.1, "Patch Set Updates for Oracle Products" at http://support.oracle.com

  • "Oracle Database Upgrade Path Reference List" (Note ID 730365.1) on My Oracle Support at http://support.oracle.com, which contains an upgrade reference list for most available Oracle Database releases, including download information, patch numbers, and links to other notes

2.5 About the Pre-Upgrade Information Tool for Oracle Database

After you have installed the software for Oracle Database 12c, you must analyze your database before upgrading it to the new release. This is done by running the preupgrd.sql Pre-Upgrade Information Tool from the environment of the database you are to upgrade. Running the Pre-Upgrade Information Tool provides a preview of the items that DBUA checks and information about anything to be fixed. The Pre-Upgrade Information Tool generates fixup scripts that you can run to resolve issues that are flagged in the source database.

This section contains these topics:

Note:

If you are upgrading manually and have not run the Pre-Upgrade Information Tool first, then the catctl.pl script could terminate with errors. Running the tool is mandatory because it warns you of issues to be fixed before upgrading.

2.5.1 Using the New preupgrd.sql Pre-Upgrade Information Tool

Oracle Database 12c introduces the preupgrd.sql Pre-Upgrade Information Tool. The new preupgrd.sql script replaces the utlu121i.sql script and earlier versions of the Pre-Upgrade Information Tool. With the new Pre-Upgrade Information Tool, the default behavior of the prerequisite upgrade checks has been enhanced in the following ways:

  • A log file, preupgrade.log, is created containing the output of the Pre-Upgrade Information Tool.

  • The preupgrade_fixups.sql script is created to list and describe issues that can be fixed using SQL*Plus in the source database. It also attempts to resolve trivial issues when you execute it.

  • The postupgrade_fixups.sql script is created to address issues that can be fixed after the database has been upgraded. See Chapter 4, "Post-Upgrade Tasks for Oracle Database."

If Oracle_Base is defined, then the generated scripts and log files are created in Oracle_Base/cfgtoollogs/. If Oracle_Base is not defined, then the generated scripts and log files are created in ORACLE_HOME/cfgtoollogs/.

To run the new Pre-Upgrade Information Tool on the source database:

  1. Copy preupgrd.sql and utluppkg.sql from the /rdbms/admin directory of the new Oracle home where you installed Oracle Database 12c to a directory that is accessible when you connect to your source database, which is the database to be upgraded.

  2. Log in to the system as the owner of the environment of the database being upgraded.

    Important:

    The Pre-Upgrade Information Tool, which consists of preupgrd.sql and utluppkg.sql, must be copied to and must be run from the environment of the database being upgraded.
  3. Start SQL*Plus and connect to the database to be upgraded using an account with DBA privileges:

    SQL> CONNECT / AS SYSDBA
    
  4. On your file system, create $ORACLE_HOME)/cfgtoollogs/db_unique_name/preupgrade, if this directory does not already exist. If your database is under ORACLE_BASE, then ensure that this directory exists under $ORACLE_BASE/cfgtoollogs/db_unique_name/preupgrade.

  5. Run the new Pre-Upgrade Information Tool. For example, if you copied preupgrd.sql to the /admin directory of the source Oracle home:

    SQL> @$ORACLE_HOME/rdbms/admin/preupgrd.sql
    

    The fixup scripts and log file are generated in the /preupgrade directory of the source database.

  6. View and read through the resulting generated fixup scripts and log file, which are located in $ORACLE_BASE/cfgtoollogs/db_unique_name/preupgrade if ORACLE_BASE is defined, or $ORACLE_HOME/cfgtoollogs/db_unique_name/preupgrade if ORACLE_BASE is not defined.

  7. After you have reviewed the scripts, Oracle recommends that you execute preupgrade_fixups.sql on the source database. The preupgrade_fixups.sql script will attempt to resolve issues reported by the preupgrade process. See "Run the postupgrade_fixups.sql Script."

    Issues that cannot be resolved automatically by a fixup script are flagged with ** USER ACTION REQUIRED **.

  8. Fix the flagged issues that require you to complete manual procedures. See "Pre-Upgrade Information Tool Warnings and Recommendations for Oracle Database" for more details about actions to take.

  9. Run the Pre-Upgrade Information Tool as many times as needed for you to work through and resolve warnings.

2.5.2 Pre-Upgrade Information Tool Warnings and Recommendations for Oracle Database

Before upgrading to the new release of Oracle Database, Oracle recommends that you analyze the information and warnings displayed by the Pre-Upgrade Information Tool.

See Also:

The following support notes on My Oracle Support at http://support.oracle.com:
  • Note 472937.1 "Information On Installed Database Components"

  • Note 753041.1 "How to Diagnose Components with NON VALID Status"

The following topics describe warnings and the appropriate actions to take:

2.5.2.1 Update Access Control Lists and Network Utility Packages

Starting with Oracle Database 12c, the access control of the UTL packages (UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR) is implemented using Oracle Database Real Application Security and does not require Oracle XML DB.

To update ACLs and Network Utility packages:

  1. Ensure that the logged-in user has the connect privilege for the host and port specified by DBMS_LDAP.init. New behavior for the DBMS_LDAP PL/SQL package and the HttpUriType type requires the creation or update of access control lists (ACLs) after performing the upgrade to the new release of Oracle Database.

    For example, if your application depends on the DBMS_LDAP package, then the error "ORA-24247: network access denied by access control list (ACL)" may occur. To avoid this error, the logged-in user must have the connect privilege for the host and port specified by DBMS_LDAP.init.

  2. If one or all of the UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, and UTL_INADDR packages are installed, then you might be required to re-install these packages after performing the upgrade to ensure that you have the latest version of these packages for the new Oracle Database 12c release.

See Also:

Oracle Database Real Application Security Administrator's and Developer's Guide for information on configuring access control lists

2.5.2.2 Evaluate Dependencies and Add ACLs for Network Utility Packages

You might be required to evaluate the dependencies of network utility packages and provide access by adding the appropriate access control lists (ACLs).

To check the status of access to network utility packages and to add ACLs for network utility packages:

  1. Run the Pre-Upgrade Information Tool as described in "Using the New preupgrd.sql Pre-Upgrade Information Tool".

  2. Check the output from the Pre-Upgrade Information Tool (preupgrade.log) for messages such as:

    WARNING: --> Database contains schemas with objects dependent on network packages.
    .... Refer to the Database Upgrade Guide for instructions to configure Network ACLs.
    .... USER WKSYS has dependent objects.
    .... USER SYSMAN has dependent objects.
    .... USER FLOWS_010600 has dependent objects.
    .
    
  3. Query the DBA_DEPENDENCIES view to obtain more information about the dependencies. For example:

    SELECT * FROM DBA_DEPENDENCIES
    WHERE referenced_name IN ('UTL_TCP','UTL_SMTP','UTL_MAIL','UTL_HTTP','UTL_INADDR','DBMS_LDAP')
      AND owner NOT IN ('SYS','PUBLIC','ORDPLUGINS');
    
  4. Prepare post-upgrade scripts now to make the scripts available for use in your database environment. This ensures the new access controls are part of your upgrade testing.

    To configure network access control lists (ACLs) in the database so that these packages can work as they did in prior releases, see the example script provided in "Configure Fine-Grained Access to External Network Services After Upgrading Oracle Database". This script shows how to use the DBMS_NETWORK_ACL_ADMIN package to create, assign, and add privileges to the access control list.

  5. After the upgrade, you must grant the specific required privileges. Access is based on the usage in the original database.

See Also:

Oracle Database Real Application Security Administrator's and Developer's Guide for information on configuring access control lists

2.5.2.3 About Database Links with Passwords from Earlier Oracle Database Releases

This information is important only for downgrading to your original database release after performing the upgrade. During the upgrade to Oracle Database 12c any passwords in database links are encrypted.

  • To downgrade to the release from which you upgraded, all of the database links with encrypted passwords must be dropped before the downgrade. Consequently, the database links are nonexistent 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.

  • For information about earlier releases, refer to the original documentation for the Oracle Database release from which you upgraded. You may also refer to your platform-specific Oracle Installation Guide for the earlier release.

See Also:

Oracle Database Administrator's Guide for information about authentication and database links

2.5.2.4 About Oracle Database Warnings for TIMESTAMP WITH TIME ZONE Data Type

The time zone files that are supplied with Oracle Database 12c have been updated to reflect changes in transition rules for some time zone regions. The changes might affect existing data of the TIMESTAMP WITH TIME ZONE data type.

Oracle recommends that you ensure that you have the latest time zone files before you upgrade the database. If the time zone file version of the database you are upgrading is not the most recent version of the time zone file available for the new release of Oracle Database, then the Pre-Upgrade Information Tool displays a warning and describes how to proceed. Table 2-2, "Choices for Fixing the Time Zone File Version" describes the warnings and summarizes how to resolve a mismatch in time zone file versions.

Caution:

The TIMESTAMP WITH TIME ZONE data stored in the database can become corrupted during the upgrade if there is a time zone file version mismatch.

Table 2-2 Choices for Fixing the Time Zone File Version

IF the time zone version on the database being upgraded is... THEN fix the time zone files...

Earlier than the most current version included in the new database release and the Pre-Upgrade Information Tool displays "Database is using a time zone file older than version n."

After completing the database upgrade.

Use the DBMS_DST PL/SQL package and follow the instructions in "Steps to Upgrade Time Zone File and Timestamp with Time Zone Data" in Oracle Database Globalization Support Guide.

See Also: Oracle Database PL/SQL Packages and Types Reference for information on the DBMS_DST PL/SQL package and support note ID 1509653.1 "Updating the RDBMS DST version in 12c Release 1 (12.1.0.1 and up) using DBMS_DST" on My Oracle Support at http://support.oracle.com

Later than the version included in the new database release and the Pre-Upgrade Information Tool displays "Database is using a time zone file greater than version n."

Before beginning the database upgrade.

You must patch the Oracle home by using an RDBMS DST patch with the appropriate patch for the time zone file version in use. Apply the patch for each database to be upgraded. Otherwise, the upgrade script terminates without upgrading the database. The RDBMS DST patches are available from My Oracle Support. Refer to note ID 412160.1 at http://support.oracle.com.


See Also:

2.5.2.5 Decrease Oracle Database Downtime by Gathering Optimizer Statistics

Statistics gathering occurs for those tables that lack statistics or are significantly changed during the upgrade of Oracle Database. Collect statistics before performing the actual database upgrade. Oracle strongly recommends that if your database contains thousands of dictionary tables, then collect statistics the night before starting the upgrade.

To decrease the amount of downtime:

  • Oracle recommends that you use the DBMS_STATS.GATHER_DICTIONARY_STATS procedure to gather these statistics. For example, enter the following SQL statement:

    SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
    

See Also:

Oracle Database PL/SQL Packages and Types Reference for the syntax and complete information for the GATHER_DICTIONARY_STATS procedure

2.5.2.6 Identify Invalid Objects in Oracle Database with the utluiobj Script

Any invalid SYS or SYSTEM objects found before upgrading the database are stored in the table named registry$sys_inv_objs after running the Pre-Upgrade Information Tool, preupgrd.sql. Additionally, any invalid non-SYS or non-SYSTEM objects found before upgrading the database are stored in registry$nonsys_inv_objs.

To identify invalid objects before upgrading and invalid objects that result from the upgrade:

  • Run utluiobj.sql from $ORACLE_HOME/rdbms/admin/

    Running the utluiobj.sql script before and after upgrading enables you to compare the invalid objects after the upgrade to the objects that were invalid before the upgrade. This is like a health check for the database. Having more invalid objects after the upgrade indicates that something went wrong.

  • You can fix the invalid objects, or contact My Oracle Support for assistance.

Note:

Ensure that you first run the Pre-Upgrade Information Tool as part of the upgrade process. DBUA runs this tool in the Prerequisite Checks phase. You can manually run this tool before upgrading. If the Pre-Upgrade Information Tool has not previously been run, you will see an error stating that the table registry$sys_inv_objs does not exist. The Pre-Upgrade Information Tool creates and populates registry$sys_inv_objs. See "Using the New preupgrd.sql Pre-Upgrade Information Tool."

See Also:

Oracle Database Administrator's Guide for information on manually recompiling invalid objects with PL/SQL package procedures

2.5.2.7 Verify That Materialized View Refreshes Have Completed Before Upgrading

Before upgrading Oracle Database, you must wait until all materialized views have completed refreshing. You can query the system to determine if there are any materialized view refreshes still in progress.

To determine if there are any materialized view refreshes still in progress:

  • Run the following SQL query:

    SQL> SELECT o.name FROM sys.obj$ o, sys.user$ u, sys.sum$ s
                       WHERE o.type# = 42 AND bitand(s.mflags, 8) =8;
    

See Also:

2.5.2.8 Ensure That No Files Need Media Recovery Before Upgrading

Before upgrading Oracle Database, you must ensure that there are no files requiring media recovery. You can query the system to get a list of files, and then recover them as appropriate.

To get a list of files that require media recovery:

  • Run the following statement:

    SQL> SELECT * FROM v$recover_file;
    

See Also:

Oracle Database Backup and Recovery User's Guide for information about performing block media recovery

2.5.2.9 Ensure That No Files Are in Backup Mode Before Upgrading

Files must not be in backup mode when upgrading Oracle Database; therefore, you must wait until backups are completed. You can query the system to see a list of any files in backup mode. Then take appropriate action by either waiting for the backup to complete, or by aborting any backups that are not needed.

To get a list of files in backup mode:

  • Run the following statement:

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

See Also:

Oracle Database Backup and Recovery User's Guide for information about backing up and archiving data

2.5.2.10 Resolve Outstanding Distributed Transactions Before Upgrading

You must resolve outstanding distributed transactions before upgrading Oracle Database. You can do this by first querying to see any pending transactions, and then committing the transactions. You must wait until all pending distributed transactions have been committed.

To resolve outstanding distributed transactions:

  1. Run the following statement:

    SQL> SELECT * FROM dba_2pc_pending;
    
  2. If the query in the previous step returns any rows, then run the following statements:

    SQL> SELECT local_tran_id FROM dba_2pc_pending;
    SQL> EXECUTE dbms_transaction.purge_lost_db_entry('');
    SQL> COMMIT;
    

Tip:

Oracle Database Administrator's Guide for information on managing distributed transactions

2.5.2.11 Purge the Database Recycle Bin Before Upgrading

All the user recycle bins in the database must be empty before you begin the upgrade process for Oracle Database. You use the PURGE statement to remove items and their associated objects and to release their storage space. If you have the SYSDBA privilege, then you can purge all the recycle bins in the entire database by specifying DBA_RECYCLEBIN, instead of RECYCLEBIN. Starting with Oracle Database 12c, you can use the new PURGE DBA_RECYCLEBIN system privilege to perform the same action without the requirement of granting or being granted the SYSDBA privilege.

The PURGE DBA_RECYCLEBIN statement is a special PURGE command that removes all the objects from the systemwide recycle bin and is equivalent to purging the recycle bin of every user. In earlier releases, this statement required the SYSDBA administrative privilege, which is highly undesirable in terms of separation of duty and least privilege. To provide compliance with separation of duty, Oracle Database 12c introduces a new system privilege, PURGE DBA_RECYCLEBIN, which enables you to run PURGE DBA_RECYCLEBIN without having the SYSDBA administrative privilege.

To empty the database recycle bin, run the following command:

SQL> PURGE DBA_RECYCLEBIN

Caution:

The database recycle bin must be empty during the upgrade process to avoid possible ORA-00600 errors and to minimize the upgrade time.

See Also:

2.5.2.12 Synchronize the Standby Database with the Primary Database When Upgrading

If a standby database exists, then you must synchronize it with the primary database before upgrading Oracle Database.

To check if a standby database exists and to synchronize the standby database:

  1. Run the following query:

    SQL> SELECT SUBSTR(value,INSTR(value,'=',INSTR(UPPER(value),'SERVICE'))+1)
    FROM v$parameter
    WHERE name LIKE 'log_archive_dest%' AND UPPER(value) LIKE 'SERVICE%';
    
  2. If the query in the previous step returns a row, then synchronize the standby database with the primary database.

    • Make sure all the logs are transported to the standby server after a final log switch in the primary.

    • Start the recovery of the standby database with the NODELAY option.

See Also:

Oracle Data Guard Concepts and Administration for information on synchronizing a physical standby database with the primary database

2.5.3 Sample Output of the New Pre-Upgrade Information Tool

The Pre-Upgrade Information Tool displays recommendations but does not execute the recommendations automatically to ensure that you have control over how and when the fixup scripts are run.

The following sample shows the output that is generated in preupgrade.log by running the new Pre-Upgrade Information Tool (preupgrd.sql):

Oracle Database Pre-Upgrade Information Tool 06-19-2012 14:30:11
Script Version: 12.1.0.1.0 Build: 004
**********************************************************************
   Database Name:  L4
         Version:  10.2.0.5.0
      Compatible:  10.2.0
       Blocksize:  8192
        Platform:  Linux x86 64-bit
   Time zone file:  V4
**********************************************************************
                          [Renamed Parameters]
                     [No Renamed Parameters in use]
**********************************************************************
**********************************************************************
                    [Obsolete/Deprecated Parameters]
             [No Obsolete or Desupported Parameters in use]
**********************************************************************
                            [Component List]
**********************************************************************
--> Oracle Catalog Views                   [upgrade]  VALID     
--> Oracle Packages and Types              [upgrade]  VALID     
--> JServer JAVA Virtual Machine           [upgrade]  VALID     
--> Oracle XDK for Java                    [upgrade]  VALID     
--> Real Application Clusters              [upgrade]  INVALID   
--> Oracle Workspace Manager               [upgrade]  VALID     
--> Oracle Text                            [upgrade]  VALID     
--> Oracle XML Database                    [install]  
--> Oracle Java Packages                   [upgrade]  VALID     
--> Oracle Multimedia                      [upgrade]  VALID     
--> Data Mining                            [upgrade]  VALID     
**********************************************************************
                              [Tablespaces]
**********************************************************************
--> SYSTEM tablespace is adequate for the upgrade.
     minimum required size: 973 MB
--> SYSAUX tablespace is adequate for the upgrade.
     minimum required size: 277 MB
--> TEMP tablespace is adequate for the upgrade.
     minimum required size: 60 MB
--> UD1 tablespace is adequate for the upgrade.
     minimum required size: 400 MB
 
                      [No adjustments recommended]
 
**********************************************************************
**********************************************************************
                          [Pre-Upgrade Checks]
**********************************************************************
WARNING: --> Process Count may be too low
 
     Database has a maximum process count of 60 which is lower than the
     default value of 300 for this release.
     You should update your processes value before the upgrade
     to a value of at least 300.
     For example:
        ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE
     or update your init.ora file.
 
ERROR: --> Compatible set too low
 
     "compatible" currently set at 10.2.0 and must
     be set to at least 11.0.0 before upgrading the database.
     Do not make this change until you are ready to upgrade
     because a downgrade back to 10.2 is not possible once compatible
     has been raised.
 
     Update your init.ora or spfile to make this change.
 
WARNING: --> "ORACLE_OCM" user found in database
 
     This is an internal account used by Oracle Configuration Manager. 
     Please drop this user before upgrading.
 
WARNING: --> "DMSYS" schema exists in the database
 
     During the upgrade from 10g the schema is migrated
     to SYS and removed from the database later.
     During the upgrade from 11g, DMSYS schema is removed as part of the upgrade.
 
WARNING: --> Database contains INVALID objects before upgrade
 
     The list of invalid SYS/SYSTEM objects was written to
     registry$sys_inv_objs.
     The list of non-SYS/SYSTEM objects was written to
     registry$nonsys_inv_objs unless there were over 5000.
     Use utluiobj.sql after the upgrade to identify any new invalid
     objects due to the upgrade.
 
INFORMATION: --> Older Time zone in use
 
     Database is using a time zone file older than version 17.
     After the upgrade, it is recommended that DBMS_DST package
     be used to upgrade the 10.2.0.5.0 database time zone version
     to the latest version which comes with the new release.
     Please refer to My Oracle Support note number 1509653.1 for details.
 
WARNING: --> Existing schemas with network ACLs exist
 
     Database contains schemas with objects dependent on network packages.
     Refer to the Upgrade Guide for instructions to configure Network ACLs.
     USER ORACLE_OCM has dependent objects.
 
 
**********************************************************************
                      [Pre-Upgrade Recommendations]
**********************************************************************
 
                        *****************************************
                        ********* Dictionary Statistics *********
                        *****************************************
 
Please gather dictionary statistics 24 hours before
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:
    EXECUTE dbms_stats.gather_dictionary_stats;
 
                        *****************************************
                     ************* DMSYS SCHEMA ******************
                        *****************************************
 
The DMSYS schema exists in the database.  At the end of the upgrade,
DMSYS schema and its associated objects are removed from the database 
by catuppst.sql
 
**********************************************************************
                     [Post-Upgrade Recommendations]
**********************************************************************
 
                        *****************************************
                        ********* Time Zone File Older **********
                        *****************************************
 
 Database is using a time zone file older than version 17
 After the upgrade, it is recommended that DBMS_DST package
 be used to upgrade the 10.2.0.5.0 database time zone version
 to the latest version which comes with the new release.
 Please refer to My Oracle Support note number 1509653.1 for details.
 
                        *****************************************
                        ******** Fixed Object Statistics ********
                        *****************************************
 
Please create stats on fixed objects two weeks
after the upgrade using the command:
   EXECUTE DBMS_STATS.GATHER_FIXED_OBJECT_STATS;
 
**********************************************************************
                   ************  Summary  ************
 
ERROR: --> You have 1 error(s) that must be addressed
           before performing your upgrade.
 
 After your database is upgraded and open in normal mode you must run 
 rdbms/admin/catuppst.sql which executes several required tasks and completes
 the upgrade process.
 
 You should follow that with the execution of rdbms/admin/utlrp.sql, and a
 comparison of invalid objects before and after the upgrade using
 rdbms/admin/utluiobj.sql
 
 If needed you may want to upgrade your time zone data using the process
 described in My Oracle Support note 1509653.1
                   ***********************************

2.6 Backing Up Oracle Database for Upgrading

After running the Pre-Upgrade Information Tool and cleanly shutting down the database, Oracle recommends that you back up your Oracle database. To minimize downtime, you may perform an online backup or create a guaranteed restore point. Database Upgrade Assistant (DBUA) enables you to specify your backup and restore point.

Important:

Before you make any changes to the Oracle software, Oracle recommends that you create a backup of the Oracle software and databases. For Oracle software running on Windows operating systems, you must also take a backup of the Windows registry. Without a registry backup, you cannot restore the Oracle software to a working state if the upgrade to Oracle Database 12c fails and you want to revert to the previous software installation.

See Also:

To perform a backup of the database to be upgraded:

  1. Sign on to Oracle RMAN:

    rman "target / nocatalog"
    
  2. Run 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';
    }
    

See Also:

Oracle Database Backup and Recovery User's Guide for more information about performing RMAN backups

2.7 Preparing the New Oracle Home for Upgrading

After backing up the database to be upgraded, prepare the new Oracle home in a new location. Install the software for Oracle Database 12c into the new location.

To prepare the new Oracle home for upgrading:

  1. Optional; if you are using DBUA, this step is performed automatically. Copy configuration files from the Oracle home of the database being upgraded to the new Oracle home for Oracle Database 12c:

    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, but it must not reside in the Oracle home of the old environment after you upgrade to Oracle Database 12c.

      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. See Oracle Database Administrator's Guide for information about managing initialization parameters. See Oracle Real Application Clusters Administration and Deployment Guide for information about initialization parameter files in Oracle RAC environments.
    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 you must restore the parameter file 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 new Oracle home in Oracle Database 12c.

      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.

  2. Adjust your parameter file in Oracle Database 12c by completing the following steps:

    1. Remove desupported initialization parameters and adjust deprecated initialization parameters. Certain parameters are desupported in Oracle Database 12c, while other parameters have become deprecated. Remove all desupported parameters from any parameter file that starts an Oracle Database 12c instance. Desupported parameters might cause errors in Oracle Database 12c. Also, alter any parameter whose syntax has changed in the new release.

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

      See Also:

      Chapter 8, "Deprecated and Desupported Features for Oracle Database 12c" for the initialization parameters that have been deprecated or have been desupported
    2. Adjust the values of the initialization parameters to at least the minimum values indicated by the Pre-Upgrade Information Tool.

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

    4. 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. 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.

    5. If you are upgrading a cluster database, then you may need to modify the SPFILE or initORACLE_SID.ora files.

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

  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.

    See Also:

2.7.1 Prerequisites for Preparing Oracle Home on Windows

For security reasons, different Windows user accounts configured as Oracle home users for different Oracle homes are not allowed to share the same Oracle Base.

The following considerations apply before you can upgrade Oracle Database on Windows platforms:

  • Database upgrade is supported when the same Windows user account is used as the Oracle home user in both the source and destination Oracle homes.

  • Database upgrade is supported when the Oracle home from which the database is being upgraded uses the Windows Built-in Account. Releases earlier than Oracle Database 12c (release 11.2 and earlier) only supported the built-in account option for the Oracle home user on Windows.

  • The Oracle home user may not have access to files outside its own Oracle Base and Oracle home. Therefore, if you choose a different Oracle Base during upgrade, Oracle Database services may not have access to the files in the older Oracle Base. Using DBUA for database upgrade ensures that the Oracle home user has access to files outside its own Oracle Base and Oracle home.

    Before upgrading manually or using the custom files (such as, wallets and configuration files) from the older Oracle Base, you must grant access to the Oracle home user for these outside files or copy these files to the new Oracle Base.

See Also:

Oracle Database Platform Guide for Microsoft Windows for information about database administration on Windows

2.8 Considerations for Oracle Net Services When Upgrading Oracle Database

In Oracle Database 12c, new, underlying net services parameters enable data compression, which reduces the size of the session data unit to be transmitted over a SQL TCP connection.

The following new parameters for the sqlnet.ora file specify compression, and the preferred compression scheme:

  • SQLNET.COMPRESSION

  • SQLNET.COMPRESSION_LEVELS

  • SQLNET.COMPRESSION_THRESHOLD

These new parameters are not supported in earlier releases and are only available in Oracle Database 12c.

See Also:

Oracle Database Net Services Reference for information about the new sqlnet.ora compression parameters

If a listener was not configured in the database from which you are upgrading, then you must run Oracle Net Configuration Assistant (Net CA) to configure the listening protocol address and service information for the new release of Oracle Database, including a listener.ora file, before running DBUA. A new version of the listener is required for releases of Oracle Database earlier than release 11.2. The new listener is backward compatible with earlier Oracle databases.

You can upgrade an Oracle RAC database with DBUA, which automatically migrates the listener from your old Oracle home to the new Oracle Grid Infrastructure home. You must administer the listener by using the lsnrctl command in the Oracle Grid Infrastructure home. Do not attempt to use the lsnrctl commands from Oracle home locations for earlier releases.

See Also:

Oracle Database Net Services Administrator's Guide for complete information about using Oracle Net Configuration Assistant

2.9 Testing the Upgrade Process for Oracle Database

Oracle recommends that you create a full working copy of your database environment in which to test all the pre-upgrade, upgrade, and post-upgrade processes. You can create a test environment that does not interfere with the current production Oracle database. Oracle Data Guard, for example, enables you to create physical and snapshot standby databases.

Your test environment depends on the upgrade method you have chosen:

  • If you plan to use DBUA or perform a manual upgrade, then create a test version of the current production database.

  • If you plan to use Data Pump Export/Import, then export and import in stages, using subsets of the current production database.

Practice upgrading the database using the test environment. The best practice is to perform testing of the upgrade process on an exact copy of the database to be upgraded, rather than on a downsized copy or test data. If an exact copy is impractical, then carefully chose a representative subset of your data to move over to your test environment and test the upgrade on that data.

See Also:

2.9.1 Upgrade Oracle Call Interface (OCI) and Precompiler Applications

Upgrade any Oracle Call Interface (OCI) and precompiler applications that you plan to use with the new release of Oracle Database. Oracle recommends that you test these applications on a sample database before upgrading your current production database.

2.10 Testing an Upgraded Test Copy of Oracle Database

Perform the planned tests on the current database and on the test database that you upgraded to the new release of Oracle Database.

  • Compare the test results, noting anomalies.

  • Repeat the test upgrade as many times as necessary until issues are resolved.

Test the newly upgraded test database with existing applications to verify that they operate properly with a new Oracle database.

  • Test enhanced functions and new capabilities by adding available Oracle Database features.

  • Ensure that the applications operate in the same manner as they did in the current database.

See Also: