When you start Oracle Database in upgrade mode, you can only run queries on fixed views. If you attempt to run other views or PL/SQL, then you receive errors.

When the database is started in upgrade mode, only queries on fixed views execute without errors. This restriction applies until you either run the Parallel Upgrade Utility (catctl.pl) directly, or indirectly by using the dbupgrade script). Before running an upgrade script, using PL/SQL on any other view, or running queries on any other view returns an error. If you receive any of the errors described in this section, then issue the SHUTDOWN ABORT command to shut down the database, and then correct the problem.

The following list of errors can occur when you attempt to start the new Oracle Database release. Some of these errors write to the alert log, and not to your session.

• 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.2.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

  The path variable can be pointing to the earlier release Oracle home.

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

Review this topic if your Oracle Database homes are owned by different operating system user accounts, or you encounter an upgrade.xml not found error.

DBUA upgrades by default assume that both the source (release earlier than Oracle Database 12c) Oracle home and the destination (new 12c) Oracle home are owned by the same user. If each Oracle home is not owned by the same user, then you must change to database file permissions and pass additional parameters to DBUA. If you do not do this, then during upgrade, the DBUA Prerequisite Checks page reports upgrade.xml not found errors. You are not permitted to proceed with the upgrade until this error is corrected.

• All Oracle Database installation owners should have the group that you designate as the OINSTALL group (or Oracle Inventory group) as their primary group. 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. If this is not the case, then confirm that each installation owner has the same group as their primary group, and ensure that members of the OINSTALL group have read/write access to all the earlier release and later release Oracle Database files and directories.

• Run DBUA by specifying the -logdir command line option, and provide a directory to which both the new release and earlier release binary owners can write. For example: /tmp. DBUA uses the directory you designate with the logdir parameter to store the output from the Pre-upgrade Information Tool, and to store any DBUA log files generated during the upgrade. You run the Pre-Upgrade Information tool from the earlier release Oracle Database instance as the earlier release Oracle Database installation owner user account.

  For example:

  dbua -logdir /tmp

Review this section if you encounter ORA-00942, ORA-00904, or ORA-01722 errors.

If you do 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, then complete the following procedure:

1. Enter a SHUTDOWN ABORT command, and wait for the command to complete running.

2. Revert to the original Oracle home directory

3. Run the Pre-Upgrade Information Tool.

Review this section if you encounter ORA-01650, ORA-01651, ORA-01652, ORA-01653, ORA-01654, ORA-01655, ORA-0431, ORA-01562, ORA-19815, or other errors that suggest resource limit errors.

If you run out of resources during an upgrade, then increase the resource allocation. After increasing the resource allocation, shut down the instance with SHUTDOWN ABORT, and restart the instance in UPGRADE mode before re-running the catupgrd.sql script.

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

Use this section to understand and resolve SP2–1540: "Oracle Database cannot startup in an Edition session."

If an upgrade script or a command running in SQL*Plus set the EDITION parameter, then Oracle Database cannot start properly afterward. When you attempt to start the database, you receive the following error:

SP2-1540: "Oracle Database cannot startup in an Edition session"

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.

Use this procedure to fix ORA-01822 and ORA-16512 errors involving time zone file mismatches.

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

This error is returned if the time zone file version is set incorrectly. An incorrect time zone setting 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, and re-run the upgrade.

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

If a server restarts during the upgrade, then you may see one of the following error messages:

ACFS-9427: Failed to unload ADVM/ACFS drivers. A system reboot is recommended

ACFS-9428 Failed to load ADVM/ACFS drivers. A system reboot is recommended.

• Cause

  The ADVM and ACFS drivers are still in use. 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.

Starting in Oracle Database 18c (18.1), all OPTION OFF components are upgraded to the new release, but these options are disabled for Oracle Database Standard Edition (SE) remain OPTION OFF.

When you upgrade Oracle Database Standard Edition (SE) starter databases, the components that are not included with starter databases are turned on and upgraded. When utlrp.sql is run, options that are not turned on with your server and not included with SE are reset to OPTION OFF in the DBA_REGISTRY view.

You must create a new password file for Oracle ASM after an Oracle Grid Infrastructure upgrade.

Use this procedure to identify DRA_REEVALUATE_OPEN_FAILURES jobs that block upgrades.

During an upgrade, if DBUA fails with the error ORA-27248: sys.dra_reevaluate_open_failures is running, then the job DRA_REEVALUATE_OPEN_FAILURES is running, which causes upgrade failures. Ensure that the job is stopped before continuing the upgrade.

In a job definition, if ALLOW_RUNS_IN_RESTRICTED_MODE is set to TRUE, and the job owner is permitted to log in during restricted mode, then that job is permitted to run when the database is in restricted or upgrade mode. The default setting for this parameter is FALSE.

Use the following query to see the state of any running jobs:

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

Review to understand ORA-16000: database open for read-only access errors.

Use this procedure to fix ORA-01722: invalid number upgrade errors.

If the initialization parameter MAX_STRING_SIZE is set to EXTENDED, but the 32K migration that the utl32k.sql script carries out is not completed, then the database upgrade fails with the following error:

SELECT TO_NUMBER('32K_MIGRATION_NOT_COMPLETED')
                    *
      ERROR at line 1:
      ORA-01722: invalid number

The database upgrade does not automatically run the utl32k.sql script, and does not perform the 32K migration.

Complete the upgrade and the 32K migration by using this manual procedure:

1. Reset the initialization parameter MAX_STRING_SIZE to STANDARD.

2. Restart the database in UPGRADE mode.

3. Rerun the upgrade using the manual procedure.

4. After the database is upgraded, set the initialization parameter MAX_STRING_SIZE to EXTENDED.

5. Restart the database in UPGRADE mode.

6. Run the SQL script ../rdbms/admin/utl32k.sql.

After you run the utl32k.sql script, the upgraded database completes the 32K migration and supports the EXTENDED parameter.

A Cluster Ready Services (CRS) shutdown on all cluster member nodes can place the cluster in a heterogeneous state. Use this procedure to recover from that problem.

Oracle Automatic Storage Management (Oracle ASM) loses the rolling migration state if CRS shuts down on all nodes. This CRS shutdown can create a heterogeneous state, so that you cannot restart all cluster member nodes. You cannot start two nodes of different versions in the cluster. If you attempt to start nodes running different versions of Oracle ASM, then one of the sets of heterogeneous nodes running Oracle ASM nodes fails, generating either ORA-15153 or ORA-15163 error messages.

Consider the following scenario of four nodes (node1, node2, node3, and node4) that are at Oracle Database release 11.2.0.2 and being upgraded to release 12.1.0.2.

• Node1 and node2 are upgraded to 12.1.0.2 and running.

• Node3 and node 4 are still at 11.2.0.2 and running.

• Now consider that there is an outage where all CRS stacks are down, which leaves the cluster in a heterogeneous state (that is, two nodes at 11.2.0.2 and two nodes at 12.1.0.2).

Using this scenario as an example, complete the following procedure:

1. Restart only the nodes that are in the earlier release. In this scenario, start the nodes in release 11.2.0.2 ( node3 or node4, or both).

2. run the following SQL command on the Oracle ASM instance on node3 or node4 before starting any 12.1.0.2 node:

   ALTER SYSTEM START ROLLING MIGRATION TO '12.1.0.2'

3. Continue the documented upgrade procedure from the point of failure.

Review the user-defined object types affected by versioning.

Release 12.1.0.2 introduces versioning of data types that can be attributes of Oracle object types (reference Bug 18897657). Because of this feature, cross-version replication between release 12.1.0.1 and release 12.1.0.2 databases can be affected, which results in ORA-26656 errors.

If any user-defined object types contain attributes of DATE, TIMESTAMP, TIMESTAMP WITH TIME ZONE, TIMESTAMP WITH LOCAL TIME ZONE, BINARY_FLOAT, BINARY_DOUBLE, NCHAR, NVARCHAR2, NCLOB, ANYDATA, and similar objects, then you must apply the mandatory Patch Set Update 18038108 to all release 12.1.0.1 instances.