Recommended and Best Practices to Complete After Upgrading Oracle Database
Oracle recommends that you complete these good practices guidelines for updating Oracle Database. Except where noted, these practices are recommended for all types of upgrades.
- Back Up the Database
Oracle strongly recommends that you at least perform a level 1 backup, or if time allows, perform a level 0 backup. - Run AutoUpgrade Postupgrade Checks
If you did not run AutoUpgrade indeploy
mode, then run Autoupgrade with thepreupgrade
parameter, run inpostfixups
mode. - Gathering Dictionary Statistics After Upgrading
To help to assure good performance, use this procedure to gather dictionary statistics after completing your upgrade. - Upgrading Statistics Tables Created by the DBMS_STATS Package After Upgrading Oracle Database
If you created statistics tables using theDBMS_STATS.CREATE_STAT_TABLE
procedure, then upgrade these tables by runningDBMS_STATS.UPGRADE_STAT_TABLE
. - Regathering Fixed Objects Statistics with DBMS_STATS
After an upgrade, or after other database configuration changes, Oracle strongly recommends that you regather fixed object statistics after you have run representative workloads on Oracle Database. - Reset Passwords to Enforce Case-Sensitivity
For upgraded databases, improve security by using case-sensitive passwords for default user accounts and user accounts. - 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. - Finding and Resetting User Passwords That Use the 10G Password Version
For better security, find and reset passwords for user accounts that use the10G
password version so that they use later, more secure password versions. - Understand Oracle Grid Infrastructure, Oracle ASM, and Oracle Clusterware
Oracle Clusterware and Oracle Automatic Storage Management (Oracle ASM) are both part of an Oracle Grid Infrastructure installation. - Oracle Grid Infrastructure Installation and Upgrade and Oracle ASM
Oracle ASM is installed with Oracle Grid Infrastructure. - Add New Features as Appropriate
Review new features as part of your database upgrade plan. - Develop New Administrative Procedures as Needed
Plan a review of your scripts and procedures, and change as needed. - Migrating From Rollback Segments To Automatic Undo Mode
If your database release is earlier than Oracle Database 11g, then you must migrate the database that is being upgraded from using rollback segments (manual undo management) to automatic undo management. - Migrating Tables from the LONG Data Type to the LOB Data Type
You can use theALTER TABLE
statement to change the data type of aLONG
column toCLOB
and that of aLONG RAW
column toBLOB
. - Turn off Traditional Auditing in Upgraded Oracle Databases
Traditional auditing is deprecated in Oracle Database 21c, and is desupported in Oracle Database 23c. Oracle recommends that you turn off traditional audit in your database and use only unified auditing. - Identify Oracle Text Indexes for Rebuilds
You can run a script that helps you to identify Oracle Text index indexes with token tables that can benefit by being rebuilt after upgrading to the new Oracle Database release.. - Dropping and Recreating DBMS_SCHEDULER Jobs
If DBMS_SCHEDULER jobs do not function after upgrading from an earlier release, drop and recreate the jobs. - Transfer Unified Audit Records After the Upgrade
Review these topics to understand how you can obtain better performance after you upgrade and migrate to unified auditing - About Recovery Catalog Upgrade After Upgrading Oracle Database
If you use a version of the recovery catalog schema that is older than that required by the RMAN client, then you must upgrade it. - Upgrading the Time Zone File Version After Upgrading Oracle Database
If the AutoUpgrade preupgrade report instructs you to upgrade the time zone files after completing the database upgrade, and you do not set AutoUpgrade to complete this task for you, then use any of the supported methods to upgrade the time zone file. - Enabling Disabled Release Update Bug Fixes in the Upgraded Database
Because bug fixes in Release Updates that can cause execution plan changes are disabled, Oracle recommends that you enable the disabled bug fixes that you want to use. - About Testing the Upgraded Production Oracle Database
Repeat tests on your production database that you carried out on your test database to ensure applications operate as expected.
Parent topic: Postupgrade Tasks for Oracle Database
Back Up the Database
Oracle strongly recommends that you at least perform a level 1 backup, or if time allows, perform a level 0 backup.
Related Topics
Run AutoUpgrade Postupgrade Checks
If you did not run AutoUpgrade in deploy
mode, then run
Autoupgrade with the preupgrade
parameter, run in
postfixups
mode.
Note:
If you ran AutoUpgrade in deploy
mode, then this step was already
completed for you, so you do not need to complete it now.
To see how to check your database after upgrades, use the following example.
Example 7-10 Running AutoUpgrade Using Postupgrade Fixup Mode
Suppose you have upgraded an Oracle Database 12c Release 2 (12.2) Oracle Database. To run postupgrade checks, you complete this procedure:-
Set the Oracle home environment to the source Oracle Database home:
.setenv ORACLE_HOME /u01/app/oracle/product/12.2.0/dbhome_1
- Set the Oracle System Identifier (SID) to the source Oracle
Database SID:
.setenv ORACLE_SID db122
- Run AutoUpgrade using the preupgrade parameter in postfixups mode,
setting the target home to the target Oracle Database Oracle home. For example:
java -jar autoupgrade.jar -preupgrade "target_home=/u01/app/oracle/product/21.0.0/dbhome_1,dir=/autoupgrade/test/log" –mode postfixups
- Check the results of the postfixup script checks in the file
postfixups.xml
under directory/autoupgrade/test/log/db122/102/postfixups
.
Gathering Dictionary Statistics After Upgrading
To help to assure good performance, use this procedure to gather dictionary statistics after completing your upgrade.
Oracle recommends that you gather dictionary statistics both before and after upgrading the database, because Data Dictionary tables are modified and created during the upgrade. With Oracle Database 12c release 2 (12.2) and later releases, you gather statistics as a manual procedure after the upgrade, when you bring the database up in normal mode.
Note:
If you completed your upgrade using the AutoUpgrade utility, then you do not need to complete this task. The AutoUpgrade utility completes it for you.
CDB: Oracle recommends that you use catcon
to gather Data Dictionary statistics across the entire
multitenant architecture
To gather dictionary statistics for all PDBs in a container database, use the following syntax
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l
/tmp -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"
To gather dictionary statistics on a particular PDB, use syntax similar to the following:
$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -c
'SALES1' -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"
In the preceding example the -c SALES1
option specifies
a PDB inclusion list for the command that you run, specifying the database named
SALES1
. The option -b gatherstats
specifies
the base name for the logs. The option --x
specifies the SQL
command that you want to execute. The SQL command itself is inside the quotation
marks.
Upgrading Statistics Tables Created by the DBMS_STATS Package After Upgrading Oracle Database
If you created statistics tables using the DBMS_STATS.CREATE_STAT_TABLE
procedure, then upgrade these tables by running DBMS_STATS.UPGRADE_STAT_TABLE
.
In the following example, green
is the owner of the statistics table and STAT_TABLE
is the name of the statistics table.
EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('green', 'stat_table');
Perform this procedure for each statistics table.
See Also:
Oracle Database PL/SQL Packages and Types Reference for information about the DBMS_STATS package
Regathering Fixed Objects Statistics with DBMS_STATS
After an upgrade, or after other database configuration changes, Oracle strongly recommends that you regather fixed object statistics after you have run representative workloads on Oracle Database.
Note:
To provide the most correct fixed object statistics for performance
tuning, Oracle strongly recommends that you gather baseline statistics at a
point when the system is running with a representative workload. For useful
results, never run DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
immediately after the upgrade.
Fixed objects are the X$
tables and their indexes.
V$
performance views are defined through X$
tables. Gathering fixed object statistics is valuable for database performance,
because these statistics help the optimizer to generate good execution plans, which
can improve database performance. Failing to obtain representative statistics can
lead to suboptimal execution plans, which can cause significant performance
problems.
Ensure that your database has run representative workloads, and then
gather fixed objects statistics by using the
DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
PL/SQL procedure.
DBMS_STATS.GATHER_FIXED_OBJECTS_STATS
also displays
recommendations for removing all hidden or underscore parameters and events from the
INIT.ORA
or SPFILE
.
Because of the transient nature of X$
tables, you must
gather fixed objects statistics when there is a representative workload on the
system. If you cannot gather fixed objects statistics during peak load, then Oracle
recommends that you do it after the system is in a runtime state, and the most
important types of fixed object tables are populated.
To gather statistics for fixed objects, run the following PL/SQL procedure:
SQL> execute dbms_stats.gather_fixed_objects_stats;
Related Topics
Reset Passwords to Enforce Case-Sensitivity
For upgraded databases, improve security by using case-sensitive passwords for default user accounts and user accounts.
For greater security, Oracle recommends that you enable case sensitivity in
passwords. In Oracle Database 21c and later release, the IGNORECASE
parameter for the orapwd
file is desupported. All newly created
password files are case-sensitive. Case sensitivity increases the security of passwords
by requiring that users enter both the correct password string, and the correct case for
each character in that string. For example, the password hPP5620qr
fails if it is entered as hpp5620QR
or hPp5620Qr
.
Upgraded password files from earlier Oracle Database releases can retain original case-insensitive passwords. To ensure that password files are case-sensitive, Oracle recommends that you force case sensitivity by migrating password files from one format to another, using the following syntax:
orapwd input_file=input_password _file file=output_password_file
To secure your database, create passwords in a secure fashion. If you have default passwords in your database, then change these passwords. Every password should satisfy the Oracle recommended password requirements, including passwords for predefined user accounts.
For new databases created after the upgrade, there are no additional tasks or management requirements.
Existing Database Requirements and Guidelines for Password Changes
- Passwords must be at least eight characters, and passwords such as
welcome
andoracle
are not allowed. - For existing databases, to take advantage of password case-sensitivity, you must
reset the passwords of existing users during the database upgrade procedure.
Reset the password for each existing database user with an
ALTER USER
statement. - Query the
PASSWORD_VERSIONS
column ofDBA_USERS
to find theUSERNAME
of accounts that only have the 10G password version, and do not have either the11G
or the12C
password version. Reset the password for any account that has only the10G
password version.
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:
-
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);
-
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
andDBMS_XDB_CONFIG.getHTTPPort
respectively. -
To see all the used port numbers, query
DBMS_XDB_CONFIG.usedport
.
Finding and Resetting User Passwords That Use the 10G Password Version
For better security, find and reset passwords for user accounts that use the 10G
password version so that they use later, more secure password versions.
Finding All Password Versions of Current Users
You can query the DBA_USERS
data dictionary view to find a list of all the password versions configured for user accounts.
For example:
SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;
USERNAME PASSWORD_VERSIONS
------------------------------ -----------------
JONES 10G 11G 12C
ADAMS 10G 11G
CLARK 10G 11G
PRESTON 11G
BLAKE 10G
The PASSWORD_VERSIONS
column shows the list of password versions that exist for the account. 10G
refers to the earlier case-insensitive Oracle password version, 11G
refers to the SHA-1-based password version, and 12C
refers to the SHA-2-based SHA-512 password version.
-
User
jones
: The password for this user was reset in Oracle Database 12c Release 12.1 when theSQLNET.ALLOWED_LOGON_VERSION_SERVER
parameter setting was8
. This enabled all three password versions to be created. -
Users
adams
andclark
: The passwords for these accounts were originally created in Oracle Database 10g and then reset in Oracle Database 11g. The Oracle Database 11g software was using the defaultSQLNET.ALLOWED_LOGON_VERSION
setting of8
at that time. Because case insensitivity is enabled by default, their passwords are now case sensitive, as is the password forpreston
. -
User
preston
: This account was imported from an Oracle Database 11g database that was running in Exclusive Mode (SQLNET.ALLOWED_LOGON_VERSION = 12
). -
User
blake
: This account still uses the Oracle Database 10g password version. At this stage, userblake
is prevented from logging in.
Resetting User Passwords That Use the 10G Password Version
You should remove the 10G
password version from the accounts of all users. In the following procedure, to reset the passwords of users who have the 10G
password version, you must temporarily relax the SQLNET.ALLOWED_LOGON_VERSION_SERVER
setting, which controls the ability level required of clients before login can be allowed. Relaxing the setting enables these users to log in and change their passwords, and hence generate the newer password versions in addition to the 10G
password version. Afterward, you can set the database to use Exclusive Mode and ensure that the clients have the O5L_NP
capability. Then the users can reset their passwords again, so that their password versions no longer include 10G
, but only have the more secure 11G
and 12C
password versions.
Understand Oracle Grid Infrastructure, Oracle ASM, and Oracle Clusterware
Oracle Clusterware and Oracle Automatic Storage Management (Oracle ASM) are both part of an Oracle Grid Infrastructure installation.
If Oracle Grid Infrastructure is installed for a single server, then it is deployed as an Oracle Restart installation with Oracle ASM. If Oracle Grid Infrastructure is installed for a cluster, then it is deployed as an Oracle Clusterware installation with Oracle ASM.
Oracle Restart enhances the availability of Oracle Database in a single-instance environment. If you install Oracle Restart, and there is a temporary failure of any part of the Oracle Database software stack, including the database, listener, and Oracle ASM instance, Oracle Restart automatically restarts the failed component. In addition, Oracle Restart starts all these components when the database host computer is restarted. The components are started in the proper order, taking into consideration the dependencies among components.
Oracle Clusterware is portable cluster software that enables clustering of single servers so that they cooperate as a single system. Oracle Clusterware also provides the required infrastructure for Oracle RAC. In addition, Oracle Clusterware enables the protection of any Oracle application or any other application within a cluster. In any case Oracle Clusterware is the intelligence in those systems that ensures required cooperation between the cluster nodes.
Oracle Grid Infrastructure Installation and Upgrade and Oracle ASM
Oracle ASM is installed with Oracle Grid Infrastructure.
In earlier releases, Oracle ASM was installed as part of the Oracle Database installation. Starting with Oracle Database release 11.2, Oracle ASM is installed when you install the Grid Infrastructure components. Oracle ASM shares an Oracle home with Oracle Clusterware.
See Also:
Oracle Grid Infrastructure Installation Guide for your platform for information about Oracle homes, role-allocated system privileges groups, different installation software owner users, and other changes.
Add New Features as Appropriate
Review new features as part of your database upgrade plan.
Oracle Database New Features Guide describes many of the new features available in the new Oracle Database release. Determine which of these new features can benefit the database and applications. You can then develop a plan for using these features.
It is not necessary to make any immediate changes to begin using your new Oracle Database software. You can choose to introduce new feature enhancements into your database and applications gradually.
Develop New Administrative Procedures as Needed
Plan a review of your scripts and procedures, and change as needed.
After familiarizing yourself with the features of the new Oracle Database release, review your database administration scripts and procedures to determine whether any changes are necessary.
Coordinate your changes to the database with the changes that are necessary for each application. For example, by enabling integrity constraints in the database, you may be able to remove some data checking from your applications.
Migrating From Rollback Segments To Automatic Undo Mode
If your database release is earlier than Oracle Database 11g, then you must migrate the database that is being upgraded from using rollback segments (manual undo management) to automatic undo management.
Automatic undo management is the default undo space management mode. The UNDO_MANAGEMENT
initialization parameter specifies which undo space management mode the system should use:
-
If UNDO_MANAGEMENT is set to
AUTO
(or if UNDO_MANAGEMENT is not set), then the database instance starts in automatic undo management mode.A null UNDO_MANAGEMENT initialization parameter defaults to automatic undo management mode in Oracle Database 11g Release 1 (11.1) and later. In earlier releases it defaults to manual undo management mode. Use caution when upgrading earlier releases.
-
If UNDO_MANAGEMENT is set to
MANUAL
, then undo space is allocated externally as rollback segments.
Migrating Tables from the LONG Data Type to the LOB Data Type
You can use the ALTER TABLE
statement to change the data type of a LONG
column to CLOB
and that of a LONG RAW
column to BLOB
.
The LOB
data types (BFILE
, BLOB
, CLOB
, and NCLOB
) can provide many advantages over LONG
data types.
In the following example, the LONG
column named long_col
in table long_tab
is changed to data type CLOB
:
SQL> ALTER TABLE Long_tab MODIFY ( long_col CLOB );
After using this method to change LONG
columns to LOBs, all the existing constraints and triggers on the table are still usable. However, all the indexes, including Domain indexes and Functional indexes, on all columns of the table become unusable and must be rebuilt using an ALTER INDEX...REBUILD
statement. Also, the Domain indexes on the LONG
column must be dropped before changing the LONG
column to a LOB.
See Also:
Oracle Database SecureFiles and Large Objects Developer's Guide for information about modifying applications to use LOB data
Turn off Traditional Auditing in Upgraded Oracle Databases
Traditional auditing is deprecated in Oracle Database 21c, and is desupported in Oracle Database 23c. Oracle recommends that you turn off traditional audit in your database and use only unified auditing.
Unified Auditing and Traditional Auditing (mixed mode) has been the default auditing mode from Oracle Database 12c onward. Mixed mode auditing was offered to enable you to become familiar with Unified Auditing, and to transition from Traditional Auditing. With the deprecation of Traditional Auditing in Oracle Database 21c, Oracle recommends that you turn off traditional audit in your database and use only unified auditing.. Refer to the procedure in Oracle Database Security Guide.
- Understanding Auditing for Oracle Database
Decide which audit policies you want to use in the upgraded database. - Turning Off Traditional Auditing and Using Unified Auditing for Oracle Database
Use this procedure for multitenant container (CDB) databases to turn off traditional auditing, and to use unified auditing. - About Managing Earlier Audit Records After You Move to Unified Auditing
Review, archive, and purge earlier audit trails in preparation for using the unified audit trail. - Moving From Pure Unified Auditing to Mixed-Mode Auditing
Use this procedure to turn on traditional auditing in mixed-mode audit configuration. - Obtaining Documentation References if You Choose Not to Use Unified Auditing
You can access documentation listed here to obtain configuration information about how to use non-unified auditing.
Related Topics
Understanding Auditing for Oracle Database
Decide which audit policies you want to use in the upgraded database.
For newly created databases, the mixed-mode method of unified auditing is enabled by
default, which has both traditional auditing and unified auditing. The predefined audit
policies ORA_SECURECONFIG
and ORA_LOGIN_LOGOUT
policies are enabled by default. Oracle recommends that you consider turning off
traditional auditing and use only unified
If you have upgraded from an earlier release to Oracle Database 12c, then
your database uses the same auditing functionality that was used in the earlier release.
Oracle recommends that you consider turning off traditional auditing, and ensure the
predefined audit policies ORA_SECURECONFIG
and
ORA_LOGIN_LOGOUT
policies are enabled so that you can start using
pure unified auditing.
To enable and configure the audit policies and how they are used, choose one method as follows:
-
Use the pure unified audit facility.
Transition to unified auditing to use the full unified auditing facility features. After you complete the procedure to transition to unified auditing, you can create and enable new audit policies and also use the predefined audit policies. The audit records for these policies write to the unified audit trail. The earlier audit trails and their audit records remain, but no new audit records write to the earlier audit trails.
Note:
The audit configuration from the earlier release has no effect in the unified audit system. Only unified audit policies generate audit records inside the unified audit trail.
-
Use a mixed-mode audit facility.
The mixed-mode audit facility assists you transition to unified auditing. It enables both traditional and unified auditing facilities to run simultaneously and applies to both new and upgraded databases. The mixed-mode unified auditing facility becomes available if you enable at least one of the unified auditing predefined audit policies. Audit records for these policies write to the unified audit trail. The audit configuration in the earlier release of Oracle Database is also available, and the audit records for this configuration write to the earlier audit trails. If you decide that you prefer using the pure unified audit facility, then you can migrate to it.
Note:
If the database is not writable, then audit records write to new format operating system files in the
$ORACLE_BASE/audit/$ORACLE_SID
directory.
Turning Off Traditional Auditing and Using Unified Auditing for Oracle Database
Use this procedure for multitenant container (CDB) databases to turn off traditional auditing, and to use unified auditing.
Perform the following procedure in the
root
. The procedure configures both the root
CDB and any
associated PDBs to use unified auditing.
Note:
Oracle recommends that you start using unified auditing now. It is deprecated in Oracle Database 21c, and desupported in Oracle Database 23ai.
If you need to continue using traditional auditing as a transition, you can disable unified auditing from the container database (CDB) root only, not for individual pluggable databases (PDBs).
However, when unified auditing is disabled, individual PDBs can use the mixed mode auditing, depending on whether or not the local audit policy is enabled in that PDB. If you have a CDB common audit policy enabled, then all PDBs use mixed mode auditing.
-
Log in to SQL*Plus as user
SYS
with theSYSDBA
privilege.sqlplus sys as sysdba Enter password: password
In the multitenant environment, this login connects you to
root
. -
Check if your Oracle Database is migrated to unified auditing using this query:
SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
If the output for the
VALUE
column isTRUE
, then unified auditing is already enabled in your database. You can proceed to Managing Earlier Audit Records. If the output isFALSE
, then complete the remaining steps in this procedure. -
Stop the database. For single-instance environments, enter the following commands from SQL*Plus:
SQL> SHUTDOWN IMMEDIATE SQL> EXIT
For Windows systems, stop the Oracle service:
net stop OracleService%ORACLE_SID%
For Oracle Real Application Clusters (Oracle RAC) installations, shut down each database instance as follows:
srvctl stop database -db db_name
-
Stop the listener. (Stopping the listener is not necessary for Oracle RAC and Oracle Grid Infrastructure listeners.)
lsnrctl stop listener_name
You can find the name of the listener by running the
lsnrctl status
command. TheAlias
setting indicates the name. -
Go to the directory
$ORACLE_HOME/rdbms/lib
. -
Enable unified auditing for the Oracle user.
-
Linux and Unix
make -f ins_rdbms.mk uniaud_on oracle ORACLE_HOME=$ORACLE_HOME
-
Microsoft Windows
Rename the file
%ORACLE_HOME%/bin/orauniaud12.dll.dbl
to%ORACLE_HOME%/bin/orauniaud12.dll
.
Note:
For Oracle RAC databases that have non-shared Oracle homes, you must repeat this step on each cluster member node, so that the binaries are updated inside the local ORACLE_HOME on each cluster node.
-
-
Restart the listener.
lsnrctl start listener_name
-
Restart the database.
Log in to SQL*Plus and then enter the
STARTUP
command:sqlplus sys as sysoper Enter password: password SQL> STARTUP
For Microsoft Windows systems, start the Oracle service:
net start OracleService%ORACLE_SID%
For Oracle RAC installations, start each database instance:
srvctl start database -db db_name
After you migrate to unified auditing, refer to "LOB Columns of Database
Audit Trails should use Securefile Storage (Doc ID 2659172.1)" and review information
about the Oracle home script Oracle_home/rdbms/admin/auditpostupgrade.sql
. To obtain performance
benefits of unified auditing, Oracle strongly recommends that you run this script after
completing the upgrade.
About Managing Earlier Audit Records After You Move to Unified Auditing
Review, archive, and purge earlier audit trails in preparation for using the unified audit trail.
After you complete the procedure in Oracle Database to turn off traditional auditing and use unified auditing, any audit records that your database had before remain in their earlier audit trails. You can archive these audit records and then purge their audit trails. With unified auditing in place, any new audit records write to the unified audit trail.
Related Topics
Moving From Pure Unified Auditing to Mixed-Mode Auditing
Use this procedure to turn on traditional auditing in mixed-mode audit configuration.
If you decide that you want to re-enable traditional auditing in mixed-mode, then you can use this procedure to turn on traditional auditing. In this case, your database uses the mixed-mode audit facility.
Note:
Be aware that traditional auditing is deprecated, and is desupported in Oracle Database 23c. Plan accordingly.-
Stop the database.
sqlplus sys as sysoper Enter password: password SQL> SHUTDOWN IMMEDIATE SQL> EXIT
For Microsoft Windows systems, stop the Oracle service:
net stop OracleService%ORACLE_SID%
For Oracle RAC installations, shut down each database instance as follows:
srvctl stop database -db db_name
-
Go to the
$ORACLE_HOME/rdbms/lib
directory. -
Disable the unified auditing executable.
-
Linux/Unix: Run the following command:
make -f ins_rdbms.mk uniaud_off oracle ORACLE_HOME=$ORACLE_HOME
-
Microsoft Windows: Rename the
%ORACLE_HOME%/bin/orauniaud12.dll
file to%ORACLE_HOME%/bin/orauniaud12.dll.dbl
.
-
-
Restart the database.
sqlplus sys as sysoper Enter password: password SQL> STARTUP SQL> EXIT
For Microsoft Windows systems, start the Oracle service again.
net start OracleService%ORACLE_SID%
For Oracle RAC installations, start each database instance using the following syntax:
srvctl start database -db db_name
Obtaining Documentation References if You Choose Not to Use Unified Auditing
You can access documentation listed here to obtain configuration information about how to use non-unified auditing.
After upgrading to the new release Oracle Database, if you choose not to change to unified auditing, then Oracle documentation and Oracle Technology Network provide information about traditional auditing. Be aware that traditional auditing is deprecated in Oracle Database 21c and desupported in Oracle Database 23c. Plan accordingly.
Oracle Database Security Guide is the main source of information for configuring auditing. You must use the Oracle Database Release 11g version of this manual. To access this guide
-
Visit the database page on
docs.oracle.com
site on Oracle Technology Network: -
Select Oracle Database.
-
In the Downloads page, select the Documentation tab.
-
On the release list field, select Earlier Releases, and select Oracle Database 11g Release 2 (11.2).
-
From the Oracle Database 11g Release 2 (11.2) Documentation page, select the All Books link to display publications in the documentation set.
-
Search for Security Guide.
-
Select either the HTML or the PDF link for this guide.
Identify Oracle Text Indexes for Rebuilds
You can run a script that helps you to identify Oracle Text index indexes with token tables that can benefit by being rebuilt after upgrading to the new Oracle Database release..
When you upgrade from Oracle Database 12c release 1 (12.2.0.1) to Oracle Database 18c and later releases, the Oracle Text token tables ($I
, $P
, and so on) are expanded from 64 bytes to 255 bytes. However, if you have indexes with existing token tables using the smaller size range, then the Oracle Text indexes cannot take advantage of this widened token column range. You must rebuild the indexes to use the 255 byte size range. Oracle provides a script that can assist you to identify indexes that can benefit by being rebuilt.
Obtain the script from My Oracle Support:
Dropping and Recreating DBMS_SCHEDULER Jobs
If DBMS_SCHEDULER jobs do not function after upgrading from an earlier release, drop and recreate the jobs.
If you find that DBMS_SCHEDULER jobs are not functioning after an upgrade. drop and recreate those jobs. This issue can occur even if the upgrade process does not report issues, and system objects are valid.
Transfer Unified Audit Records After the Upgrade
Review these topics to understand how you can obtain better performance after you upgrade and migrate to unified auditing
- About Transferring Unified Audit Records After an Upgrade
Transferring the unified audit records from Oracle Database 12c release 12.1 to the new relational table under theAUDSYS
schema for the new Oracle Database release improves the read performance of the unified audit trail. - Transferring Unified Audit Records After an Upgrade
You can transfer unified audit records to the new relational table in AUDSYS by using the DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDS PL/SQL procedure.
About Transferring Unified Audit Records After an Upgrade
Transferring the unified audit records from Oracle Database 12c release 12.1 to the new relational table under the AUDSYS
schema for the new Oracle Database release improves the read performance of the unified audit trail.
Starting with Oracle Database 12c Release 2, unified audit records are written directly to a new internal relational table that is located in the AUDSYS schema. In Oracle Database 12c release 12.1, the unified audit records were written to the common logging infrastructure (CLI) SGA queues. If you migrated to unified auditing in that release, then to obtain better read performance, you can transfer the unified audit records that are from that release to the new Oracle Database release internal table. It is not mandatory that you perform this transfer, but Oracle recommends that you do so to obtain better unified audit trail read performance. This is a one-time operation. All new unified audit records that are generated after the upgrade are written to the new table. The table is a read-only table. Any attempt to modify the metadata or data of this table is mandatorily audited.
After you upgrade to the new Oracle Database release, if you have any unified audit records present in the UNIFIED_AUDIT_TRAIL
from the earlier release, then consider transferring them to the new internal relational table by using the transfer procedure for better read performance of the unified audit trail.
As with the SYS
schema, you cannot query the AUDSYS schema if you have the SELECT ANY TABLE system privilege. In addition, this table is not listed as a schema object in the ALL_TABLES data dictionary view unless you have either the SELECT ANY DICTIONARY system privilege or an explicit SELECT privilege on this internal table. Until the database is open read write, the audit records are written to operating system spillover files (.bin
format). However, you can transfer the audit records in these operating system files to the internal relational table after the database opens in the read write mode by using the DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES procedure.
Parent topic: Transfer Unified Audit Records After the Upgrade
Transferring Unified Audit Records After an Upgrade
You can transfer unified audit records to the new relational table in AUDSYS by using the DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDS PL/SQL procedure.
Parent topic: Transfer Unified Audit Records After the Upgrade
About Recovery Catalog Upgrade After Upgrading Oracle Database
If you use a version of the recovery catalog schema that is older than that required by the RMAN client, then you must upgrade it.
Upgrading the Time Zone File Version After Upgrading Oracle Database
If the AutoUpgrade preupgrade report instructs you to upgrade the time zone files after completing the database upgrade, and you do not set AutoUpgrade to complete this task for you, then use any of the supported methods to upgrade the time zone file.
By default, AutoUpgrade changes the database time zone to the latest
available level. If you don’t want the time zone to be upgraded, then you must
explicitly set the local parameter timezone_upg
in your AutoUpgrade
configuration file to no
. For example:
upg1.timezone_upg=no
Note:
If you explicitly disable the time zone file upgrade in your AutoUpgrade configuration file, then Oracle recommends that you perform this task either as part of your upgrade plan, or at a later point in time.
Enabling Disabled Release Update Bug Fixes in the Upgraded Database
Because bug fixes in Release Updates that can cause execution plan changes are disabled, Oracle recommends that you enable the disabled bug fixes that you want to use.
After you upgrade your database, the bug fix patches that can cause execution plan
changes included in the Release Updates are installed disabled by default. These bug
fixes will not be activated until you enable the fixes. You can either enable these
fixes manually, with PFILE
or ALTER SYSTEM
commands,
or you can use the DBMS_OPTIM_BUNDLE
package. Starting with AutoUpgrade
19.12, the DBMS_OPTIM_BUNDLE
package includes 58 standard fixes. You
can now add additional fixes using DBMS_OPTIM_BUNDLE
. If you add fixes,
then the fixes that you add are run in addition to the default fixes.
Oracle strongly recommends that you enable these disabled patches that you want to use in your production system, and run complete workload performance tests using these patches as part of your upgrade test plan.
For more information about using DBMS_OPTIM_BUNDLE
to enable
patches that were disabled because they can change execution plans, see Oracle Database PL/SQL
Packages and Types Reference, and My Oracle Support note 2147007.1.
About Testing the Upgraded Production Oracle Database
Repeat tests on your production database that you carried out on your test database to ensure applications operate as expected.
If you upgraded a test database to the new Oracle Database release, and then tested it, then you can now repeat those tests on the production database that you upgraded to the new Oracle Database release. Compare the results, noting anomalies. Repeat the test upgrade as many times as necessary.
To verify that your applications operate properly with a new Oracle Database release, test the newly upgraded production database with your existing applications. You also can test enhanced functions by adding available Oracle Database features, and then testing them. However, first ensure that the applications operate in the same manner as they did before the upgrade.