When patching an Oracle home, you might run into problems. OPatch might not behave as expected. It is helpful to know where to look for error messages or find additional information to pass on to Oracle Support if you want to log an SR for your problem. So OPatch maintains logs for apply, rollback, and lsinventory operations. The OPatch log files are located in the $ORACLE_HOME/cfgtoollogs/opatch. Each time you run OPatch, a new log file is created, and each log file is tagged with the operation’s timestamp. OPatch maintains an index of processed commands and log files in the opatch_history.txt file – and that is also in the above-mentioned $ORACLE_HOME/cfgtoollogs/opatch directory. So if you change the directory to $ORACLE_HOME/cfgtoollogs/opatch, you’ll see that every time you run OPatch, a log file is created with a date stamp. And then, at the bottom, you’ll see an opatch_history.txt file. look at the file, you’ll see a record of each time you ran the opatch apply, opatch rollback, or lsinventory command. The DBMS_QOPATCH package provides a PL/SQL or a SQL interface to view the installed database patches.

The package returns the patch and patch metadata information available as part of the “opatch lsinventory -xml” command in real-time. So it’s basically a way to see which patches are applied to your database home but from a PL/SQL or a SQL interface. So you basically get an XML-formatted return of your patch information. The DBMS_QOPATCH package allows users to query what patches are installed from SQL*Plus, write wrapper programs to create reports and do validation checks across multiple environments, and also to check patches installed on cluster nodes from a single location. If you log into SQL*Plus as the sys user and then perform select DBMS_QOPATCH.GET_OPATCH_LSINVENTORY from dual. And you’ll see just lots of XML information – which you can use an XML parser to make sense of it.

Starting in Oracle Database 12c, the multithreaded Oracle model enables specific Oracle processes to execute as operating system threads in separate address spaces. Setting up an Oracle database instance for using multi-process multi-thread architecture is done by starting up the Oracle database instance with the THREADED_EXECUTION initialization parameter set to TRUE.

The multi-process multi-thread model requires a password file for SYSDBA authentication while starting the database instance. Without using the SYS password

an  ORA-1031: insufficient privileges error will be triggered on startup.

When the THREADED_EXECUTION parameter is set to TRUE, you must set the DEDICATED_THROUGH_BROKER_LISTENER parameter to ON in your listener.ora file.

When that parameter is set, the listener knows that it should not spawn an OS process when a connect request is received; instead, it passes the request to the database so that a database thread is spawned and answers the connection.

 

 

 

Oracle Groundbreakers EMEA 2021 
Michigan Oracle Users Summit 2021 

Would you please download and install the one-off patch for your database version and OS for bugs not included in RU yet? If you do not find a patch for your specific version and OS from MOS, please open a Service Request with details on the patch needed. In addition, please include a list of patches already applied (opatch lsinventory -detail) and any other patches you intend to apply.

Some of the Optimizer bug fixes (not all) are controlled by the “_FIX_CONTROL” setting and are DISABLED by default in 19c when installed either through one-off backport or through RUs. Please refer to the corresponding Patch Readme carefully for one-off patches and enable the fixed control to activate the fix.

Example:

SQL> alter system set “_FIX_CONTROL”=”29302565:1”;

After applying DB RU 19.12.0.0.210720 or DB RUR 19.11.1.0.210720, you may notice that the Block Change Tracking (BCT) file is getting created of a size that is not in line with the database size.
Oracle recommends that you apply interim one-off Patch 33185773 to correct this problem(s) in the RU/RURs indicated above.
Note the fix for this issue has been included in the Oct2021 quarterly RU/RURs.

MV2OCI is a new tool is permitting the load data and migration from “on-premises” to Oracle Cloud Database leveraging on Oracle Data Pump and within one command. Data Pump Import lets you import data from Data Pump files residing on the Oracle Cloud Database node.
For more information see Doc ID 2514026.1.

For all offerings using Oracle Database 19c or later, if you are not licensed for Oracle Multitenant, then you may have up to 3 user-created PDBs in a given container database at any time. For all offerings using Oracle Database 12.1 through 18c, if you are not licensed for Oracle Multitenant, then the container database architecture is available in single-tenant mode, that is, with one user-created PDB, one user-created application root, and one user-created proxy PDB.

EE: Extra cost option; if you are licensed for Oracle Multitenant, then you can create up to 252 PDBs.

ODA and Exa: Extra cost option; if you are licensed for Oracle Multitenant, then you can create up to 4096 PDBs.

ExaCS/CC, DBCS EE-HP, and DBCS EE-EP: Included option; you can create up to 4096 PDBs.

If you want to perform a cross-platform upgrade, you need to know the restrictions and guidelines of this method.

When using DBUA or performing a manual upgrade for Oracle Database, you cannot directly migrate or transport data in a database on one operating system to another operating system. For example, you cannot migrate data in an Oracle database on Solaris to an Oracle 19c database on Windows using DBUA. You must follow procedures specific to your operating system platforms.

To see the platforms that support cross-platform data transport, run the following query using SQL*Plus:

SELECT * FROM V$TRANSPORTABLE_PLATFORM ORDER BY PLATFORM_NAME;
If the source platform and the target platform are of different endianness, then you cannot use the RMAN CONVERT DATABASE  command. This process requires both the source and target platform to be the same endian value. Your available options are Data Pump replication, Data Pump export/import, or Transportable Tablespace, with an RMAN CONVERT TABLESPACE. If the platforms are of the same endianness, then no conversion is necessary and data can be transported as if on the same platform.

For more information see:

Oracle Database Administrator’s Guide for a discussion of transporting data across platforms

Oracle Database Backup and Recovery User’s Guide for information on using the RMAN CONVERT DATABASE and RMAN CONVERT TABLESPACE commands