{"id":1436,"date":"2016-11-21T17:39:03","date_gmt":"2016-11-21T15:39:03","guid":{"rendered":"http:\/\/www.ludovicocaldara.net\/dba\/?p=1436"},"modified":"2020-08-18T16:19:18","modified_gmt":"2020-08-18T14:19:18","slug":"dbms_qopatch-datapatch-rollback-apply-force","status":"publish","type":"post","link":"https:\/\/www.ludovicocaldara.net\/dba\/dbms_qopatch-datapatch-rollback-apply-force\/","title":{"rendered":"DBMS_QOPATCH, datapatch, rollback, apply force"},"content":{"rendered":"<p>I am working for a customer on a quite big implementation of Cold Failover Cluster with Oracle Grid Infrastructure on Linux. I hope to have some material to publish soon about it! However, in this post I will be talking about patching the database in a cold-failover environment.<\/p>\n<p><strong>DISCLAIMER<\/strong>: I use massively scripts provided in this great blog post by Simon Pane:<\/p>\n<p><a href=\"https:\/\/www.pythian.com\/blog\/oracle-database-12c-patching-dbms_qopatch-opatch_xml_inv-and-datapatch\/\">https:\/\/www.pythian.com\/blog\/oracle-database-12c-patching-dbms_qopatch-opatch_xml_inv-and-datapatch\/<\/a><\/p>\n<p>Thank you Simon for sharing this \ud83d\ude42<\/p>\n<p><strong>Intro<\/strong><\/p>\n<p>We are not yet in the process of doing out-of-place patching; at the moment the customer prefers to do in-place patching:<\/p>\n<ul>\n<li>evacuate a node by relocating all the databases on other nodes<\/li>\n<li>patching the node binaries<\/li>\n<li>move back the databases and patch them with datapatch<\/li>\n<li>do the same for the remaining nodes<\/li>\n<\/ul>\n<p>I beg to disagree with this method, being a fan of having many patched golden copies distributed on all servers and patching the databases by just changing the ORACLE_HOME and running datapatch (like <a href=\"https:\/\/www.ludovicocaldara.net\/dba\/rhp-racsig-webcast-recording\/\">Rapid Home Provisioning<\/a> does). But, this is the situation today, and we have to live with it.<\/p>\n<p><strong>Initial situation<\/strong><\/p>\n<ul>\n<li>Server 1, 2 and 3: one-off 20139391 applied<\/li>\n<li>New database created<\/li>\n<\/ul>\n<p><a href=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch1.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1437\" src=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch1.png\" alt=\"cfc_qopatch1\" width=\"599\" height=\"210\" srcset=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch1.png 599w, https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch1-300x105.png 300w, https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch1-500x175.png 500w\" sizes=\"auto, (max-width: 599px) 100vw, 599px\" \/><\/a>When the DBCA creates a new database, in 12.1.0.2, it does not run datapatch by default, thus, the database does not have any patches installed.<\/p>\n<p>However, this specific one-off patch does not modify anything in the database (sql_patch=false)<\/p>\n<pre class=\"lang:plsql decode:true\">SQL&gt; -- Patches installed in the oracle home\r\nSQL&gt; r\r\n  1   with a as (select dbms_qopatch.get_opatch_lsinventory patch_output from dual)\r\n  2   select x.patch_id, x.patch_uid, x.description\r\n  3     from a,\r\n  4          xmltable('InventoryInstance\/patches\/*'\r\n  5             passing a.patch_output\r\n  6             columns\r\n  7                patch_id number path 'patchID',\r\n  8                patch_uid number path 'uniquePatchID',\r\n  9                description varchar2(80) path 'patchDescription',\r\n 10                sql_patch varchar2(8) path 'sqlPatch'\r\n 10          ) x\r\n 11 *\r\n\r\n  PATCH_ID  PATCH_UID DESCRIPTION               SQL_PATCH\r\n---------- ---------- ------------------------- ---------\r\n  20139391   18466820                           false\r\n\r\nSQL&gt; -- Patches installed in the database\r\nSQL&gt; select s.patch_id, s.patch_uid, s.description from dba_registry_sqlpatch s;\r\nno rows selected\r\n\r\nSQL&gt;\r\n<\/pre>\n<p>and the datapatch runs without touching the db:<\/p>\n<pre class=\"lang:plsql highlight:0 decode:true\">oracle1&gt; $ORACLE_HOME\/OPatch\/datapatch -verbose\r\nSQL Patching tool version 12.2.0.0.0 on Wed Nov  2 13:34:10 2016\r\nCopyright (c) 2014, Oracle.  All rights reserved.\r\n\r\nConnecting to database...OK\r\nDetermining current state...done\r\n\r\nCurrent state of SQL patches:\r\n\r\nAdding patches to installation queue and performing prereq checks...\r\nInstallation queue:\r\n  Nothing to roll back\r\n  Nothing to apply\r\n\r\nSQL Patching tool complete on Wed Nov  2 13:34:13 2016\r\noracle1&gt; \r\n<\/pre>\n<p>Next step: I evacuate the server 2 and patch it, then I relocate my database on it<\/p>\n<p><a href=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch2.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1438\" src=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch2.png\" alt=\"cfc_qopatch2\" width=\"601\" height=\"208\" srcset=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch2.png 601w, https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch2-300x104.png 300w, https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch2-500x173.png 500w\" sizes=\"auto, (max-width: 601px) 100vw, 601px\" \/><\/a><\/p>\n<pre class=\"lang:plsql highlight:0 decode:true\">oracle2&gt; $ORACLE_HOME\/OPatch\/opatch lspatches\r\n24340679;DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679)\r\n\r\nOPatch succeeded.\r\noracle2&gt;\r\noracle2&gt; crsctl relocate res theludot.db -n oracle2\r\nCRS-2673: Attempting to stop 'theludot.db' on 'oracle1'\r\nCRS-2677: Stop of 'theludot.db' on 'oracle1' succeeded\r\nCRS-2672: Attempting to start 'theludot.db' on 'oracle2'\r\nCRS-2676: Start of 'theludot.db' on 'oracle2' succeeded\r\noracle2&gt;\r\n<\/pre>\n<p>Now the database is not at the same level of the binaries and need to be patched:<\/p>\n<pre class=\"lang:plsql decode:true \">SQL&gt; -- Patches installed in the oracle home\r\nSQL&gt; r\r\n  1  with a as (select dbms_qopatch.get_opatch_lsinventory patch_output from dual)\r\n  2   select x.*\r\n  3     from a,\r\n  4   xmltable('InventoryInstance\/patches\/*'\r\n  5   passing a.patch_output\r\n  6   columns\r\n  7      patch_id number path 'patchID',\r\n  8      patch_uid number path 'uniquePatchID',\r\n  9      description varchar2(80) path 'patchDescription',\r\n 10    constituent number path 'constituent',\r\n 11    patch_type varchar2(20) path 'patchType',\r\n 12    rollbackable varchar2(20) path 'rollbackable',\r\n 13    sql_patch varchar2(8) path 'sqlPatch',\r\n 14    DBStartMode varchar2(10) path 'sqlPatchDatabaseStartupMode'\r\n 15*  ) x\r\n\r\n  PATCH_ID  PATCH_UID DESCRIPTION                                        CONSTITUENT PATCH_TYPE           ROLLBACKABLE SQL_PATC DBSTARTMOD\r\n---------- ---------- -------------------------------------------------- ----------- -------------------- ------------ -------- ----------\r\n  24340679   20646358 DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679)     24340679 singleton            true         true     normal\r\n  23144544   20247727 DATABASE BUNDLE PATCH: 12.1.0.2.160719 (23144544)     24340679 singleton            true         true     normal\r\n  22806133   19983161 DATABASE BUNDLE PATCH: 12.1.0.2.160419 (22806133)     24340679 singleton            true         true     normal\r\n  21949015   19576071 DATABASE BUNDLE PATCH: 12.1.0.2.160119 (21949015)     24340679 singleton            true         true     normal\r\n  21694919   19338504 DATABASE BUNDLE PATCH: 12.1.0.2.13 (21694919)         24340679 singleton            true         true     normal\r\n  21527488   19238856 DATABASE BUNDLE PATCH: 12.1.0.2.12 (21527488)         24340679 singleton            true         true     normal\r\n  21359749   19147148 DATABASE BUNDLE PATCH: 12.1.0.2.11 (21359749)         24340679 singleton            true         true     normal\r\n  21125181   18992109 DATABASE BUNDLE PATCH: 12.1.0.2.10 (21125181)         24340679 singleton            true         true     normal\r\n  20950328   18903184 DATABASE BUNDLE PATCH: 12.1.0.2.9 (20950328)          24340679 singleton            true         true     normal\r\n  20788771   18810992 DATABASE BUNDLE PATCH: 12.1.0.2.8 (20788771)          24340679 singleton            true         true     normal\r\n  20594149   18687526 DATABASE BUNDLE PATCH: 12.1.0.2.7 (20594149)          24340679 singleton            true         true     normal\r\n  20415006   18565812 DATABASE BUNDLE PATCH: 12.1.0.2.6 (20415006)          24340679 singleton            true         true     normal\r\n  20243804   18468778 DATABASE BUNDLE PATCH: 12.1.0.2.5 (20243804)          24340679 singleton            true         true     normal\r\n<\/pre>\n<p>The column CONSTITUENT is important here because it tells us what the parent patch_id is. This is the column that we have to check when we want to know if the patch has been applied on the database.<\/p>\n<pre class=\"lang:plsql highlight:0 decode:true\">oracle2&gt; $ORACLE_HOME\/OPatch\/datapatch -verbose\r\nSQL Patching tool version 12.1.0.2.0 on Wed Nov  2 13:47:49 2016\r\nCopyright (c) 2016, Oracle.  All rights reserved.\r\n\r\nLog file for this invocation: \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/sqlpatch_63956_2016_11_02_13_47_49\/sqlpatch_invocation.log\r\n\r\nConnecting to database...OK\r\nBootstrapping registry and package to current versions...done\r\nDetermining current state...done\r\n\r\nCurrent state of SQL patches:\r\nBundle series DBBP:\r\n  ID 161018 in the binary registry and not installed in the SQL registry\r\n\r\nAdding patches to installation queue and performing prereq checks...\r\nInstallation queue:\r\n  Nothing to roll back\r\n  The following patches will be applied:\r\n    24340679 (DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679))\r\n\r\nInstalling patches...\r\nPatch installation complete.  Total patches installed: 1\r\n\r\nValidating logfiles...\r\nPatch 24340679 apply: SUCCESS\r\n  logfile: \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/24340679\/20646358\/24340679_apply_THELUDOT_2016Nov02_13_48_03.log (no errors)\r\nSQL Patching tool complete on Wed Nov  2 13:49:51 2016\r\noracle2&gt;<\/pre>\n<p>Now the patch is visible inside the dba_registry_sqlpatch:<\/p>\n<pre class=\"lang:plsql decode:true\">SQL&gt; r\r\n  1* select patch_id, patch_uid, description, action_time, action, status, bundle_series, bundle_id  from dba_registry_sqlpatch\r\n\r\n  PATCH_ID  PATCH_UID DESCRIPTION                                        ACTION_TIME                    ACTION          STATUS   BUNDLE_SERIES  BUNDLE_ID\r\n---------- ---------- -------------------------------------------------- ------------------------------ --------------- -------- ------------- ----------\r\n  24340679   20646358 DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679)  02-NOV-16 01.49.51.664800 PM   APPLY           SUCCESS  DBBP              161018\r\n<\/pre>\n<p>Notice that the child patches are not listed in thie view.<\/p>\n<p><strong>Rolling back<\/strong><\/p>\n<p>Now, one node is patched, but the others are not. What happen if I relocate the patched database to a non-patched node?<\/p>\n<p><a href=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch3.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1440\" src=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch3.png\" alt=\"cfc_qopatch3\" width=\"603\" height=\"210\" srcset=\"https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch3.png 603w, https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch3-300x104.png 300w, https:\/\/www.ludovicocaldara.net\/dba\/wp-content\/uploads\/2016\/11\/cfc_qopatch3-500x174.png 500w\" sizes=\"auto, (max-width: 603px) 100vw, 603px\" \/><\/a><\/p>\n<pre class=\"lang:plsql highlight:0 decode:true\">oracle1&gt; crsctl relocate res theludot.db -n oracle1\r\nCRS-2673: Attempting to stop 'theludot.db' on 'oracle2'\r\nCRS-2677: Stop of 'theludot.db' on 'oracle2' succeeded\r\nCRS-2672: Attempting to start 'theludot.db' on 'oracle1'\r\nCRS-2676: Start of 'theludot.db' on 'oracle1' succeeded\r\noracle1&gt;<\/pre>\n<p>The patch is applied inside the database but not in the binaries!<\/p>\n<pre class=\"lang:plsql decode:true\">SQL&gt;  select patch_id, patch_uid, description, action_time, action, status, bundle_series, bundle_id\r\n  2   from dba_registry_sqlpatch;\r\n\r\n  PATCH_ID  PATCH_UID DESCRIPTION                                        ACTION_TIME                    ACTION          STATUS   BUNDLE_SERIES  BUNDLE_ID\r\n---------- ---------- -------------------------------------------------- ------------------------------ --------------- -------- ------------- ----------\r\n  24340679   20646358 DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679)  02.11.16 13:49:51.664800       APPLY           SUCCESS  DBBP              161018\r\n\r\nSQL&gt; r\r\n  1  with a as (select dbms_qopatch.get_opatch_lsinventory patch_output from dual)\r\n  2   select x.*\r\n  3     from a,\r\n  4   xmltable('InventoryInstance\/patches\/*'\r\n  5   passing a.patch_output\r\n  6   columns\r\n  7      patch_id number path 'patchID',\r\n  8      patch_uid number path 'uniquePatchID',\r\n  9      description varchar2(80) path 'patchDescription',\r\n 10    constituent number path 'constituent',\r\n 11    patch_type varchar2(20) path 'patchType',\r\n 12    rollbackable varchar2(20) path 'rollbackable',\r\n 13    sql_patch varchar2(8) path 'sqlPatch',\r\n 14    DBStartMode varchar2(10) path 'sqlPatchDatabaseStartupMode'\r\n 15* ) x\r\n\r\n  PATCH_ID  PATCH_UID DESCRIPTION                                        CONSTITUENT PATCH_TYPE           ROLLBACKABLE SQL_PATC DBSTARTMOD\r\n---------- ---------- -------------------------------------------------- ----------- -------------------- ------------ -------- ----------\r\n  20139391   18466820                                                                singleton            true         false\r\n<\/pre>\n<p>If I run datapatch again, the patch is rolled back:<\/p>\n<pre class=\"lang:plsql highlight:0 decode:true\">oracle1&gt; $ORACLE_HOME\/OPatch\/datapatch -verbose\r\nSQL Patching tool version 12.2.0.0.0 on Wed Nov  2 14:48:50 2016\r\nCopyright (c) 2014, Oracle.  All rights reserved.\r\n\r\nConnecting to database...OK\r\nDetermining current state...done\r\n\r\nCurrent state of SQL patches:\r\n\r\nAdding patches to installation queue and performing prereq checks...\r\nInstallation queue:\r\n  The following patches will be rolled back:\r\n    24340679 (DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679))\r\n  Nothing to apply\r\n\r\ncatcon: ALL catcon-related output will be written to \/tmp\/sqlpatch_catcon__catcon_24776.lst\r\ncatcon: See \/tmp\/sqlpatch_catcon_*.log files for output generated by scripts\r\ncatcon: See \/tmp\/sqlpatch_catcon__*.lst files for spool files, if any\r\nInstalling patches...\r\nPatch installation complete.  Total patches installed: 1\r\n\r\nValidating logfiles...\r\nPatch 24340679 rollback: SUCCESS\r\n  logfile: \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/24340679\/20646358\/24340679_rollback_THELUDOT_2016Nov. 02_14_48_53.log (no errors)\r\nSQL Patching tool complete on Wed Nov  2 14:48:53 2016\r\noracle1&gt;<\/pre>\n<p>The patch has been rolled back according to the datapatch, and the action is shown in the dba_registry_sqlpatch:<\/p>\n<pre class=\"lang:plsql decode:true\">SQL&gt; r\r\n  1   select patch_id, patch_uid, description, action_time, action, status, bundle_series, bundle_id\r\n  2*  from dba_registry_sqlpatch\r\n\r\n  PATCH_ID  PATCH_UID DESCRIPTION                                        ACTION_TIME                    ACTION          STATUS   BUNDLE_SERIES  BUNDLE_ID\r\n---------- ---------- -------------------------------------------------- ------------------------------ --------------- -------- ------------- ----------\r\n  24340679   20646358 DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679)  02.11.16 13:49:51.664800       APPLY           SUCCESS  DBBP              161018\r\n  24340679   20646358                                                    02.11.16 14:48:53.760632       ROLLBACK        SUCCESS\r\n<\/pre>\n<p>But if I look at the logfile, the patch had some errors:<\/p>\n<pre class=\"lang:plsql decode:true\">oracle1&gt; grep \"ORA-\\|PLS-\" \/tmp\/sqlpatch_catcon_0.log\r\nORA-20001: set_patch_metadata not called\r\nORA-06512: a \"SYS.DBMS_SQLPATCH\", ligne 621\r\nORA-06512: a ligne 2\r\nIGNORABLE ERRORS: ORA-02303\r\nIGNORABLE ERRORS: ORA-01418\r\nIGNORABLE ERRORS: ORA-01435\r\nIGNORABLE ERRORS: ORA-01435\r\nIGNORABLE ERRORS: ORA-01435\r\nIGNORABLE ERRORS: ORA-01435\r\nIGNORABLE ERRORS: ORA-01435\r\nIGNORABLE ERRORS: ORA-01435\r\nORA-01555: cliches trop vieux : rollback segment no , nomme \"\", trop petit\r\nORA-22924: cliche trop ancien\r\nORA-06512: a \"SYS.DBMS_SQLPATCH\", ligne 102\r\nORA-06512: a \"SYS.DBMS_SQLPATCH\", ligne 663\r\nORA-06512: a ligne 1\r\n<\/pre>\n<p>Indeed, the patch looks still there:<\/p>\n<pre class=\"lang:plsql decode:true \">SQL&gt; r\r\n  1  SELECT dbms_sqlpatch.sql_registry_state\r\n  2* FROM dual\r\n\r\nSQL_REGISTRY_STATE\r\n--------------------------------------------------------------------------------\r\n&lt;sql_registry_state&gt;\r\n  &lt;!-- Non bundle patches --&gt;\r\n  &lt;!-- Bundle patches --&gt;\r\n  &lt;patch bundle=\"yes\" id=\"24340679\" uid=\"20646358\" action=\"APPLY\" status=\"SUCCES\r\nS\" bundle_series=\"DBBP\" bundle_id=\"161018\"&gt;DBBP bundle patch 161018 (DATABASE BU\r\nNDLE PATCH: 12.1.0.2.161018 (24340679))&lt;\/patch&gt;\r\n&lt;\/sql_registry_state&gt;\r\n<\/pre>\n<p>If I try to run it again, it does nothing\/it fails saying the patch is not there:<\/p>\n<pre class=\"lang:plsql highlight:0 decode:true\">oracle1&gt; $ORACLE_HOME\/OPatch\/datapatch -rollback 24340679\r\nSQL Patching tool version 12.2.0.0.0 on Wed Nov  2 16:10:49 2016\r\nCopyright (c) 2014, Oracle.  All rights reserved.\r\n\r\nConnecting to database...OK\r\nDetermining current state...done\r\nAdding patches to installation queue and performing prereq checks...done\r\nInstallation queue:\r\n  Nothing to roll back\r\n  Nothing to apply\r\n\r\nSQL Patching tool complete on Wed Nov  2 16:10:51 2016\r\n\r\noracle1&gt; $ORACLE_HOME\/OPatch\/datapatch -rollback 24340679 -force\r\nSQL Patching tool version 12.2.0.0.0 on Wed Nov  2 16:11:01 2016\r\nCopyright (c) 2014, Oracle.  All rights reserved.\r\n\r\nConnecting to database...OK\r\nDetermining current state...done\r\n\r\nError: prereq checks failed!\r\n  patch 24340679: Could not determine unique patch ID for patch 24340679 because it is not present in the SQL registry\r\nPrereq check failed, exiting without installing any patches.\r\n\r\nPlease refer to MOS Note 1609718.1 for information on how to resolve the above errors.\r\n\r\nSQL Patching tool complete on Wed Nov  2 16:11:01 2016\r\n<\/pre>\n<p><strong>What does it say on the patched node?<\/strong><\/p>\n<pre class=\"lang:plsql highlight:0 decode:true\">oracle2&gt; crsctl relocate res theludot.db -n oracle2\r\nCRS-2673: Attempting to stop 'theludot.db' on 'oracle1'\r\nCRS-2677: Stop of 'theludot.db' on 'oracle1' succeeded\r\nCRS-2672: Attempting to start 'theludot.db' on 'oracle2'\r\nCRS-2676: Start of 'theludot.db' on 'oracle2' succeeded\r\noracle2&gt;\r\noracle2&gt; $ORACLE_HOME\/OPatch\/datapatch -verbose\r\nSQL Patching tool version 12.1.0.2.0 on Wed Nov\u00a0 2 16:15:36 2016\r\nCopyright (c) 2016, Oracle.\u00a0 All rights reserved.\r\n\r\nLog file for this invocation: \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/sqlpatch_7878_2016_11_02_16_15_36\/sqlpatch_invocation.log\r\n\r\nConnecting to database...OK\r\nBootstrapping registry and package to current versions...done\r\nDetermining current state...done\r\n\r\nCurrent state of SQL patches:\r\nBundle series DBBP:\r\n\u00a0 ID 161018 in the binary registry and ID 161018 in the SQL registry\r\n\r\nAdding patches to installation queue and performing prereq checks...\r\nInstallation queue:\r\n\u00a0 Nothing to roll back\r\n\u00a0 Nothing to apply\r\n\r\nSQL Patching tool complete on Wed Nov\u00a0 2 16:15:49 2016<\/pre>\n<p>Whaaat? datapatch there says that the patch IS in the registry and there&#8217;s nothing to do. Let&#8217;s try to force its apply again:<\/p>\n<pre class=\"lang:plsql decode:true\">oracle2&gt; $ORACLE_HOME\/OPatch\/datapatch -verbose -apply 24340679 -force\r\nSQL Patching tool version 12.1.0.2.0 on Wed Nov  2 16:17:40 2016\r\nCopyright (c) 2016, Oracle.  All rights reserved.\r\n\r\nLog file for this invocation: \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/sqlpatch_12726_2016_11_02_16_17_40\/sqlpatch_invocation.log\r\n\r\nConnecting to database...OK\r\nDetermining current state...done\r\n\r\nCurrent state of SQL patches:\r\nBundle series DBBP:\r\n  ID 161018 in the binary registry and ID 161018 in the SQL registry\r\n\r\nAdding patches to installation queue and performing prereq checks...\r\nInstallation queue:\r\n  Nothing to roll back\r\n  The following patches will be applied:\r\n    24340679 (DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679))\r\n\r\nInstalling patches...\r\nPatch installation complete.  Total patches installed: 1\r\n\r\nValidating logfiles...\r\nPatch 24340679 apply: SUCCESS\r\n  logfile: \/u01\/app\/oracle\/cfgtoollogs\/sqlpatch\/24340679\/20646358\/24340679_apply_THELUDOT_2016Nov02_16_17_40.log (no errors)\r\nSQL Patching tool complete on Wed Nov  2 16:18:50 2016\r\n<\/pre>\n<pre class=\"lang:plsql decode:true \">SQL&gt; r\r\n  1  select patch_id, patch_uid, description, action_time, action, status, bundle_series, bundle_id\r\n  2* from dba_registry_sqlpatch\r\n\r\n  PATCH_ID  PATCH_UID DESCRIPTION                                        ACTION_TIME                    ACTION          STATUS   BUNDLE_SERIES  BUNDLE_ID\r\n---------- ---------- -------------------------------------------------- ------------------------------ --------------- -------- ------------- ----------\r\n  24340679   20646358 DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679)  02-NOV-16 01.49.51.664800 PM   APPLY           SUCCESS  DBBP              161018\r\n  24340679   20646358                                                    02-NOV-16 02.48.53.760632 PM   ROLLBACK        SUCCESS\r\n  24340679   20646358 DATABASE BUNDLE PATCH: 12.1.0.2.161018 (24340679)  02-NOV-16 04.18.50.320745 PM   APPLY           SUCCESS  DBBP              161018\r\n<\/pre>\n<p><strong>Conclusion<\/strong><\/p>\n<p>I&#8217;m not sure whether it is safe to run the patched database in a non-patched Oracle Home. I guess it is time for a new SR \ud83d\ude42<\/p>\n<p>Meanwhile, we will try hard not to relocate the databases once they have been patched.<\/p>\n<p>Cheers<\/p>\n<p>&#8212;<\/p>\n<p>Ludo<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I am working for a customer on a quite big implementation of Cold Failover Cluster with Oracle Grid Infrastructure on Linux. I hope to have some material to publish soon about it! However, in this post I will be talking &hellip; <a href=\"https:\/\/www.ludovicocaldara.net\/dba\/dbms_qopatch-datapatch-rollback-apply-force\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[326,3,52,330,149,132],"tags":[],"class_list":["post-1436","post","type-post","status-publish","format-standard","hentry","category-oracle","category-oracledb","category-12c","category-oracle-inst-upg","category-oracle-rac","category-triblog"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/posts\/1436","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/comments?post=1436"}],"version-history":[{"count":5,"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/posts\/1436\/revisions"}],"predecessor-version":[{"id":1468,"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/posts\/1436\/revisions\/1468"}],"wp:attachment":[{"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/media?parent=1436"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/categories?post=1436"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ludovicocaldara.net\/dba\/wp-json\/wp\/v2\/tags?post=1436"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}