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.

You use the DBMS_RESOURCE_MANAGER package to create a CDB resource plan and define the directives for the plan. Then, from the root container of your CDB connects as the SYS user. Then, create a pending area using the CREATE_PENDING_AREA procedure. After the pending area has been completed, you use the CREATE_CDB_PLAN procedure to create the CDB resource plan. Next, create the CDB resource plan directives for the PDBs using the CREATE_CDB_PLAN_DIRECTIVE procedure. Each directive specifies how resources are allocated to a specific PDB. Finally, you validate the pending area and then submit it. This is done using the VALIDATE_PENDING_AREA and SUBMIT_PENDING_AREA procedures, respectively.


Oracle Sharding on Oracle Container Engine for Kubernetes (OKE) uses StatefulSet to provide stable, unique network identifiers and stable, persistent storage so you can create and manage your Oracle Sharding replica set natively in OKE with Oracle supported helm and chart templates. In addition, data is stored on persistent volume, so all the data is still there when a pod is recreated.
Related Resources:
Oracle Sharding on Docker GitHub Link: https://lnkd.in/dN2VUSXd
Oracle Sharding on OKE GitHub Link:  https://lnkd.in/du2gfxG6
OCR (Oracle Container Registry) Link: https://lnkd.in/dTebi76i