Tasks to Complete Only After Manually Upgrading Oracle Database

After you complete your upgrade, you must perform the tasks described here if you upgrade your database manually instead of using DBUA.

Changing Passwords for Oracle Supplied Accounts

Oracle recommends that you carry out these tasks to protect new Oracle user accounts.

Depending on the release from which you upgraded, there may be new Oracle user accounts on your database. Oracle recommends that you lock all Oracle supplied accounts except for SYS and SYSTEM, and expire their passwords, so that new passwords are required when the accounts are unlocked.

Note:

If the default Oracle Database 12c security settings are in place, then passwords must be at least eight characters, and passwords such as welcome and oracle are not allowed.

See Also:

Oracle Database Security Guide about password requirements

You can view the status of all accounts by issuing the following SQL statement:

SQL> SELECT username, account_status
         FROM dba_users
         ORDER BY username;

To lock and expire passwords, issue the following SQL statement:

SQL> ALTER USER username PASSWORD EXPIRE ACCOUNT LOCK;

Create or Migrate Your Password File with ORAPWD

Review if you have REMOTE_LOGIN_PASSWORDFILE set.

If the REMOTE_LOGIN_PASSWORDFILE initialization parameter is set to EXCLUSIVE, then create or migrate the password file with ORAPWD. Oracle Database 12c provides a new option to ORAPWD for migrating the password file from your existing database.

As of Oracle Database 12c release 2 (12.2), if REMOTE_LOGIN_PASSWORDFILE is set to SHARED, then you receive a pre-upgrade check validation warning. You can choose one of the following options to correct this issue:

  • Disable the password file-based authentication entirely by setting REMOTE_LOGIN_PASSWORDFILE = NONE

  • Limit the password file-based authentication by setting REMOTE_LOGIN_PASSWORD = EXCLUSIVE

See Also:

Oracle Database Administrator's Guide for more information about creating or migrating password files

Migrating Your Initialization Parameter File to a Server Parameter File

If you are currently using a traditional initialization parameter file, then use this procedure to migrate to a server parameter file.

  1. If the initialization parameter file is located on a client computer, then transfer the file from the client computer to the server computer.

  2. Create a server parameter file using the CREATE SPFILE statement. This statement reads the initialization parameter file to create a server parameter file. You are not required to start the database to issue a CREATE SPFILE statement.

  3. Start up the instance using the newly-created server parameter file.

Note:

If you are using Oracle RAC, then you must combine all of your instance-specific initialization parameter files into a single initialization parameter file. Complete the procedures necessary for using a server parameter file with cluster databases.

See Also:

Identifying and Copying Oracle Text Files To a New Oracle Home

To upgrade Oracle Text, use this procedure to identify and copy required files from your existing Oracle home to the new release Oracle home. Complete this task after you upgrade Oracle Database.

Certain Oracle Text features rely on files under the Oracle home that you have configured. After a manual upgrade to a new release, or after any other process that changes the Oracle home, you must identify and move these files manually. These files include any user filters, any mail filter configuration files, and all the knowledge base extension files. After you identify the files, copy the files from your existing Oracle home to the new Oracle home.

To identify the list of files that you must copy from the existing Oracle home, Oracle recommends that you run the SQL script /ctx/admin/ctx_oh_files.sql.
  1. Log in with the SYS, SYSTEM, or CTXSYS system privileges for the earlier release database.
  2. Run $ORACLE_HOME/ctx/admin/ctx_oh.sql under the Oracle home of the earlier release database.

    For example:

    sqlplus / as sysdba
    connected
    SQL> @?/ctx/admin/ctx_oh_files
  3. Review the output from the ctx_oh_files.sql command, and copy those files to the new Oracle home.

Upgrading the Oracle Clusterware Configuration

If you are using Oracle Clusterware, then you must upgrade the Oracle Clusterware keys for the database.

Run srvctl for Oracle Database 12c to upgrade the database. For example:

ORACLE_HOME/bin/srvctl upgrade database -db name -o ORACLE_HOME

Adjust the Initialization Parameter File for the New Release

Review these topics to help you to check your initialization parameters after upgrading.

Each release of Oracle Database introduces new initialization parameters, deprecates some initialization parameters, and desupports some initialization parameters. You must adjust the parameter file to account for these changes and to take advantage of new initialization parameters that might be beneficial to your system. Additionally, when you perform a manual upgrade without using DBUA, the tnsnames.ora file is not automatically populated with new configuration information and settings. Therefore, you must manually update tnsnames.ora and adjust local_listener and remote_listener parameter references if these must be resolved.

See Also:

  • Oracle Database Reference “Changes In this Release” section for a list of the new initialization parameters in Oracle Database 12c, and for information about each parameter

  • for desupported and deprecated initialization parameters in Oracle Database 12c

Setting the COMPATIBLE Initialization Parameter After Upgrade

After testing, you can set the COMPATIBLE initialization parameter to the compatibility level you want for your new database.

The COMPATIBLE initialization parameter controls the compatibility level of your database. Set the COMPATIBLE initialization parameter to a higher value only when you are certain that you no longer need the ability to downgrade your database.

  1. Perform a backup of your database before you raise the COMPATIBLE initialization parameter (optional).

    Raising the COMPATIBLE initialization parameter can cause your database to become incompatible with earlier releases of Oracle Database. A backup ensures that you can return to the earlier release if necessary.

  2. If you are using a server parameter file, then complete the following steps:

    1. To set or change the value of the COMPATIBLE initialization parameter, update the server parameter file.

      For example, to set the COMPATIBLE initialization parameter to 12.2.0, enter the following statement:

      SQL> ALTER SYSTEM SET COMPATIBLE = '12.2.0' SCOPE=SPFILE;
      
    2. Shut down and restart the instance.

  3. If you are using an initialization parameter file, then complete the following steps:

    1. If an instance is running, then shut it down.

      For example:

      SQL> SHUTDOWN IMMEDIATE
      
    2. To set or change the value of the COMPATIBLE initialization parameter, you edit the initialization parameter file.

      For example, to set the COMPATIBLE initialization parameter to for Oracle Database release 12.2, enter the following in the initialization parameter file:

      COMPATIBLE = 12.2.0
      
    3. Start the instance using STARTUP.

Note:

If you are using an ASM disk group, then the disk group compatibility attribute must be equal to or less than the value for the database compatibility parameter in init.ora.

See Also:

Oracle Database Backup and Recovery User's Guide for more information about performing a backup

Adjust TNSNAMES.ORA and LISTENER Parameters After Upgrade

After performing a manual upgrade, if you must resolve local_listener and remote_listener in tnsnames.ora, then you must manually adjust those parameters.

DBUA handles changes to network naming and listeners during automatic upgrades. However, during a manual upgrade, neither tnsnames.ora nor the listeners are changed.

Set CLUSTER_DATABASE Initialization Parameter For Oracle RAC After Upgrade

For upgrades of Oracle RAC databases you set the CLUSTER_DATABASE initialization parameter to false before upgrading a cluster database.

After you complete the upgrade, you must set this parameter to true.