On this blog post I will write detailed steps on how to apply patches on bare metal/virtual machine DB systems and database homes by using DBCLI.
Yes, I enjoy the black screen 🙂
No, this is not the only option. You can also use Console and API’s.
This procedure is not applicable for Exadata DB systems.
1) Access to the Oracle Cloud Infrastructure Object Storage service, including connectivity to the applicable Swift endpoint for Object Storage. Oracle recommend using Service Gateway to enable this access.
2) /u01 FS with at least 15Gb of free space
3) Clusterware running
4) All DB system nodes running
Backup your database prior to the patch event.
Non Prod first
Test this patch on non prod (or test) server first
1) Update the CLI
2) Wait the job to complete
3) Check for installed and available patches
4) Display the latest patch versions available
5) Run pre check
dbcli update-server --precheck
run describe-job to check job status:
dbcli describe-job -i <jobId>
6) Update the server components. This step will patch GI.
Once successfully completed proceed with DB home patching.
7) List db homes
8) Run update home on select OH
dbcli update-dbhome -i <Id>
And check status with describe-job command:
You can find the DCS Logs at:
Under the hood dbcli relies on opatchauto so you can also check $ORACLE_HOME/cfgtoollogs/opatchauto directory for logs.
There is also a nice doc about troubleshooting in case something goes wrong.
CONFIGURE DEVICE TYPE disk PARALLELISM 2;
CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
RMAN always allocates the number of channels specified in PARALLELISM, using specifically configured channels if you have configured them and generic channels if you have not. Note that if you configure specific channels with numbers higher than the parallelism setting, RMAN will not use these channels.
$ORACLE_HOME/bin/dbupgrade -n 4
-n options specifies the number of processes to use for parallel operations.
Non-CDBs: The -n parameter specifies the number of SQL processes to use when upgrading the database.
Multitenant architecture databases (CDBs): The number of PDBs upgraded concurrently is controlled by the value of the -n parameter. Multiple PDB upgrades are processed together. Starting in Oracle Database 12c, the default value for multitenant architecture databases is the number of CPUs on your system. A cpu_count equal to 24 equates to a default value of 24 for -n.
Values for the -n parameter:
Non-CDBs: The maximum value for -n is 8. The minimum value is 1. The default value is 4.
Multitenant architecture databases (CDBs): The maximum value for -n is unlimited. The minimum value is 4. The maximum PDB upgrades running concurrently is the value of -n divided by the value of -N.
-N option specifies the number of SQL processors to use when upgrading PDBs.
For non-CDBs, this parameter is ignored.
For CDBs, the maximum value is 8. The minimum value is 1. The default value is 2.
So without specifying values for the parameters -n and -N (that is, accept the default value of -N, which is 2, and accept the default value of -n as the CPU_COUNT parameter value, which is 24).
The following parallel processing occurs:
12 PDBs are upgraded in parallel (CPU_COUNT divided by 2)
2 parallel processes run for each PDB
That is what came from the top of my head so it should have more parallel options 🙂
Thanks Tim to get the community together every year ! #ThanksOGB
I am a big fan of automation. I don’t like to do the same thing over and over, so after reading the post about purge/rotate oracle trace and log files from Fred Denis I started testing his scripts to implement them.
Everything was perfect until I run adrci purge to clean rdbms old files from Oracle 12.1 and got error DIA-49803.