how to rollback ojvm patch?

Question

Bibhuti Wu · Answer

To roll back a patch that was applied to an Oracle Fusion Middleware Oracle home, use the opatch rollback command. To roll back multiple patches that were previously applied to an Oracle Fusion Middleware Oracle home, use the opatch nrollback command.

Sasha Ashok · Answer

Go to the Patching page of the database deployment on which you want to roll back a patch: Open the Oracle Database Cloud Service console. Click Rollback.

Grant Stabile · Answer

This article we are going to see steps used to apply the latest Oracle 19c Database Release Update 19.11.0.0.0 (Patch 32578972)
The environment is single instance database. Note:- 1)Review readme file on Patch 32578972 – Database Release Update 19.11.0.0
2)Download patch 32578972_190000_Linux-x86-64.zip
3)Make sure the opatch version is minimum 12.2.0.1.24 Step:-1 Download the Patch from oracle support
p32578972_190000_Linux-x86-64.zip
p6880880_122010_Linux-x86-64.zip Download from My Oracle Support patch 6880880 OPatch Utility You must use the OPatch utility version 12.2.0.1.24 or later to apply this patch. Oracle recommends that you use the latest released OPatch version for 19c, which is available for download from My Oracle Support patch 6880880 by selecting the 12.2.0.1.0 release. Reference:-
Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2) Step:-2 Copied the patch to DB Server [oracle@Prod22 patch]$ pwd
/u02/patch
[oracle@Prod22 patch]$ ls -lrt
total 0
-rwxrwxr-x. 1 oracle oinstall 0 Jun 18 20:03 p32578972_190000_Linux-x86-64.zip
-rwxrwxr-x. 1 oracle oinstall 0 Jun 18 20:07 p6880880_122010_Linux-x86-64.zip Step:-3 Upgrade Opatch Tool from 12.2.0.1.17 to 12.2.0.1.25 [oracle@Prod22 ~]$ export ORACLE_HOME=/u02/app/oracle/product/19.0.0/dbhome_1
[oracle@Prod22 ~]$ export PATH=/u02/app/oracle/product/19.0.0/dbhome_1/OPatch:$PATH
[oracle@Prod22 ~]$ opatch version
OPatch Version: 12.2.0.1.17 OPatch succeeded. [oracle@Prod22 ~]$ cd /u02/patch/
[oracle@Prod22 patch]$ ls -lrt
total 0
-rwxrwxr-x. 1 oracle oinstall 0 Jun 18 20:03 p32578972_190000_Linux-x86-64.zip
-rwxrwxr-x. 1 oracle oinstall 0 Jun 18 20:07 p6880880_122010_Linux-x86-64.zip
[oracle@Prod22 patch]$ cp p6880880_122010_Linux-x86-64.zip /u02/app/oracle/product/19.0.0/dbhome_1 [oracle@Prod22 patch]$ cd /u02/app/oracle/product/19.0.0/dbhome_1
[oracle@Prod22 dbhome_1]$ mv OPatch OPatch_bkp
[oracle@Prod22 dbhome_1]$ unzip p6880880_122010_Linux-x86-64.zip [oracle@Prod22 dbhome_1]$ opatch version
OPatch Version: 12.2.0.1.25 OPatch succeeded. Step:-4 Pre-Steps In Database Level Check the Patch status:- SET LINESIZE 500
SET PAGESIZE 1000
SET SERVEROUT ON
SET LONG 2000000
COLUMN action_time FORMAT A12
COLUMN action FORMAT A10
COLUMN comments FORMAT A30
COLUMN description FORMAT A60
COLUMN namespace FORMAT A20
COLUMN status FORMAT A10 SELECT TO_CHAR(action_time, ‘YYYY-MM-DD’) AS action_time,action,status,
description,patch_id FROM sys.dba_registry_sqlpatch ORDER by action_time; Check the list of components is valid:- col comp_id for a10
col version for a11
col status for a10
col comp_name for a37
select comp_id,comp_name,version,status from dba_registry; Identifying Invalid Objects before patching:- COLUMN object_name FORMAT A30
SELECT owner,
object_type,
object_name,
status
FROM dba_objects
WHERE status = ‘INVALID’
ORDER BY owner, object_type, object_name; Step 5:- Shutdown Database and Listener SQL> show parameter db_name NAME TYPE VALUE
———————————— ———– ——————————
db_name string     oradbwr SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down. [oracle@Prod22 ~]$ lsnrctl stop LSNRCTL for Linux: Version 19.0.0.0.0 – Production on 18-JUN-2021 21:24:56 Copyright (c) 1991, 2019, Oracle. All rights reserved. Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=Prod22)(PORT=1521)))
The command completed successfully Step:-6 Take Backup of ORACLE_HOME and Database (Rollback plan) cd /u02/patch
tar -cvf oracle_home_24Nov_2020.tar $ORACLE_HOME [oracle@Prod22 patch]$ ls -lrt
total 1589612
-rwxr-xr-x. 1 oracle oinstall 1503579785 Jun 18 21:12 p32578972_190000_Linux-x86-64.zip
-rw-r–r–. 1 oracle oinstall 52418048078 Jun 18 21:27 oracle_home_18JUL_2021.tar Step:-7 Apply RU patch on ORACLE_HOME 19c [oracle@Prod22 patch]$ pwd
/u02/patch
[oracle@Prod22 patch]$ unzip p32578972_190000_Linux-x86-64.zip [oracle@Prod22 patch]$ cd 32578972
[oracle@Prod22 32578972]$ ls -lrt
total 32
drwxr-xr-x. 4 oracle oinstall 63 Mar 9 19:46 32399816 -> OJVM Patch
drwxr-xr-x. 5 oracle oinstall 76 Apr 16 20:10 32545013 -> Database patch
-rw-rw-r–. 1 oracle oinstall 6555 Apr 20 17:22 PatchSearch.xml
-rw-r–r–. 1 oracle oinstall 22206 Apr 21 10:32 README.html First we are going to apply the patch for database. [oracle@Prod22 32578972]$ cd 32545013
[oracle@Prod22 32545013]$ export ORACLE_HOME=/u02/app/oracle/product/19.0.0/dbhome_1
[oracle@Prod22 32545013]$ export PATH=/u02/app/oracle/product/19.0.0/dbhome_1/OPatch:$PATH
[oracle@Prod22 32545013]$ opatch version
OPatch Version: 12.2.0.1.25 OPatch succeeded. [oracle@Prod22 32545013]$ opatch apply
Oracle Interim Patch Installer version 12.2.0.1.25
Copyright (c) 2021, Oracle Corporation. All rights reserved.
Oracle Home : /u02/app/oracle/product/19.0.0/dbhome_1
Central Inventory : /u02/app/oraInventory
from : /u02/app/oracle/product/19.0.0/dbhome_1/oraInst.loc
OPatch version : 12.2.0.1.25
OUI version : 12.2.0.7.0
Log file location : /u02/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2021-06-18_21-34-11PM_1.log
Verifying environment and performing prerequisite checks…
——————————————————————————–
Start OOP by Prereq process.
Launch OOP…
Oracle Interim Patch Installer version 12.2.0.1.25
Copyright (c) 2021, Oracle Corporation. All rights reserved.
Oracle Home : /u02/app/oracle/product/19.0.0/dbhome_1
Central Inventory : /u02/app/oraInventory
from : /u02/app/oracle/product/19.0.0/dbhome_1/oraInst.loc
OPatch version : 12.2.0.1.25
OUI version : 12.2.0.7.0
Log file location : /u02/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2021-06-18_21-35-12PM_1.log
Verifying environment and performing prerequisite checks…
OPatch continues with these patches: 32545013
Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = ‘/u02/app/oracle/product/19.0.0/dbhome_1’)
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files…
Applying interim patch ‘32545013’ to OH ‘/u02/app/oracle/product/19.0.0/dbhome_1’
ApplySession: Optional component(s) [ oracle.network.gsm, 19.0.0.0.0 ] , [ oracle.rdbms.ic, 19.0.0.0.0 ] , [ oracle.rdbms.tg4db2, 19.0.0.0.0 ] , [ oracle.tfa, 19.0.0.0.0 ] , [ oracle.options.olap.api, 19.0.0.0.0 ] , [ oracle.ons.cclient, 19.0.0.0.0 ] , [ oracle.options.olap, 19.0.0.0.0 ] , [ oracle.network.cman, 19.0.0.0.0 ] , [ oracle.oid.client, 19.0.0.0.0 ] , [ oracle.ons.eons.bwcompat, 19.0.0.0.0 ] , [ oracle.net.cman, 19.0.0.0.0 ] , [ oracle.xdk.companion, 19.0.0.0.0 ] , [ oracle.jdk, 1.8.0.191.0 ] not present in the Oracle Home or a higher version is found.
Patching component oracle.rdbms.rsf, 19.0.0.0.0…
Patching component oracle.rdbms.util, 19.0.0.0.0…
Patching component oracle.rdbms, 19.0.0.0.0…
Patching component oracle.assistants.acf, 19.0.0.0.0…
Patching component oracle.assistants.deconfig, 19.0.0.0.0…
Patching component oracle.assistants.server, 19.0.0.0.0…
Patching component oracle.buildtools.rsf, 19.0.0.0.0…
Patching component oracle.ctx, 19.0.0.0.0…
Patching component oracle.dbjava.ic, 19.0.0.0.0…
Patching component oracle.dbjava.jdbc, 19.0.0.0.0…
Patching component oracle.dbjava.ucp, 19.0.0.0.0…
Patching component oracle.dbtoolslistener, 19.0.0.0.0…
Patching component oracle.duma, 19.0.0.0.0…
Patching component oracle.javavm.client, 19.0.0.0.0…
Patching component oracle.ldap.owm, 19.0.0.0.0…
Patching component oracle.ldap.rsf, 19.0.0.0.0…
Patching component oracle.marvel, 19.0.0.0.0…
Patching component oracle.network.rsf, 19.0.0.0.0…
Patching component oracle.oracore.rsf, 19.0.0.0.0…
Patching component oracle.precomp.common.core, 19.0.0.0.0…
Patching component oracle.rdbms.dbscripts, 19.0.0.0.0…
Patching component oracle.rdbms.deconfig, 19.0.0.0.0…
Patching component oracle.rdbms.oci, 19.0.0.0.0…
Patching component oracle.rhp.db, 19.0.0.0.0…
Patching component oracle.sdo, 19.0.0.0.0…
Patching component oracle.sdo.locator.jrf, 19.0.0.0.0…
Patching component oracle.sqlplus, 19.0.0.0.0…
Patching component oracle.wwg.plsql, 19.0.0.0.0…
Patching component oracle.xdk, 19.0.0.0.0…
Patching component oracle.odbc, 19.0.0.0.0…
Patching component oracle.xdk.rsf, 19.0.0.0.0…
Patching component oracle.dbdev, 19.0.0.0.0…
Patching component oracle.xdk.parser.java, 19.0.0.0.0…
Patching component oracle.javavm.server, 19.0.0.0.0…
Patching component oracle.sdo.locator, 19.0.0.0.0…
Patching component oracle.rdbms.install.plugins, 19.0.0.0.0…
Patching component oracle.mgw.common, 19.0.0.0.0…
Patching component oracle.ons, 19.0.0.0.0…
Patching component oracle.ons.ic, 19.0.0.0.0…
Patching component oracle.ldap.rsf.ic, 19.0.0.0.0…
Patching component oracle.oraolap, 19.0.0.0.0…
Patching component oracle.ctx.atg, 19.0.0.0.0…
Patching component oracle.rdbms.install.common, 19.0.0.0.0…
Patching component oracle.sqlplus.ic, 19.0.0.0.0…
Patching component oracle.oraolap.dbscripts, 19.0.0.0.0…
Patching component oracle.xdk.xquery, 19.0.0.0.0…
Patching component oracle.network.listener, 19.0.0.0.0…
Patching component oracle.rdbms.dv, 19.0.0.0.0…
Patching component oracle.oraolap.api, 19.0.0.0.0…
Patching component oracle.rdbms.scheduler, 19.0.0.0.0…
Patching component oracle.rdbms.crs, 19.0.0.0.0…
Patching component oracle.ctx.rsf, 19.0.0.0.0…
Patching component oracle.ldap.security.osdt, 19.0.0.0.0…
Patching component oracle.precomp.rsf, 19.0.0.0.0…
Patching component oracle.ldap.client, 19.0.0.0.0…
Patching component oracle.network.client, 19.0.0.0.0…
Patching component oracle.rdbms.drdaas, 19.0.0.0.0…
Patching component oracle.rdbms.rman, 19.0.0.0.0…
Patching component oracle.rdbms.lbac, 19.0.0.0.0…
Patching component oracle.nlsrtl.rsf, 19.0.0.0.0…
Patching component oracle.ovm, 19.0.0.0.0…
Patching component oracle.rdbms.rsf.ic, 19.0.0.0.0…
Patching component oracle.precomp.common, 19.0.0.0.0…
Patching component oracle.precomp.lang, 19.0.0.0.0…
Patching component oracle.jdk, 1.8.0.201.0…
Patch 32545013 successfully applied.
Sub-set patch [29517242] has become inactive due to the application of a super-set patch [32545013].
Please refer to Doc ID 2161861.1 for any possible further required actions.
Log file location: /u02/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2021-06-18_21-35-12PM_1.log OPatch succeeded. Apply OJVM Patch in oracle 19c database. [oracle@Prod22 32545013]$ cd ..
[oracle@Prod22 32578972]$ ls -lrt
total 32
drwxr-xr-x. 4 oracle oinstall 63 Mar 9 19:46 32399816
drwxr-xr-x. 5 oracle oinstall 76 Apr 16 20:10 32545013
-rw-rw-r–. 1 oracle oinstall 6555 Apr 20 17:22 PatchSearch.xml
-rw-r–r–. 1 oracle oinstall 22206 Apr 21 10:32 README.html
[oracle@Prod22 32578972]$ cd 32399816
[oracle@Prod22 32399816]$ opatch apply
Oracle Interim Patch Installer version 12.2.0.1.25
Copyright (c) 2021, Oracle Corporation. All rights reserved.
Oracle Home : /u02/app/oracle/product/19.0.0/dbhome_1
Central Inventory : /u02/app/oraInventory
from : /u02/app/oracle/product/19.0.0/dbhome_1/oraInst.loc
OPatch version : 12.2.0.1.25
OUI version : 12.2.0.7.0
Log file location : /u02/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2021-06-18_21-55-39PM_1.log
Verifying environment and performing prerequisite checks…
OPatch continues with these patches: 32399816
Do you want to proceed? [y|n]
y
User Responded with: Y
All checks passed.
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = ‘/u02/app/oracle/product/19.0.0/dbhome_1’)
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files…
Applying interim patch ‘32399816’ to OH ‘/u02/app/oracle/product/19.0.0/dbhome_1’
Patching component oracle.javavm.server, 19.0.0.0.0…
Patching component oracle.javavm.server.core, 19.0.0.0.0…
Patching component oracle.rdbms.dbscripts, 19.0.0.0.0…
Patching component oracle.rdbms, 19.0.0.0.0…
Patching component oracle.javavm.client, 19.0.0.0.0…
Patch 32399816 successfully applied.
Log file location: /u02/app/oracle/product/19.0.0/dbhome_1/cfgtoollogs/opatch/opatch2021-06-18_21-55-39PM_1.log OPatch succeeded. Step:-8 Startup the Database and Listener [oracle@Prod22 32399816]$ lsnrctl start LSNRCTL for Linux: Version 19.0.0.0.0 – Production on 18-JUN-2021 21:59:39 Copyright (c) 1991, 2021, Oracle. All rights reserved. Starting /u02/app/oracle/product/19.0.0/dbhome_1/bin/tnslsnr: please wait… TNSLSNR for Linux: Version 19.0.0.0.0 – Production
System parameter file is /u02/app/oracle/product/19.0.0/dbhome_1/network/admin/listener.ora
Log messages written to /u02/app/oracle/diag/tnslsnr/Prod22/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=Prod22)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521))) Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=Prod22)(PORT=1521)))
STATUS of the LISTENER
————————
Alias LISTENER
Version TNSLSNR for Linux: Version 19.0.0.0.0 – Production
Start Date 18-JUN-2021 21:59:40
Uptime 0 days 0 hr. 0 min. 0 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u02/app/oracle/product/19.0.0/dbhome_1/network/admin/listener.ora
Listener Log File /u02/app/oracle/diag/tnslsnr/Prod22/listener/alert/log.xml
Listening Endpoints Summary…
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=Prod22)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary…
Service “oradbwr” has 1 instance(s).
Instance “oradbwr”, status UNKNOWN, has 1 handler(s) for this service…
The command completed successfully [oracle@Prod22 ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 – Production on Fri Jun 18 22:00:15 2021
Version 19.11.0.0.0 Copyright (c) 1982, 2020, Oracle. All rights reserved. Connected to an idle instance. SQL> startup upgrade -> to run datapatch command ORACLE instance started. Total System Global Area 2936008960 bytes
Fixed Size 8900864 bytes
Variable Size 402653184 bytes
Database Buffers 2516582400 bytes
Redo Buffers 7872512 bytes
Database mounted.
Database opened. Step:-9 Execute post patch steps and run datapatch command [oracle@Prod22 ~]$ cd $ORACLE_HOME/OPatch
[oracle@Prod22 OPatch]$ ./datapatch -verbose
SQL Patching tool version 19.11.0.0.0 Production on Fri Jun 18 22:02:53 2021
Copyright (c) 2012, 2021, Oracle. All rights reserved. Log file for this invocation: /u02/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_8419_2021_06_18_22_02_53/sqlpatch_invocation.log Connecting to database…OK
Gathering database info…done
Bootstrapping registry and package to current versions…done
Determining current state…done Current state of interim SQL patches:
Interim patch 32399816 (OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)):
Binary registry: Installed
SQL registry: Not installed Current state of release update SQL patches:
Binary registry:
19.11.0.0.0 Release_Update 210413004009: Installed
SQL registry:
Applied 19.3.0.0.0 Release_Update 190410122720 successfully on 17-JUN-21 11.10.59.010964 PM Adding patches to installation queue and performing prereq checks…done
Installation queue:
No interim patches need to be rolled back
Patch 32545013 (Database Release Update : 19.11.0.0.210420 (32545013)):
Apply from 19.3.0.0.0 Release_Update 190410122720 to 19.11.0.0.0 Release_Update 210413004009
The following interim patches will be applied:
32399816 (OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)) Installing patches…
Patch installation complete. Total patches installed: 2 Validating logfiles…done Automatic recompilation incomplete; run utlrp.sql to revalidate. Please refer to MOS Note 1609718.1 and/or the invocation log
/u02/app/oracle/cfgtoollogs/sqlpatch/sqlpatch_8419_2021_06_18_22_02_53/sqlpatch_invocation.log
for information on how to resolve the above errors. SQL Patching tool complete on Fri Jun 18 22:09:19 2021 Step:-10 After applying RU patch,Check the DBA_REGISTRY_SQLPATCH SQL> shut immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started. Total System Global Area 2936008960 bytes
Fixed Size 8900864 bytes
Variable Size 402653184 bytes
Database Buffers 2516582400 bytes
Redo Buffers 7872512 bytes
Database mounted.
Database opened. SET LINESIZE 500
SET PAGESIZE 1000
SET SERVEROUT ON
SET LONG 2000000
COLUMN action_time FORMAT A12
COLUMN action FORMAT A10
COLUMN patch_type FORMAT A10
COLUMN description FORMAT A32
COLUMN status FORMAT A10
COLUMN version FORMAT A10 select CON_ID,
TO_CHAR(action_time, ‘YYYY-MM-DD’) AS action_time,
PATCH_ID,
PATCH_TYPE,
ACTION,
DESCRIPTION,
SOURCE_VERSION,
TARGET_VERSION
from CDB_REGISTRY_SQLPATCH
order by CON_ID, action_time, patch_id;
spool off Step:-11 Check opatch lsinventory and list of patches applied in ORACLE_HOME [oracle@Prod22 OPatch]$ export ORACLE_HOME=/u02/app/oracle/product/19.0.0/dbhome_1
[oracle@Prod22 OPatch]$ export PATH=/u02/app/oracle/product/19.0.0/dbhome_1/OPatch:$PATH
[oracle@Prod22 OPatch]$ opatch lspatches
32399816;OJVM RELEASE UPDATE: 19.11.0.0.210420 (32399816)
32545013;Database Release Update : 19.11.0.0.210420 (32545013)
29585399;OCW RELEASE UPDATE 19.3.0.0.0 (29585399) OPatch succeeded. Step:12 Execute utlrp.sql to compile invalid objects [oracle@Prod22 OPatch]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 – Production on Fri Jun 18 22:19:33 2021
Version 19.11.0.0.0
Copyright (c) 1982, 2020, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 – Production
Version 19.11.0.0.0 SQL> @?/rdbms/admin/utlrp.sql Session altered. TIMESTAMP
——————————————————————————–
COMP_TIMESTAMP UTLRP_BGN 2021-06-18 22:19:46 DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC> objects in the database. Recompilation time is proportional to the
DOC> number of invalid objects in the database, so this command may take
DOC> a long time to execute on a database with a large number of invalid
DOC> objects.
DOC>
DOC> Use the following queries to track recompilation progress:
DOC>
DOC> 1. Query returning the number of invalid objects remaining. This
DOC> number should decrease with time.
DOC> SELECT COUNT(*) FROM obj$ WHERE status IN (4, 5, 6);
DOC>
DOC> 2. Query returning the number of objects compiled so far. This number
DOC> should increase with time.
DOC> SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;
DOC>
DOC> This script automatically chooses serial or parallel recompilation
DOC> based on the number of CPUs available (parameter cpu_count) multiplied
DOC> by the number of threads per CPU (parameter parallel_threads_per_cpu).
DOC> On RAC, this number is added across all RAC nodes.
DOC>
DOC> UTL_RECOMP uses DBMS_SCHEDULER to create jobs for parallel
DOC> recompilation. Jobs are created without instance affinity so that they
DOC> can migrate across RAC nodes. Use the following queries to verify
DOC> whether UTL_RECOMP jobs are being created and run correctly:
DOC>
DOC> 1. Query showing jobs created by UTL_RECOMP
DOC> SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like ‘UTL_RECOMP_SLAVE_%’;
DOC>
DOC> 2. Query showing UTL_RECOMP jobs that are running
DOC> SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like ‘UTL_RECOMP_SLAVE_%’;
DOC># PL/SQL procedure successfully completed.
TIMESTAMP
——————————————————————————–
COMP_TIMESTAMP UTLRP_END 2021-06-18 22:20:06 DOC> The following query reports the number of invalid objects.
DOC>
DOC> If the number is higher than expected, please examine the error
DOC> messages reported with each object (using SHOW ERRORS) to see if they
DOC> point to system misconfiguration or resource constraints that must be
DOC> fixed before attempting to recompile these objects.
DOC># OBJECTS WITH ERRORS
——————-
0 DOC> The following query reports the number of exceptions caught during
DOC> recompilation. If this number is non-zero, please query the error
DOC> messages in the table UTL_RECOMP_ERRORS to see if any of these errors
DOC> are due to misconfiguration or resource constraints that must be
DOC> fixed before objects can compile successfully.
DOC> Note: Typical compilation errors (due to coding errors) are not
DOC> logged into this table: they go into DBA_ERRORS instead.
DOC># ERRORS DURING RECOMPILATION
—————————
0
Function created.
PL/SQL procedure successfully completed.
Function dropped.
### validate_javavm caught -29548
PL/SQL procedure successfully completed. Check the list of components is valid:- col comp_id for a10
col version for a11
col status for a10
col comp_name for a37
select comp_id,comp_name,version,status from dba_registry; Connect with me:- Telegram App-> https://t.me/oracledbwr
LinkedIn-> https://www.linkedin.com/in/hariprasathdba
Facebook-> https://www.facebook.com/HariPrasathdba
FB Group-> https://www.facebook.com/groups/894402327369506/
FB Page -> https://www.facebook.com/dbahariprasath/?
Twitter -> https://twitter.com/oracledbwr

Yash tqglipy · Answer

[oracle@ranesh 30886680]$ opatch apply

Oracle Interim Patch Installer version 12.2.0.1.19

Oracle Home : /u01/app/oracle/product/12.2.0.1/db_1

Central Inventory : /u01/app/oraInventory

from : /u01/app/oracle/product/12.2.0.1/db_1/oraInst.loc

OPatch version : 12.2.0.1.19

OUI version : 12.2.0.1.4

Log file location : /u01/app/oracle/product/12.2.0.1/db_1/cfgtoollogs/opatch/opatch2021-02-18_15-43-47PM_1.log

Verifying environment and performing prerequisite checks…

OPatch continues with these patches: 30886680

Do you want to proceed? [y|n]

y

User Responded with: Y

All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.

(Oracle Home = ‘/u01/app/oracle/product/12.2.0.1/db_1’)

Is the local system ready for patching? [y|n] y

User Responded with: Y

Backing up files…

Applying interim patch ‘30886680’ to OH ‘/u01/app/oracle/product/12.2.0.1/db_1’

ApplySession: Optional component(s) [ oracle.swd.oui, 12.2.0.1.0 ] , [ oracle.oid.client, 12.2.0.1.0 ] , [ oracle.has.crs, 12.2.0.1.0 ] , [ oracle.rdbms.drdaas, 12.2.0.1.0 ] , [ oracle.ons.daemon, 12.2.0.1.0 ] , [ oracle.network.cman, 12.2.0.1.0 ] not present in the Oracle Home or a higher version is found.

Patching component oracle.rdbms.rsf, 12.2.0.1.0…

Patching component oracle.rdbms, 12.2.0.1.0…

Patching component oracle.rdbms.util, 12.2.0.1.0…

Patching component oracle.network.rsf, 12.2.0.1.0…

Patching component oracle.ctx, 12.2.0.1.0…

Patching component oracle.ctx.rsf, 12.2.0.1.0…

Patching component oracle.has.common.cvu, 12.2.0.1.0…

Patching component oracle.ldap.rsf, 12.2.0.1.0…

Patching component oracle.rdbms.dbscripts, 12.2.0.1.0…

Patching component oracle.rdbms.deconfig, 12.2.0.1.0…

Patching component oracle.rdbms.rsf.ic, 12.2.0.1.0…

Patching component oracle.sdo, 12.2.0.1.0…

Patching component oracle.sdo.locator, 12.2.0.1.0…

Patching component oracle.tfa, 12.2.0.1.0…

Patching component oracle.xdk.parser.java, 12.2.0.1.0…

Patching component oracle.rdbms.dv, 12.2.0.1.0…

Patching component oracle.precomp.rsf, 12.2.0.1.0…

Patching component oracle.rdbms.crs, 12.2.0.1.0…

Patching component oracle.rdbms.rman, 12.2.0.1.0…

Patching component oracle.rdbms.install.plugins, 12.2.0.1.0…

Patching component oracle.sqlplus, 12.2.0.1.0…

Patching component oracle.ons, 12.2.0.1.0…

Patching component oracle.oraolap, 12.2.0.1.0…

Patching component oracle.xdk.rsf, 12.2.0.1.0…

Patching component oracle.xdk, 12.2.0.1.0…

Patching component oracle.rdbms.lbac, 12.2.0.1.0…

Patching component oracle.sqlplus.ic, 12.2.0.1.0…

Patching component oracle.assistants.server, 12.2.0.1.0…

Patching component oracle.nlsrtl.rsf, 12.2.0.1.0…

Patching component oracle.assistants.deconfig, 12.2.0.1.0…

Patching component oracle.ldap.rsf.ic, 12.2.0.1.0…

Patching component oracle.ldap.client, 12.2.0.1.0…

Patching component oracle.assistants.acf, 12.2.0.1.0…

Patching component oracle.rdbms.oci, 12.2.0.1.0…

Patching component oracle.install.deinstalltool, 12.2.0.1.0…

Patching component oracle.oracore.rsf, 12.2.0.1.0…

Patching component oracle.precomp.lang, 12.2.0.1.0…

Patching component oracle.precomp.common, 12.2.0.1.0…

Patching component oracle.jdk, 1.8.0.91.0…

OPatch found the word “error” in the stderr of the make command.

Please look at this stderr. You can re-run this make command.

Stderr output:

chmod: changing permissions of `/u01/app/oracle/product/12.2.0.1/db_1/bin/extjobO’: Operation not permitted

make: [iextjob] Error 1 (ignored)

Patch 30886680 successfully applied.

OPatch Session completed with warnings.

Log file location: /u01/app/oracle/product/12.2.0.1/db_1/cfgtoollogs/opatch/opatch2021-02-18_15-43-47PM_1.log

OPatch completed with warnings.

Solution:

-rwsr-x—. 1 root oinstall 2251869 Apr 15 20:46 extjobO

-rwsr-x—. 1 root oinstall 2260593 Apr 15 20:46 jssu

Change permission of the above

[root@ranesh ~]# chown -R oracle:oinstall /u01/app/oracle/product/12.2.0.1/db_1

After giving permission

-rwxr-x—. 1 oracle oinstall 2251869 Apr 15 20:46 extjobO

-rwxr-x—. 1 oracle oinstall 2260593 Apr 15 20:46 jssu

Rollback the patch and apply the patch again

[oracle@ranesh 30886680]$ opatch rollback -id 30886680

Oracle Interim Patch Installer version 12.2.0.1.19

Oracle Home : /u01/app/oracle/product/12.2.0.1/db_1

Central Inventory : /u01/app/oraInventory

from : /u01/app/oracle/product/12.2.0.1/db_1/oraInst.loc

OPatch version : 12.2.0.1.19

OUI version : 12.2.0.1.4

Log file location : /u01/app/oracle/product/12.2.0.1/db_1/cfgtoollogs/opatch/opatch2021-02-18_16-12-41PM_1.log

Patches will be rolled back in the following order:

30886680

The following patch(es) will be rolled back: 30886680

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.

(Oracle Home = ‘/u01/app/oracle/product/12.2.0.1/db_1’)

Is the local system ready for patching? [y|n]

y

User Responded with: Y

Rolling back patch 30886680…

RollbackSession rolling back interim patch ‘30886680’ from OH ‘/u01/app/oracle/product/12.2.0.1/db_1’

Patching component oracle.rdbms.rsf, 12.2.0.1.0…

Deleting “picstk.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libplp12_pic.a”

Deleting “kolaet.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libgeneric12.a”

Deleting “skgrlib.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libgeneric12.a”

Deleting “kgcs.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libgeneric12.a”

Patching component oracle.rdbms, 12.2.0.1.0…

Patching component oracle.ctx, 12.2.0.1.0…

Patching component oracle.ctx.rsf, 12.2.0.1.0…

Patching component oracle.has.common.cvu, 12.2.0.1.0…

Patching component oracle.ldap.rsf, 12.2.0.1.0…

Patching component oracle.rdbms.dbscripts, 12.2.0.1.0…

Patching component oracle.rdbms.deconfig, 12.2.0.1.0…

Patching component oracle.rdbms.rsf.ic, 12.2.0.1.0…

Patching component oracle.sdo, 12.2.0.1.0…

Patching component oracle.sdo.locator, 12.2.0.1.0…

Patching component oracle.tfa, 12.2.0.1.0…

Patching component oracle.xdk.parser.java, 12.2.0.1.0…

Patching component oracle.rdbms.dv, 12.2.0.1.0…

Patching component oracle.precomp.rsf, 12.2.0.1.0…

Patching component oracle.rdbms.crs, 12.2.0.1.0…

Patching component oracle.rdbms.rman, 12.2.0.1.0…

Patching component oracle.rdbms.install.plugins, 12.2.0.1.0…

Patching component oracle.sqlplus, 12.2.0.1.0…

Patching component oracle.ons, 12.2.0.1.0…

Patching component oracle.oraolap, 12.2.0.1.0…

Patching component oracle.xdk.rsf, 12.2.0.1.0…

Deleting “jznmerge.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libxml12.a”

Deleting “jznprint.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libxml12.a”

Deleting “jznindex.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libxml12.a”

Deleting “jznevq.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libxml12.a”

Deleting “jzncsv.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libxml12.a”

Patching component oracle.xdk, 12.2.0.1.0…

Patching component oracle.rdbms.lbac, 12.2.0.1.0…

Patching component oracle.sqlplus.ic, 12.2.0.1.0…

Patching component oracle.assistants.server, 12.2.0.1.0…

Patching component oracle.nlsrtl.rsf, 12.2.0.1.0…

Patching component oracle.assistants.deconfig, 12.2.0.1.0…

Patching component oracle.ldap.rsf.ic, 12.2.0.1.0…

Patching component oracle.ldap.client, 12.2.0.1.0…

Patching component oracle.assistants.acf, 12.2.0.1.0…

Patching component oracle.rdbms.oci, 12.2.0.1.0…

Patching component oracle.install.deinstalltool, 12.2.0.1.0…

Patching component oracle.oracore.rsf, 12.2.0.1.0…

Deleting “slmeset.o” from archive “/u01/app/oracle/product/12.2.0.1/db_1/lib/libcore12.a”

Patching component oracle.precomp.lang, 12.2.0.1.0…

Patching component oracle.precomp.common, 12.2.0.1.0…

Patching component oracle.jdk, 1.8.0.91.0…

RollbackSession removing interim patch ‘30886680’ from inventory

Log file location: /u01/app/oracle/product/12.2.0.1/db_1/cfgtoollogs/opatch/opatch2021-02-18_16-12-41PM_1.log

OPatch succeeded.

[oracle@ranesh 30886680]$ opatch apply

Oracle Interim Patch Installer version 12.2.0.1.19

Oracle Home : /u01/app/oracle/product/12.2.0.1/db_1

Central Inventory : /u01/app/oraInventory

from : /u01/app/oracle/product/12.2.0.1/db_1/oraInst.loc

OPatch version : 12.2.0.1.19

OUI version : 12.2.0.1.4

Log file location : /u01/app/oracle/product/12.2.0.1/db_1/cfgtoollogs/opatch/opatch2021-02-18_16-20-57PM_1.log

Verifying environment and performing prerequisite checks…

OPatch continues with these patches: 30886680

Do you want to proceed? [y|n]

y

User Responded with: Y

All checks passed.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.

(Oracle Home = ‘/u01/app/oracle/product/12.2.0.1/db_1’)

Is the local system ready for patching? [y|n]

y

User Responded with: Y

Backing up files…

Applying interim patch ‘30886680’ to OH ‘/u01/app/oracle/product/12.2.0.1/db_1’

ApplySession: Optional component(s) [ oracle.swd.oui, 12.2.0.1.0 ] , [ oracle.oid.client, 12.2.0.1.0 ] , [ oracle.has.crs, 12.2.0.1.0 ] , [ oracle.rdbms.drdaas, 12.2.0.1.0 ] , [ oracle.ons.daemon, 12.2.0.1.0 ] , [ oracle.network.cman, 12.2.0.1.0 ] not present in the Oracle Home or a higher version is found.

Patching component oracle.rdbms.rsf, 12.2.0.1.0…

Patching component oracle.rdbms, 12.2.0.1.0…

Patching component oracle.rdbms.util, 12.2.0.1.0…

Patching component oracle.network.rsf, 12.2.0.1.0…

Patching component oracle.ctx, 12.2.0.1.0…

Patching component oracle.ctx.rsf, 12.2.0.1.0…

Patching component oracle.has.common.cvu, 12.2.0.1.0…

Patching component oracle.ldap.rsf, 12.2.0.1.0…

Patching component oracle.rdbms.dbscripts, 12.2.0.1.0…

Patching component oracle.rdbms.deconfig, 12.2.0.1.0…

Patching component oracle.rdbms.rsf.ic, 12.2.0.1.0…

Patching component oracle.sdo, 12.2.0.1.0…

Patching component oracle.sdo.locator, 12.2.0.1.0…

Patching component oracle.tfa, 12.2.0.1.0…

Patching component oracle.xdk.parser.java, 12.2.0.1.0…

Patching component oracle.rdbms.dv, 12.2.0.1.0…

Patching component oracle.precomp.rsf, 12.2.0.1.0…

Patching component oracle.rdbms.crs, 12.2.0.1.0…

Patching component oracle.rdbms.rman, 12.2.0.1.0…

Patching component oracle.rdbms.install.plugins, 12.2.0.1.0…

Patching component oracle.sqlplus, 12.2.0.1.0…

Patching component oracle.ons, 12.2.0.1.0…

Patching component oracle.oraolap, 12.2.0.1.0…

Patching component oracle.xdk.rsf, 12.2.0.1.0…

Patching component oracle.xdk, 12.2.0.1.0…

Patching component oracle.rdbms.lbac, 12.2.0.1.0…

Patching component oracle.sqlplus.ic, 12.2.0.1.0…

Patching component oracle.assistants.server, 12.2.0.1.0…

Patching component oracle.nlsrtl.rsf, 12.2.0.1.0…

Patching component oracle.assistants.deconfig, 12.2.0.1.0…

Patching component oracle.ldap.rsf.ic, 12.2.0.1.0…

Patching component oracle.ldap.client, 12.2.0.1.0…

Patching component oracle.assistants.acf, 12.2.0.1.0…

Patching component oracle.rdbms.oci, 12.2.0.1.0…

Patching component oracle.install.deinstalltool, 12.2.0.1.0…

Patching component oracle.oracore.rsf, 12.2.0.1.0…

Patching component oracle.precomp.lang, 12.2.0.1.0…

Patching component oracle.precomp.common, 12.2.0.1.0…

Patching component oracle.jdk, 1.8.0.91.0…

Patching component oracle.ldap.client, 12.2.0.1.0…

Patching component oracle.assistants.acf, 12.2.0.1.0…

Patching component oracle.rdbms.oci, 12.2.0.1.0…

Patching component oracle.install.deinstalltool, 12.2.0.1.0…

Patching component oracle.oracore.rsf, 12.2.0.1.0…

Patching component oracle.precomp.lang, 12.2.0.1.0…

Patching component oracle.precomp.common, 12.2.0.1.0…

Prashant Adhiyaman · Answer

On the other hand, a DBA shouldn’t resort to this unless there is a big impact on production applications since in a controlled IT change environments patches are usually applied first in test, QA, and then production and tested during these stages.

Also, another important information to mention is that Oracle is now releasing 2 patches ( 1 database, and 1 for JAVA component) every quarter. And the Java Component patch sometimes could lead to application problems with specific vendors so you need to be careful.

The following is general overview procedure in how to roll back a database patch (either for database or Java component), in my example I am referring to JULY 2015 Oracle release quarterly security patch. It’s very important that you read the (readme.html) accompanied with the patches downloaded.

1.de-installing the database patch:

lsnrctl stop LISTENER_TESTDB

sqlplus ‘/as sysdba’

SQL> shutdown immediate

**** Then run the Opatch utility to roll back the applied patch:

cd /app/oracle/downloaded_patch/july2015/20831110

opatch rollback -id 20831110

You should receive message similar “OPatch completed successfully”

If you have warning then you can check the logs in the directory specified in the output.

sqlplus ‘/as sysdba’

startup

cd $ORACLE_HOME/OPatch

./datapatch –verbose

*** To verify that the patch is rolled back successfully:

select * from dba_registry_sqlpatch where PATCH_ID=20831110;

Important Remark:

My recommendation is to use utilrip after that to re-compile all database objects:

@$ORACLE_HOME/rdbms/admin/utlrp.sql

Also checking that all database components are vaild post de-instillation:

Select * from dba_registry;

lsnrctl start LISTENER_TESTDB

********************************************************************

2.de-installing the Java patch:

lsnrctl stop LISTENER_TESTDB

SQL> shutdown immediate

*** Then run the Opatch utility to roll back the applied patch:

cd /app/oracle/downloaded_patch/july2015/JAVA/21068507

opatch rollback -id 21068507

sqlplus ‘/as sysdba’

SQL> startup upgrade ;

SQL>exit

cd $ORACLE_HOME/OPatch

./datapatch –verbose

You will receive a message similar to this:

Patch 21068507 rollback: SUCCESS

SQL> shutdown immediate;

SQL> startup

Don’t forget to startup the listener:

lsnrctl start LISTENER_TESTDB

*** To verify that the patch is rolled back successfully:

select * from dba_registry_sqlpatch where PATCH_ID=21068507;

Important Remark:

My recommendation is to use utilrip after that re-compile all database objects:

@$ORACLE_HOME/rdbms/admin/utlrp.sql

Also checking that all database components are valid post de-instillation:

Select * from dba_registry;

I hope this would help…..

Liikkanen Real · Answer

If you came hear hoping I was going to say there are valid reasons not to patch, you are out of luck. There is never a valid reason not to patch…

Instead this post is more about the general approach to patching. I’ve spent 22+ years writing about Oracle, including how to install it, but I’ve written practically nothing about how to patch a database. My stock answer is “read the patch notes”, and to be honest that is probably the best thing anyone can do. Although patching is a lot more standardized these days, it’s still worth reading the patch notes in case something unexpected happens. In this post I just want to talk about a few top-level things…

There are two big reasons for patching to a new ORACLE_HOME, or out-of-place patching.

There are some downsides though.

So should you follow the recommendation of patching to a new home or not? The answer as always is “it depends”.

The reduction in downtime for a single instance database is good, but if you are running RAC or Data Guard, this isn’t really an issue as the database remains online for most of the patching anyway. Having a quick fallback is great, but once again if you are running RAC or Data Guard this isn’t a big deal.

If you are running without RAC or Data Guard, you have made a decision that you can tolerate a certain level of downtime, so is taking the system down for an hour every quarter that big a deal? I’ve heard of folks who use RAC and/or Data Guard who still bring the whole system offline to patch, so the decision is probably going to be very different for people, depending on their environment and the constraints they are working with.

I hope you’re taking OS and database backups before patching. If something catastrophic happens, such that a rollback of the patch is not possible, you can recover your original home and database from the backups. Clearly this could take a long time, depending on how your backups are done, but the risk of loss is low. So the question is, can you tolerate the additional downtime?

You have to make a decision on the pros and cons of each approach for you, and of course deal with the consequences. If in doubt, go with the recommendation and patch to a new home.

Read-only Oracle homes were introduced in 18c (here) as an option, and are the default from Oracle 21c onward. One of the benefits of read-only Oracle homes is they make switching homes so much easier. You haven’t got to worry about copying configuration files between homes, as they are already located outside the home.

You have a choice between patching using a Release Update (RU), or a Release Update Revision (RUR). To put it simply, a RU contains not only the latest security patches and regression fixes, but may also include additional functionality, so the risk of introducing a new bug is higher. A RUR is just the security patches and regression fixes. Unlike the Critical Patch Updates (CPUs) of the past, that ran on endlessly, RURs are tied to specific RUs, so you will end up applying the RUs, but at a later date, when hopefully the bugs have been sorted by the RUR…

The folks at Oracle suggest applying the RUs, which is what I (currently) do. Some in the Oracle community suggest applying RURs is the safer strategy. If you look at the “Known Issues” for each RU, and the list of recommended one-off patches that should be applied after the RU, you can see why some people are nervous of going directly to RUs.

Once again, this comes down to you and your experience of patching with the feature set you use. If you are finding RUs are too problematic, go with the RUR approach. You can always change your mind at any time…

There’s a new kid on the block starting with 19.17 on Linux, which are monthly recommended patches (MRPs). They replace RURs. There are 6 MRPs per RU, with each MRP containing the RU and the current batch of recommended one-off patches, as documented in MOS Note 555.1.

I’m assuming these are rolling and standby-first patches, but I can’t confirm that yet.

Rolling patches can be applied one node at a time, so there are always database instances running, which means the database remains available for the whole of the patching process.

Release Updates (RUs) and Release Update Revisions (RURs) are always rolling patches, so it makes sense to take advantage of this approach. If you are applying one-off patches, these may not be rolling patches, so always check the patch notes to make sure.

Even when rolling patches are available, you can still make the decision to take the whole system offline to apply the patches. I’m not sure why you would want to do this, but the option is there for you.

Release Updates (RUs) and Release Update Revisions (RURs) are always standby-first patches. This gives you some flexibility on how you approach patching your system. Here are two scenarios with a two node Data Guard setup, where node 1 is the primary and node 2 is the standby.

Scenario 1 : Switchovers

Scenario 2 : No switchovers

Scenario 1 reduces downtime, as the primary is always running while the standby is having the binaries patched. Scenario 2 is simpler, but has a more extensive downtime as the primary is out of action while the binaries are being patched.

Remember, one-off patches may not be standby-first patches, so you may only have the option of scenario 2 when applying them. You have to read the patch notes.

Oracle 21c has simplified the OJVM patching situation. In previous releases the OJVM patches were completely separate. The grid infrastructure (GI) and database patches for 21c include the OJVM patches. For 19c the OJVM patches are still separate.

The separate 19c OJVM patches come with additional restrictions. They are not standby-first patches, and according to the patch notes, they can only be applied as RAC rolling patches if you use out-of-place patching.

Writing about patching is difficult, because everyone has a unique environment, and their own constraints placed on them by their business. I’ve always avoided writing too much about patching because I know it’s opening myself up for criticism. Whatever you say, someone will always disagree because of their unique situation, or demand yet another patching scenario because of their unique environment. You’re damned if you do, and damned if you don’t.

I’ve recently written a few patching articles for specific scenarios (here). I may add some more, but it’s not going to be a complete list, and don’t expect me to write articles about stuff I don’t use, like Exadata. These are purely meant as inspiration for new people. Ultimately, you need to read the patch notes and decide what is best for you!

If all this is too much hassle, you do have the option of moving your database to the cloud and letting them worry about patching it. 🙂

Read the patch notes!

Cheers

Tim…

Amira hdqhxb · Answer

I've had my fights with datapatch over the years, so I was curious by what I saw. Initially, you may suspect it's a bug, but I thought about the issue being with the OJVM patch, and how that particular patch is handled by datapatch.

Patching the Oracle database is a two-step process. First, the Oracle binaries are patched by the opatch command. After the Oracle home is patched, the datapatch script must be run on a database to apply any fixes that include post-patch SQL.

The OJVM patch in particular has been a thorn in the side of many DBAs. In database 19c and lower, a mismatch between the Java classes in the database and the files in the home will cause an ORA-29548 error to occur.

Operations performed by datapatch will create rows in the dba_registry_sqlpatch view, which goes back to Martin's original question. Why was the 19.9 OJVM patch listed twice when querying the view? I believe the hint lies in the data that we see from the ACTION_TIME column.

To confirm, I went to my lab system with the same 19.9 patch set installed:

I applied the 19.13 patches, as shown below:

Once I finished, I ran datapatch, which completed successfully. I checked the dba_registry_sqlpatch, and I saw the same thing:

Sure enough, we have 2 entries for the 19.9 OJVM patch. What could be causing this? If you look at the output from datapatch, you can see that the script performs a rollback of the 19.9 OJVM patch before applying the 19.13 version:

When checking dba_registry_sqlpatch there is another column, ACTION. This column shows what happened during the operation in euqstion. When I add this column to my query, it all comes in to focus:

Going back to Martin's original question, I believe this is what he is seeing. Checking the ACTION_TIME column in his results shows that the second operation on the 19.9 OJVM patch occurred three seconds before the operation on the 19.11 OJVM patch.

Ask Sawal

how to rollback ojvm patch?

Related Questions

More Questions

Contact