Before you upgrade Oracle Database, you must understand the requirements and recommendations. 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:
Patch Set Updates and Requirements for Upgrading Oracle Database
Recommendations for Oracle Net Services When Upgrading 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:
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 athttp://education.oracle.com/The path that you must take to upgrade to the latest release of 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. You may directly upgrade from release 12.1.0.1 to 12.1.0.2.
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 Oracle Database 12c.
For example, if the database from which you are upgrading is running Oracle Database 9i, then follow these steps:
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).
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: |
|---|---|
|
12.1.0.1, 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:
|
See Also:
"Supported Releases for Downgrading Oracle Database" for information related to downgrading your databaseOracle 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:
The Manual, Command-line Method for Upgrading Oracle Database
The Export/Import Method for Migrating Data When 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.
In an Oracle Real Application Clusters (Oracle RAC) environment, DBUA does not upgrade all the databases per se; DBUA upgrades all the database files and configuration files on all nodes in the cluster.
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.
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.
See Also:
"Choose a New Location for Oracle Home when Upgrading" for more informationPerform 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).
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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 recommendations for Oracle Net Services.
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:
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:
Oracle Database Testing Guide for information about how to capture and replay workloads
Oracle Database Performance Tuning Guide for more information on the Automatic Workload Repository
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 changesA 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.
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.
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 ManagerBulk 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.
In the source release of Oracle Database, create an STS that includes the execution plan for each of the SQL statements.
Load the STS into a staging table and export the staging table into a dump file.
Import the staging table from a dump file into the new release of Oracle and unload the STS.
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 baselinesUnpack 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.
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.
Create a staging table using the DBMS_SPM.CREATE_STGTAB_BASELINE procedure.
Pack the SQL plan baselines you created in step 1 into the staging table using the DBMS_SPM.PACK_STGTAB_BASELINE function.
Export the staging table into a flat file using Data Pump.
Transfer this flat file to the target system.
Import the staging table from the flat file using Data Pump.
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:
Oracle Database SQL Tuning Guide for more information about loading plans from a staging table
Oracle Database Utilities for information about using Data Pump
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 testingThe 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 RMANDepending on the operating system and Oracle components in your database environment, there is specific information and requirements to be aware of.
The following topics discuss system recommendations and requirements for performing an upgrade:
Relocating Existing Data Files to the New Oracle Database Environment
About Upgrading PL/SQL Packages That Are Not Installed by Default
Saving Oracle Enterprise Manager Database Control Configuration and Data
About Upgrading Oracle Grid Infrastructure and Oracle Clusterware
Requirement for Upgrading Oracle Databases That Use Oracle Database Vault
Requirements for Upgrading Databases That Use Oracle Label Security and Oracle Database Vault
Requirement for Upgrading Databases that Use Oracle Warehouse Builder (OWB)
See Also:
Oracle Database Net Services Reference for information about upgrade recommendations for Oracle Net Services
Oracle Database Installation Guide for your operating system-specific information about preparing to upgrade
"About Rolling Upgrades for Oracle ASM and Oracle RAC Databases" for information about rolling upgrades
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 filesPackages 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.
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:
Install the software for the new Oracle Database 12c release.
Set ORACLE_HOME to your old Oracle home.
Set ORACLE_SID to the SID of the database being upgraded.
Set PATH, LD_LIBRARY_PATH, and SHLIB_PATH to point to the Oracle home of the database being upgraded.
Go to the Oracle home of the new Oracle Database 12c release.
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 inemdwgrd.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.
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.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:
Shut down the DB Control application immediately.
$ emctl stop dbconsole
Start SQL*Plus and connect to the database using the SYS account AS SYSDBA.
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;
Execute emremove.sql. The script is located under ORACLE_HOME/rdbms/admin/ of the new Oracle Database 12c Oracle home.
$ @emremove.sql
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
On Windows platforms, also delete the DB Console service, generally with the name OracleDBConsoleSID.
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 ManagementIf 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.
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 upgradesThe following recommendations 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 systemStarting 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:
Run the OUI installer on the node where the Oracle Clusterware stack is running or open a terminal.
Log in as root or Administrator.
Change directory (cd) to the Oracle Clusterware home (Grid home), and start Oracle Clusterware by entering the following command:
# crsctl start crs
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 systemIf 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.
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:
See Also:
Oracle Grid Infrastructure Installation Guide for your operating system for information on configuring NTP and Oracle Cluster Time Synchronization ServiceOracle 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.
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 ASMOracle 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 databasesTo 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:
Oracle Data Guard Broker for information about upgrading and downgrading in an Oracle Data Guard Broker configuration
Oracle Data Guard Concepts and Administration for information about upgrading using standby databases
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
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 theRMAN 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:
Oracle Database Administrator's Guide for information on transporting data across platforms
Oracle Database Backup and Recovery User's Guide for information on using the RMAN CONVERT DATABASE and RMAN CONVERT TABLESPACE commands
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 informationUpgrading 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.
Set up a standby database running the earlier database software release using an existing database backup.
Upgrade the standby database to Oracle Database 12c. See "Upgrading with Oracle Database Upgrade Assistant (DBUA)."
Synchronize the standby database with the production database.
Test your environment in active/live mode.
Switch over the application to the standby database.
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."
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 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.
See Also:
Oracle OLAP User's GuideIf you are upgrading from a database earlier than Oracle Database release 12.1 that uses Oracle Label Security (OLS) and Oracle 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 Oracle 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.
This section contains the following topics:
Requirement for Upgrading Oracle Databases That Use Oracle Database Vault
Running olspreupgrade.sql on Oracle Database Release 11.1.0.7
Running olspreupgrade.sql on Oracle Database Release 10.2.0.5 or 11.2
See Also:
Oracle Label Security Administrator's Guide for information about the OLS preprocess scriptBefore you upgrade databases that use Oracle Database Vault, you must be aware of certain requirements, especially for upgrading a CDB.
When upgrading Oracle Database release 11.2 or earlier to Oracle Database 12c, if you have enabled Oracle Database Vault in your current Oracle home, then by default Oracle Database Vault is disabled in the new target Oracle home.
If you are upgrading Oracle Database release 12.1.0.1 to release 12.1.0.2, then you must manually disable Oracle Database Vault in the release 12.1.0.1 Oracle home before you begin the upgrade process.
If you are upgrading a CDB, then you must run dvsys.dbms_macadm.disable_dv as DV Owner as described in the following note.
Important:
To disable Oracle Database Vault on CDBroot and PDBs, run dvsys.dbms_macadm.disable_dv as DV Owner as follows:
SQL> execute dvsys.dbms_macadm.disable_dv();
Stop the CDB and restart it, and open the PDBs in Read-Write state.
Once the upgrade is complete, enable Oracle Database Vault again in the new Oracle home.
See Also:
Oracle Database Vault Administrator's Guide for instructions about disabling and enabling Oracle Database VaultIf Oracle Label Security is installed in the earlier release that you are upgrading, then you must run the OLS preprocess olspreupgrade.sql script. If Oracle 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:
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.
Start SQL*Plus and connect to the database to be upgraded as DVOWNER.
Execute the following statement:
SQL> EXEC dbms_macadm.add_auth_to_realm('Oracle Database Vault','SYS',NULL, 0);
At the system prompt, enter:
CONNECT SYS AS SYSDBA
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.
After the olspreupgrade.sql has been successfully run, start SQL*Plus and connect to the database as DVOWNER.
Execute the following statement:
SQL> EXEC dbms_macadm.delete_auth_from_realm('Oracle Database Vault','SYS');
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 Oracle 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:
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.
Start SQL*Plus and connect to the database to be upgraded as DVOWNER.
Execute the following statement:
SQL> GRANT DV_PATCH_ADMIN to SYS;
At the system prompt, enter:
CONNECT SYS AS SYSDBA
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.
After the olspreupgrade.sql has been successfully run, start SQL*Plus and connect to the database as DVOWNER.
Execute the following statement:
SQL> REVOKE DV_PATCH_ADMIN from SYS;
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:
Add Oracle Database 12c Access to Existing standalone OWB 11.2.0.3 Installation
Keep Existing OWB 11.2.0.3 Installation In-place with Oracle Database Release 11.2.0.3
Use the Standalone OWB 11.2.0.3 Installation Where Available
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:
Stop all OWB applications from running: the OWB Runtime service, Browser, and Name Address server.
Install Oracle Database 12c software and follow the database upgrade instructions as described in Chapter 3, "Upgrading Oracle Database."
Apply OWB Cumulative patch 16568042 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, go to My Oracle Support at http://support.oracle.com, click Patches, and search for patch request number 16568042.
Follow in-place migration steps in the patch README.txt file.
Continue to run OWB release 11.2.0.3 from the standalone Oracle home.
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:
Stop all OWB applications from running: the OWB Runtime service, Browser, and Name Address server.
Install Oracle Database 12c software and follow the database upgrade instructions as described in Chapter 3, "Upgrading Oracle Database."
After you have installed Oracle Database 12c, do NOT remove Oracle Database release 11.2.0.3. You run OWB from this Oracle home.
Apply patch 16568042 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, go to My Oracle Support at http://support.oracle.com, click Patches, and search for patch request number 16568042.
Follow in-place migration steps in the patch README.txt file.
Run OWB from the integrated Oracle Database release 11.2.0.3 Oracle home.
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:
Stop all OWB applications from running: the OWB Runtime service, Browser, and Name Address server.
Install the OWB standalone client into its own OWB home directory.
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.
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
Install Oracle Database 12c software and follow the database upgrade instructions as described in Chapter 3, "Upgrading Oracle Database."
Apply OWB Cumulative patch 16568042 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, go to My Oracle Support at http://support.oracle.com, click Patches, and search for patch request number 16568042.
Follow in-place migration steps in the patch README.txt file.
Run OWB release 11.2.0.3 from the standalone Oracle home location.
Remove the AUDSYS schema and the AUDIT_ADMIN and AUDIT_VIEWER roles. At this stage, there should be no AUDSYS schema.
Log into SQL*Plus as user SYS with the SYSDBA system privilege.
sqlplus sys as sysdba
Enter password: password
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;
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 a Multitenant Container Oracle Database (CDB)".To install the new Oracle Database software for this release:
If you are upgrading an Oracle RAC database, then you must perform the following steps in the order shown:
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 "Recommendations 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.Mount the Oracle Grid Infrastructure installation media.
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).
If necessary, perform patch upgrades of the earlier release of Oracle Clusterware software to the most recent patch version.
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.
When prompted, open a separate terminal session, log in as root, and run root.sh.
See Also:
Oracle Grid Infrastructure Installation Guide for your operating system
Oracle Real Application Clusters Installation Guide for your operating system
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, Oracle 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 Oracle Database Vault".
When installation of Oracle Database software has completed successfully, click Exit to close Oracle Universal Installer.
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
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 thecatctl.pl script could terminate with errors. Running the tool is mandatory because it warns you of issues to be fixed before upgrading.Oracle Database 12c introduces the preupgrd.sql Pre-Upgrade Information Tool. The new preupgrd.sql script replaces 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 Pre-Upgrade Information Tool on the source database:
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. Preferably, this should be a temp directory.
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.Start SQL*Plus and connect to the database to be upgraded using an account with DBA privileges:
SQL> CONNECT / AS SYSDBA
(Recommended.) Run the Pre-Upgrade Information Tool (preupgrd.sql) for the following scenarios:
Before you upgrade a non-CDB in the source Oracle Home.
SQL> @$ORACLE_HOME/rdbms/temp/preupgrd.sql
Before you upgrade a CDB in a source Oracle Home.
When running preupgrd.sql in a CDB, make sure all the PDBs are opened. To open all the PDBs:
SQL> alter pluggable database all open;
Run catcon.pl and preupgrd.sql as follows:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -n 1 -d
$ORACLE_HOME/rdbms/admin -l <output directory for catcon logs> -b preupgrd
preupgrd.sql
The log file preupgrd0.log in <output directory for catcon logs> contains the screen output of preupgrd.sql. Refer to preupgrd0.log for locations to the preupgrade results and fix-up scripts.
Before a PDB is unplugged in the source Oracle Home. (See "Upgrading a Pluggable Database (PDB)" for additional information.)
If running preupgrd.sql in a single PDB, connect to the CDB and switch to the PDB as follows:
alter session set container = PDB1;
The fixup scripts and log file are generated in the preupgrade directory of the source database. To view the PDB-only output, see cfgtoollogs/SID/preupgrade/pdbfiles. The PDB files are first written to preupgrade/pdbfiles and then concatenated to preupgrade.log, preupgrade_fixups.sql, and postupgrade_fixups.sql in the cfgtoollogs/SID/preupgrade directory.
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.
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.
Issues that cannot be resolved automatically by a fixup script are flagged with ** USER ACTION REQUIRED **.
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.
Run the Pre-Upgrade Information Tool as many times as needed for you to work through and resolve warnings.
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 athttp://support.oracle.com:
The following topics describe warnings and the appropriate actions to take:
Evaluate Dependencies and Add ACLs for Network Utility Packages
About Database Links with Passwords from Earlier Oracle Database Releases
About Oracle Database Warnings for TIMESTAMP WITH TIME ZONE Data Type
Decrease Oracle Database Downtime by Gathering Optimizer Statistics
Identify Invalid Objects in Oracle Database with the utluiobj Script
Verify That Materialized View Refreshes Have Completed Before Upgrading
Resolve Outstanding Distributed Transactions Before Upgrading
Synchronize the Standby Database with the Primary Database When Upgrading
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:
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.
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 listsYou 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:
Run the Pre-Upgrade Information Tool as described in "Using the Pre-Upgrade Information Tool (preupgrd.sql)".
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. .
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');
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 Access Control Lists (ACLs) to External Network Services". This script shows how to use the DBMS_NETWORK_ACL_ADMIN package to create, assign, and add privileges to the access control list.
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 listsThis 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 linksThe 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 See Also: Oracle Database PL/SQL Packages and Types Reference for information on the |
|
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 |
See Also:
The support note "Updated DST Transitions and New Time Zones in Oracle Time Zone File Patches" (ID 412160.1) from My Oracle Support at http://support.oracle.com
Oracle Database Globalization Support Guide for detailed information about upgrading the time zone file and timestamp with time zone data
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 theGATHER_DICTIONARY_STATS procedureAny 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 tableregistry$sys_inv_objs does not exist. The Pre-Upgrade Information Tool creates and populates registry$sys_inv_objs. See "Using the Pre-Upgrade Information Tool (preupgrd.sql)."See Also:
Oracle Database Administrator's Guide for information on manually recompiling invalid objects with PL/SQL package proceduresBefore 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:
Oracle Database PL/SQL Packages and Types Reference for information on using the DBMS_MVIEW package to manage materialized views
Oracle Database SQL Language Reference for information about the DROP MATERIALIZED VIEW statement to permanently remove an existing materialized view from the database
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 recoveryFiles 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 dataYou 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:
Run the following statement:
SQL> SELECT * FROM dba_2pc_pending;
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 transactionsAll 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:
Oracle Database Administrator's Guide for information about purging objects in the recycle bin
Oracle Database SQL Language Reference for complete information about the PURGE statement
Oracle Database Security Guide for information about separation of duty for database administration
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:
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%';
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 databaseIf you are upgrading a database that includes Oracle Application Express:
You can upgrade Oracle Application Express separately to reduce upgrade time for the database.
A minimum value of 150 for open_cursors is required. Oracle recommends open_cursors = 150 when Oracle Application Express will be upgraded. Otherwise, you may see the following error.
ORA-01000: maximum open cursors exceeded ORA-06512: at "APEX_040200.WWV_FLOW_API", line 1594
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 and written to preupgrade.log by running the Oracle Database 12c Pre-Upgrade Information Tool (preupgrd.sql) on a release 11.2.0.3 database to be upgraded:
Oracle Database Pre-Upgrade Information Tool 03-06-2014 12:18:01
Script Version: 12.1.0.2.0 Build: 006
**********************************************************************
Database Name: MyDB
ContainerName: Not Applicable in Pre-12.1 database
ContainerID: Not Applicable in Pre-12.1 database
Version: 11.2.0.3.0
Compatible: 11.1.0
Blocksize: 8192
Platform: Linux x86 64-bit
Timezone file: V14
**********************************************************************
[Update parameters]
[Update Oracle Database 11.2.0.3.0 init.ora or spfile]
--> If Target Oracle is 32-bit, refer here for Update Parameters:
WARNING: --> "shared_pool_size" needs to be increased to at least 247463936
WARNING: --> "java_pool_size" needs to be increased to at least 67108864
WARNING: --> "db_cache_size" needs to be increased to at least 50331648
WARNING: --> "processes" needs to be increased to at least 300
--> If Target Oracle is 64-bit, refer here for Update Parameters:
WARNING: --> "shared_pool_size" needs to be increased to at least 494927872
WARNING: --> "java_pool_size" needs to be increased to at least 134217728
WARNING: --> "db_cache_size" needs to be increased to at least 50331648
WARNING: --> "processes" needs to be increased to at least 300
**********************************************************************
**********************************************************************
[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 [upgrade] VALID
--> Oracle Java Packages [upgrade] VALID
--> Oracle Multimedia [upgrade] VALID
--> Expression Filter [upgrade] VALID
--> Rule Manager [upgrade] VALID
**********************************************************************
[Tablespaces]
**********************************************************************
--> SYSTEM tablespace is adequate for the upgrade.
minimum required size: 909 MB
--> SYSAUX tablespace is adequate for the upgrade.
minimum required size: 500 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 prior to the upgrade
to a value of at least 300.
For example:
ALTER SYSTEM SET PROCESSES=300 SCOPE=SPFILE
or update your init.ora file.
INFORMATION: --> Older Timezone in use
Database is using a time zone file older than version 21.
After the upgrade, it is recommended that DBMS_DST package
be used to upgrade the 11.2.0.3.0 database time zone version
to the latest version which comes with the new release.
Please refer to My Oracle Support note number 977512.1 for details.
**********************************************************************
[Pre-Upgrade Recommendations]
**********************************************************************
*****************************************
********* Dictionary Statistics *********
*****************************************
Please gather dictionary statistics 24 hours prior to
upgrading the database.
To gather dictionary statistics execute the following command
while connected as SYSDBA:
EXECUTE dbms_stats.gather_dictionary_stats;
^^^ MANUAL ACTION SUGGESTED ^^^
*****************************************
*********** Hidden Parameters ***********
*****************************************
Please review and remove any unnecessary hidden/underscore parameters prior
to upgrading. It is strongly recommended that these be removed before upgrade
unless your application vendors and/or Oracle Support state differently.
Changes will need to be made in the init.ora or spfile.
^^^ MANUAL ACTION SUGGESTED ^^^
To view existing hidden parameters execute the following command
while connected AS SYSDBA:
SELECT name, value from SYS.V$PARAMETER WHERE name
LIKE '\_%' ESCAPE '\' order by name;
Or run the Pre-Upgrade Fixup Script to display the Hidden Parameters
currently set.
**********************************************************************
[Post-Upgrade Recommendations]
**********************************************************************
*****************************************
******** Fixed Object Statistics ********
*****************************************
Please create stats on fixed objects two weeks
after the upgrade using the command:
EXECUTE DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
^^^ MANUAL ACTION SUGGESTED ^^^
**********************************************************************
************ Summary ************
0 ERRORS exist in your database.
1 WARNING that Oracle suggests are addressed to improve database performance.
1 INFORMATIONAL message that should be reviewed prior to 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 timezone data using the process
described in My Oracle Support note 977512.1
***********************************
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:
Oracle Database Backup and Recovery User's Guide for information on online backups and backup mode
Oracle Database Backup and Recovery User's Guide for information on Flashback Database and restore points
To perform a backup of the database to be upgraded:
rman "target / nocatalog"
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 backupsAfter 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.
See Also:
To prepare the new Oracle home for upgrading:
Copy configuration files from the Oracle home of the database being upgraded to the new Oracle home for Oracle Database 12c. If you are using DBUA, the configuration files are copied for you automatically and you can ignore this step.
If you need to manually copy your configuration files to the new Oracle home:
If your parameter file resides within the old environment's Oracle home, then copy it to the new Oracle home. By default, Oracle looks for the 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.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.
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.
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.
Adjust your parameter file in Oracle Database 12c by completing the following steps:
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 desupportedAdjust the values of the initialization parameters to at least the minimum values indicated by the Pre-Upgrade Information Tool.
Make sure all path names in the parameter file are fully specified. You should not have relative path names in the parameter file.
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.
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.
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:
Oracle Database Reference for information about CLUSTER_DATABASE
Oracle Real Application Clusters Administration and Deployment Guide for information about initialization parameter files in Oracle RAC
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 recommendations 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 WindowsIn 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:
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 newsqlnet.ora compression parametersIf 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 AssistantOracle 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:
Oracle Database Testing Guide for information about testing a database upgrade
Oracle Database Utilities for information on Data Pump Export and Import utilities
Oracle Data Guard Concepts and Administration for information on physical and snapshot standby databases
Note ID 1462240.1 "Oracle Upgrade Companion" on My Oracle Support at http://support.oracle.com for detailed information and pointers about testing before upgrading
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.
See Also:
"Upgrading Precompiler and OCI Applications in Oracle Database" for more informationPerform 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:
Chapter 5, "Upgrading Applications After Upgrading Oracle Database" for more information on using applications with Oracle Database
Oracle Database Testing Guide for information on testing a database upgrade