Posts

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.

 

 

 

You now can control the size of the batch of heartbeats that use Oracle Key Vault or OCI KMS (OCI Vault) for centralized key management. The HEARTBEAT_BATCH_SIZE initialization parameter, new with this release, enables you to set the heartbeat batch size. The duration of the heartbeat period defaults to 3 seconds.

This enhancement benefits the situation where you have a very large deployment of PDBs (for example, 1000) that use Oracle Key Vault. By setting the heartbeat batch size, you can stagger the heartbeats across batches of PDBs to ensure that for each batch a heartbeat can be completed for each PDB within the batch during the heartbeat period, and also ensure that PDB keys can be reliably fetched from an Oracle Key Vault server and cached in the persistent state.

For more information see:

https://docs.oracle.com/en/database/oracle/oracle-database/21/asoag/configuring-united-mode2.html#GUID-B4B3CCD1-B10B-4CA8-AA54-57A27AAB58D0