1. Using AutoUpgrade to Upgrade and Convert Non-CDBs to a PDB with the Same Operating System
  2. Post-Upgrade Tasks for Oracle Database
  3. Required Tasks to Complete After Upgrading Oracle Database

Required Tasks to Complete After Upgrading Oracle Database

Review and complete these required tasks that are specified for your environment after you complete your upgrade.

You must complete these postupgrade tasks after you upgrade Oracle Database.

Note:

This list of required tasks is based on the assumption that you have used AutoUpgrade to perform the upgrade. AutoUpgrade completes automatically many tasks that otherwise you are required to perform manually.

Parent topic: Post-Upgrade Tasks for Oracle Database

Setting Environment Variables on Linux and Unix Systems After Manual Upgrades

Check that required operating system environment variables point to the directories of the new Oracle Database release.

Typically, operating system environment variables are set in profiles and shell scripts. Confirm that the following Oracle user environment variables point to the directories of the new Oracle home:

  • ORACLE_HOME

  • PATH

Look for other environment variables that refer to the earlier release Oracle home, such as LD_LIBRARY_PATH. In general, you should replace all occurrences of the old Oracle home in your environment variables with the new Oracle home paths.

Related Topics

Parent topic: Required Tasks to Complete After Upgrading Oracle Database

Recompile Invalid Objects in the Database

After you install, patch, or upgrade a database, recompile invalid objects on the CDB and PDBs with a recompilation driver script.

Oracle provides the recompilation scripts utlrp.sql, utlprp.sql, and utlprpom.sql. These scripts are located in the Oracle_home/rdbms/admin directory.

Note:

Starting with AutoUpgrade 23.1, when you run the AutoUpgrade utility, AutoUpgrade runs the utlprpom.sql script, and does not run utlrp.sql. When AutoUpgrade is used for upgrades to Oracle Database 12c Release 2 (12.2.0.1) and later releases, AutoUpgrade only recompiles invalid objects owned by Oracle-maintained schemas. Because database upgrades do not need to touch user objects, AutoUpgrade maintains this policy when it recompiles invalid objects.

After installing a database, recomplile all invalid objects;

  1. Change directory to Oracle_home/rdbms/admin. For example 

    $ cd $ORACLE_HOME/rdbms/admin

  2. Use the catcon.pl script in the Oracle home to run utlrp.sql. For example: 

    $ORACLE_HOME/perl/bin/perl catcon.pl --n 1 --e --b utlrp --d '''.''' utlrp.sql

    Note the following conditions of this use case:

    • --n parameter: is set to 1, so the script runs each PDB recompilation in sequence.

    • --e parameter: turns echo on.
    • --b parameter: Sets the log file base name. It is set to utlrp.

    Expect a time delay for the serial recompilation of PDBs to complete. Depending on the number of PDBs that you are upgrading, the recompilation can extend significantly beyond the time required for the upgrade scripts to complete.

    The utlrp.sql script automatically recompiles invalid objects in either serial or parallel recompilation, based on both the number of invalid objects, and on the number of CPUs available. CPUs are calculated using the number of CPUs (cpu_count) multiplied by the number of threads for each CPU (parallel_threads_per_cpu). On Oracle Real Application Clusters (Oracle RAC), this number is added across all Oracle RAC nodes.

After patching or upgrading a database, there is more than one approach you can use to recompile invalid Oracle-owned and user-owned objects:

Recompile all invalid objects (the invalid objects in both Oracle and user schemas) by using utlrp.sql or utlprp.sql.

If time is a factor and the type of invalid objects is predominately application owned, then you can recompile Oracle-owned invalid objects first, and defer recompiling application-owned invalid objects to a later time. To recompile invalid objects in Oracle schemas, use utlprpom.sql. To recompile the remaining invalid objects, use utlrp.sql or utlprp.sql.

Note:

When you use either utlprp.sql or utlprpom.sql, note that both scripts require you to define the degree of parallelism that the script should use, or determine the number of parallel recompile jobs to use.

The script uses syntax as follows, where base is the base name you want to have given to log files, N is the number of PDBs on which you want to run recompilation jobs in parallel (degrees of parallelism), script.sql is the Oracle recompilation script you chose to use, and P is the number of PDBs on which you want to run in parallel: 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -b base -d $ORACLE_HOME/rdbms/admin
          -n N -l /tmp script.sql '--pP'

Suppose you are running recompilation in a CDB using the log file base name recomp, with a degrees of parallelism setting of 3 jobs per PDB container, the script you choose to use is utlprp.sql, and you want to recompile across at most 10 PDBs at a time. In that case, the syntax you use to run the recompile operation is similar to the following, 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -b recomp -d $ORACLE_HOME/rdbms/admin -n 10 -l /tmp utlprp.sql '--p3'

Related Topics

Parent topic: Required Tasks to Complete After Upgrading Oracle Database

Check PL/SQL Packages and Dependent Procedures

It is possible that packages that you installed in the earlier release Oracle Database are not available in the new release, which can affect applications.

After the upgrade, if you use AutoUpgrade, review the AutoUpgrade report on invalid objects. If you use a replay upgrade, then check to ensure that any packages that you may have used in your own scripts, or that you call from your scripts, are available in the new release. Testing procedures dependent on packages should be part of your upgrade plan.

Code in database applications can reference objects in the connected database. For example, Oracle Call Interface (OCI) and precompiler applications can submit anonymous PL/SQL blocks. Triggers in Oracle Forms applications can reference a schema object. Such applications are dependent on the schema objects they reference. Dependency management techniques vary, depending on the development environment. Oracle Database does not automatically track application dependencies.

Related Topics

Parent topic: Required Tasks to Complete After Upgrading Oracle Database

Configuring the FTP and HTTP Ports and HTTP Authentication for Oracle XML DB

Oracle Database Configuration Assistant (DBCA) does not configure ports for Oracle XML DB on Oracle Database 12c and later releases. Upgrades use digest authentication.

Oracle recommends that when you configure ports, you also configure the authentication for HTTP for accessing Oracle XML DB Repository to take advantage of improved security features.

Starting with Oracle Database 12c, Oracle enhanced database security by supporting digest authentication. Digest authentication is an industry-standard protocol that is commonly used with the HTTP protocol. It is supported by most HTTP clients. Digest authentication ensures that passwords are always transmitted in a secure manner, even when an encrypted (HTTPS) connection is not in use. Support for digest authentication enables organizations to deploy applications that use Oracle XML DB HTTP, without having to worry about passwords being compromised. Digest authentication support in Oracle XML DB also ensures that the Oracle XML DB HTTP server remains compatible with Microsoft Web Folders WebDAV clients.

After installing or upgrading for the new release, you must manually configure the FTP and HTTP ports for Oracle XML DB as follows:

  1. Use DBMS_XDB_CONFIG.setHTTPPort(HTTP_port_number) to set the HTTP port for Oracle XML DB: 

    SQL> exec DBMS_XDB_CONFIG.setHTTPPort(port_number);

  2. Use DBMS_XDB_CONFIG.setFTPPort(FTP_port_number) to set the FTP port for Oracle XML DB: 

    SQL> exec DBMS_XDB_CONFIG.setFTPPort(FTP_port_number);

    Note:

    You can query the port numbers to use for FTP and HTTP in the procedure by using DBMS_XDB_CONFIG.getFTPPort and DBMS_XDB_CONFIG.getHTTPPort respectively.

  3. To see all the used port numbers, query DBMS_XDB_CONFIG.usedport.

Parent topic: Required Tasks to Complete After Upgrading Oracle Database

Install Oracle Text Supplied Knowledge Bases After Upgrading Oracle Database

After an Oracle Database upgrade, all user extensions to the Oracle Text supplied knowledge bases must be regenerated.

Regenerating the user extensions affect all databases installed in the given Oracle home.

After an upgrade, the Oracle Text-supplied knowledge bases that are part of the companion products for the new Oracle Database are not immediately available. Any Oracle Text features dependent on the supplied knowledge bases that were available before the upgrade do not function after the upgrade. To re-enable such features, you must install the Oracle Text supplied knowledge bases from the installation media for the new Oracle Database release.

See Also:

Parent topic: Required Tasks to Complete After Upgrading Oracle Database

Replace the DEMO Directory in Read-Only Oracle Homes

After upgrading Read-Only Oracle homes, make a copy of the earlier release Oracle Database demo directory, and replace the demo directory in the Read-Only Oracle home with the new release demo directory.

Oracle Database 18c and later releases contain a product demonstration directory in the file path Oracle_home/rdbms/demo. These directories include examples and product demonstrations that are specific to the options and features for each Oracle Database release, some of which you can add to after upgrade by installing Oracle Database Examples. In your earlier release, if you downloaded and worked with the earlier release demonstration files, then you have two problems: you want to save your earlier release work for review and testing with the new release, and you want to obtain refreshes of the demonstrations that are specific to the new release.

After upgrading the Oracle home, and downloading and doing any other work you want to do with the new demonstration files, you can then refresh your old demonstration files.

Example 4-1 Copying the Earlier Release Demo Directory and Refreshing the Demonstrations in the Read-Only Oracle Home

After the upgrade, use this procedure to save any work in your earlier demo directory in the Read-Only Oracle home, and and replace the earlier release demo directory with the new release demo directory:

  1. Log in as the Oracle software owner user (oracle).

  2. Check if the rdbms/demo directory is copied to the Read Only Oracle home.

    In this example, the environment variable ORACLE_BASE_HOME is defined as the path to the Read-Only Oracle home.

    Linux and Unix platforms:

    $ ls -l -d $ORACLE_BASE_HOME/rdbms/demo
/u01/app/oracle/product/19.0.0/dbhome_1/rdbms/demo

    Microsoft Windows platforms

    ls -l -d %ORACLE_BASE_HOME%\rdbms\demo 
%ORACLE_BASE_HOME%\rdbms\demo

  3. Change directory to the Read-Only Oracle home, and make a copy, where demo.old_release18 is the name you give to your earlier release demonstration files: 

    cd $ORACLE_BASE_HOME/rdbms
mv demo demo.old_release18

  4. Copy the new demo directory from the upgraded Oracle home to the Read-Only Oracle home.

    In this example, the environment variable ORACLE_HOME is defined as the new release Oracle home.

    Linux and Unix:

    cp -r $ORACLE_HOME/rdbms/demo demo

    Microsoft Windows

    xcopy c:\%ORACLE_HOME%\rdbms\demo c:%ORACLE_BASE_HOME%\rdbms\demo /E

Parent topic: Required Tasks to Complete After Upgrading Oracle Database

Configure Access Control Lists (ACLs) to External Network Services

Oracle Database 12c and later releases include fine-grained access control to the UTL_TCP, UTL_SMTP, UTL_MAIL, UTL_HTTP, or UTL_INADDR packages.

If you have applications that use these packages, then after upgrading Oracle Database you must configure network access control lists (ACLs) in the database before the affected packages can work as they did in earlier releases. Without the ACLs, your applications can fail with the error "ORA-24247: network access denied by access control list (ACL)."

See Also:

Oracle Database Security Guide for more complicated situations, such as connecting some users to host A and other users to host B

Parent topic: Required Tasks to Complete After Upgrading Oracle Database

Enabling Oracle Database Vault After Upgrading Oracle Database

Depending on your target database release, you can be required to reenable Oracle Database Vault, or revoke Oracle Database Vault role granted for upgrade.

Parent topic: Required Tasks to Complete After Upgrading Oracle Database

Upgrading Oracle Database Without Disabling Oracle Database Vault

To upgrade to Oracle Database 12c Release 2 (12.2.0.1) or later releases, either grant the DV_PATCH_ADMIN role to SYS commonly in the root container, and revoke after the upgrade, or disable Oracle Database Vault and reenable it after upgrade.

If Oracle Database Vault is enabled and you are upgrading an entire CDB, then use one of the following methods:

  • CDB upgrade method 1: Temporarily grant the DV_PATCH_ADMIN to user SYS commonly by logging into the root container as a common user with the DV_OWNER role, and then issuing the GRANT DV_PATCH_ADMIN TO SYS CONTAINER=ALL statement. Oracle Database Vault controls will be in the same state as it was before the upgrade. When the upgrade is complete, log into the root container as the DV_OWNER user, and revoke the DV_PATCH_ADMIN role from SYS by issuing the REVOKE DV_PATCH_ADMIN FROM SYS CONTAINER=ALL statement.
  • CDB upgrade method 2: Log into each container as a user who has the DV_OWNER role, and then run the DBMS_MACADM.DISABLE_DV procedure. You must first disable Oracle Database Vault on the PDBs, and then after that, disable Oracle Database Vault on the root container last. If you are upgrading only one PDB, then you can disable Oracle Database Vault in that PDB only. After you have completed the upgrade, you can enable Oracle Database Vault by logging into each container as the DV_OWNER user and then executing the DVSYS.DBMS_MACADM.ENABLE_DV procedure. The order of enabling Oracle Database Vault must be the root container first and PDBs afterward. You can enable the PDBs in any order, but the root container must be enabled first.

If you manually disable Oracle Database Vault before the upgrade, then you must enable Oracle Database Vault manually after the upgrade.

If you did not have Oracle Database Vault enabled before the upgrade, then you can enable it manually after the upgrade.

Note:

This procedure applies to non-CDB upgrades as well

Related Topics

Parent topic: Enabling Oracle Database Vault After Upgrading Oracle Database

Postupgrade Scenarios with Oracle Database Vault

Postupgrade tasks for Oracle Database Vault change, depending on your target Oracle Database release, and the option you chose to prepare for upgrade.

Upgrades to Oracle Database 21c and Later

You must choose one of the following options:

  • Grant the DV_PATCH_ADMIN role to SYS commonly (container=all).
  • Disable Oracle Database Vault before upgrade.

If you granted the DV_PATCH_ADMIN role to SYS before the upgrade, then revoke the DV_PATCH_ADMIN role from SYS after the upgrade. If you disabled Oracle Database Vault, then reenable it after the upgrade is complete.

Upgrades to Oracle Database 18c and 19c

You do not need to disable Oracle Database Vault.

Note:

For all upgrades, after the upgrade is complete, Oracle Database Vault has the same enforcement status that was in place for your source database before the upgrade.

Parent topic: Enabling Oracle Database Vault After Upgrading Oracle Database

Check for the SQLNET.ALLOWED_LOGON_VERSION Parameter Behavior

Connections to Oracle Database from clients earlier than release 10g fail with the error ORA-28040: No matching authentication protocol.

Starting with Oracle Database 18c, the default value for the SQLNET.ALLOWED_LOGON_VERSION parameter changed from 11 in Oracle Database 12c (12.2) to 12 in Oracle Database 18c and later releases. The use of this parameter is deprecated.

SQLNET.ALLOWED_LOGON_VERSION is now replaced with the SQLNET.ALLOWED_LOGON_VERSION_SERVER and SQLNET.ALLOWED_LOGON_VERSION_CLIENT parameters. If you have not explicitly set the SQLNET.ALLOWED_LOGON_VERSION_SERVER parameter in the upgraded database, then connections from clients earlier than release 10g fail with the error ORA-28040: No matching authentication protocol. For better security, check the password verifiers of your database users, and then configure the database to use the correct password verifier by setting the SQLNET.ALLOWED_LOGON_VERSION_SERVER and SQLNET.ALLOWED_LOGON_VERSION_CLIENT parameters.

If you have password-protected roles (secure roles) in your existing database, and if you upgrade to Oracle Database 18c and later releases with the default SQLNET.ALLOWED_LOGON_VERSION_SERVER setting of 12, because those secure roles only have release 10g verifiers, then the password for each secure role must be reset by the administrator so that the secure roles can remain usable after the upgrade.

See Also:

Parent topic: Required Tasks to Complete After Upgrading Oracle Database