Datapatch is the new tool that enables automation of post-patch SQL actions for RDBMS patches.
and
Datapatch can be executed to complete post-patch SQL actions after the database is restarted following patch application.
For patches that do not have post-patch SQL actions to be performed, calling datapatch is a no-op.
For patches that do have post-patch SQL instructions to be invoked on the database instance, datapatch will automatically detect ALL pending actions (from one installed patch or multiple installed patches) and complete the actions as appropriate.
How does Oracle detect ALL pending actions?
Datapatch determines the requisite apply/rollback actions by matching an internal repository with the patch inventory.
When should datatach be invoked?
Datapatch should be invoked when the database is restarted after a patching session.
From 12.1.0.2 and onwards, Oracle Corporation points out that they have made some change to the datapatch utility. The most important in my opinion is that datapatch now assumes "the role of catbundle when applying bundles/PSU."
This means that
catbundle.sql has been deprecated and patch registry is maintained only in registry$sqlpatch.
Application of the PSU does not update registry$history table anymore.
The status for patch application is now entirely maintained in registry$sqlpatch
Here's an abbreviated output from using datapatch as part of applying Oracles latest PSU, Database Patch Set Update 12.1.0.2.170814 (Includes CPUJul2017):
1. Download and unpack the patch
[oracle@lx01oric software]$ unzip p26609783_121020_Linux-x86-64.zip2. Shutdown your oracle instance and the listener
3. Check for conflicts:
[oracle@lx01oric software]$ cd 26609783 oracle@lx01oric 26609783]$ opatch prereq CheckConflictAgainstOHWithDetail -ph ./ Oracle Interim Patch Installer version 12.1.0.1.3 Copyright (c) 2017, Oracle Corporation. All rights reserved. PREREQ session Oracle Home : /u01/oracle/product/db/12.1/12.1.0.2.0 Central Inventory : /u01/oraInventory from : /u01/oracle/product/db/12.1/12.1.0.2.0/oraInst.loc OPatch version : 12.1.0.1.3 OUI version : 12.1.0.2.0 Log file location : /u01/oracle/product/db/12.1/12.1.0.2.0/cfgtoollogs/opatch/opatch2017-09-06_13-41-14PM_1.log Invoking prereq "checkconflictagainstohwithdetail" Prereq "checkConflictAgainstOHWithDetail" passed. OPatch succeeded.4. Apply the patch:
[oracle@lx01oric 26609783]$ opatch apply Oracle Interim Patch Installer version 12.2.0.1.9 Copyright (c) 2017, Oracle Corporation. All rights reserved. Oracle Home : /u01/oracle/product/db/12.1/12.1.0.2.0 Central Inventory : /u01/oraInventory from : /u01/oracle/product/db/12.1/12.1.0.2.0/oraInst.loc OPatch version : 12.2.0.1.9 OUI version : 12.1.0.2.0 Log file location : /u01/oracle/product/db/12.1/12.1.0.2.0/cfgtoollogs/opatch/opatch2017-09-06_14-16-35PM_1.log Verifying environment and performing prerequisite checks... OPatch continues with these patches: 19769480 20299023 20831110 21359755 21948354 22291127 23054246 24006101 24732082 25171037 25755742 26609783 Do you want to proceed? [y|n] ... output abbreviated. Composite patch 26609783 successfully applied. Log file location: /u01/oracle/product/db/12.1/12.1.0.2.0/cfgtoollogs/opatch/opatch2017-09-06_14-16-35PM_1.log OPatch succeeded.
5. Start your database. When opened, execute datapatch:
[oracle@lx01oric] cd $ORACLE_HOME/OPatch [oracle@lx01oric OPatch]$ ./datapatch -verbose SQL Patching tool version 12.1.0.2.0 Production on Wed Sep 6 14:54:49 2017 Copyright (c) 2012, 2016, Oracle. All rights reserved. Log file for this invocation: /u01/oracle/cfgtoollogs/sqlpatch/sqlpatch_16001_2017_09_06_14_54_50/sqlpatch_invocation.log Connecting to database...OK Note: Datapatch will only apply or rollback SQL fixes for PDBs that are in an open state, no patches will be applied to closed PDBs. Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation (Doc ID 1585822.1) Bootstrapping registry and package to current versions... Bootstrap timed out after 240 seconds Retrying bootstrap after retryable errors....done Determining current state...done Current state of SQL patches: Bundle series PSU: ID 170814 in the binary registry and not installed in any PDB Adding patches to installation queue and performing prereq checks... Installation queue: For the following PDBs: CDB$ROOT PDB$SEED Nothing to roll back The following patches will be applied: 26609783 (DATABASE PATCH SET UPDATE 12.1.0.2.170814) Installing patches... Patch installation complete. Total patches installed: 2 Validating logfiles... Patch 26609783 apply (pdb CDB$ROOT): SUCCESS logfile: /u01/oracle/cfgtoollogs/sqlpatch/26609783/21481899/26609783_apply_CDBVEG_CDBROOT_2017Sep06_15_01_26.log (no errors) Patch 26609783 apply (pdb PDB$SEED): SUCCESS logfile: /u01/oracle/cfgtoollogs/sqlpatch/26609783/21481899/26609783_apply_CDBVEG_PDBSEED_2017Sep06_15_09_34.log (no errors) SQL Patching tool complete on Wed Sep 6 15:18:53 2017 [oracle@lx01oric OPatch]$ vi /u01/oracle/cfgtoollogs/sqlpatch/26609783/21481899/26609783_apply_CDBVEG_PDBSEED_2017Sep06_15_09_34.log6. If applicable, activate the OJVM Mitigation patch.
According to Oracle, this patch is applicable in "situations where the latest OJVM PSU cannot be installed immediately... The "Mitigation Patch" is an interim solution to protect against all currently known (Jul 2015) Oracle JavaVM security vulnerabilities in the database until such time as the OJVM PSU can be installed."
Since this is my situation, I install the mitigation patch:
[oracle@lx01oric 26609783]$ cd $ORACLE_HOME/rdbms/admin [oracle@lx01oric admin]$ sqlplus / as sysdba @dbmsjdev.sql [oracle@lx01oric admin]$ sqlplus / as sysdba SQL> exec dbms_java_dev.disable; PL/SQL procedure successfully completed. SQL>
Hello,
ReplyDeleteNeed you suggestion here ,we are applying the below patch in standby database which is open read only database,
29699220
|
|- README.txt
|
|- README.html
|
|- 29494060/-->getting error when the database is kept in open read only.
| –README.html
| —
|
|- 29774383/
error:
we got the below error which usually we have not faced before,please suggest.
Connecting to database…OK
DBD::Oracle::st execute failed: ORA-16000: database or pluggable database open for read-only access
ORA-06512: at “SYS.DBMS_LOCK”, line 245
ORA-06512: at “SYS.DBMS_LOCK”, line 252
ORA-06512: at “SYS.DBMS_LOCK”, line 305
ORA-06512: at line 4 (DBD ERROR: OCIStmtExecute) [for Statement “DECLARE
lockhandle VARCHAR2(128);
BEGIN
dbms_lock.allocate_unique(‘sqlpatch_lock’, lockhandle);
? := lockhandle;
? := dbms_lock.request(lockhandle, dbms_lock.x_mode, 1, false);
END;” with ParamValues: :p1=undef, :p2=undef] at /oradata/app/oracle/product/12.1.0.2/sqlpatch/sqlpatch.pm line 956.
My appologies for the lack of feedback. I didn't see this question until today.Bummer. You proably solved it by now. Anyway my thoughs are 1) the standby database should get the updates from the datapatch session from the primary, since they are SQL statements and, obviously 2) you cannot run datapatch against a read-only database.
DeleteRegards,
V
This comment has been removed by the author.
ReplyDelete