{"id":674,"date":"2020-02-02T21:15:28","date_gmt":"2020-02-03T00:15:28","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=674"},"modified":"2020-02-02T21:15:28","modified_gmt":"2020-02-03T00:15:28","slug":"solving-mgmtdb-errors-during-18c-gi-ru-apply","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/","title":{"rendered":"Solving MGMTDB errors during 18c GI RU apply"},"content":{"rendered":"<p style=\"text-align: justify;\">Recently I executed the <a href=\"http:\/\/www.fernandosimon.com\/blog\/19c-grid-infrastructure-upgrade\/\" target=\"_blank\" rel=\"noopener noreferrer\">upgrade of Oracle GI to 19c version<\/a>, from 18.6.0.0 to 19.5.0.0 version. But one step that was not showed there was that, because of requirements, the GI was upgraded from 18.2.0.0 to 18.6.0.0. This upgrade is a just Release Update (RU) apply and <em>opatchauto<\/em> command.<\/p>\n<p style=\"text-align: justify;\">But during this upgrade, from 18.2 to 18.6, I faced (more than one time \u2013 5 to be precise) errors during the update because of the MGMTDB errors. I got these errors:<\/p>\n<ul style=\"text-align: justify;\">\n<li>ORA-12514, TNS: Listener does not currently know of service requested in connect descriptor<\/li>\n<li>ORA-01017: invalid username\/password; logon denied<\/li>\n<li>MGTCA-1005 : Could not connect to the GIMR.<\/li>\n<li>CRS-10407: (:CLSCRED1079:)Credential domain does not exist.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Here I will show how to solve these errors, how to identify if everything was fine and if you can continue. Be careful that it is an example, always open a support SR to identify the source of the error.<\/p>\n<p style=\"text-align: justify;\"><!--more Click here to read more...--><\/p>\n<h2 style=\"text-align: justify;\">RU and Patch Process<\/h2>\n<p style=\"text-align: justify;\">To apply 18c RU over GI it is simple, basically, it is needed to call <em>opatchauto<\/em> for every node. One example of correct execution is:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">[root@exa01vm01 ~]# opatchauto apply \/u01\/patches\/grid\/29301682 -oh \/u01\/app\/18.0.0\/grid\r\n\r\nOPatchauto session is initiated at Mon Jan 20 12:48:25 2020\r\n\r\nSystem initialization log file is \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchautodb\/systemconfig2020-01-20_12-48-48PM.log.\r\n\r\nSession log file is \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/opatchauto2020-01-20_12-49-44PM.log\r\nThe id for this session is RQ3F\r\n\r\nExecuting OPatch prereq operations to verify patch applicability on home \/u01\/app\/18.0.0\/grid\r\nPatch applicability verified successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\n\r\nBringing down CRS service on home \/u01\/app\/18.0.0\/grid\r\nCRS service brought down successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\n\r\nStart applying binary patch on home \/u01\/app\/18.0.0\/grid\r\nBinary patch applied successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\n\r\nStarting CRS service on home \/u01\/app\/18.0.0\/grid\r\nCRS service started successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\nOPatchAuto successful.\r\n\r\n--------------------------------Summary--------------------------------\r\n\r\nPatching is completed successfully. Please find the summary as follows:\r\n\r\nHost:exa01vm01\r\nCRS Home:\/u01\/app\/18.0.0\/grid\r\nVersion:18.0.0.0.0\r\nSummary:\r\n\r\n==Following patches were SUCCESSFULLY applied:\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/28435192\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-20_12-51-42PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/28547619\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-20_12-51-42PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29301631\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-20_12-51-42PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29301643\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-20_12-51-42PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29302264\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-20_12-51-42PM_1.log\r\n\r\n\r\n\r\nOPatchauto session completed at Mon Jan 20 13:00:01 2020\r\nTime taken to complete the session 11 minutes, 36 seconds\r\n[root@exa01vm01 ~]#\r\n\r\n\r\n\r\n####################################################\r\n#Execute in node 2\r\n####################################################\r\n\r\n\r\n[root@exa02vm01 ~]# opatchauto apply \/u01\/patches\/grid\/29301682 -oh \/u01\/app\/18.0.0\/grid\r\n\r\nOPatchauto session is initiated at Tue Jan 21 13:12:37 2020\r\n\r\nSystem initialization log file is \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchautodb\/systemconfig2020-01-21_01-12-51PM.log.\r\n\r\nSession log file is \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/opatchauto2020-01-21_01-13-37PM.log\r\nThe id for this session is NFXL\r\n\r\nExecuting OPatch prereq operations to verify patch applicability on home \/u01\/app\/18.0.0\/grid\r\nPatch applicability verified successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\n\r\nBringing down CRS service on home \/u01\/app\/18.0.0\/grid\r\nCRS service brought down successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\n\r\nStart applying binary patch on home \/u01\/app\/18.0.0\/grid\r\nBinary patch applied successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\n\r\nStarting CRS service on home \/u01\/app\/18.0.0\/grid\r\nCRS service started successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\nOPatchAuto successful.\r\n\r\n--------------------------------Summary--------------------------------\r\n\r\nPatching is completed successfully. Please find the summary as follows:\r\n\r\nHost:exa02vm01\r\nCRS Home:\/u01\/app\/18.0.0\/grid\r\nVersion:18.0.0.0.0\r\nSummary:\r\n\r\n==Following patches were SUCCESSFULLY applied:\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/28435192\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-21_13-15-58PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/28547619\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-21_13-15-58PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29301631\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-21_13-15-58PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29301643\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-21_13-15-58PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29302264\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-21_13-15-58PM_1.log\r\n\r\n\r\n\r\nOPatchauto session completed at Tue Jan 21 13:35:21 2020\r\nTime taken to complete the session 22 minutes, 44 seconds\r\n[root@exa02vm01 ~]#<\/pre>\n<p style=\"text-align: justify;\">As you can see, call in one node first, and after the second node. Basically during this process, the opatch will apply the binary updates in GI home, restart GI (to open with the new version), and apply needed SQL patches over MGMTDB and ASM.<\/p>\n<h2 style=\"text-align: justify;\">MGMTDB and errors<\/h2>\n<p style=\"text-align: justify;\">But some errors can occur during the apply, mainly for MGMTDB. These errors are usually related to the communication between MGMTDB and CRS resources (listener and others). Usually, these errors occur when applying the patch in the last node of the cluster because the MGMTDB is swapped from other nodes (until the last one) during the patch application.<\/p>\n<p style=\"text-align: justify;\">Some errors examples that I faced:<\/p>\n<p style=\"text-align: justify;\"><strong>ORA-12514, TNS: Listener does not currently know of service requested in connect descriptor<\/strong><\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">...\r\nCRS-4123: Oracle High Availability Services has been started.\r\nOracle Clusterware active version on the cluster is [18.0.0.0.0]. The cluster upgrade state is [NORMAL]. The cluster active patch level is [4127601284].\r\nSQL Patching tool version 18.0.0.0.0 Production on Wed Jan 15 13:57:08 2020\r\nCopyright (c) 2012, 2019, Oracle.  All rights reserved.\r\n\r\nLog file for this invocation: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/sqlpatch_360667_2020_01_15_13_57_08\/sqlpatch_invocation.log\r\n\r\nConnecting to database...OK\r\nGathering database info...done\r\n\r\nNote:  Datapatch will only apply or rollback SQL fixes for PDBs\r\n       that are in an open state, no patches will be applied to closed PDBs.\r\n       Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation\r\n       (Doc ID 1585822.1)\r\n\r\nBootstrapping registry and package to current versions...done\r\nDetermining current state...done\r\n\r\nCurrent state of interim SQL patches:\r\n  No interim patches found\r\n\r\nCurrent state of release update SQL patches:\r\n  Binary registry:\r\n    18.6.0.0.0 Release_Update 1903190102: Installed\r\n  PDB CDB$ROOT:\r\n    Applied 18.2.0.0.0 Release_Update 1804041635 successfully on 02-OCT-18 03.11.47.950696 PM\r\n  PDB PDB$SEED:\r\n    Applied 18.2.0.0.0 Release_Update 1804041635 successfully on 02-OCT-18 03.16.34.680672 PM\r\n\r\nAdding patches to installation queue and performing prereq checks...done\r\nInstallation queue:\r\n  For the following PDBs: CDB$ROOT PDB$SEED\r\n    No interim patches need to be rolled back\r\n    Patch 29301631 (Database Release Update : 18.6.0.0.190416 (29301631)):\r\n      Apply from 18.2.0.0.0 Release_Update 1804041635 to 18.6.0.0.0 Release_Update 1903190102\r\n    No interim patches need to be applied\r\n\r\nInstalling patches...\r\nPatch installation complete.  Total patches installed: 2\r\n\r\nValidating logfiles...done\r\nPatch 29301631 apply (pdb CDB$ROOT): SUCCESS\r\n  logfile: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/29301631\/22832106\/29301631_apply__MGMTDB_CDBROOT_2020Jan15_13_58_14.log (no errors)\r\nPatch 29301631 apply (pdb PDB$SEED): SUCCESS\r\n  logfile: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/29301631\/22832106\/29301631_apply__MGMTDB_PDBSEED_2020Jan15_14_01_22.log (no errors)\r\nSQL Patching tool complete on Wed Jan 15 14:02:41 2020\r\nMGTCA-1005 : Could not connect to the GIMR.\r\n\r\nListener refused the connection with the following error:\r\n\r\nORA-12514, TNS:listener does not currently know of service requested in connect descriptor\r\n\r\n\r\n\r\n2020\/01\/15 14:02:49 CLSRSC-180: An error occurred while executing the command '\/u01\/app\/18.0.0\/grid\/bin\/mgmtca applysql'\r\n\r\nAfter fixing the cause of failure Run opatchauto resume\r\n\r\n]\r\nOPATCHAUTO-68061: The orchestration engine failed.\r\nOPATCHAUTO-68061: The orchestration engine failed with return code 1\r\nOPATCHAUTO-68061: Check the log for more details.\r\nOPatchAuto failed.\r\n\r\nOPatchauto session completed at Wed Jan 15 14:02:50 2020\r\nTime taken to complete the session 28 minutes, 34 seconds\r\n\r\n opatchauto failed with error code 42\r\n[root@exa03vm02 ~]#<\/pre>\n<p style=\"text-align: justify;\"><strong>ORA-01017: invalid username\/password; logon denied<\/strong><\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">CRS-4123: Oracle High Availability Services has been started.\r\nOracle Clusterware active version on the cluster is [18.0.0.0.0]. The cluster upgrade state is [NORMAL]. The cluster active patch level is [4127601284].\r\nSQL Patching tool version 18.0.0.0.0 Production on Fri Nov 29 10:32:41 2019\r\nCopyright (c) 2012, 2019, Oracle.  All rights reserved.\r\n\r\nLog file for this invocation: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/sqlpatch_128123_2019_11_29_10_32_41\/sqlpatch_invocation.log\r\n\r\nConnecting to database...OK\r\nGathering database info...done\r\n\r\nNote:  Datapatch will only apply or rollback SQL fixes for PDBs\r\n       that are in an open state, no patches will be applied to closed PDBs.\r\n       Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation\r\n       (Doc ID 1585822.1)\r\n\r\nBootstrapping registry and package to current versions...done\r\nDetermining current state...done\r\n\r\nCurrent state of interim SQL patches:\r\n  No interim patches found\r\n\r\nCurrent state of release update SQL patches:\r\n  Binary registry:\r\n    18.6.0.0.0 Release_Update 1903190102: Installed\r\n  PDB CDB$ROOT:\r\n    Applied 18.2.0.0.0 Release_Update 1804041635 successfully on 02-OCT-18 01.32.26.561113 PM\r\n  PDB GIMR_DSCREP_10:\r\n    Applied 18.2.0.0.0 Release_Update 1804041635 successfully on 02-OCT-18 01.37.12.290147 PM\r\n  PDB PDB$SEED:\r\n    Applied 18.2.0.0.0 Release_Update 1804041635 successfully on 02-OCT-18 01.37.12.290147 PM\r\n\r\nAdding patches to installation queue and performing prereq checks...done\r\nInstallation queue:\r\n  For the following PDBs: CDB$ROOT PDB$SEED GIMR_DSCREP_10\r\n    No interim patches need to be rolled back\r\n    Patch 29301631 (Database Release Update : 18.6.0.0.190416 (29301631)):\r\n      Apply from 18.2.0.0.0 Release_Update 1804041635 to 18.6.0.0.0 Release_Update 1903190102\r\n    No interim patches need to be applied\r\n\r\nInstalling patches...\r\nPatch installation complete.  Total patches installed: 3\r\n\r\nValidating logfiles...done\r\nPatch 29301631 apply (pdb CDB$ROOT): SUCCESS\r\n  logfile: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/29301631\/22832106\/29301631_apply__MGMTDB_CDBROOT_2019Nov29_10_33_45.log (no errors)\r\nPatch 29301631 apply (pdb PDB$SEED): SUCCESS\r\n  logfile: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/29301631\/22832106\/29301631_apply__MGMTDB_PDBSEED_2019Nov29_10_36_02.log (no errors)\r\nPatch 29301631 apply (pdb GIMR_DSCREP_10): SUCCESS\r\n  logfile: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/29301631\/22832106\/29301631_apply__MGMTDB_GIMR_DSCREP_10_2019Nov29_10_36_02.log (no errors)\r\nSQL Patching tool complete on Fri Nov 29 10:38:04 2019\r\nMGTCA-1005 : Could not connect to the GIMR.\r\n\r\nORA-01017: invalid username\/password; logon denied\r\n\r\n\r\n\r\n2019\/11\/29 10:38:13 CLSRSC-180: An error occurred while executing the command '\/u01\/app\/18.0.0\/grid\/bin\/mgmtca applysql'\r\n\r\nAfter fixing the cause of failure Run opatchauto resume\r\n\r\n]\r\nOPATCHAUTO-68061: The orchestration engine failed.\r\nOPATCHAUTO-68061: The orchestration engine failed with return code 1\r\nOPATCHAUTO-68061: Check the log for more details.\r\nOPatchAuto failed.\r\n\r\nOPatchauto session completed at Fri Nov 29 10:38:15 2019\r\nTime taken to complete the session 26 minutes, 48 seconds\r\n\r\n opatchauto failed with error code 42\r\n[root@exa01vm02 ~]#<\/pre>\n<p style=\"text-align: justify;\">And inside of the opatch log you can reach\/see something like:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">SQL Patching tool complete on Fri Nov 29 10:44:09 2019\r\nMGTCA-1005 : Could not connect to the GIMR.\r\n\r\nORA-01017: invalid username\/password; logon denied\r\n\r\n\r\n\r\n2019\/11\/29 10:44:18 CLSRSC-180: An error occurred while executing the command '\/u01\/app\/18.0.0\/grid\/bin\/mgmtca applysql'\r\n\r\nAfter fixing the cause of failure Run opatchauto resume\r\n\r\n]]. Failures:\r\nOPATCHAUTO-68067: Check the details to determine the cause of the failure.\r\n        at com.oracle.glcm.patch.auto.action.PatchActionExecutor.execute(PatchActionExecutor.java:172)\r\n        at com.oracle.glcm.patch.auto.wizard.silent.tasks.PatchActionTask.execute(PatchActionTask.java:102)\r\n        ... 2 more\r\n2019-11-29 10:44:19,660 INFO  [1] com.oracle.glcm.patch.auto.db.integration.model.productsupport.DBBaseProductSupport - Space available after session: 29898 MB\r\n2019-11-29 10:44:19,728 SEVERE [1] com.oracle.glcm.patch.auto.OPatchAuto - OPatchAuto failed.\r\ncom.oracle.glcm.patch.auto.OPatchAutoException: OPATCHAUTO-68061: The orchestration engine failed.\r\nOPATCHAUTO-68061: The orchestration engine failed with return code 1\r\nOPATCHAUTO-68061: Check the log for more details.\r\n        at com.oracle.glcm.patch.auto.OrchestrationEngineImpl.orchestrate(OrchestrationEngineImpl.java:40)\r\n        at com.oracle.glcm.patch.auto.OPatchAuto.orchestrate(OPatchAuto.java:858)\r\n        at com.oracle.glcm.patch.auto.OPatchAuto.orchestrate(OPatchAuto.java:398)\r\n        at com.oracle.glcm.patch.auto.OPatchAuto.orchestrate(OPatchAuto.java:344)\r\n        at com.oracle.glcm.patch.auto.OPatchAuto.main(OPatchAuto.java:212)\r\n2019-11-29 10:44:19,729 INFO  [1] com.oracle.cie.common.util.reporting.CommonReporter - Reporting console output : Message{id='null', message='OPATCHAUTO-68061: The orchestration engine failed.\r\nOPATCHAUTO-68061: The orchestration engine failed with return code 1\r\nOPATCHAUTO-68061: Check the log for more details.'}\r\n2019-11-29 10:44:19,729 INFO  [1] com.oracle.cie.common.util.reporting.CommonReporter - Reporting console output : Message{id='null', message='OPatchAuto failed.'}\r\n^C\r\n[root@exa01vm02 ~]#<\/pre>\n<p style=\"text-align: justify;\">But the common in all cases occurred during the \u201c<em>\/u01\/app\/18.0.0\/grid\/bin\/mgmtca applysql<\/em>\u201d call because the opatch detected that is need to apply the patch over MGMTDB, and tried to apply (and reached the error).<\/p>\n<h2 style=\"text-align: justify;\">Solving the issue<\/h2>\n<p style=\"text-align: justify;\">After some dig in the web about the error and MOS\/Metalink search, nothing was found. No error, hint or something related. Even after one SR opened the report was always the same: inconclusive and not relevant to build a fix. <strong>But for all one solution\/workaround can be applied and worked every time.<\/strong><\/p>\n<p style=\"text-align: justify;\">Before, just to show that if you look inside the MGMTDB itself you can see that the patch was applied correctly:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">[grid@exa01vm02 -MGMTDB]$ sqlplus \/ as sysdba\r\n\r\nSQL*Plus: Release 18.0.0.0.0 - Production on Thu Nov 14 09:19:05 2019\r\nVersion 18.6.0.0.0\r\n\r\nCopyright (c) 1982, 2018, Oracle.  All rights reserved.\r\n\r\n\r\nConnected to:\r\nOracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\r\nVersion 18.6.0.0.0\r\n\r\nSQL&gt; show pdbs\r\n\r\n    CON_ID CON_NAME                       OPEN MODE  RESTRICTED\r\n---------- ------------------------------ ---------- ----------\r\n         2 PDB$SEED                       READ ONLY  NO\r\nSQL&gt; select instance_name from v$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\n-MGMTDB\r\n\r\nSQL&gt; exit\r\nDisconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\r\nVersion 18.6.0.0.0\r\n[grid@exa01vm02 -MGMTDB]$\r\n[grid@exa01vm02 -MGMTDB]$\r\n[grid@exa01vm02 -MGMTDB]$ cd $ORACLE_HOME\/OPatch\r\n[grid@exa01vm02 -MGMTDB]$ .\/datapatch -verbose\r\nSQL Patching tool version 18.0.0.0.0 Production on Thu Nov 14 09:21:33 2019\r\nCopyright (c) 2012, 2019, Oracle.  All rights reserved.\r\n\r\nLog file for this invocation: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/sqlpatch_242627_2019_11_14_09_21_33\/sqlpatch_invocation.log\r\n\r\nConnecting to database...OK\r\nGathering database info...done\r\n\r\nNote:  Datapatch will only apply or rollback SQL fixes for PDBs\r\n       that are in an open state, no patches will be applied to closed PDBs.\r\n       Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation\r\n       (Doc ID 1585822.1)\r\n\r\nBootstrapping registry and package to current versions...done\r\nDetermining current state...done\r\n\r\nCurrent state of interim SQL patches:\r\n  No interim patches found\r\n\r\nCurrent state of release update SQL patches:\r\n  Binary registry:\r\n    18.6.0.0.0 Release_Update 1903190102: Installed\r\n  PDB CDB$ROOT:\r\n    Applied 18.6.0.0.0 Release_Update 1903190102 successfully on 13-NOV-19 05.17.48.183101 PM\r\n  PDB PDB$SEED:\r\n    Applied 18.6.0.0.0 Release_Update 1903190102 successfully on 13-NOV-19 05.17.50.152110 PM\r\n\r\nAdding patches to installation queue and performing prereq checks...done\r\nInstallation queue:\r\n  For the following PDBs: CDB$ROOT PDB$SEED\r\n    No interim patches need to be rolled back\r\n    No release update patches need to be installed\r\n    No interim patches need to be applied\r\n\r\nSQL Patching tool complete on Thu Nov 14 09:21:48 2019\r\n[grid@exa01vm02 -MGMTDB]$\r\n[grid@exa01vm02 -MGMTDB]$\r\n[grid@exa01vm02 -MGMTDB]$ \r\n[grid@exa01vm02 -MGMTDB]$ sqlplus \/ as sysdba\r\n\r\nSQL*Plus: Release 18.0.0.0.0 - Production on Thu Nov 14 09:23:35 2019\r\nVersion 18.6.0.0.0\r\n\r\nCopyright (c) 1982, 2018, Oracle.  All rights reserved.\r\n\r\n\r\nConnected to:\r\nOracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\r\nVersion 18.6.0.0.0\r\n\r\nSQL&gt; set linesize 250\r\nSQL&gt; col comments format a50\r\nSQL&gt; select ACTION_TIME,VERSION,COMMENTS from dba_registry_history;\r\n\r\nACTION_TIME                                                                 VERSION                        COMMENTS\r\n--------------------------------------------------------------------------- ------------------------------ --------------------------------------------------\r\n                                                                            18                             RDBMS_18.6.0.0.0DBRU_LINUX.X64_190313.1\r\n19-JUN-18 01.51.48.687187 PM                                                18.0.0.0.0                     Patch applied from 18.1.0.0.0 to 18.2.0.0.0\r\n13-NOV-19 05.16.14.040821 PM                                                18.0.0.0.0                     Patch applied from 18.2.0.0.0 to 18.6.0.0.0\r\n\r\nSQL&gt; exit\r\nDisconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\r\nVersion 18.6.0.0.0\r\n[grid@exa01vm02 -MGMTDB]$\r\nIf you look above even the datapatch and database itself report that patch was applied correctly:\r\n[grid@exa01vm02 -MGMTDB]$ sqlplus \/ as sysdba\r\n\r\nSQL*Plus: Release 18.0.0.0.0 - Production on Thu Nov 14 09:19:05 2019\r\nVersion 18.6.0.0.0\r\n\r\nCopyright (c) 1982, 2018, Oracle.  All rights reserved.\r\n\r\n\r\nConnected to:\r\nOracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\r\nVersion 18.6.0.0.0\r\n\r\nSQL&gt; show pdbs\r\n\r\n    CON_ID CON_NAME                       OPEN MODE  RESTRICTED\r\n---------- ------------------------------ ---------- ----------\r\n         2 PDB$SEED                       READ ONLY  NO\r\nSQL&gt; select instance_name from v$instance;\r\n\r\nINSTANCE_NAME\r\n----------------\r\n-MGMTDB\r\n\r\nSQL&gt; exit\r\nDisconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\r\nVersion 18.6.0.0.0\r\n[grid@exa01vm02 -MGMTDB]$\r\n[grid@exa01vm02 -MGMTDB]$\r\n[grid@exa01vm02 -MGMTDB]$ cd $ORACLE_HOME\/OPatch\r\n[grid@exa01vm02 -MGMTDB]$ .\/datapatch -verbose\r\nSQL Patching tool version 18.0.0.0.0 Production on Thu Nov 14 09:21:33 2019\r\nCopyright (c) 2012, 2019, Oracle.  All rights reserved.\r\n\r\nLog file for this invocation: \/u01\/app\/grid\/cfgtoollogs\/sqlpatch\/sqlpatch_242627_2019_11_14_09_21_33\/sqlpatch_invocation.log\r\n\r\nConnecting to database...OK\r\nGathering database info...done\r\n\r\nNote:  Datapatch will only apply or rollback SQL fixes for PDBs\r\n       that are in an open state, no patches will be applied to closed PDBs.\r\n       Please refer to Note: Datapatch: Database 12c Post Patch SQL Automation\r\n       (Doc ID 1585822.1)\r\n\r\nBootstrapping registry and package to current versions...done\r\nDetermining current state...done\r\n\r\nCurrent state of interim SQL patches:\r\n  No interim patches found\r\n\r\nCurrent state of release update SQL patches:\r\n  Binary registry:\r\n    18.6.0.0.0 Release_Update 1903190102: Installed\r\n  PDB CDB$ROOT:\r\n    Applied 18.6.0.0.0 Release_Update 1903190102 successfully on 13-NOV-19 05.17.48.183101 PM\r\n  PDB PDB$SEED:\r\n    Applied 18.6.0.0.0 Release_Update 1903190102 successfully on 13-NOV-19 05.17.50.152110 PM\r\n\r\nAdding patches to installation queue and performing prereq checks...done\r\nInstallation queue:\r\n  For the following PDBs: CDB$ROOT PDB$SEED\r\n    No interim patches need to be rolled back\r\n    No release update patches need to be installed\r\n    No interim patches need to be applied\r\n\r\nSQL Patching tool complete on Thu Nov 14 09:21:48 2019\r\n[grid@exa01vm02 -MGMTDB]$\r\n[grid@exa01vm02 -MGMTDB]$\r\n[grid@exa01vm02 -MGMTDB]$ \r\n[grid@exa01vm02 -MGMTDB]$ sqlplus \/ as sysdba\r\n\r\nSQL*Plus: Release 18.0.0.0.0 - Production on Thu Nov 14 09:23:35 2019\r\nVersion 18.6.0.0.0\r\n\r\nCopyright (c) 1982, 2018, Oracle.  All rights reserved.\r\n\r\n\r\nConnected to:\r\nOracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\r\nVersion 18.6.0.0.0\r\n\r\nSQL&gt; set linesize 250\r\nSQL&gt; col comments format a50\r\nSQL&gt; select ACTION_TIME,VERSION,COMMENTS from dba_registry_history;\r\n\r\nACTION_TIME                                                                 VERSION                        COMMENTS\r\n--------------------------------------------------------------------------- ------------------------------ --------------------------------------------------\r\n                                                                            18                             RDBMS_18.6.0.0.0DBRU_LINUX.X64_190313.1\r\n19-JUN-18 01.51.48.687187 PM                                                18.0.0.0.0                     Patch applied from 18.1.0.0.0 to 18.2.0.0.0\r\n13-NOV-19 05.16.14.040821 PM                                                18.0.0.0.0                     Patch applied from 18.2.0.0.0 to 18.6.0.0.0\r\n\r\nSQL&gt; exit\r\nDisconnected from Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production\r\nVersion 18.6.0.0.0\r\n[grid@exa01vm02 -MGMTDB]$<\/pre>\n<h3 style=\"text-align: justify;\">The Workaround<\/h3>\n<p style=\"text-align: justify;\">The workaround tries to bypass some checks executed to opatch when checking MGMTDB. If you look at the errors above, they were caused because CRS can\u2019t communicate correctly with the database. Maybe because of some credential failure inside of CRS or listener registration.<\/p>\n<p style=\"text-align: justify;\">The first step is to remove completely the MGMTDB. To do that you can use the dbca (from GI home and only one node):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">[grid@exa01vm02 +ASM2]$ $ORACLE_HOME\/bin\/dbca -silent -deleteDatabase -sourceDB -MGMTDB\r\n[WARNING] [DBT-19202] The Database Configuration Assistant will delete the Oracle instances and datafiles for your database. All information in the database will be destroyed.\r\nPrepare for db operation\r\n32% complete\r\nConnecting to database\r\n35% complete\r\n39% complete\r\n42% complete\r\n45% complete\r\n48% complete\r\n52% complete\r\n65% complete\r\nUpdating network configuration files\r\n68% complete\r\nDeleting instance and datafiles\r\n84% complete\r\n100% complete\r\nDatabase deletion completed.\r\nLook at the log file \"\/u01\/app\/grid\/cfgtoollogs\/dbca\/_mgmtdb\/_mgmtdb.log\" for further details.\r\n[grid@exa01vm02 +ASM2]$<\/pre>\n<p style=\"text-align: justify;\">After remove completely, you just need to recreate the MGMTDB. This can be done manually or using the script from MOS. One good source for information is the note&nbsp;<a href=\"https:\/\/support.oracle.com\/epmos\/faces\/DocContentDisplay?id=1589394.1\" target=\"_blank\" rel=\"noopener noreferrer\"><strong>How to Move\/Recreate GI Management Repository (GIMR \/ MGMTDB) to Different Shared Storage (Diskgroup, CFS or NFS etc) (Doc ID 1589394.1)<\/strong><\/a> where you can find how to create manually or the script (the script just call the dbca).<\/p>\n<p style=\"text-align: justify;\">Here I used the script, you can download it from the note <a href=\"https:\/\/support.oracle.com\/epmos\/faces\/DocContentDisplay?id=2065175.1\" target=\"_blank\" rel=\"noopener noreferrer\"><strong>MDBUtil: GI Management Repository configuration tool (Doc ID 2065175.1)<\/strong><\/a><strong>.<\/strong> The script call DBCA and you just need to specify the diskgroup that you want to use to store the database files.<\/p>\n<p style=\"text-align: justify;\">In this case, I made:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">[grid@exa01vm02 +ASM2]$ \/tmp\/mdbutil.pl --addmdb --target=+DATAC2\r\nmdbutil.pl version : 1.98\r\n2019-11-14 09:54:58: I Starting To Configure MGMTDB at +DATAC2...\r\n2019-11-14 09:55:19: I Container database creation in progress... for GI 18.0.0.0.0\r\n2019-11-14 10:12:50: I Plugable database creation in progress...\r\n2019-11-14 10:16:59: I Executing \"\/tmp\/mdbutil.pl --addchm\" on exa01vm02 as root to configure CHM.\r\nroot@exa01vm02's password:\r\n2019-11-14 10:17:26: I Executing \"\/tmp\/mdbutil.pl --addchm\" on exa01vm02 as root to configure CHM.\r\nroot@exa01vm02's password:\r\n2019-11-14 10:17:34: I MGMTDB &amp; CHM configuration done!\r\n[grid@exa01vm02 +ASM2]$<\/pre>\n<p style=\"text-align: justify;\">You can even call with debug mode:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">[grid@exa02vm03 -MGMTDB]$ \/tmp\/mdbutil.pl --addmdb --target=+DATAC3 --debug\r\nmdbutil.pl version : 1.98\r\n2020-01-15 15:30:58: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/srvctl status diskgroup -g DATAC3\r\n2020-01-15 15:30:59: D Exit code: 0\r\n2020-01-15 15:30:59: D Output of last command execution:\r\nDisk Group DATAC3 is running on exa02vm03,exa01vm03\r\n2020-01-15 15:30:59: I Starting To Configure MGMTDB at +DATAC3...\r\n2020-01-15 15:30:59: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/srvctl status mgmtlsnr\r\n2020-01-15 15:30:59: D Exit code: 0\r\n2020-01-15 15:30:59: D Output of last command execution:\r\nListener MGMTLSNR is enabled\r\n2020-01-15 15:30:59: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/srvctl status mgmtdb\r\n2020-01-15 15:31:00: D Exit code: 1\r\n2020-01-15 15:31:00: D Output of last command execution:\r\nPRCD-1120 : The resource for database _mgmtdb could not be found.\r\n2020-01-15 15:31:00: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/srvctl status mgmtdb\r\n2020-01-15 15:31:01: D Exit code: 1\r\n2020-01-15 15:31:01: D Output of last command execution:\r\nPRCD-1120 : The resource for database _mgmtdb could not be found.\r\n2020-01-15 15:31:01: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/srvctl stop mgmtlsnr\r\n2020-01-15 15:31:05: D Exit code: 0\r\n2020-01-15 15:31:05: D Output of last command execution:\r\n2020-01-15 15:31:05: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/crsctl query crs activeversion\r\n2020-01-15 15:31:05: D Exit code: 0\r\n2020-01-15 15:31:05: D Output of last command execution:\r\nOracle Clusterware active version on the cluster is [18.0.0.0.0]\r\n2020-01-15 15:31:05: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/srvctl enable qosmserver\r\n2020-01-15 15:31:06: D Exit code: 2\r\n2020-01-15 15:31:06: D Output of last command execution:\r\nPRKF-1321 : QoS Management Server is already enabled.\r\n2020-01-15 15:31:06: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/srvctl start qosmserver\r\n2020-01-15 15:31:06: D Exit code: 2\r\n2020-01-15 15:31:06: D Output of last command execution:\r\nPRCC-1014 : qosmserver was already running\r\n2020-01-15 15:31:06: I Container database creation in progress... for GI 18.0.0.0.0\r\n2020-01-15 15:31:06: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/dbca  -silent -createDatabase -createAsContainerDatabase true -templateName MGMTSeed_Database.dbc -sid -MGMTDB -gdbName _mgmtdb -storageType ASM -diskGroupName DATAC3 -datafileJarLocation \/u01\/app\/18.0.0\/grid\/assistants\/dbca\/templates -characterset AL32UTF8 -autoGeneratePasswords -skipUserTemplateCheck\r\n2020-01-15 15:47:19: D Exit code: 0\r\n2020-01-15 15:47:19: D Output of last command execution:\r\nPrepare for db operation\r\n2020-01-15 15:47:19: I Plugable database creation in progress...\r\n2020-01-15 15:47:19: D Executing: \/u01\/app\/18.0.0\/grid\/bin\/mgmtca -local\r\n2020-01-15 15:49:28: D Exit code: 0\r\n2020-01-15 15:49:28: D Output of last command execution:\r\n2020-01-15 15:49:28: D Executing: scp \/tmp\/mdbutil.pl exa01vm03:\/tmp\/\r\n2020-01-15 15:49:28: D Exit code: 0\r\n2020-01-15 15:49:28: D Output of last command execution:\r\n2020-01-15 15:49:28: I Executing \"\/tmp\/mdbutil.pl --addchm\" on exa01vm03 as root to configure CHM.\r\n2020-01-15 15:49:28: D Executing: ssh root@exa01vm03 \"\/tmp\/mdbutil.pl --addchm\"\r\nroot@exa01vm03's password:\r\n2020-01-15 15:49:39: D Exit code: 0\r\n2020-01-15 15:49:39: D Output of last command execution:\r\nmdbutil.pl version : 1.98\r\n2020-01-15 15:49:39: D Executing: scp \/tmp\/mdbutil.pl exa02vm03:\/tmp\/\r\n2020-01-15 15:49:39: D Exit code: 0\r\n2020-01-15 15:49:39: D Output of last command execution:\r\n2020-01-15 15:49:39: I Executing \"\/tmp\/mdbutil.pl --addchm\" on exa02vm03 as root to configure CHM.\r\n2020-01-15 15:49:39: D Executing: ssh root@exa02vm03 \"\/tmp\/mdbutil.pl --addchm\"\r\nroot@exa02vm03's password:\r\n2020-01-15 15:49:46: D Exit code: 0\r\n2020-01-15 15:49:46: D Output of last command execution:\r\nmdbutil.pl version : 1.98\r\n2020-01-15 15:49:46: I MGMTDB &amp; CHM configuration done!\r\n[grid@exa02vm03 -MGMTDB]$<\/pre>\n<h2 style=\"text-align: justify;\">Resume and finish<\/h2>\n<p style=\"text-align: justify;\">So, after recreating the MGMTDB we can resume the opatch:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"no-highlight\">[root@exa02vm03 ~]# opatchauto resume\r\n\r\nOPatchauto session is initiated at Wed Jan 15 15:50:15 2020\r\nSession log file is \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/opatchauto2020-01-15_03-50-16PM.log\r\nResuming existing session with id NRZ1\r\n\r\nStarting CRS service on home \/u01\/app\/18.0.0\/grid\r\nCRS service started successfully on home \/u01\/app\/18.0.0\/grid\r\n\r\nOPatchAuto successful.\r\n\r\n--------------------------------Summary--------------------------------\r\n\r\nPatching is completed successfully. Please find the summary as follows:\r\n\r\nHost:exa02vm03\r\nCRS Home:\/u01\/app\/18.0.0\/grid\r\nVersion:18.0.0.0.0\r\nSummary:\r\n\r\n==Following patches were SUCCESSFULLY applied:\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/28435192\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-15_13-40-42PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/28547619\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-15_13-40-42PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29301631\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-15_13-40-42PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29301643\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-15_13-40-42PM_1.log\r\n\r\nPatch: \/u01\/patches\/grid\/29301682\/29302264\r\nLog: \/u01\/app\/18.0.0\/grid\/cfgtoollogs\/opatchauto\/core\/opatch\/opatch2020-01-15_13-40-42PM_1.log\r\n\r\n\r\n\r\nOPatchauto session completed at Wed Jan 15 15:57:24 2020\r\nTime taken to complete the session 7 minutes, 9 seconds\r\n[root@exa02vm03 ~]#<\/pre>\n<p style=\"text-align: justify;\">But why this work? So, the idea is that when the opatch tries to check if it is needed to apply the patch over the MGMTDB, it will reach it and verify that everything was already there and the call for <strong>mgmtca applysql<\/strong> will be successful. And since all the credentials between GI and MGMTDB are fine, the check can be done correctly. Another point is that you are recreating the database with one binary that already has the RU running.<\/p>\n<p style=\"text-align: justify;\">Again, this solution can be applied for these errors when the communication between MGMTDB and GI fails because of credential errors or listener errors. And I include the complete check for opatch error to identify exactly the error (it is just because <strong>mgmtca applysql<\/strong>), and if the SQL\u2019s was applied by datpatch and are registered inside of the database. To finish, always open SR.<\/p>\n<p style=\"text-align: justify;\">&nbsp;<\/p>\n<p style=\"text-align: justify;\"><strong>Disclaimer<\/strong>: <em>\u201cThe postings on this site are my own and don\u2019t necessarily represent my actual employer positions, strategies or opinions. The information here was edited to be useful for general purpose, specific data and identifications were removed to allow reach the generic audience and to be useful for the community.\u201d<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Recently I executed the upgrade of Oracle GI to 19c version, from 18.6.0.0 to 19.5.0.0 version. But one step that was not showed there was that, because of requirements, the GI was upgraded from 18.2.0.0 to 18.6.0.0. This upgrade is a just Release Update (RU) apply and opatchauto command. But during this upgrade, from 18.2 [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[64,29,56,5,12],"tags":[99,125,81,65,124],"class_list":["post-674","post","type-post","status-publish","format-standard","hentry","category-18c","category-database","category-grid-infrastructure","category-oracle","category-upgrade","tag-18c","tag-gi","tag-grid","tag-oracle","tag-upgrade"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.7 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Solving MGMTDB errors during 18c GI RU apply - Fernando Simon<\/title>\n<meta name=\"description\" content=\"Check how to solve some errors that can occur during at the MGMTDB database during the GI RU apply for 18c upgrade\/update process.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Solving MGMTDB errors during 18c GI RU apply - Fernando Simon\" \/>\n<meta property=\"og:description\" content=\"Check how to solve some errors that can occur during at the MGMTDB database during the GI RU apply for 18c upgrade\/update process.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/\" \/>\n<meta property=\"og:site_name\" content=\"Fernando Simon\" \/>\n<meta property=\"article:published_time\" content=\"2020-02-03T00:15:28+00:00\" \/>\n<meta name=\"author\" content=\"Simon\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Simon\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"20 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/\"},\"author\":{\"name\":\"Simon\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/#\\\/schema\\\/person\\\/386da956604bca0d5be5dd52210c1dd9\"},\"headline\":\"Solving MGMTDB errors during 18c GI RU apply\",\"datePublished\":\"2020-02-03T00:15:28+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/\"},\"wordCount\":843,\"commentCount\":0,\"keywords\":[\"18c\",\"GI\",\"GRID\",\"Oracle\",\"Upgrade\"],\"articleSection\":[\"18c\",\"Database\",\"Grid Infrastructure\",\"Oracle\",\"Upgrade\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/\",\"url\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/\",\"name\":\"Solving MGMTDB errors during 18c GI RU apply - Fernando Simon\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/#website\"},\"datePublished\":\"2020-02-03T00:15:28+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/#\\\/schema\\\/person\\\/386da956604bca0d5be5dd52210c1dd9\"},\"description\":\"Check how to solve some errors that can occur during at the MGMTDB database during the GI RU apply for 18c upgrade\\\/update process.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/solving-mgmtdb-errors-during-18c-gi-ru-apply\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Solving MGMTDB errors during 18c GI RU apply\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/#website\",\"url\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/\",\"name\":\"Fernando Simon\",\"description\":\"Have you hugged your backup today?\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/#\\\/schema\\\/person\\\/386da956604bca0d5be5dd52210c1dd9\",\"name\":\"Simon\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g\",\"caption\":\"Simon\"},\"sameAs\":[\"http:\\\/\\\/www.fernandosimon.com\"],\"url\":\"https:\\\/\\\/www.fernandosimon.com\\\/blog\\\/author\\\/simon\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Solving MGMTDB errors during 18c GI RU apply - Fernando Simon","description":"Check how to solve some errors that can occur during at the MGMTDB database during the GI RU apply for 18c upgrade\/update process.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/","og_locale":"en_US","og_type":"article","og_title":"Solving MGMTDB errors during 18c GI RU apply - Fernando Simon","og_description":"Check how to solve some errors that can occur during at the MGMTDB database during the GI RU apply for 18c upgrade\/update process.","og_url":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/","og_site_name":"Fernando Simon","article_published_time":"2020-02-03T00:15:28+00:00","author":"Simon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Simon","Est. reading time":"20 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/#article","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/"},"author":{"name":"Simon","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"headline":"Solving MGMTDB errors during 18c GI RU apply","datePublished":"2020-02-03T00:15:28+00:00","mainEntityOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/"},"wordCount":843,"commentCount":0,"keywords":["18c","GI","GRID","Oracle","Upgrade"],"articleSection":["18c","Database","Grid Infrastructure","Oracle","Upgrade"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/","url":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/","name":"Solving MGMTDB errors during 18c GI RU apply - Fernando Simon","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#website"},"datePublished":"2020-02-03T00:15:28+00:00","author":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"description":"Check how to solve some errors that can occur during at the MGMTDB database during the GI RU apply for 18c upgrade\/update process.","breadcrumb":{"@id":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.fernandosimon.com\/blog\/solving-mgmtdb-errors-during-18c-gi-ru-apply\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.fernandosimon.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Solving MGMTDB errors during 18c GI RU apply"}]},{"@type":"WebSite","@id":"https:\/\/www.fernandosimon.com\/blog\/#website","url":"https:\/\/www.fernandosimon.com\/blog\/","name":"Fernando Simon","description":"Have you hugged your backup today?","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.fernandosimon.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9","name":"Simon","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a3dbc48de62fffb1829befb4a588d789ec6dc5e05977afabb3407a5f37a16482?s=96&d=mm&r=g","caption":"Simon"},"sameAs":["http:\/\/www.fernandosimon.com"],"url":"https:\/\/www.fernandosimon.com\/blog\/author\/simon\/"}]}},"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p5ofTp-aS","_links":{"self":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/674","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/comments?post=674"}],"version-history":[{"count":0,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/674\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/media?parent=674"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/categories?post=674"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/tags?post=674"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}