Recommended and Best Practices to Complete After Upgrading Oracle Database
Oracle recommends that you complete these good practices guidelines for updating Oracle Database. These practices are recommended for both manual and DBUA upgrades.
- Back Up the Database
Perform a full backup of the production database. - Running Postupgrade Fixup Scripts
Review this procedure to understand how to use thepostupgrade_fixups.sql
scripts for CDB and Non-CDB databases. - Gathering Dictionary Statistics After Upgrading
To help to assure good performance, use this procedure to gather dictionary statistics after completing your upgrade. - 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. - 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. - Set Threshold Values for Tablespace Alerts
After an upgrade, thresholds for Oracle Database 12c database Tablespace Alerts are set to null, disabling the alerts. - 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. - Configure Oracle Data Guard Broker
InitialConnectIdentifier is replaced by DGConnectIdentifier, which affects upgrades from Oracle Database 10g. - 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
. - Migrate Your Upgraded Oracle Databases to Use Unified Auditing
To use the full facilities of unified auditing, you must manually migrate to unified auditing. - 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 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: Post-Upgrade Tasks for Oracle Database
Back Up the Database
Perform a full backup of the production database.
Although this step is not required, Oracle strongly recommends that you back up your production database.
See Also:
Oracle Database Backup and Recovery User's Guide for details about backing up a database with RMAN
Running Postupgrade Fixup Scripts
Review this procedure to understand how to use the postupgrade_fixups.sql
scripts for CDB and Non-CDB databases.
The postupgrade fixup scripts are generated when you run the Pre-Upgrade Information Tool (preupgrade.jar
). Run the postupgrade scripts any time after completing an upgrade. For both Container Databases (CDBs) with pluggable databases (PDBs), and for Non-CDB databases, the postupgrade fixup scripts provide general warnings, errors, and informational recommendations.
You can run the script either by using the catcon.pl
utility, or by using SQL*Plus.
The location of the postupgrade SQL scripts and log files depends on how you set output folders, or define the Oracle base environment variable. The postupgrade fixup scripts are placed in the same directory path as the preupgrade fixup scripts.
If you specify an output directory by using the dir
option with the Pre-Upgrade Information Tool, then the output logs and files are placed under that directory in the file path /cfgtoollogs/dbunique_name/preupgrade
, where dbunique_name
is the name of your source Oracle Database. If you do not specify an output directory when you run the Pre-Upgrade Information Tool, then the output is directed to one of the following default locations:
-
If you do not specify an output directory with
DIR
, but you have set an Oracle base environment variable, then the generated scripts and log files are created in the following file path:Oracle-base/cfgtoollogs/dbunique_name/preupgrade
-
If you do not specify an output directory, and you have not defined an Oracle base environment variable, then the generated scripts and log files are created in the following file path:
Oracle-home/cfgtoollogs/dbunique_name/preupgrade
The postupgrade fixup scripts that the Pre-Upgrade Information Tool creates depend on whether your source database is a Non-CDB database, or a CDB database:
-
Non-CDB:
postupgrade_fixups.sql
-
CDB: Two different sets of scripts:
-
postupgrade_fixups.sql
: A consolidated script for all PDBs -
Multiple
postupgrade_fixups_pdbname.sql
scripts, wherepdbname
is the name of the PDB for which a script is generated: Individual scripts, which you run on specific PDBs.
-
Example 4-5 Example of Spooling Postupgrade Fixup Results for a Non-CDB Oracle Database
Set the system to spool results to a log file so you can read the output. However, do not spool to the admin
directory:
SQL> SPOOL postupgrade.log
SQL> @postupgrade_fixups.sql
SQL> SPOOL OFF
Turn off the spooling of script results to the log file:
SQL> SPOOL OFF
Example 4-6 Examples of Running Postupgrade Fixups Using catcon.pl On Linux, UNIX and Windows Systems
In the examples in this section, the catcon
command runs postupgrade_fixups.sql
in all the containers of a CDB database. Before you run this command, you must ensure that the operating system environment variables ORACLE_HOME and ORACLE_SID are set for UNIX and Linux environments, and that their equivalents are set for Windows environments. In the following examples, sales1
is the unique name for the target database.
Linux and UNIX environments:
$ORACLE_HOME/perl/bin/perl -I$ORACLE_HOME/perl/lib -I$ORACLE_HOME/rdbms/admin $ORACLE_HOME/rdbms/admin/catcon.pl -l /home/oracle/here/ -b postupg /cfgtoollogs/sales1/preupgrade/postupgrade_fixups.sql
Windows environments:
%ORACLE_HOME%\perl\bin\perl –I%ORACLE_HOME%\perl\lib –I%ORACLE_HOME%\rdbms\admin %ORACLE_HOME%\rdbms\admin\catcon.pl -l c:\tmp\logdir\ -b postupg c:\cfgtoollogs\sales1\preupgrade\postupgrade_fixups.sql
In this Windows example, the command option -l
creates logs under the file path c:/tmp/logdir/
, and places the output from the postupgrade scripts into that directory. The option -b
sets the prefix postupg
on the output files.
Note:
You must enter the catcon
parameters in the order that they are shown in these examples.
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. Starting with Oracle Database 12c release 2 (12.2), you gather statistics as a manual procedure after the upgrade, when you bring the database up in normal mode.
-
Non-CDB Oracle Database: Oracle recommends that you use the
DBMS_STATS.GATHER_DICTIONARY_STATS
procedure to gather these statistics. For example, enter the following SQL statement:SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
-
CDB (multitenant architecture) Oracle Database: Oracle recommends that you use
catcon
to gather Data Dictionary statistics across the entire multitenant architectureTo 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 namedSALES1
. 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.
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.
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 generate good execution plans, which can improve database performance. Failing to obtain representative statistics may lead to suboptimal execution plans, which may cause significant performance problems.
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 init.ora/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;
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. 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
.
To secure your database, create passwords in a secure fashion. If you have default passwords in your database, then change these passwords. By default, case sensitivity is enforce when you change 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
-
If the default security settings for Oracle Database 12c release 1 (12.1) and later are in place, then passwords must be at least eight characters, and passwords such as
welcome
andoracle
are not allowed. -
The
IGNORECASE
parameter is deprecated. Do not use this parameter. -
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 of DBA_USERS to find the USERNAME of accounts that only have the 10G password version, and do not have either the 11G or the 12C password version. Reset the password for any account that has only the 10G password version.
- 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.
See Also:
-
Oracle Database Security Guide for more information about password case sensitivity
-
Oracle Database Security Guide for more information about password strength
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 that user accounts have.
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
will be prevented from logging in.
Resetting User Passwords That Use the 10G Password Version
For better security, 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. This will enable 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 will 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.
Parent topic: Reset Passwords to Enforce Case-Sensitivity
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 12c 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.
Set Threshold Values for Tablespace Alerts
After an upgrade, thresholds for Oracle Database 12c database Tablespace Alerts are set to null, disabling the alerts.
You must identify tablespaces in the database that are candidates for monitoring, and you must set the appropriate threshold values for these tablespaces.
In newly-created Oracle Database 12c installations, the following values are used as defaults:
-
85% full warning
-
97% full critical
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.
Configure Oracle Data Guard Broker
InitialConnectIdentifier is replaced by DGConnectIdentifier, which affects upgrades from Oracle Database 10g.
The value of DGConnectIdentifier
is used for all Data Guard network traffic, all of the time. If you are upgrading an Oracle Database release 10g configuration, which requires you to first upgrade to Oracle Database 11g, then the value that exists for InitialConnectIdentifier
is retained as the new value for DGConnectIdentifier
for the database. When upgrading an Oracle Real Application Clusters (Oracle RAC) database, database administrators must ensure that the value for the InitialConnectIdentifier
property reaches all instances.
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
Migrate Your Upgraded Oracle Databases to Use Unified Auditing
To use the full facilities of unified auditing, you must manually migrate to unified auditing.
In unified auditing, all Oracle Database audit trails (SYS.AUD$
for the database audit trail, SYS.FGA_LOG$
for fine-grained auditing, DVYS.AUDIT_TRAIL$
for Database Vault, and so on) are combined into one single audit trail, which you can view by querying the UNIFIED_AUDIT_TRAIL
data dictionary view for single-instance installations and GV$UNIFIED_AUDIT_TRAIL
for Oracle Real Application Clusters environments.
- Understanding Unified Auditing Migration Process for Oracle Database
Decide which audit policies you want to use in the upgraded database. - Migrating to Unified Auditing for Oracle Database
Use this procedure for multitenant container (CDB) databases to migrate to unified auditing. - About Managing Earlier Audit Records After You Migrate to Unified Auditing
Review, archive, and purge earlier audit trails in preparation for using the unified audit trail. - Removing the Unified Auditing Functionality
Use this procedure to remove unified auditing, and to use mixed-mode audit. - Obtaining Documentation References if You Choose Not to Use Unified Auditing
You can access documentation listed here to obtain information about non-unified auditing.
See Also:
Oracle Database Security Guide for information about how the audit features have changed for this release
Understanding Unified Auditing Migration Process for Oracle Database
Decide which audit policies you want to use in the upgraded database.
By default, unified auditing is not enabled for upgraded databases. 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. For newly created databases, the mixed-mode method of unified auditing is enabled by default. After you complete the migration to unified auditing, traditional auditing is disabled, and the new audit records write to the unified audit trail.
To enable and configure the audit policies and how they are used, choose one method as follows:
-
Use the pure unified audit facility.
Migrate to unified auditing to use the full unified auditing facility features. After you complete the procedure to migrate 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 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.See Also:
-
Oracle Database Security Guide for information about the predefined audit policies
-
Oracle Database Security Guide for information about the ora_SecureConfig audit policy
-
Migrating to Unified Auditing for Oracle Database
Use this procedure for multitenant container (CDB) databases to migrate to unified auditing.
In CDB environments, perform the following procedure in the root
. The procedure migrates both the root
CDB, and any associated PDBs, to unified auditing.
-
Log in to SQL*Plus as user
SYS
with theSYSDBA
privilege.sqlplus sys as sysdba Enter password: password
In a Pluggable Databases 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 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.
-
Linux and UNIX
make -f ins_rdbms.mk uniaud_on ioracle ORACLE_HOME=$ORACLE_HOME
-
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 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
About Managing Earlier Audit Records After You Migrate to Unified Auditing
Review, archive, and purge earlier audit trails in preparation for using the unified audit trail.
After you complete the procedure to migrate Oracle Database to 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.
See Also:
-
"Archiving the Audit Trail" in Oracle Database Security Guide
-
"Purging Audit Trail Records" in Oracle Database Security Guide
Removing the Unified Auditing Functionality
Use this procedure to remove unified auditing, and to use mixed-mode audit.
After you have enabled your databases to use unified auditing, if you decide that you do not want unified auditing, then you can use this procedure to remove the unified auditing functionality. In this case, your database uses the mixed-mode audit facility.
-
Stop the database.
sqlplus sys as sysoper Enter password: password SQL> SHUTDOWN IMMEDIATE SQL> EXIT
For 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.
-
UNIX: Run the following command:
make -f ins_rdbms.mk uniaud_off ioracle ORACLE_HOME=$ORACLE_HOME
-
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 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 information about non-unified auditing.
After upgrading to Oracle Database 12c, if you choose not to change to unified auditing, then Oracle documentation and Oracle Technology Network provide information about traditional non-unified auditing.
-
Oracle Database Security Guide: This 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 Oracle Technology Network at the following URL:
-
From the
Downloads
menu, underDatabases
, selectDatabase 11g
. -
In the Downloads page, select the Documentation tab.
-
From the most recent Oracle Database 11g Release 2 (11.2) Documentation page, select the View Library link to display the home page of the Release 11g documentation set.
-
Under the Search field, select the Master Book List link.
-
Search for Security Guide.
-
Select either the HTML or the PDF link for this guide.
-
-
Oracle Database SQL Language Reference: This guide explains how to use the
AUDIT
andNOAUDIT
statements for both unified auditing and non-unified auditing environments. -
Oracle Database Reference: This guide explains how to use the initialization parameters and data dictionary views that are associated with a non-unified auditing environment. For a list of these, see Oracle Database Security Guide.
-
Oracle Database Vault Administrator's Guide: This guide explains how to configure auditing in a non-unified auditing environment for Database Vault.
-
Oracle Label Security Administrator's Guide: This guide explains how to configure auditing in a non-unified auditing environment for Oracle Label Security.
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 underAUDSYS
schema for this 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 AUDSYS
schema for this release improves the read performance of the unified audit trail.
Starting with this release, 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 you can transfer the unified audit records that are from that release to this new internal table for better read performance. It is not mandatory that you perform this transfer, but Oracle recommends that you do so because the new internal table improves the unified audit trail read performance. This is a one-time operation. All new unified audit records that are generated after the upgrade will be written to the new table. The table is a read-only table and any attempt to modify the metadata or data of this table is mandatorily audited.
After you upgrade to Oracle Database 12c release 12.2, if you have any unified audit records present in the UNIFIED_AUDIT_TRAIL
from the earlier release, then consider transferring them to this 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 OS spillover files (.bin
format). However, you can transfer the audit records in these OS 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 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 12c release. Compare the results, noting anomalies. Repeat the test upgrade as many times as necessary.
Test the newly upgraded production database with existing applications to verify that they operate properly with a new Oracle database. You also might test enhanced functions by adding available Oracle Database features. However, first ensure that the applications operate in the same manner as they did before the upgrade.