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

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

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

3 Upgrading Oracle Database

Oracle provides a comprehensive set of tools for upgrading Oracle Database with minimal downtime and for migrating your applications to the new release.

This chapter contains the following topics:

Caution:

If you retain the old Oracle software, then never start the upgraded database with the old Oracle software. Only start the database with the executables in the new Oracle Database installation.

3.1 Upgrading Oracle Database with Database Upgrade Assistant

Database Upgrade Assistant (DBUA) provides a graphical user interface to guide you through the upgrade of Oracle Database. You can also invoke DBUA in silent mode, which does not present a user interface, as described in "Using DBUA in Silent Mode to Upgrade Oracle Database".

The following topics describe considerations and procedures for upgrading a database using DBUA:

3.1.1 Considerations for Using DBUA

If you stop the upgrade, but do not restore the database, then you cannot restart DBUA until you start the existing database in UPGRADE mode using the Oracle Database 12c server. You cannot go back to the original Oracle Database server unless you restore your database. Instead, you must continue with a manual (command line) upgrade as described in "Manually Upgrading Oracle Database".

Additional considerations for using DBUA are as follows:

  • Oracle recommends that you run the Pre-Upgrade Information Tool before starting the upgrade with DBUA. Although DBUA runs the Pre-Upgrade Information Tool as part of the pre-requisite checks, it is good practice to run the tool ahead of time in order to analyze the database and take actions that can decrease downtime for upgrading. See "About the Pre-Upgrade Information Tool for Oracle Database" for information and steps.

  • Set Archive Log ON during upgrade. Oracle recommends that you set Archive Log ON in order for DBUA to create and update the log file for the upgrade process.

  • If the database instance is not running, then DBUA tries to start the instance. If the instance is up and running, then DBUA connects to it.

  • For Oracle RAC, if you upgrade a cluster database using DBUA, then you must leave the CLUSTER_DATABASE initialization parameter set to TRUE.

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

  • If Database Vault is enabled, then DBUA disables Database Vault during the upgrade. See "About Upgrading Oracle Databases That Use Database Vault".

  • The procedures for using DBUA are the same for pluggable databases (PDBs) as for a non-CDB. See Oracle Database Concepts for an overview and documentation roadmap for working with a multitenant container database (CDB) and PDBs.

3.1.2 About Running DBUA for Oracle Database Upgrades

If you installed the software for Oracle Database 12c and specified that you are upgrading an existing Oracle database, then DBUA starts automatically. You can also start DBUA independently after the installation is complete as described in "Rerunning the Upgrade for Oracle Database".

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

DBUA does not begin the upgrade process until all of the pre-upgrade steps are completed. Refer to "Tasks for Preparing to Upgrade Oracle Database", which provides a general overview and pointers to further information and procedures.

3.1.2.1 Upgrade Scripts Invoked by DBUA

During the upgrade, DBUA automatically modifies or creates new required tablespaces and invokes the appropriate upgrade scripts.

During the prerequisite phase, DBUA runs the Pre-Upgrade Information Tool, preupgrd.sql, and uses the following logic to modify or create new required tablespaces:

  • If the datafiles are auto-extensible and have enough disk space to grow, then DBUA continues with the upgrade.

  • If the datafiles are not auto-extensible, then DBUA prompts you and makes the files auto-extensible.

  • If the tablespaces are auto-extensible and the MAXSIZE initialization parameter needs adjustment, then DBUA prompts for the same and adjusts the MAXSIZE parameter.

  • If there is not enough disk space to grow, then DBUA prompts you to create space (by adding more datafiles). DBUA does not automatically add new datafiles because DBUA cannot determine where to create the files.

DBUA addresses many issues found during the prerequisite phase. For example, DBUA can ensure that the correct time zone file is used and make ACL adjustments.

During the upgrade phase, DBUA runs catctl.pl, which runs the upgrade processes in parallel instead of serially, optimally taking advantage of CPU capacity to decrease downtime as much as possible.

3.1.3 About Windows Authentication When Upgrading

On Windows systems, users who connect with the SYSDBA privilege can take advantage of Windows native authentication. If these users work with Oracle Database using their domain accounts, then you must explicitly grant them local administrative privileges and ORA_DBA membership.

Unlike earlier releases, it is not mandatory that the Oracle Database services run using the privileges of a Local System account. You can run Oracle Database services using the privileges of a Windows user account. To authenticate to the database, you can use the Oracle Database Windows-specific operating system groups.

See Also:

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

The steps to upgrade a database using the DBUA graphical user interface are performed from within the new Oracle home where the Oracle Database 12c software has been installed. Only an Administrator should invoke DBUA for Windows systems.

See Also:

To upgrade a database using DBUA on Linux, UNIX, or Windows:

  1. The dbua executable is located in the ORACLE_HOME/bin directory. Start DBUA from the Oracle home where the new database software has been installed:

    • On Linux or UNIX platforms, enter the following command at a system prompt in the new home for Oracle Database 12c:

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

    The DBUA Select Operation page displays.

    Description of dbua_1.png follows
    Description of the illustration dbua_1.png

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

    Click Next.

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

    If the source database does not have operating system authentication, then DBUA prompts you for SYSDBA user name and password.

    See Also:

    "Moving a Database from an Existing 12c Oracle Home" for the procedure to move a database from an existing 12.1 Oracle home to a new 12.1 Oracle home

    Note:

    • This may affect your authentication on Windows systems: Starting with Oracle Database 12c, Windows NTS authentication using the NTLM protocol is no longer supported for security reasons. Kerberos authentication is the only supported authentication. In this release, NTS does not work in Windows NT domains nor in domains with Windows NT controllers.

    • This may affect user accounts on Windows Systems: Starting with Oracle Database 12c, Oracle uses the standard Windows User Account instead of Local System Account to run Oracle database services. This separation of roles provides better security on Windows.

    See Oracle Database Platform Guide for Microsoft Windows for information about managing user accounts on Windows systems.

    Description of dbua_2.png follows
    Description of the illustration dbua_2.png

  3. In the Target Oracle Home field, DBUA shows the location of the new Oracle home for the Oracle Database 12c software installation.

    In the Select Database area, from the Source Oracle Home drop-down list, choose the database you want to upgrade to Oracle Database 12c. DBUA fills in the information for the release and selects the Oracle database associated with the selected Oracle home.

    You can select only one database at a time. If the database does not appear in the list, then make sure an entry with the database name exists in the oratab file in the etc directory.

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

    Click Next.

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

    • Empty database recycle bin.

    • Invalid objects.

    • Deprecated and desupported initialization parameters.

    • Time zone data file version.

    When DBUA finishes its analysis, the Prerequisite Checks page displays. The analysis takes several minutes to complete.

    Description of dbua_3.png follows
    Description of the illustration dbua_3.png

  4. The Prerequisite Checks page shows the validation and results, the severity, whether the result is fixable if there is a problem, and the action you can take. When you select the validation result, the Fixable column displays whether the result can be fixed or not. The Action drop-down list shows actions you can take. For example, select Fix for DBUA to run a script or command to fix the problem.

    When you select a result in the Validation column, DBUA displays information about the result in the bottom area of the page.

    • Click the link for more details in the text information area. The Validation Details box appears with more information.

    • If there are validation errors or warnings and these are fixable, you can select an Action to take.

    Click Next.

    The Upgrade Options Configuration page appears with the Upgrade Options tab selected.

    Description of dbua_4.png follows
    Description of the illustration dbua_4.png

  5. The Upgrade Options Configuration page with the Upgrade Options tab selected provides the following options:

    Upgrade Parallelism

    The Upgrade Parallelism section enables the degree of parallelism for the upgrade process. This option reduces the time needed to perform the upgrade, based on the number of CPUs available to handle the running of scripts and processes simultaneously.

    By default, DBUA sets Upgrade Parallelism to the number of CPUs or 2 if the number of CPUs is less than 4. You can adjust this default value by selecting a new value from the Degree of Parallelism drop-down list.

    Upgrade Options

    The Upgrade Options section provides the following settings:

    • Recompile Invalid Objects During Post-Upgrade.

      Select Recompile Invalid Objects During Post-Upgrade if you want DBUA to recompile all invalid PL/SQL modules after the upgrade is complete. Specify the parallelism for the recompilation of invalid objects during post upgrade. DBUA provides a recommended degree of Recompilation Parallelism, which it sets to one less than the number of CPU you have available. Taking advantage of parallelism can significantly reduce the upgrade time. If you do not have DBUA recompile invalid objects in its post-upgrade phase, then you must manually recompile invalid objects after the database is upgraded.

    • Upgrade Time Zone Data.

      Select Upgrade Time Zone Data for DBUA to update the time zone data file for this release. If you do not select this option, then you must update the time zone configuration file manually after the upgrade.

    • Gather Statistics Before Upgrade.

      Select Gather Statistics Before Upgrade to reduce the overall time for the upgrade process.

    • Change Tablespace Offline/Read Only During Upgrade.

      Select Change Tablespace Offline/Read Only During Upgrade if you are upgrading a database for which you must transport tablespaces. In this case, the file headers must be made read/write before transporting.

    File Locations

    The File Locations area enables you to browse for the location for output that DBUA creates for diagnostics. You can enter a full path into the field, or you can click Browse to navigate to a location.

    (Optional) Click the Custom Scripts tab to specify custom SQL scripts that you would like to run before and after the upgrade.

    The Custom Scripts page appears. (You may click Next without using the Custom Scripts option.)

    Description of dbua_4b.png follows
    Description of the illustration dbua_4b.png

  6. Optional: In the Before Upgrade and After Upgrade fields, browse to the location of any custom SQL scripts that you would like to run. You can specify either one or both, or leave the fields blank to skip this option.

    Click Next.

    The Management Options page appears.

    Description of dbua_mgt_options.png follows
    Description of the illustration dbua_mgt_options.png

  7. In the Management Options page, select an option:

    • Configure Enterprise Manager Database Express

      Oracle Enterprise Manager Database Express is a web-based database management application that is built into Oracle Database 12c. EM Express replaces the DB Control component that was available in releases 10g and 11g.

    • Register with Enterprise Manager Cloud Control

      Registering with Oracle Enterprise Manager Cloud Control adds the database and its related entities such as Listener, Oracle ASM disk groups, and Oracle Clusterware as managed targets.

      If you select this option, then you must provide information in the following fields:

      • OMS Host

      • OMS Port

      • Enterprise Manager Admin Username

      • Enterprise Manager Admin Password

      • DBSNMP Password

    Click Next.

    If you are upgrading a single-instance database or Oracle Express Edition (XE), then the Move Database Files page appears.

    Note:

    If you are upgrading an Oracle Real Application Clusters database, then the Move Database Files page does not display. To continue with your Oracle RAC upgrade, you can skip the steps pertaining to moving database files and configuring the network.
    Description of dbua_5.png follows
    Description of the illustration dbua_5.png

  8. In the Move Database Files page, select an option:

    • Move Database Files as Part of Upgrade

    • Move Fast Recovery Area as Part of Upgrade

    Note:

    The fast recovery area is an Oracle-managed disk location used for storing backup and recovery-related files. Oracle strongly recommends configuring a fast recovery area, because it significantly enhances speed, reliability, and manageability of the database recovery process. The location of the fast recovery area is also used by Oracle Enterprise Manager if you enable local management on the Management Options page.
  9. If you choose Move Database Files as Part of Upgrade, then you must also configure Storage Type for the database files.

    In the Storage Type drop-down list, select File System or Oracle ASM.

    • If you select File System, then your database files are moved to the host file system.

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

      See Also:

  10. If you choose Move Fast Recovery Area as Part of Upgrade, then you must also configure the storage type and location for the fast recovery area and specify the size to be allocated as described in this step.

    • The Move Database Files and Move Fast Recovery Area options are independent of each other. For example, you can choose to move database files to Oracle ASM and leave the fast recovery area on the file system.

    • When you choose to move the fast recovery area, DBUA does not physically move existing archived redo logs to a new location. Instead, DBUA sets the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE initialization parameters to the new location and new size when the database is started from the new Oracle home.

    • If an Oracle Express Edition database is being upgraded to Oracle Enterprise Edition, then you must configure a fast recovery area. If a fast recovery area is currently configured, then the current settings are retained but the page displays to enable you to override these values.

    Fast Recovery Area Storage Type

    In the Storage Type list, select File System or Oracle ASM.

    If you select File System, then your fast recovery area is on the host file system.

    If you select Oracle Automatic Storage Management (Oracle ASM), then your fast recovery area is on Oracle ASM storage, which must currently exist on your system. If you do not have an Oracle ASM instance, then you can create one using Automatic Storage Management Configuration Assistant (ASMCA) from the Oracle Cloud Infrastructure home and then restart DBUA.

    Fast Recovery Area Location

    Browse to the location on the host file system, or on Oracle ASM storage.

    Fast Recovery Area Size

    Specify the size to allocate for the fast recovery area. The default is 1024 MB.

    Click Next.

    The Network Configuration page appears for listener selection.

    Description of dbua_6.png follows
    Description of the illustration dbua_6.png

  11. The Listener Selection area of the Network Configuration page shows a table with: Name, Port, Oracle home, Status, and Migrate columns. To the left of the listener name is a box for selecting the listener.

    Select one or more listeners from the source Oracle home to be migrated to the new upgraded Oracle home.

    1. DBUA adds the selected listener to the listener.ora file of the target Oracle home and starts it.

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

    3. DBUA reloads the listener.ora file in both the source and target Oracle Database environments.

    Note:

    If there are other databases registered with the same listener, then their new client connection requests may be affected during listener migration.

    Click Next.

    DBUA displays the Recovery Options page. DBUA performs the listener migration during the pre-upgrade steps.

    Description of dbua_7.png follows
    Description of the illustration dbua_7.png

  12. In the Recovery Options page, select the recovery method to use in case the upgrade process encounters a problem.

    The following recovery options and configurations are available:

    • Use RMAN Backup

    • Use Flashback and Guaranteed Restore Point

    • I have my own backup and restore strategy

    Use RMAN Backup

    If you select Create RMAN Backup before Upgrade, then enter the full path for a location for the backup in the Backup Location field.

    If you select Use RMAN Backup but do not choose to create an RMAN backup before upgrading, then DBUA displays the time stamp for the latest RMAN backup that exists. You can click Restore Script next to the time stamp to select an existing script to run for restoring this backup.

    Use Flashback and Guaranteed Restore Point

    Select Create a Guaranteed Restore Point Before Upgrade to have DBUA create a restore point before DBUA enters the upgrade process.

    If you previously enabled Flashback Database and configured a fast recovery area with a flashback retention target, then you can select Use Existing Guaranteed Restore Point and pick the named SCN from the drop-down list. Your current settings for the restore point are retained. DBUA displays a page to permit you to override these values if needed.

    I have my own backup and restore strategy

    Select this option only if you used your own backup procedure to back up the database. In this case, Restore restores only the original database settings. To restore the database itself, you must restore the backup you created with your own backup utilities.

    Note:

    The database you are upgrading must be release 11.1.0.7 or later in order to take advantage of Flashback and Guaranteed Restore Point, and this must be enabled in the source database.

    See Also:

    Oracle Database Backup and Recovery User's Guide for more information on using Flashback Database and guaranteed restore points

    Click Next.

    The Database Upgrade Summary page appears.

    Description of dbua_8.png follows
    Description of the illustration dbua_8.png

  13. The Summary page shows the following information about the upgrade before it starts:

    • Name, version, and Oracle home of the source and target databases

    • Database backup location, available space, and space required

    • Warnings ignored

    • Database components to be upgraded

    • Initialization parameters changes

    • Database files location

    • Listener registration

    See Also:

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

    Check all of the specifications. Then click Back or Finish as follows:

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

    • Click Finish if everything is correct.

    The Progress page displays with the progress bar and DBUA begins the upgrade. The Progress page also shows a table with the steps being performed, the time duration, and the status as the upgrade proceeds. DBUA provides a Stop button in case you must cancel the upgrade at this point.

    Description of dbua_9.png follows
    Description of the illustration dbua_9.png

  14. After the upgrade has completed, the Upgrade Results page displays a description of the original database and the upgraded database and shows the changes made to the initialization parameters. The page also shows the directory where various log files are stored after the upgrade.

    Description of dbua_10.png follows
    Description of the illustration dbua_10.png

  15. Optional: Examine the log files to obtain more details about the upgrade process. The DBUA log files are located under /oracle_base/cfgtoollogs/dbua/logs.

    Note:

    An HTML version of the Upgrade Results is also saved in the log files directory. You can click the links in this HTML page to view the log pages in your browser.

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

  16. Complete the procedures described in Chapter 4, "Post-Upgrade Tasks for Oracle Database".

Note:

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

If the default security settings for Oracle Database 12c are in place, then passwords must be at least eight characters, and passwords such as welcome and oracle are not allowed. See Oracle Database Security Guide for information about configuring authentication.

3.1.5 Moving a Database from an Existing 12c Oracle Home

With DBUA you can migrate an Oracle Database 12c database from an existing 12c Oracle home to another 12c Oracle home.

To move a database from an existing 12c home to a new 12c Oracle home:

  1. Start DBUA as described in "Using DBUA to Upgrade the Database on Linux, UNIX, and Windows Systems".

    DBUA starts with the The Select Operation page.

    Description of dbua_movedb1.png follows
    Description of the illustration dbua_movedb1.png

  2. In the Select Operation page, choose Move Database from a Different Release 12.1 Oracle Home and click Next.

    The Select Database page appears.

    Description of dbua_movedb2.png follows
    Description of the illustration dbua_movedb2.png

  3. In the Select Database page, select the database you want to move to the new Oracle home. Only databases under a release 12c Oracle home appear. If you do not have an Oracle Database 12c database, then no database is available for the move operation.

    Click Next. The Move Database Options page appears.

  4. In the Move Database Options page, you can specify a different location for the diagnostic log files that DBUA creates, and you can optionally specify your custom SQL scripts, if any, to run after moving the database.

    Click Next. The Database Move Summary page appears.

  5. Review the summary for the move operation and click Next. The Progress page appears showing the processes for DBUA moving the database.

  6. Click Finish when the move operation completes.

3.1.6 Using DBUA in Silent Mode to Upgrade Oracle Database

When invoked with the -silent command line option, DBUA operates in silent mode. In silent mode, DBUA does not present a user interface. DBUA writes messages (including information, errors, and warnings) to a log file in ORACLE_HOME/cfgtoollogs/dbua/SID/upgraden, where n represents the consecutive number for the upgrade that DBUA has run. Oracle strongly recommends that you read the resulting DBUA log files to ensure a successful upgrade.

To upgrade a database with DBUA in silent mode 

  • Issue the following command

    dbua -silent -sid ORCL &
    

    where the database is named ORCL in this example.

3.1.6.1 Oracle DBUA Command Line Options for Silent Mode

Database Upgrade Assistant (DBUA) supports command line options when run in silent mode. Table 3-1 describes the various options and the corresponding parameters that are supported by DBUA.

Note:

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

Table 3-1 DBUA Command Line Options

Option Description

-silent

Specifies that DBUA should operate in silent mode.

-sid SID

Specifies the system identifier (SID) of the database to upgrade.

-oracleHome home_name

Specifies the Oracle Database home directory of the database to upgrade.

-oracleBase base_name

Specifies the Oracle Database base directory of the database to upgrade.

-listeners

To create a listener in the Oracle home of the new release, specify listenrName:lsnrPort.

-createListeners

To register the database with existing listeners, pass listeners by comma separated listenerName:Oracle Home. Listeners from the earlier release home are migrated to the new release home. By specifying -listeners lsnrName1,lsnrName2, DBUA searches the specified listeners from the Grid Infrastructure home (if Grid Infrastructure is configured), the target home, and the source home.

-diagnosticDest diagnostic_destination

Specifies the default location to store Oracle trace and diagnostic files. It replaces the initialization parameter settings for background dump destination and user dump destination from earlier releases.

-sysDBAUserName SYSDBA_user

Specifies a user with SYSDBA privileges.

-sysDBAPassword SYSDBA_pwd

Specifies the password for SYSDBA_user.

-autoextendFiles

Autoextends database files during the upgrade. Data files revert to their original autoextend settings after the upgrade.

-newGlobalDbName db_name

Specifies a new global database name. This option applies only if you are moving data files or upgrading an Oracle XE database.

-newSid new_SID

Specifies a new system identifier (SID) of the database to upgrade. This option applies only if you are moving data files or upgrading an Oracle XE database.

-upgradeTimezone

Upgrades the time zone file version for the database.

-generateMapFile

Applies only if you are moving data files or upgrading an Oracle XE database. If you specify this option, then DBUA only generates a database map file in the log location and then exits.

-useASM

Applies only if you are moving data files or upgrading an Oracle XE database. If the database to upgrade has an Oracle ASM instance, then this option tells DBUA to use it for the upgrade.

-commonFileLocation common_files

Specifies a common location to store database files. This option applies only if you are moving data files or upgrading an Oracle XE database.

-omfLocation omf_area

Specifies a database area for Oracle Managed Files. This option applies only if you are moving data files or upgrading an Oracle XE database.

-databaseMapFile map_file_name

Specifies the full name of the map file to map database files. This option applies only if you are moving data files or upgrading an Oracle XE database.

-newRecoveryArea recover_area

Specifies the recovery area for a database that is moved during upgrade. This option applies only if you are moving data files or upgrading an Oracle XE database.

-newRecoveryAreaSize recover_size

Specifies the recovery area size (MB) for a database that is moved during upgrade. This option applies only if you are moving data files or upgrading an Oracle XE database.

-apexAdminPassword apex_pwd

Specifies the password for the Application Express Administrator.

-disableUpgradeScriptLogging

Disables the detailed log generation for running SQL scripts during the upgrade process. This is enabled by default. To enable log generation, do not specify this option.

-backupLocation directory

Specifies a directory to back up your database before the upgrade starts.

-postUpgradeScripts script [, script ] ...

Specifies a comma-delimited list of SQL scripts. Specify complete path names. The scripts are executed after the upgrade.

-initParam parameter=value [, parameter=value ] ...

Specifies a comma-delimited list of initialization parameter values of the form name=value.

-disableArchiveLogMode

Turns off archiving and flashback logging for the duration of the upgrade.

-recompile_invalid_objects true|false

When you specify TRUE for this option, DBUA recompiles all invalid PL/SQL modules immediately after the upgrade is performed.

-degree_of_parallelism number

Specifies the level to be used for parallel recompilation.

-recoveryAreaDestination directory

Specifies the destination directory for all recovery files. This option applies only if you are moving data files, upgrading an Oracle XE database, or configuring Oracle Enterprise Manager.

[-localRacSid SID

Specifies the local SID of the cluster database if the cluster database is not registered in the Oracle Cluster Registry.

-h | -help

Displays help for DBUA.


3.1.6.2 DBUA Command Line Syntax for Silent Mode

You can specify all valid options from the command line using the following syntax:

dbua [ -silent ] [ -sid SID ] [-oracleHome home_name] [-oracleBase base_name]
[-diagnosticDest diagnostic_destination]
[-sysDBAUserName SYSDBA_user] [-sysDBAPassword SYSDBA_pwd]
[-upgradeASM] [-autoextendFiles] [-newGlobalDbName db_name] [-newSid new_SID]
[-generateMapFile] [-useASM] [-commonFileLocation common_files]
[-omfLocation omf_area] [-databaseMapFile map_file_name]
[-newRecoveryArea recover_area] [-newRecoveryAreaSize recover_size]
[-apexAdminPassword apex_pwd] [-disableUpgradeScriptLogging ] 
[-backupLocation directory]
[-sysauxTablespace -datafileName name -datafileSize size 
  -datafileSizeNext size -datafileSizeMax size]
[-postUpgradeScripts script [, script ] ... ]
[-initParam parameter=value [, parameter=value ] ... ]
[-disableArchiveLogMode] [-recompile_invalid_objects true | false]
[-degree_of_parallelism number]
[-recoveryAreaDestination directory] [-h|-help]

3.2 About the New Parallel Upgrade Utility for Oracle Database

Oracle Database 12c introduces the Parallel Upgrade Utility (catctl.pl), which enables components that do not have to be upgraded in a specific order to be upgraded at the same time, taking full advantage of CPU capacity. Oracle continues to make improvements to the upgrade process to simplify both manual upgrades and upgrades performed with the Database Upgrade Assistant (DBUA). DBUA and the manual upgrade procedures take advantage of the new Parallel Upgrade Utility. The Parallel Upgrade Utility reduces the total amount of time it takes to perform an upgrade by loading the database dictionary in parallel using multiple SQL processes to upgrade the database.

Related topics about the new Parallel Upgrade Utility (catctl.pl) are as follows:

3.2.1 General Steps for Running the New Parallel Upgrade Utility (catctl.pl)

The Parallel Upgrade Utility loads the data dictionary and components in parallel, thus reducing the overall upgrade time. Before invoking the Parallel Upgrade Utility, catctl.pl, follow the procedures for backing up your database that you would normally do before upgrading. Also, as a prerequisite, you must run the Pre-Upgrade Information Tool (preupgrd.sql) to identify any problems that a database administrator must address before the upgrade proceeds.

The detailed procedure for manually running catctl.pl is described in "Manually Upgrading Oracle Database". The general steps for upgrading your database with the Parallel Upgrade Utility are as follows:

  1. Back up your current database as described in "Backing Up Oracle Database for Upgrading".

  2. Install the Oracle Database 12c software for the new release as described in "Installing the New Oracle Database Software".

  3. Ensure the Pre-Upgrade Information Tool (preupgrd.sql) has been run on the source database as described in "About the Pre-Upgrade Information Tool for Oracle Database".

  4. From the ORACLE_HOME/rdbms/admin directory, start SQL*Plus.

  5. Connect to the database to be upgraded using an account with DBA privileges:

    CONNECT / AS SYSDBA
    
  6. Start the database in upgrade mode by issuing the following command:

    SQL> STARTUP UPGRADE
    

    Note:

    The UPGRADE keyword performs operations that prepare the environment for the upgrade.

    You might be required to use the PFILE option in your startup command to specify the location of your initialization parameter file. See Oracle Database Administrator's Guide for information about specifying initialization parameters at startup and the initialization parameter file.

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

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

  7. Exit SQL*Plus.

  8. Run catctl.pl from the new Oracle home. See "Parallel Upgrade Utility (catctl.pl) Parameters" for the parameters available for running catctl.pl.

    To run catctl.pl on Linux:

    cd $ORACLE_HOME/rdbms/admin
    $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql
    

    To run catctl.pl on Windows:

    cd %ORACLE_HOME%\rdbms\admin
    %ORACLE_HOME%\perl\bin\perl catctl.pl catupgrd.sql
    

3.2.2 Parallel Upgrade Utility (catctl.pl) Parameters

The parameters listed in Table 3-2 are available when invoking catctl.pl. See "Example for Using the Parallel Upgrade Utility" for more information on how catctl.pl processes the upgrade phases and for an example.

Table 3-2 catctl.pl Parameters

Parameter Description

-u

Specifies username and prompts for password.

-n

Specifies the number of processes to use for parallel operations (default = 4). The maximum is 8. Set this parameter to 0 to run catctl.pl in serial mode.

-d

Specifies the location of the directory containing the files to be processed.

-l

Specifies the location for the directory to use for spool log files. The default is the current working directory.

-s

Names the SQL script to initialize sessions.

-e

Sets echo OFF while running the scripts. The default is echo ON.

-p

Restarts the specified phase (skip successful phases on a rerun).


3.2.3 Example for Using the Parallel Upgrade Utility

The catctl.pl Parallel Upgrade Utility is integrated with DBUA. However, for manual, command line upgrades, you can run catctl.pl with various parameters. For example, to run catctl.pl in serial mode instead of using parallel operations, then you can set the -n parameter to 0.

Example 3-1 Running catctl.pl with select parameters

If -n 4 is used when invoking catctl.pl, then catupgrd0.log, catupgrd1.log, catupgrd2.log, and catupgrd3.log are created during the upgrade process. When evaluating if an upgrade succeeded or failed, all of the catupgrd#.log files must be checked. If catctl.pl is rerun, then the previous log files are overwritten unless you specify a different log directory.

cd $ORACLE_HOME/rdbms/admin
$ORACLE_HOME/perl/bin/perl catctl.pl -n 4 -l $ORACLE_HOME/diagnostics catupgrd.sql

3.3 Changes to How the Data Dictionary is Upgraded and Status is Displayed

In Oracle Database 12c, improvements have been made to the upgrade process and how upgrade status appears for the upgraded database.

The following topics discuss changes that affect performance and status for data dictionary objects:

3.3.1 Parallel Upgrading of Data Dictionary

Upgrading the data dictionary in Oracle Database is now done in parallel with the catctl.pl utility, which speeds up the upgrade process. Instead of one SQL process loading the data dictionary, there can now be multiple processes, depending on CPU capacity. The catctl.pl utility loads data into the dictionary as fast as possible and defers any work that can be done in normal mode instead of upgrade mode. Upgrading the database in this fashion reduces the overall downtime.

3.3.2 Change to Upgrade Status Setting

When the upgrade is complete and if there are no errors, then the status of the database is set to UPGRADED. This behavior differs from earlier releases where the status of the database was set to VALID after upgrading. The UPGRADED status indicates that the data dictionary has been loaded without any errors. If any errors are logged to registry$error, then the status of the upgrade is set to INVALID.

3.3.3 Change to Status After Running the Re-compilation utlrp.sql Script

In earlier releases of Oracle Database after upgrading a database, VALID meant that all objects in the data dictionary have been recompiled and are ready for use. In Oracle Database 12c, obtaining a VALID status differs. Running the utlrp.sql script in normal mode, recompiles data dictionary objects and moves the data dictionary from an UPGRADED status to a VALID status.

Oracle cannot guarantee that the database upgrade is valid unless utlrp.sql has been run after upgrading and before starting the upgraded database for the first time. Not running utlrp.sql after performing an upgrade forces data dictionary objects to be compiled during their first access. The first user accessing the database suffers the performance hit for each of the invalid objects accessed at this point. Once recompilation of those invalid objects is completed, then normal processing returns. Running utlrp.sql ensures that the database is ready for use after upgrading. Any errors found are reported immediately and can be fixed before users of the upgraded database encounter problems.

3.4 Manually Upgrading Oracle Database

After installing the software for Oracle Database 12c and preparing the new Oracle home, you can proceed with a manual, command-line upgrade rather than use DBUA.

The procedure in this section assumes that you installed the software for Oracle Database 12c, that you prepared the new Oracle home, and that you have run the Pre-Upgrade Information Tool. Refer to "Installing the New Oracle Database Software" and "Preparing the New Oracle Home for Upgrading" for additional procedures.

To manually upgrade the database:

  1. If you have not done so, run the Pre-Upgrade Information Tool as described in "About the Pre-Upgrade Information Tool for Oracle Database". Review the Pre-Upgrade Information tool output and correct all issues noted in the output before proceeding. Refer to "Pre-Upgrade Information Tool Warnings and Recommendations for Oracle Database" for information about fixing any issues.

  2. Back up the source database as described in "Backing Up Oracle Database for Upgrading".

  3. If you have not done so, prepare the new Oracle home as described in "Preparing the New Oracle Home for Upgrading".

  4. Shut down the database instance:

    SQL> SHUTDOWN IMMEDIATE
    
  5. If your operating system is Windows, then complete the following steps:

    1. Stop the OracleServiceSID Oracle service of the database you are upgrading, where SID is the instance name. For example, if your SID is ORCL, then enter the following at a command prompt:

      C:\> NET STOP OracleServiceORCL
      
    2. Delete the Oracle service at a command prompt using ORADIM. Refer to "Variables for using ORADIM During Upgrading Oracle Database on Windows" for more information.

      If your SID is ORCL, then enter the following command. Substitute the actual name for your SID.

      C:\> ORADIM -DELETE -SID ORCL
      
    3. Create the service for Oracle Database 12c at a command prompt using the ORADIM command of the new Oracle Database release as shown in the following example:

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

      Most Oracle Database services log on to the system using the privileges of the Oracle Home User. The service runs with the privileges of this user. The ORADIM command prompts you for the password to this user account. You can specify other options using ORADIM.

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

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

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

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

    1. Your ORACLE_SID is set correctly

    2. The oratab file points to the Oracle home for Oracle Database 12c

    3. The following environment variables point to the Oracle Database 12c directories:

      • ORACLE_HOME

      • PATH

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

    Note:

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

    See Also:

    Oracle Database Installation Guide for operating system-specific information about setting other important environment variables on your operating system
  7. Log in to the system as the owner of the Oracle home under the new Oracle Database 12c.

  8. From the ORACLE_HOME/rdbms/admin directory, start SQL*Plus.

  9. Connect to the database to be upgraded using an account with DBA privileges:

    CONNECT / AS SYSDBA
    
  10. Start the instance by issuing the following command:

    SQL> STARTUP UPGRADE
    

    Note:

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

    You might be required to use the PFILE option to specify the location of your initialization parameter file. See Oracle Database Administrator's Guide for information about specifying initialization parameters at startup and the initialization parameter file.

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

  11. Exit SQL*Plus.

  12. Run the catctl.pl script from the new Oracle home. In this release, the new Parallel Upgrade Utility, catctl.pl, provides parallel upgrade options that reduce downtime. (You can use catctl.pl -n 0 to run the upgrade processes serially.)

    To run catctl.pl on Linux:

    cd $ORACLE_HOME/rdbms/admin
    $ORACLE_HOME/perl/bin/perl catctl.pl catupgrd.sql
    

    To run catctl.pl on Windows:

    cd %ORACLE_HOME%\rdbms\admin
    %ORACLE_HOME%\perl\bin\perl catctl.pl catupgrd.sql
    

    Note:

    • You can use the -d option to specify the directory that contains the files to be processed, and -l to specify the directory to use for spool log files. Refer to Table 3-2, "catctl.pl Parameters" for all the options.

    • If you choose to run the catupgrd.sql script, doing so now requires an additional input parameter as follows:

      SQL> catupgrd.sql PARALLEL=NO
      

    See Also:

    "General Steps for Running the New Parallel Upgrade Utility (catctl.pl)" for information about catctl.pl parameters and options
  13. The upgraded database is shut down after running catctl.pl. Restart the instance to reinitialize the system parameters for normal operation.

    SQL> STARTUP
    

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

    Note:

    If you encountered a message listing desupported initialization parameters when you started the database in Step 10, then remove the desupported initialization parameters from the parameter file before restarting. If necessary, convert the SPFILE to a PFILE so you can edit the file to delete parameters. See Oracle Database Administrator's Guide for information about specifying initialization parameters at startup and the initialization parameter file.
  14. Run utlu121s.sql, the Post-Upgrade Status Tool, to display a summary of the upgrade results. To see information about the state of the database, you can run utlu121s.sql any time after completing the upgrade.

    If the utlu121s.sql script returns errors or shows components that are not VALID or not the most recent release, then see "Troubleshooting the Upgrade for Oracle Database" for more information.

  15. Important: The catuppst.sql script is run as part of the upgrade process unless the upgrade returns errors during the process. Check the log file for "Started: catuppst.sql" to verify that catuppst.sql ran during the upgrade process. If catuppst.sql has not run, then proceed to run catuppst.sql as shown in this step. Warning messages are also displayed when running catctl.pl indicating that catuppst.sql was not run during the upgrade.

    Run catuppst.sql, which is located in the ORACLE_HOME/rdbms/admin directory, as follows:

    SQL> @rdbms/admin/catuppst.sql
    
  16. Recommended Best Practice: Gather fixed object statistics to minimize the time needed for recompilation with utlrp.sql in the next step. Execute the following SQL statement:

    SQL> execute dbms_stats.gather_fixed_objects_stats;
    
  17. Run utlrp.sql to recompile any remaining stored PL/SQL and Java code.

    SQL> @utlrp.sql
    
  18. Verify that all expected packages and classes are valid. (This step assumes that you previously ran preupgrd.sql before starting the upgrade.)

    SQL> @utluiobj.sql
    

    Note:

    If the Pre-upgrade Information Tool detected INVALID objects and populated the registry$sys_inv_objs and registry$nonsys_inv_objs tables, then execute ORACLE_HOME/rdbms/admin/utluiobj.sql to display only those objects which are newly invalid because of the upgrade process. The utluiobj.sql script only displays objects that are now INVALID but which were VALID before the upgrade. See "Using the New preupgrd.sql Pre-Upgrade Information Tool.".
  19. Run utlu121s.sql again to verify that all issues have been fixed. Refer to step 14.

  20. Exit SQL*Plus.

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

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

    where db-unique-name is the database name assigned to it (not the instance name), and oraclehome is the Oracle home location in which the database is being upgraded. The SRVCTL utility supports long GNU-style options in addition to short CLI options used in earlier releases.

Your database is now upgraded to Oracle Database 12c. You are ready to complete the procedures described in Chapter 4, "Post-Upgrade Tasks for Oracle Database".

Note:

Oracle Warehouse Builder (OWB) components are not upgraded as part of the Oracle Database upgrade process. Oracle Warehouse Builder is not installed as part of Oracle Database 12c. See "Requirement for Upgrading Databases that Use Oracle Warehouse Builder (OWB)" for more information.

Caution:

If you retain the old Oracle software, then never start the upgraded database with the old software. Only start the database with the executables in the new Oracle Database installation. Also, before you remove the old Oracle environment, make sure you relocate any data files in that environment to the new Oracle Database environment. See the Oracle Database Administrator's Guide for information about relocating data files.

3.4.1 Variables for using ORADIM During Upgrading Oracle Database on Windows

On Windows platforms, ORADIM provides a command-line interface to manually perform administrative tasks like starting and stopping Windows databases and services, among other administrative functions. Database Configuration Assistant (DBCA) provides a graphical user interface to perform the same tasks. The variables for ORADIM that you must know about when upgrading Oracle Database include the SID of the database you are upgrading, the new Oracle home location, and the password for the new database instance. Also, ORADIM writes a log file to the ORACLE_HOME\database directory.

The following table describes the variables for using ORADIM when upgrading:

ORADIM Variable Description
SID The same SID name as the SID of the database you are upgrading.
PASSWORD The password for the new Oracle Database 12c database instance. This is the password for the user connected with SYSDBA privileges. The -SYSPWD option is required.

The default Oracle Database 12c security settings require that passwords must be at least eight characters, and passwords such as welcome and oracle are not allowed. See Oracle Database Security Guide for more information.

USERS The maximum number of users who can be granted SYSDBA and SYSOPER privileges.
ORACLE_HOME The Oracle home location for Oracle Database 12c. Ensure that you specify the full path name with the -PFILE option, including the drive letter of the Oracle home location. See Oracle Database Administrator's Guide for information about specifying initialization parameters at startup and the initialization parameter file.

See Also:

Oracle Database Platform Guide for Microsoft Windows for complete information about using ORADIM to administer a database instance

3.4.2 About the catupgrd.sql Script in Earlier Releases of Oracle Database

Earlier releases of Oracle Database used the catupgrd.sql Upgrade Utility to process the upgrade. Oracle strongly recommends that starting with Oracle Database 12c, you use the catctl.pl Parallel Upgrade Utility, which replaces catupgrd.sql and provides both parallel processing mode and serial mode. The information about catupgrd.sql is provided here for backward compatibility with any custom scripts or processes that you use for upgrading. You must execute the catupgrd.sql script from the Oracle Database 12c environment.

Note:

If you run catupgrd.sql by itself, then catuppst.sql does not run as part of the upgrade process. The catuppst.sql script must be run after catupgrd.sql completes.

See Also:

"Deprecation of catupgrd.sql Script and Introduction of New catctl.pl Utility," for information about running the earlier Upgrade Utility

The catupgrd.sql script creates and alters certain data dictionary tables. It also upgrades or installs the following database components in the new Oracle Database 12c database:

  • Oracle Database Catalog Views

  • Oracle Database Packages and Types

  • JServer JAVA Virtual Machine

  • Oracle Database Java Packages

  • Oracle XDK

  • Oracle Real Application Clusters

  • Oracle Workspace Manager

  • Oracle Multimedia

  • Oracle XML Database

  • OLAP Analytic Workspace

  • Oracle OLAP API

  • OLAP Catalog

  • Oracle Text

  • Spatial

  • Oracle Data Mining

  • Oracle Label Security

  • Messaging Gateway

  • Oracle Expression Filter

  • Oracle Rules Manager

  • Oracle Enterprise Manager Repository

  • Database Vault

  • Oracle Application Express

Note:

After the upgrade to release 12.1, the OLAP Catalog (AMD) is set to status OPTION OFF as it is no longer supported in this release.

See "Desupport of OLAP Catalog (AMD)."

3.4.3 About the Mandatory catuppst.sql Script

Running catuppst.sql is mandatory for completing the upgrade. This script generates informational messages and log files. DBUA and catctl.pl automatically run catuppst.sql. Run this script separately if any errors occurred during the manual upgrade. See "Manually Upgrading Oracle Database" for more information.

The catuppst.sql script, which is located in the ORACLE_HOME/rdbms/admin directory, performs remaining upgrade actions that do not require the database to be in UPGRADE mode. This script also automatically applies the latest Oracle patch set update (PSU).

An example of the catuppst.sql output is as follows:

Generating apply and rollback scripts...
Check the following file for errors:
Apply script: .*
Rollback script: .*
Executing script file...
Updating registry...
Check the following log file for errors: 

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

Updating registry...
Check the following log file for errors:
.../cfgtoollogs/catbundle/catbundle_PSU_*.log 

3.5 Upgrading Using a Multitenant Container Database (CDB)

Multitenant architecture enables an Oracle database to function as a multitenant container database (CDB). All Oracle databases before Oracle Database 12c were non-CDBs.

After upgrading an earlier release to Oracle Database 12c, you can plug the upgraded database into a CDB as described in "Upgrading and Plugging into a CDB." You can also move a database from an earlier release into a CDB as described in "Migrating With Data Pump Export/Import into a PDB."

This section contains the following topics:

See Also:

Oracle Database Administrator's Guide for complete information about creating and configuring a CDB and Oracle Database Concepts for an overview of multitenant architecture

3.5.1 Upgrading and Plugging into a CDB

You can upgrade Oracle Database using either DBUA or the Parallel Upgrade Utility and then plug the upgraded database into a CDB. Be sure to follow any necessary pre-upgrade procedures described in Chapter 2, "Preparing to Upgrade Oracle Database." The following procedure assumes that both databases are on the same system.

See Also:

Oracle Database Administrator's Guide for information about creating and removing PDBs with SQL*Plus

To upgrade a database and plug it into a CDB:

  1. Install the new Oracle Database 12c software. See Oracle Database Installation Guide for your operating system platform.

  2. Upgrade the database as described in this guide. See Chapter 3, "Upgrading Oracle Database."

  3. Set the COMPATIBLE parameter to 12.0.0, if you have not already done so as part of the upgrade process. See "The COMPATIBLE Initialization Parameter in Oracle Database."

  4. Make sure the database is in read-only mode.

    SQL> startup mount
    SQL> alter database open read only;
    
  5. Create the XML file for the PDB. The path to the location can be anything you choose. This location is where the XML file will be saved.

    SQL> exec DBMS_PDB.DESCRIBE('path/pdb.xml');
    
  6. Shut down the database.

    SQL> SHUTDOWN IMMEDIATE
    
  7. Plug the database into the CDB.

    SQL> CREATE PLUGGABLE DATABASE pdb1 USING 'path/pdb.xml' NOCOPY TEMPFILE REUSE;
    

    In this example, the PDB is named pdb1. You can use any name, but the name must be unique for this CDB.

    This example also assumes that the data files remain in the same location as they were when the database was standalone. If the data files have been copied to a different location (for example, stored with Oracle ASM), then the parameter SOURCE_FILE_NAME_CONVERT must be specified. See Oracle Database Administrator's Guide for an example of using the SOURCE_FILE_NAME_CONVERT clause.

    TEMPFILE REUSE specifies that the existing TEMP tablespaces can be reused.

    You should see "Pluggable database created." The upgraded database is now a PDB ready for the CDB.

  8. Connect to the PDB using a previously configured listener. The name of the PDB in this example is PDB1.

    SQL> sys/oracle@PDB1 as sysdba
    

    You can alternatively connect to the PDB as follows:

    SQL> ALTER SESSION set container=pdb1;
    
  9. Convert the dictionary to the PDB type. From the admin directory, run the noncdb_to_pdb.sql script. This script must be run before the PDB can be opened for the first time.

    @$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
    
  10. Startup and open the new PDB in read/write mode. You must open the new PDB in read/write mode for Oracle Database to complete the integration of the new PDB into the CDB. See Oracle Database Administrator's Guide for more information about modifying the open mode of PDBs with the STARTUP SQL*Plus command.

    SQL> STARTUP PLUGGABLE DATABASE pdb1 OPEN;
    
  11. Back up the PDB. See "Backing Up an Upgraded PDB."

3.5.2 Migrating With Data Pump Export/Import into a PDB

You can move a non-CDB into a CDB by transporting the database using Oracle Data Pump Full Transportable Export/Import. This is no different than using Oracle Data Pump Full Transportable Export/Import for a standalone, non-CDB. The transported database becomes a pluggable database (PDB) associated with the CDB. Full Transportable Export/Import can move a release 11.2.0.3 or later database into an Oracle Database 12c CDB efficiently.

If the Oracle Database release of the non-CDB is 11.2.0.3 or later, then you can use Full Transportable Export/Import to move the data. When transporting a non-CDB from Oracle Database 11g release 11.2.0.3 or higher to Oracle Database 12c, the VERSION Data Pump export parameter must be set to 12 or higher.

To upgrade using the CDB method:

  1. Install the new Oracle Database 12c software on the target. Use Oracle Universal Installer (OUI) to install the software. See Oracle Database Installation Guide for your platform.

  2. Set the database compatibility level to 12.0.0. See "The COMPATIBLE Initialization Parameter in Oracle Database."

  3. Use Database Configuration Assistant (DBCA) to create a CDB on the new installation. See the procedure in Oracle Database Administrator's Guide for using DBCA to create a CDB.

    Alternatively, you can create the CDB with the CREATE DATABASE SQL statement. See the procedure in Oracle Database Administrator's Guide for using the CREATE DATABASE statement to create a CDB.

  4. Prepare the PDB. See the prerequisites in Oracle Database Administrator's Guide for preparing for PDBs.

  5. Create a PDB using the seed PDB. The seed PDB, named PDB$SEED, is created in the empty CDB when you create the CDB. See the procedure for creating a PDB using the seed in Oracle Database Administrator's Guide.

  6. Using Oracle Data Pump, export the data from the non-CDB and import it into the new release 12c PDB. See Oracle Database Utilities for the procedure for using Data Pump to move databases into a CDB.

3.5.3 Backing Up an Upgraded PDB

A PDB cannot be recovered unless it is backed up. After upgrading using the method of creating a CDB and plugging in a database, be sure to back up the PDB. See Oracle Database Backup and Recovery User's Guide for information about backing up a PDB.

3.6 About Transporting and Upgrading a Database (Full Transportable Export/Import)

The Full Transportable Export/Import feature of Oracle Data Pump provides two options, which are described in detail in Oracle Database Administrator's Guide. The two options are:

  • Using a file-based Oracle Data Pump export/import

  • Using a non-file based network mode Oracle Data Pump import

See Also:

3.7 Troubleshooting the Upgrade for Oracle Database

Oracle provides troubleshooting tips for errors or issues you may encounter while upgrading your database. To learn about important changes that affect this release, be sure to read Chapter 8, "Deprecated and Desupported Features for Oracle Database 12c."

This section contains the following topics:

3.7.1 About Starting Oracle Database in Upgrade Mode

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

Errors described in this section might occur when attempting to start the new Oracle Database 12c database. Some of these errors write to the alert log and not to your session. If you receive any of these errors, then issue the SHUTDOWN ABORT command to shut down the database and correct the problem.

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

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

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

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

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

    The STARTUP command was issued without the UPGRADE keyword.

  • Ora-00704: bootstrap failure

    See Also:

    Ora-00704, Ora-39700: Database Must Be Opened With Upgrade Option (Doc ID 1349722.1) on My Oracle Support at http://support.oracle.com
  • ORA-00336: log file size xxxx blocks is less than minimum 8192 blocks

    A redo log file size is less than 4 MB:

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

3.7.2 Running DBUA with Different ORACLE_HOME Owner

When upgrading your database, DBUA expects that both the source (pre-12c) Oracle home and the destination (new 12c) Oracle home are owned by the same user. If this is not the case in your environment, then you need to make some changes to database file permissions and pass additional parameters to DBUA. Otherwise on the DBUA Prerequisite Checks page you will see the "upgrade.xml not found" error, and you will not be able to proceed with the upgrade.

  • First, ensure all database files (data files, the redo file, control files, archive log destination, recovery area, spfile, and password file) are readable and writable by both the new 12c and pre-12c binary owners. This can be achieved by having both users in the same group, such as "oinstall" and by giving the group read/write access to all the database files.

  • Run DBUA by specifying the -logdir command line switch, and provide a directory that both 12c and pre-12c binary owners can write to, for example, /tmp. DBUA will use this directory to store the output from the Pre-upgrade Information Tool (which you execute on the pre-12c instance running under the pre-12c binary owner) and any DBUA logs generated by the 12c binary owner during upgrade.

    • For example, run DBUA as follows at the command line:

      dbua -logdir /tmp
      

3.7.3 Oracle Database Upgrade Script Termination Errors

If you did not run the Pre-Upgrade Information Tool before starting the upgrade, then the catctl.pl and catupgrd.sql scripts terminate with errors as follows:

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

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

3.7.4 Resource Limits for Upgrading Oracle Database

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

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

  • SYSTEM and SYSAUX tablespaces

    Typically if your SYSTEM tablespace size is insufficient, you receive an error message during the upgrade as follows:

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

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

  • Shared memory

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

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

    See Also:

    Oracle Database Administrator's Guide for information about using manual shared memory management
  • Rollback segments/undo tablespace

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

    ORA-01562: failed to extend rollback segment number string
    

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

  • Fast Recovery Area

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

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

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

3.7.5 SQL*Plus Edition Session Startup Error for Oracle Database

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

3.7.6 Manual Workaround for ORA-01408 on Oracle Database Index

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

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

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

3.7.7 Error ORA-00018 for DBCA Processes with Release 11.1.0.7 Databases

If you are using Oracle Grid Infrastructure and you want to create an Oracle RAC release 11.1.0.7 database, then you may need to increase the DBCA default for session processes. For Oracle Database 12c, DBCA sets the default value for processes to 300. In earlier releases, DBCA set the default value to 150.

If you see the error message "ORA-00018:maximum number of session exceeded," then change the default value for session processes in DBCA to 300. DBCA then successfully creates the release 11.1.0.7 database to use with Oracle Grid Infrastructure release 12.1.

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

Running the DBMS_DST package after upgrading to Oracle Database 12c can result in the ORA-01882: time zone region not found error.

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

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

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

3.7.9 Continuing Upgrades After Server Restarts (ADVM/ACFS Driver Error)

On Windows platforms, an error may occur related to ADVM or ACFS drivers if a server restarts during an upgrade. You may see the following error message.

ACFS-9427: Failed to unload ADVM/ACFS drivers. A system reboot is recommended, or ACFS-9428 Failed to load ADVM/ACFS drivers. A system reboot is recommended.
Cause: If you see these errors during an upgrade, then the cause is that the ADVM and ACFS drivers are still in use, and you must restart the system to start the new drivers.
Action: Complete the steps as described in the following procedures.

For nodes other than the first node (the node on which the upgrade is started):

  1. Restart the node where the error occurs.

  2. Run the root script on that node again.

For first nodes (the node on which the upgrade is started):

  1. Complete the upgrade of all other nodes in the cluster.

  2. Restart the first node.

  3. Run the root script on the first node again.

  4. To complete the upgrade, log in as root, and run the script configToolAllCommands, located in the path Grid_home/cfgtoollogs/configToolAllCommands.

See Also:

Oracle Grid Infrastructure Installation Guide for your operating system for more information about troubleshooting upgrade issues for clusters

3.7.10 Understanding Component Status of the Post-Upgrade Status Tool

The utlu121s.sql Post-Upgrade Status Tool reports VALID status for all components after the upgrade.

The following list shows and briefly describes other status values that you might see:

  • NO SCRIPT

    The component upgrade script was not found in ORACLE_HOME. Check the install logs, install the component software, and then rerun catctl.pl. See "Scripts for Upgrading Oracle Database".

  • OPTION OFF

    The server option required for the component was not installed or was not linked with the server. Check the V$OPTION view and the install logs. Install the component or relink the server with the required option, and then rerun catctl.pl. See "Scripts for Upgrading Oracle Database".

  • REMOVED

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

  • INVALID

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

  • UPGRADING

    The component upgrade did not complete. Resolve the problem and rerun catctl.pl. See "Scripts for Upgrading Oracle Database".

3.7.11 DBUA Marks Invalid Components with an X on the Upgrade Result Page

DBUA displays the final component status in the Upgrade Results page. Please check the final component status on the Upgrade Result page. Invalid components are marked with an X and the option to recompile is provided.

Run utlrp.sql to recompile the invalid objects as follows:

SQL> @utlrp.sql

3.7.12 Adjusting Oracle ASM Password File Location After Upgrade

The Oracle ASM password file location is not shown in the command output when you invoke srvctl config asm after a Grid Infrastructure upgrade. The location of the password file is not automatically passed to the new Oracle ASM disk group. To enable srvctl to have the password file location after upgrade, you must advance the diskgroup compatibility setting and create a PWFILE in the diskgroup. Then SRVCTL will report the configured location of the shared PWFILE.

Follow the procedure in Oracle Automatic Storage Management Administrator's Guide for managing a shared password file in a disk group.

3.7.13 Error ORA-27248: sys.dra_reevaluate_open_failures is running

If DBUA failed with error "ORA-27248: sys.dra_reevaluate_open_failures is running" when upgrading the database, then the job DRA_REEVALUATE_OPEN_FAILURES is running and causes upgrade failure. You need to ensure that the job is stopped.

In a job definition, if ALLOW_RUNS_IN_RESTRICTED_MODE is set to TRUE, the job is permitted to run when the database is in restricted or upgrade mode, provided that the job owner is permitted to log in during this mode. The default setting is FALSE. Therefore, if the jobs is defined by SYS / SYSTEM, then it will be running during upgrade mode.

You can use the following query to see the state of any jobs that may be running:

SQL> select OBJECT_NAME, Owner, OBJECT_TYPE from dba_objects whereobject_name like '%DRA_REEVA%';

3.8 Rerunning the Upgrade for Oracle Database

When upgrading Oracle Database, the upgrade process can be rerun or restarted with DBUA or with the catctl.pl script.

You can use the following method to rerun the upgrade:

3.8.1 Rerunning the Upgrade with the Upgrade (catctl.pl) Script

You can rerun the upgrade with the catctl.pl script.

  1. Shut down the database as follows:

    SQL> SHUTDOWN IMMEDIATE
    
  2. Restart the database in UPGRADE mode:

    SQL> STARTUP UPGRADE
    
  3. Rerun catctl.pl.

    Note:

    You can rerun the catctl.pl script as many times as necessary.
  4. Run utlu121s.sql, the Post-Upgrade Status Tool, which provides a summary of the status of the upgrade in the spool log. You can run utlu121s.sql any time before or after completing the upgrade.

    If the utlu121s.sql script returns errors or shows components that are not VALID or not the most recent release, then see "Troubleshooting the Upgrade for Oracle Database" for more information.

  5. Important: The catuppst.sql script is run as part of the upgrade process unless the upgrade returns errors during the process. Check the log file for "Started: catuppst.sql" to verify that catuppst.sql ran during the upgrade process. If catuppst.sql has not run, then proceed to run catuppst.sql as shown in this step. Warning messages are also displayed when running catctl.pl indicating that catuppst.sql was not run during the upgrade.

    Run catuppst.sql, which is located in the ORACLE_HOME/rdbms/admin directory, as follows:

    SQL> @rdbms/admin/catuppst.sql
    
  6. Recommended Best Practice: Gather fixed object statistics to minimize the time needed for recompilation with utlrp.sql in the next step. Execute the following SQL statement:

    SQL> execute dbms_stats.gather_fixed_objects_stats;
    
  7. Run utlrp.sql to recompile any remaining stored PL/SQL and Java code.

    SQL> @utlrp.sql
    

    Verify that all expected packages and classes are valid:

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

    Note:

    If the Pre-upgrade Information Tool detected INVALID objects and populated the registry$sys_inv_objs and registry$nonsys_inv_objs tables, then execute ORACLE_HOME/rdbms/admin/utluiobj.sql to display only those objects which are newly invalid because of the upgrade process. The utluiobj.sql script only displays objects that are now INVALID but which were VALID before the upgrade.
  8. Run utlu121s.sql again to verify that all issues have been fixed. See step 4.

  9. Exit SQL*Plus.

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

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

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

Your database is now upgraded to Oracle Database 12c. You are ready to complete the procedures described in Chapter 4, "Post-Upgrade Tasks for Oracle Database".