{"id":724,"date":"2020-04-20T21:23:35","date_gmt":"2020-04-21T00:23:35","guid":{"rendered":"https:\/\/www.fernandosimon.com\/blog\/?p=724"},"modified":"2020-07-19T19:08:58","modified_gmt":"2020-07-19T22:08:58","slug":"exadata-and-zdlra-patch-exadata-stack","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/","title":{"rendered":"Exadata and ZDLRA, Patch Exadata Stack"},"content":{"rendered":"<p style=\"text-align: justify;\">The process to patch Exadata stack and software changed in the last years and it became easier. Now, with patchmgr to be used for all (database servers, storage cells, and switches) the process is much easier to control the steps. Here I will show the steps that are involved in this process.<\/p>\n<p style=\"text-align: justify;\">Independent if it is ZDLRA or Exadata, the process for Engineering System is the same. So, this post can be used as a guide for the Exadata patch apply as well. In 2018 I already made a similar process about how to patch\/upgrade Exadata to 18c (<a href=\"https:\/\/www.fernandosimon.com\/blog\/reaching-exadata-18c\/\" target=\"_blank\" rel=\"noopener noreferrer\">you can access here<\/a>) and even made a partial\/incomplete post for 12c in 2015.<\/p>\n<p style=\"text-align: justify;\">The process will be very similar and can be done in rolling and non-rolling mode. In the first, the services continue to run and you don\u2019t need to shutdown databases, but will take more time because the patchmgr applies server by server. At the second, you need to shutdown the entire GI and the patch is applied in parallel and will be faster.<\/p>\n<p style=\"text-align: justify;\"><!--moreClick here to read more...--><\/p>\n<h2 style=\"text-align: justify;\">Exadata Version for ZDLRA<\/h2>\n<p style=\"text-align: justify;\">The Exadata version that can be used for ZDLRA needs to be marked as supported by the ZDLRA team and needs to be compatible with the version that you are running. This compatibility matrix is found at note <a href=\"https:\/\/support.oracle.com\/epmos\/faces\/DocContentDisplay?id=1927416.1\" target=\"_blank\" rel=\"noopener noreferrer\">Zero Data Loss Recovery Appliance Supported Versions (Doc ID 1927416.1)<\/a>.<\/p>\n<p style=\"text-align: justify;\">I posted how to <a href=\"https:\/\/www.fernandosimon.com\/blog\/zdlra-patch-the-recovery-appliance\/\" target=\"_blank\" rel=\"noopener noreferrer\">upgrade ZDLRA here<\/a>, and the first thing to download the correct version is discovering which version of ZDLRA you are running. To do that, the racli version is used:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 ~]# racli version\r\nRecovery Appliance Version:\r\n        exadata image: 19.2.3.0.0.190621\r\n        rarpm version: ra_automation-19.2.1.1.1.202001-RELEASE.x86_64\r\n        rdbms version: RDBMS_19.3.0.0.190416DBRU_LINUX.X64_RELEASE\r\n        transaction  :\r\n        zdlra version: ZDLRA_19.2.1.1.1.202001_LINUX.X64_RELEASE\r\n[root@zerosita01 ~]#<\/pre>\n<p style=\"text-align: justify;\">With that, check what version is compatible at the matrix:<\/p>\n<p style=\"text-align: justify;\"><a href=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png\" target=\"_blank\" rel=\"noopener noreferrer\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-725 size-full\" src=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png\" alt=\"\" width=\"1541\" height=\"572\" srcset=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png 1541w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG-300x111.png 300w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG-1024x380.png 1024w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG-768x285.png 768w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG-1536x570.png 1536w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG-624x232.png 624w\" sizes=\"auto, (max-width: 1541px) 100vw, 1541px\" \/><\/a><\/p>\n<p style=\"text-align: justify;\">So, we can see that version 19.2.1.1.1.202001 is compatible with several Exadata version. Here, in this example, I will use the version 19.3.2.0.0.<\/p>\n<h2 style=\"text-align: justify;\">Prechecks<\/h2>\n<p style=\"text-align: justify;\">Now, we start to patch whatever the Engineering System you are using. Exadata, ZDLRA, SuperCluster. The process follows almost the same to all.<\/p>\n<p style=\"text-align: justify;\">I recommend doing some prechecks before start the patch itself. The first it checks the actual Exadata version that you are running at database servers, storage servers, and switches. Doing this you can check if you need to apply intermediate patches (usually for switches this can occurs) because you are in an old version.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 radump]# dcli -l root -g \/root\/cell_group \"imageinfo\" |grep \"Active image version\"\r\nzerocell01: Active image version: 19.2.3.0.0.190621\r\nzerocell02: Active image version: 19.2.3.0.0.190621\r\nzerocell03: Active image version: 19.2.3.0.0.190621\r\nzerocell04: Active image version: 19.2.3.0.0.190621\r\nzerocell05: Active image version: 19.2.3.0.0.190621\r\nzerocell06: Active image version: 19.2.3.0.0.190621\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]# dcli -l root -g \/root\/db_group \"imageinfo\" |grep \"Image version\"\r\nzerosita01: Image version: 19.2.3.0.0.190621\r\nzerosita02: Image version: 19.2.3.0.0.190621\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]# dcli -l root -g \/root\/ib_group \"version\" |grep version\r\nzdls-iba01: SUN DCS 36p version: 2.2.12-2\r\nzdls-iba01: BIOS version: NUP1R918\r\nzdls-ibb01: SUN DCS 36p version: 2.2.12-2\r\nzdls-ibb01: BIOS version: NUP1R918\r\n[root@zerosita01 radump]# dcli -l root -g \/root\/ib_group \"version\" |grep \"36p\"\r\nzdls-iba01: SUN DCS 36p version: 2.2.12-2\r\nzdls-ibb01: SUN DCS 36p version: 2.2.12-2\r\n[root@zerosita01 radump]#<\/pre>\n<p style=\"text-align: justify;\">After that, I recommend the restart of ILOM from database and storage (if you do for the switch, the entire switch will restart). This is needed to avoid fsck of ILOM filesystem due longtime online (in old machines like V2, X2, the FSCK can take a lot of time and trigger the timeout and rollback of patchmgr), and to show if some hardware error was not triggered yet:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 radump]# dcli -g \/root\/cell_group -l root 'ipmitool mc reset cold'\r\nzerocell01: Sent cold reset command to MC\r\nzerocell02: Sent cold reset command to MC\r\nzerocell03: Sent cold reset command to MC\r\nzerocell04: Sent cold reset command to MC\r\nzerocell05: Sent cold reset command to MC\r\nzerocell06: Sent cold reset command to MC\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]# dcli -g \/root\/db_group -l root 'ipmitool mc reset cold'\r\nzerosita01: Sent cold reset command to MC\r\nzerosita02: Sent cold reset command to MC\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]#\r\n######################################################\r\nAfter some time\r\n######################################################\r\n[root@zerosita01 radump]# dcli -l root -g \/root\/cell_group \"ipmitool sunoem led get\" |grep \": SERVICE\"\r\nzerocell01: SERVICE          | OFF\r\nzerocell02: SERVICE          | OFF\r\nzerocell03: SERVICE          | OFF\r\nzerocell04: SERVICE          | OFF\r\nzerocell05: SERVICE          | OFF\r\nzerocell06: SERVICE          | OFF\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]#\r\n[root@zerosita01 radump]# dcli -l root -g \/root\/db_group \"ipmitool sunoem led get\" |grep \": SERVICE\"\r\nzerosita01: SERVICE          | OFF\r\nzerosita02: SERVICE          | OFF\r\n[root@zerosita01 radump]#\r\n<\/pre>\n<p style=\"text-align: justify;\">As you can see, after the ILOM restart, there is no HW error (service leds are off).<\/p>\n<h2 style=\"text-align: justify;\">Downloading the patch<\/h2>\n<h3 style=\"text-align: justify;\">ZDLRA<\/h3>\n<p style=\"text-align: justify;\">To download the Exadata patch, the correct place is the note <a href=\"https:\/\/support.oracle.com\/epmos\/faces\/DocContentDisplay?id=1927416.1\" target=\"_blank\" rel=\"noopener noreferrer\">Zero Data Loss Recovery Appliance Supported Versions (Doc ID 1927416.1)<\/a>. And we can match the ZDLRA version that we are using with the Exadata:<\/p>\n<p style=\"text-align: justify;\"><a href=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-Patch.png\" target=\"_blank\" rel=\"noopener noreferrer\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-726 size-full\" src=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-Patch.png\" alt=\"\" width=\"1521\" height=\"413\" srcset=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-Patch.png 1521w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-Patch-300x81.png 300w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-Patch-1024x278.png 1024w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-Patch-768x209.png 768w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-Patch-624x169.png 624w\" sizes=\"auto, (max-width: 1521px) 100vw, 1521px\" \/><\/a><\/p>\n<p style=\"text-align: justify;\">If the link does not work (it\u2019s common) the patch can be downloaded at note <a href=\"https:\/\/support.oracle.com\/epmos\/faces\/DocContentDisplay?id=888828.1\" target=\"_blank\" rel=\"noopener noreferrer\">888828.1<\/a> from Exadata. Be careful to download the same patch numbers.<\/p>\n<p style=\"text-align: justify;\">I recommend downloading the patches do \/radump folder. If you want, you can create one specific folder for that:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 radump]# mkdir exa_stack\r\n[root@zerosita01 radump]# cd exa_stack\/\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# cp \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/19.2.1.1.1-201910-30614042\/EXA-STACK\/patchmgr\/p21634633_193100_Linux-x86-64.zip .\/\r\n[root@zerosita01 exa_stack]# cp \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/19.2.1.1.1-201910-30614042\/EXA-STACK\/dbnode\/p30439212_193000_Linux-x86-64.zip .\/\r\n[root@zerosita01 exa_stack]# cp \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/19.2.1.1.1-201910-30614042\/EXA-STACK\/switch\/p30469711_193000_Linux-x86-64.zip .\/\r\n[root@zerosita01 exa_stack]# cp \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/19.2.1.1.1-201910-30614042\/EXA-STACK\/storage\/p30540336_193000_Linux-x86-64.zip .\/\r\n[root@zerosita01 exa_stack]#<\/pre>\n<p style=\"text-align: justify;\">And after download, we can unzip the patches from Infiniband\/RCoE, Storage, and database patch manager. The patch from database server it is not needed to be unzipped:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# unzip p21634633_193100_Linux-x86-64.zip\r\nArchive:  p21634633_193100_Linux-x86-64.zip\r\n   creating: dbserver_patch_19.191113\/\r\n...\r\n...\r\n  inflating: dbserver_patch_19.191113\/patchmgr_functions\r\n  inflating: dbserver_patch_19.191113\/imageLogger\r\n  inflating: dbserver_patch_19.191113\/ExaXMLNode.pm\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# unzip p30439212_193000_Linux-x86-64.zip\r\nArchive:  p30439212_193000_Linux-x86-64.zip\r\n  inflating: exadata_ol7_base_repo_19.3.2.0.0.191119.iso\r\n  inflating: README.html\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# unzip p30469711_193000_Linux-x86-64.zip\r\nArchive:  p30469711_193000_Linux-x86-64.zip\r\n   creating: patch_switch_19.3.2.0.0.191119\/\r\n  inflating: patch_switch_19.3.2.0.0.191119\/nxos.7.0.3.I7.6.bin\r\n...\r\n...\r\n  inflating: patch_switch_19.3.2.0.0.191119\/patchmgr_functions\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# unzip p30540336_193000_Linux-x86-64.zip\r\nArchive:  p30540336_193000_Linux-x86-64.zip\r\n   creating: patch_19.3.2.0.0.191119\/\r\n  inflating: patch_19.3.2.0.0.191119\/dostep.sh\r\n...\r\n...\r\n  inflating: patch_19.3.2.0.0.191119\/19.3.2.0.0.191119.iso\r\n   creating: patch_19.3.2.0.0.191119\/linux.db.rpms\/\r\n  inflating: patch_19.3.2.0.0.191119\/README.html\r\n[root@zerosita01 exa_stack]#<\/pre>\n<h3 style=\"text-align: justify;\">Exadata<\/h3>\n<p style=\"text-align: justify;\">Specific for Exadata, the right place it is download from the note <a href=\"https:\/\/support.oracle.com\/epmos\/faces\/DocContentDisplay?id=888828.1\" target=\"_blank\" rel=\"noopener noreferrer\">888828.1<\/a>. There, you can choose the desired version that you want.&nbsp;<\/p>\n<p style=\"text-align: justify;\">After that, you can put in one specific folder and unzip (as shown for ZDLRA above) the files.<\/p>\n<h2 style=\"text-align: justify;\">Shutdown ZDLRA<\/h2>\n<p style=\"text-align: justify;\">This step is needed just for ZDLRA to shutdown it (the \u201csoftware\u201d and the database). Just login with the sqlplus and execute dbms_ra.shutdown as rasys user:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">root@zerosita01 exa_stack]# su - oracle\r\nLast login: Wed Mar  4 14:07:44 CET 2020 from 99.234.123.138 on ssh\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$ sqlplus rasys\/xxxxxx\r\n\r\nSQL*Plus: Release 19.0.0.0.0 - Production on Wed Mar 4 14:10:07 2020\r\nVersion 19.3.0.0.0\r\n\r\nCopyright (c) 1982, 2019, Oracle.  All rights reserved.\r\n\r\nLast Successful login time: Wed Mar 04 2020 14:00:02 +01:00\r\n\r\nConnected to:\r\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\r\nVersion 19.3.0.0.0\r\n\r\nSQL&gt; SELECT state FROM ra_server;\r\n\r\nSTATE\r\n-------------\r\nON\r\n\r\nSQL&gt; exec dbms_ra.shutdown;\r\n\r\nPL\/SQL procedure successfully completed.\r\n\r\nSQL&gt; SELECT state FROM ra_server;\r\n\r\nSTATE\r\n-------------\r\nOFF\r\n\r\nSQL&gt; exit\r\nDisconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\r\nVersion 19.3.0.0.0\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$ srvctl stop database -d zdlras\r\n[oracle@zerosita01 ~]$<\/pre>\n<h2 style=\"text-align: justify;\">Patching<\/h2>\n<p style=\"text-align: justify;\"><strong>Pre-Patch<\/strong><\/p>\n<p style=\"text-align: justify;\">I recommend using the <em>screen<\/em> to avoid that your session being killed by a firewall or network issues during the patch. With this, a session that simulates a console connection is created and you can reconnect it if needed. You can download from <a href=\"https:\/\/linux.oracle.com\/\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/linux.oracle.com\/<\/a>.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# rpm -Uvh \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/screen-4.1.0-0.25.20120314git3c2946.el7.x86_64.rpm\r\nPreparing...                          ################################# [100%]\r\nUpdating \/ installing...\r\n   1:screen-4.1.0-0.25.20120314git3c29################################# [100%]\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# screen -L -RR Patch-Exadata-Stack\r\n[root@zerosita01 exa_stack]# pwd\r\n\/radump\/exa_stack\r\n[root@zerosita01 exa_stack]#<\/pre>\n<p style=\"text-align: justify;\">Another detail is unmounting all NSF that you are using (and remove\/comment from fstab too to avoid mounting during the boot). If not, you will receive a warning about that. This is important for Exadata because you can have long mount time during the startup and this can force the rollback because the time to do the patch reaches the limit. If you don\u2019t want to unmount (because you are patching in rolling mode), there is one flag that can be passed at patchmgr to avoid mount during the reboot:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# umount \/zfs\r\n[root@zerosita01 exa_stack]#\r\n\r\n    SUMMARY OF WARNINGS AND ERRORS FOR zerosita01:\r\n\r\n    zerosita01: WARNING: Active network mounts found on this DB node.\r\n    zerosita01: The following known issues will be checked for but require manual follow-up:\r\n    zerosita01: (*) - Yum rolling update requires fix for 11768055 when Grid Infrastructure is below 11.2.0.2 BP12\r\n<\/pre>\n<p style=\"text-align: justify;\">It is needed to create files with the hostname for the switches, dbnodes, and storage servers.<\/p>\n<h3 style=\"text-align: justify;\">1 &#8211; Shutdown<\/h3>\n<p style=\"text-align: justify;\">This step depends on the chosen mode that you are patching. If it is in rolling mode, you can skip. If no, continue with the shutdown.<\/p>\n<p style=\"text-align: justify;\">Since the patch will be in non-rolling mode, it is needed to shutdown all the services running in the machine. To avoid any kind of service running, I shutdown the cluster services and CRS in all nodes:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# \/u01\/app\/19.0.0.0\/grid\/bin\/crsctl stop cluster -all\r\nCRS-2673: Attempting to stop 'ora.crsd' on 'zerosita01'\r\nCRS-2673: Attempting to stop 'ora.crsd' on 'zerosita02'\r\n...\r\n...\r\nCRS-2673: Attempting to stop 'ora.diskmon' on 'zerosita02'\r\nCRS-2677: Stop of 'ora.diskmon' on 'zerosita02' succeeded\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# \/u01\/app\/19.0.0.0\/grid\/bin\/crsctl stop crs\r\nCRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'zerosita01'\r\nCRS-2673: Attempting to stop 'ora.drivers.acfs' on 'zerosita01'\r\n...\r\n...\r\nCRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'zerosita01' has completed\r\nCRS-4133: Oracle High Availability Services has been stopped.\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# ssh -q zerosita02\r\nLast login: Wed Mar  4 14:15:09 CET 2020 from 99.234.123.138 on ssh\r\nLast login: Wed Mar  4 14:15:57 2020 from zerosita01.zero.flisk.net\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]# \/u01\/app\/19.0.0.0\/grid\/bin\/crsctl stop crs\r\nCRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'zerosita02'\r\nCRS-2673: Attempting to stop 'ora.mdnsd' on 'zerosita02'\r\n...\r\n...\r\nCRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'zerosita02' has completed\r\nCRS-4133: Oracle High Availability Services has been stopped.\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]# logout\r\n[root@zerosita01 exa_stack]#\r\n<\/pre>\n<h3 style=\"text-align: justify;\">2 \u2013 Patch Switches<\/h3>\n<p style=\"text-align: justify;\"><strong>Stopping cells services<\/strong><\/p>\n<p style=\"text-align: justify;\">This part of the process is not a requirement but can be done only in non-rolling executions. The idea is to stop all services running at storage to avoid IB port errors. And doing this, the \u201calerthistory\u201d from cell doesn\u2019t report error:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 patch_switch_19.3.2.0.0.191119]# dcli -l root -g \/root\/cell_group \"cellcli -e list cell\"\r\nzerocell01: zerocell01   online\r\nzerocell02: zerocell02   online\r\nzerocell03: zerocell03   online\r\nzerocell04: zerocell04   online\r\nzerocell05: zerocell05   online\r\nzerocell06: zerocell06   online\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]#\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]#\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]# dcli -l root -g \/root\/cell_group \"cellcli -e alter cell shutdown services all\"\r\nzerocell01:\r\nzerocell01: Stopping the RS, CELLSRV, and MS services...\r\nzerocell01: The SHUTDOWN of services was successful.\r\nzerocell02:\r\nzerocell02: Stopping the RS, CELLSRV, and MS services...\r\nzerocell02: The SHUTDOWN of services was successful.\r\nzerocell03:\r\nzerocell03: Stopping the RS, CELLSRV, and MS services...\r\nzerocell03: The SHUTDOWN of services was successful.\r\nzerocell04:\r\nzerocell04: Stopping the RS, CELLSRV, and MS services...\r\nzerocell04: The SHUTDOWN of services was successful.\r\nzerocell05:\r\nzerocell05: Stopping the RS, CELLSRV, and MS services...\r\nzerocell05: The SHUTDOWN of services was successful.\r\nzerocell06:\r\nzerocell06: Stopping the RS, CELLSRV, and MS services...\r\nzerocell06: The SHUTDOWN of services was successful.\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]#<\/pre>\n<p style=\"text-align: justify;\">After that, we can start the patch for Infiniband switches.<\/p>\n<p style=\"text-align: justify;\"><strong>ibswitch_precheck<\/strong><\/p>\n<p style=\"text-align: justify;\">This step checks if it is possible to apply the patch over ibswitch. Some versions have requirements that need to be matched, and if not, we need to fix (one example is hosts file that is wrong or space for FS).<\/p>\n<p style=\"text-align: justify;\">To call the process we enter in the folder that corresponds to an unzipped patch from switches (patch 30469711 in this scenario):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# cd patch_switch_19.3.2.0.0.191119\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]#\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]#\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]# .\/patchmgr -ibswitches \/root\/ib_group -upgrade -ibswitch_precheck\r\n\r\n2020-03-04 14:19:21 +0100        :Working: Verify SSH equivalence for the root user to node(s)\r\n2020-03-04 14:19:26 +0100        :SUCCESS: Verify SSH equivalence for the root user to node(s)\r\n2020-03-04 14:19:29 +0100 1 of 1 :Working: Initiate pre-upgrade validation check on InfiniBand switch(es).\r\n ----- InfiniBand switch update process started 2020-03-04 14:19:29 +0100 -----\r\n[NOTE     ] Log file at \/radump\/exa_stack\/patch_switch_19.3.2.0.0.191119\/upgradeIBSwitch.log\r\n\r\n[INFO     ] List of InfiniBand switches for upgrade: ( zdls-iba01 zdls-ibb01 )\r\n[SUCCESS  ] Verifying Network connectivity to zdls-iba01\r\n[SUCCESS  ] Verifying Network connectivity to zdls-ibb01\r\n[SUCCESS  ] Validating verify-topology output\r\n[INFO     ] Master Subnet Manager is set to \"zdls-iba01\" in all Switches\r\n\r\n[INFO     ] ---------- Starting with InfiniBand Switch zdls-iba01\r\n[WARNING  ] Infiniband switch meets minimal version requirements, but downgrade is only available to 2.2.13-2 with the current package.\r\n     To downgrade to other versions:\r\n     - Manually download the InfiniBand switch firmware package to the patch directory\r\n     - Set export variable \"EXADATA_IMAGE_IBSWITCH_DOWNGRADE_VERSION\" to the appropriate version\r\n     - Run patchmgr command to initiate downgrade.\r\n[SUCCESS  ] Verify SSH access to the patchmgr host zerosita01.zero.flisk.net from the InfiniBand Switch zdls-iba01.\r\n[INFO     ] Starting pre-update validation on zdls-iba01\r\n[SUCCESS  ] Verifying that \/tmp has 150M in zdls-iba01, found 492M\r\n[SUCCESS  ] Verifying that \/ has 20M in zdls-iba01, found 26M\r\n[SUCCESS  ] NTP daemon is running on zdls-iba01.\r\n[INFO     ] Manually validate the following entries Date:(YYYY-MM-DD) 2020-03-04 Time:(HH:MM:SS) 14:26:40\r\n[INFO     ] Validating the current firmware on the InfiniBand Switch\r\n[SUCCESS  ] Firmware verification on InfiniBand switch zdls-iba01\r\n[SUCCESS  ] Verifying that the patchmgr host zerosita01.zero.flisk.net is recognized on the InfiniBand Switch zdls-iba01 through getHostByName\r\n[SUCCESS  ] Execute plugin check for Patch Check Prereq on zdls-iba01\r\n[INFO     ] Finished pre-update validation on zdls-iba01\r\n[SUCCESS  ] Pre-update validation on zdls-iba01\r\n[SUCCESS  ] Prereq check on zdls-iba01\r\n\r\n[INFO     ] ---------- Starting with InfiniBand Switch zdls-ibb01\r\n[WARNING  ] Infiniband switch meets minimal version requirements, but downgrade is only available to 2.2.13-2 with the current package.\r\n     To downgrade to other versions:\r\n     - Manually download the InfiniBand switch firmware package to the patch directory\r\n     - Set export variable \"EXADATA_IMAGE_IBSWITCH_DOWNGRADE_VERSION\" to the appropriate version\r\n     - Run patchmgr command to initiate downgrade.\r\n[SUCCESS  ] Verify SSH access to the patchmgr host zerosita01.zero.flisk.net from the InfiniBand Switch zdls-ibb01.\r\n[INFO     ] Starting pre-update validation on zdls-ibb01\r\n[SUCCESS  ] Verifying that \/tmp has 150M in zdls-ibb01, found 492M\r\n[SUCCESS  ] Verifying that \/ has 20M in zdls-ibb01, found 26M\r\n[SUCCESS  ] NTP daemon is running on zdls-ibb01.\r\n[INFO     ] Manually validate the following entries Date:(YYYY-MM-DD) 2020-03-04 Time:(HH:MM:SS) 14:27:13\r\n[INFO     ] Validating the current firmware on the InfiniBand Switch\r\n[SUCCESS  ] Firmware verification on InfiniBand switch zdls-ibb01\r\n[SUCCESS  ] Verifying that the patchmgr host zerosita01.zero.flisk.net is recognized on the InfiniBand Switch zdls-ibb01 through getHostByName\r\n[SUCCESS  ] Execute plugin check for Patch Check Prereq on zdls-ibb01\r\n[INFO     ] Finished pre-update validation on zdls-ibb01\r\n[SUCCESS  ] Pre-update validation on zdls-ibb01\r\n[SUCCESS  ] Prereq check on zdls-ibb01\r\n[SUCCESS  ] Overall status\r\n\r\n ----- InfiniBand switch update process ended 2020-03-04 14:20:54 +0100 -----\r\n2020-03-04 14:20:54 +0100 1 of 1 :SUCCESS: Initiate pre-upgrade validation check on InfiniBand switch(es).\r\n2020-03-04 14:20:54 +0100        :SUCCESS: Completed run of command: .\/patchmgr -ibswitches \/root\/ib_group -upgrade -ibswitch_precheck\r\n2020-03-04 14:20:54 +0100        :INFO   : upgrade attempted on nodes in file \/root\/ib_group: [zdls-iba01 zdls-ibb01]\r\n2020-03-04 14:20:54 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/patch_switch_19.3.2.0.0.191119:\r\n2020-03-04 14:20:54 +0100        :INFO   :  - upgradeIBSwitch.log\r\n2020-03-04 14:20:54 +0100        :INFO   :  - upgradeIBSwitch.trc\r\n2020-03-04 14:20:54 +0100        :INFO   :  - patchmgr.stdout\r\n2020-03-04 14:20:54 +0100        :INFO   :  - patchmgr.stderr\r\n2020-03-04 14:20:54 +0100        :INFO   :  - patchmgr.log\r\n2020-03-04 14:20:54 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-04 14:20:54 +0100        :INFO   : Exit status:0\r\n2020-03-04 14:20:55 +0100        :INFO   : Exiting.\r\n\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]#\r\n<\/pre>\n<p style=\"text-align: justify;\">If the status is a success, we can continue to the next step.<\/p>\n<p style=\"text-align: justify;\"><strong>upgrade<\/strong><\/p>\n<p style=\"text-align: justify;\">After the precheck, we can call the upgrade. The call is the same, just changing the parameter to <em>upgrade<\/em>:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 patch_switch_19.3.2.0.0.191119]# .\/patchmgr -ibswitches \/root\/ib_group -upgrade\r\n\r\n2020-03-04 14:30:46 +0100        :Working: Verify SSH equivalence for the root user to node(s)\r\n2020-03-04 14:30:51 +0100        :SUCCESS: Verify SSH equivalence for the root user to node(s)\r\n2020-03-04 14:30:54 +0100 1 of 1 :Working: Initiate upgrade of InfiniBand switches to 2.2.14-1. Expect up to 40 minutes for each switch\r\n\r\n ----- InfiniBand switch update process started 2020-03-04 14:30:54 +0100 -----\r\n[NOTE     ] Log file at \/radump\/exa_stack\/patch_switch_19.3.2.0.0.191119\/upgradeIBSwitch.log\r\n\r\n[INFO     ] List of InfiniBand switches for upgrade: ( zdls-iba01 zdls-ibb01 )\r\n[SUCCESS  ] Verifying Network connectivity to zdls-iba01\r\n[SUCCESS  ] Verifying Network connectivity to zdls-ibb01\r\n[SUCCESS  ] Validating verify-topology output\r\n[INFO     ] Proceeding with upgrade of InfiniBand switches to version 2.2.14_1\r\n[INFO     ] Master Subnet Manager is set to \"zdls-iba01\" in all Switches\r\n\r\n[INFO     ] ---------- Starting with InfiniBand Switch zdls-iba01\r\n[WARNING  ] Infiniband switch meets minimal version requirements, but downgrade is only available to 2.2.13-2 with the current package.\r\n     To downgrade to other versions:\r\n     - Manually download the InfiniBand switch firmware package to the patch directory\r\n     - Set export variable \"EXADATA_IMAGE_IBSWITCH_DOWNGRADE_VERSION\" to the appropriate version\r\n     - Run patchmgr command to initiate downgrade.\r\n[SUCCESS  ] Verify SSH access to the patchmgr host zerosita01.zero.flisk.net from the InfiniBand Switch zdls-iba01.\r\n[INFO     ] Starting pre-update validation on zdls-iba01\r\n[SUCCESS  ] Verifying that \/tmp has 150M in zdls-iba01, found 492M\r\n[SUCCESS  ] Verifying that \/ has 20M in zdls-iba01, found 26M\r\n[SUCCESS  ] Service opensmd is running on InfiniBand Switch zdls-iba01\r\n[SUCCESS  ] NTP daemon is running on zdls-iba01.\r\n[INFO     ] Manually validate the following entries Date:(YYYY-MM-DD) 2020-03-04 Time:(HH:MM:SS) 14:38:06\r\n[INFO     ] Validating the current firmware on the InfiniBand Switch\r\n[SUCCESS  ] Firmware verification on InfiniBand switch zdls-iba01\r\n[SUCCESS  ] Verifying that the patchmgr host zerosita01.zero.flisk.net is recognized on the InfiniBand Switch zdls-iba01 through getHostByName\r\n[SUCCESS  ] Execute plugin check for Patch Check Prereq on zdls-iba01\r\n[INFO     ] Finished pre-update validation on zdls-iba01\r\n[SUCCESS  ] Pre-update validation on zdls-iba01\r\n[INFO     ] Package will be downloaded at firmware update time via scp\r\n[SUCCESS  ] Execute plugin check for Patching on zdls-iba01\r\n[INFO     ] Starting upgrade on zdls-iba01 to 2.2.14_1. Please give upto 15 mins for the process to complete. DO NOT INTERRUPT or HIT CTRL+C during the upgrade\r\n[INFO     ] Rebooting zdls-iba01 to complete the firmware update. Wait for 15 minutes before continuing. DO NOT MANUALLY REBOOT THE INFINIBAND SWITCH\r\n[SUCCESS  ] Load firmware 2.2.14_1 onto zdls-iba01\r\n[SUCCESS  ] Verify that \/conf\/configvalid is set to 1 on zdls-iba01\r\n[INFO     ] Set SMPriority to 5 on zdls-iba01\r\n[INFO     ] Starting post-update validation on zdls-iba01\r\n[SUCCESS  ] Service opensmd is running on InfiniBand Switch zdls-iba01\r\n[SUCCESS  ] NTP daemon is running on zdls-iba01.\r\n[INFO     ] Manually validate the following entries Date:(YYYY-MM-DD) 2020-03-04 Time:(HH:MM:SS) 14:54:47\r\n[INFO     ] \/conf\/configvalid is 1\r\n[INFO     ] Validating the current firmware on the InfiniBand Switch\r\n[SUCCESS  ] Firmware verification on InfiniBand switch zdls-iba01\r\n[SUCCESS  ] Execute plugin check for Post Patch on zdls-iba01\r\n[INFO     ] Finished post-update validation on zdls-iba01\r\n[SUCCESS  ] Post-update validation on zdls-iba01\r\n[SUCCESS  ] Update InfiniBand switch zdls-iba01 to 2.2.14_1\r\n\r\n[INFO     ] ---------- Starting with InfiniBand Switch zdls-ibb01\r\n[WARNING  ] Infiniband switch meets minimal version requirements, but downgrade is only available to 2.2.13-2 with the current package.\r\n     To downgrade to other versions:\r\n     - Manually download the InfiniBand switch firmware package to the patch directory\r\n     - Set export variable \"EXADATA_IMAGE_IBSWITCH_DOWNGRADE_VERSION\" to the appropriate version\r\n     - Run patchmgr command to initiate downgrade.\r\n[SUCCESS  ] Verify SSH access to the patchmgr host zerosita01.zero.flisk.net from the InfiniBand Switch zdls-ibb01.\r\n[INFO     ] Starting pre-update validation on zdls-ibb01\r\n[SUCCESS  ] Verifying that \/tmp has 150M in zdls-ibb01, found 492M\r\n[SUCCESS  ] Verifying that \/ has 20M in zdls-ibb01, found 26M\r\n[SUCCESS  ] Service opensmd is running on InfiniBand Switch zdls-ibb01\r\n[SUCCESS  ] NTP daemon is running on zdls-ibb01.\r\n[INFO     ] Manually validate the following entries Date:(YYYY-MM-DD) 2020-03-04 Time:(HH:MM:SS) 14:55:24\r\n[INFO     ] Validating the current firmware on the InfiniBand Switch\r\n[SUCCESS  ] Firmware verification on InfiniBand switch zdls-ibb01\r\n[SUCCESS  ] Verifying that the patchmgr host zerosita01.zero.flisk.net is recognized on the InfiniBand Switch zdls-ibb01 through getHostByName\r\n[SUCCESS  ] Execute plugin check for Patch Check Prereq on zdls-ibb01\r\n[INFO     ] Finished pre-update validation on zdls-ibb01\r\n[SUCCESS  ] Pre-update validation on zdls-ibb01\r\n[INFO     ] Package will be downloaded at firmware update time via scp\r\n[SUCCESS  ] Execute plugin check for Patching on zdls-ibb01\r\n[INFO     ] Starting upgrade on zdls-ibb01 to 2.2.14_1. Please give upto 15 mins for the process to complete. DO NOT INTERRUPT or HIT CTRL+C during the upgrade\r\n[INFO     ] Rebooting zdls-ibb01 to complete the firmware update. Wait for 15 minutes before continuing. DO NOT MANUALLY REBOOT THE INFINIBAND SWITCH\r\n[SUCCESS  ] Load firmware 2.2.14_1 onto zdls-ibb01\r\n[SUCCESS  ] Verify that \/conf\/configvalid is set to 1 on zdls-ibb01\r\n[INFO     ] Set SMPriority to 5 on zdls-ibb01\r\n[INFO     ] Starting post-update validation on zdls-ibb01\r\n[SUCCESS  ] Service opensmd is running on InfiniBand Switch zdls-ibb01\r\n[SUCCESS  ] NTP daemon is running on zdls-ibb01.\r\n[INFO     ] Manually validate the following entries Date:(YYYY-MM-DD) 2020-03-04 Time:(HH:MM:SS) 15:12:05\r\n[INFO     ] \/conf\/configvalid is 1\r\n[INFO     ] Validating the current firmware on the InfiniBand Switch\r\n[SUCCESS  ] Firmware verification on InfiniBand switch zdls-ibb01\r\n[SUCCESS  ] Execute plugin check for Post Patch on zdls-ibb01\r\n[INFO     ] Finished post-update validation on zdls-ibb01\r\n[SUCCESS  ] Post-update validation on zdls-ibb01\r\n[SUCCESS  ] Update InfiniBand switch zdls-ibb01 to 2.2.14_1\r\n[INFO     ] InfiniBand Switches ( zdls-iba01 zdls-ibb01 ) updated to 2.2.14_1\r\n[SUCCESS  ] Overall status\r\n\r\n ----- InfiniBand switch update process ended 2020-03-04 15:05:48 +0100 -----\r\n2020-03-04 15:05:48 +0100 1 of 1 :SUCCESS: Upgrade InfiniBand switch(es) to 2.2.14-1.\r\n2020-03-04 15:05:48 +0100        :SUCCESS: Completed run of command: .\/patchmgr -ibswitches \/root\/ib_group -upgrade\r\n2020-03-04 15:05:48 +0100        :INFO   : upgrade attempted on nodes in file \/root\/ib_group: [zdls-iba01 zdls-ibb01]\r\n2020-03-04 15:05:48 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/patch_switch_19.3.2.0.0.191119:\r\n2020-03-04 15:05:48 +0100        :INFO   :  - upgradeIBSwitch.log\r\n2020-03-04 15:05:48 +0100        :INFO   :  - upgradeIBSwitch.trc\r\n2020-03-04 15:05:48 +0100        :INFO   :  - patchmgr.stdout\r\n2020-03-04 15:05:48 +0100        :INFO   :  - patchmgr.stderr\r\n2020-03-04 15:05:48 +0100        :INFO   :  - patchmgr.log\r\n2020-03-04 15:05:48 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-04 15:05:48 +0100        :INFO   : Exit status:0\r\n2020-03-04 15:05:48 +0100        :INFO   : Exiting.\r\n\r\nYou have new mail in \/var\/spool\/mail\/root\r\n[root@zerosita01 patch_switch_19.3.2.0.0.191119]# cd ..\r\n[root@zerosita01 exa_stack]# dcli -l root -g \/root\/ib_group \"version\" |grep version\r\nzdls-iba01: SUN DCS 36p version: 2.2.14-1\r\nzdls-iba01: BIOS version: NUP1R918\r\nzdls-ibb01: SUN DCS 36p version: 2.2.14-1\r\nzdls-ibb01: BIOS version: NUP1R918\r\n[root@zerosita01 exa_stack]#<\/pre>\n<p style=\"text-align: justify;\">As you can see, the patch uses the file \u201c\/root\/ib_group\u201d that contains the switches hostname and the patchmgr patched one by one. This mode to patch (one by one) is needed because of the architecture of the IB network. One switch is the \u201cmaster\u201d of the network.<\/p>\n<p style=\"text-align: justify;\">The patch process is simple, copy the new version (through scp) to the switch and call the upgrade script. After that, reboot to load the new version.<\/p>\n<p style=\"text-align: justify;\"><strong>Startup cells services<\/strong><\/p>\n<p style=\"text-align: justify;\">After the success of the patch, we can start the cell services:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# dcli -l root -g \/root\/cell_group \"cellcli -e alter cell startup services all\"\r\nzerocell01:\r\nzerocell01: Starting the RS, CELLSRV, and MS services...\r\nzerocell01: Getting the state of RS services...  running\r\nzerocell01: Starting CELLSRV services...\r\nzerocell01: The STARTUP of CELLSRV services was successful.\r\nzerocell01: Starting MS services...\r\nzerocell01: The STARTUP of MS services was successful.\r\nzerocell02:\r\nzerocell02: Starting the RS, CELLSRV, and MS services...\r\nzerocell02: Getting the state of RS services...  running\r\nzerocell02: Starting CELLSRV services...\r\nzerocell02: The STARTUP of CELLSRV services was successful.\r\nzerocell02: Starting MS services...\r\nzerocell02: The STARTUP of MS services was successful.\r\nzerocell03:\r\nzerocell03: Starting the RS, CELLSRV, and MS services...\r\nzerocell03: Getting the state of RS services...  running\r\nzerocell03: Starting CELLSRV services...\r\nzerocell03: The STARTUP of CELLSRV services was successful.\r\nzerocell03: Starting MS services...\r\nzerocell03: The STARTUP of MS services was successful.\r\nzerocell04:\r\nzerocell04: Starting the RS, CELLSRV, and MS services...\r\nzerocell04: Getting the state of RS services...  running\r\nzerocell04: Starting CELLSRV services...\r\nzerocell04: The STARTUP of CELLSRV services was successful.\r\nzerocell04: Starting MS services...\r\nzerocell04: The STARTUP of MS services was successful.\r\nzerocell05:\r\nzerocell05: Starting the RS, CELLSRV, and MS services...\r\nzerocell05: Getting the state of RS services...  running\r\nzerocell05: Starting CELLSRV services...\r\nzerocell05: The STARTUP of CELLSRV services was successful.\r\nzerocell05: Starting MS services...\r\nzerocell05: The STARTUP of MS services was successful.\r\nzerocell06:\r\nzerocell06: Starting the RS, CELLSRV, and MS services...\r\nzerocell06: Getting the state of RS services...  running\r\nzerocell06: Starting CELLSRV services...\r\nzerocell06: The STARTUP of CELLSRV services was successful.\r\nzerocell06: Starting MS services...\r\nzerocell06: The STARTUP of MS services was successful.\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# dcli -l root -g \/root\/cell_group \"cellcli -e list cell\"\r\nzerocell01: zerocell01   online\r\nzerocell02: zerocell02   online\r\nzerocell03: zerocell03   online\r\nzerocell04: zerocell04   online\r\nzerocell05: zerocell05   online\r\nzerocell06: zerocell06   online\r\n[root@zerosita01 exa_stack]# \r\n[root@zerosita01 exa_stack]# dcli -l root -g \/root\/cell_group \"cellcli -e list alerthistory\"\r\n[root@zerosita01 exa_stack]#<\/pre>\n<p style=\"text-align: justify;\">In the end, you can see that there is no error for cells.<\/p>\n<h3 style=\"text-align: justify;\">3 &#8211; Patch Storage Cells<\/h3>\n<p style=\"text-align: justify;\">To patch the Storage Cell the process is similar, we use the patchmgr that it is inside of patch that was downloaded. The <em>patch_19.3.2.0.0.191119<\/em> that we unzipped before.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# ls -l\r\ntotal 7577888\r\ndrwxrwxr-x 3 root root       4096 Nov 13 16:11 dbserver_patch_19.191113\r\n-rw-rw-r-- 1 root root 1505257472 Nov 19 19:23 exadata_ol7_base_repo_19.3.2.0.0.191119.iso\r\n-rw-r--r-- 1 root root  438739135 Mar  4 13:40 p21634633_193100_Linux-x86-64.zip\r\n-rw-r--r-- 1 root root 1460815642 Mar  4 13:46 p30439212_193000_Linux-x86-64.zip\r\n-rw-r--r-- 1 root root 2872128400 Mar  4 13:47 p30469711_193000_Linux-x86-64.zip\r\n-rw-r--r-- 1 root root 1474890484 Mar  4 13:48 p30540336_193000_Linux-x86-64.zip\r\ndrwxrwxr-x 5 root root       4096 Nov 19 19:29 patch_19.3.2.0.0.191119\r\ndrwxrwxr-x 6 root root       4096 Mar  4 15:05 patch_switch_19.3.2.0.0.191119\r\n-rw-rw-r-- 1 root root     264228 Nov 19 19:29 README.html\r\n-rw-r--r-- 1 root root      31912 Mar  4 15:05 screenlog.0\r\n[root@zerosita01 exa_stack]#<\/pre>\n<p style=\"text-align: justify;\"><strong>cleanup<\/strong><\/p>\n<p style=\"text-align: justify;\">I always like to start the patch with the cleanup option for patchmgr. This connects in every cell and removes all possible old files (from the previous patch). It is a good start to avoid errors:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# cd patch_19.3.2.0.0.191119\r\n[root@zerosita01 patch_19.3.2.0.0.191119]#\r\n[root@zerosita01 patch_19.3.2.0.0.191119]# .\/patchmgr -cells \/root\/cell_group -cleanup\r\n\r\n2020-03-04 16:08:06 +0100        :Working: Cleanup\r\n2020-03-04 16:08:08 +0100        :SUCCESS: Cleanup\r\n2020-03-04 16:08:09 +0100        :SUCCESS: Completed run of command: .\/patchmgr -cells \/root\/cell_group -cleanup\r\n2020-03-04 16:08:09 +0100        :INFO   : Cleanup attempted on nodes in file \/root\/cell_group: [zerocell01 zerocell02 zerocell03 zerocell04 zerocell05 zerocell06]\r\n2020-03-04 16:08:09 +0100        :INFO   : Current image version on cell(s) is:\r\n2020-03-04 16:08:09 +0100        :INFO   : zerocell01: 19.2.3.0.0.190621\r\n2020-03-04 16:08:09 +0100        :INFO   : zerocell02: 19.2.3.0.0.190621\r\n2020-03-04 16:08:09 +0100        :INFO   : zerocell03: 19.2.3.0.0.190621\r\n2020-03-04 16:08:09 +0100        :INFO   : zerocell04: 19.2.3.0.0.190621\r\n2020-03-04 16:08:09 +0100        :INFO   : zerocell05: 19.2.3.0.0.190621\r\n2020-03-04 16:08:09 +0100        :INFO   : zerocell06: 19.2.3.0.0.190621\r\n2020-03-04 16:08:09 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/patch_19.3.2.0.0.191119:\r\n2020-03-04 16:08:09 +0100        :INFO   :  - &lt;cell_name&gt;.log\r\n2020-03-04 16:08:09 +0100        :INFO   :  - patchmgr.stdout\r\n2020-03-04 16:08:09 +0100        :INFO   :  - patchmgr.stderr\r\n2020-03-04 16:08:09 +0100        :INFO   :  - patchmgr.log\r\n2020-03-04 16:08:09 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-04 16:08:09 +0100        :INFO   : Exit status:0\r\n2020-03-04 16:08:09 +0100        :INFO   : Exiting.\r\n\r\n[root@zerosita01 patch_19.3.2.0.0.191119]#<\/pre>\n<p style=\"text-align: justify;\"><strong>patch_check_prereq<\/strong><\/p>\n<p style=\"text-align: justify;\">The next is check the prereqs to do the patch (this test space and if the current version is compatible to do the direct upgrade):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 patch_19.3.2.0.0.191119]# .\/patchmgr -cells \/root\/cell_group -patch_check_prereq\r\n\r\n2020-03-04 16:09:22 +0100        :Working: Check cells have ssh equivalence for root user. Up to 10 seconds per cell ...\r\n2020-03-04 16:09:24 +0100        :SUCCESS: Check cells have ssh equivalence for root user.\r\n2020-03-04 16:09:30 +0100        :Working: Initialize files. Up to 1 minute ...\r\n2020-03-04 16:09:32 +0100        :Working: Setup work directory\r\n2020-03-04 16:09:34 +0100        :SUCCESS: Setup work directory\r\n2020-03-04 16:09:37 +0100        :SUCCESS: Initialize files.\r\n2020-03-04 16:09:37 +0100        :Working: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction. Up to 40 minutes ...\r\n2020-03-04 16:09:52 +0100        :INFO   : Wait correction of degraded md11 due to md partner size mismatch. Up to 30 minutes.\r\n2020-03-04 16:09:53 +0100        :SUCCESS: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction.\r\n2020-03-04 16:09:53 +0100        :Working: Check space and state of cell services. Up to 20 minutes ...\r\n2020-03-04 16:11:10 +0100        :SUCCESS: Check space and state of cell services.\r\n2020-03-04 16:11:10 +0100        :Working: Check prerequisites on all cells. Up to 2 minutes ...\r\n2020-03-04 16:11:13 +0100        :SUCCESS: Check prerequisites on all cells.\r\n2020-03-04 16:11:13 +0100        :Working: Execute plugin check for Patch Check Prereq ...\r\n2020-03-04 16:11:14 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 22909764 v1.0.\r\n2020-03-04 16:11:14 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:11:14 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 17854520 v1.3.\r\n2020-03-04 16:11:14 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:11:14 +0100        :SUCCESS: No exposure to bug 17854520 with non-rolling patching\r\n2020-03-04 16:11:14 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 22468216 v1.0.\r\n2020-03-04 16:11:14 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:11:14 +0100        :SUCCESS: Patchmgr plugin complete: Prereq check passed for the bug 22468216\r\n2020-03-04 16:11:14 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 24625612 v1.0.\r\n2020-03-04 16:11:14 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:11:14 +0100        :SUCCESS: Patchmgr plugin complete: Prereq check passed for the bug 24625612\r\n2020-03-04 16:11:14 +0100        :SUCCESS: No exposure to bug 22896791 with non-rolling patching\r\n2020-03-04 16:11:14 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 22651315 v1.0.\r\n2020-03-04 16:11:14 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:11:16 +0100        :SUCCESS: Patchmgr plugin complete: Prereq check passed for the bug 22651315\r\n2020-03-04 16:11:17 +0100        :SUCCESS: Execute plugin check for Patch Check Prereq.\r\n2020-03-04 16:11:17 +0100        :Working: Check ASM deactivation outcome. Up to 1 minute ...\r\n2020-03-04 16:11:28 +0100        :SUCCESS: Check ASM deactivation outcome.\r\n2020-03-04 16:11:28 +0100        :Working: check if MS SOFTWAREUPDATE is scheduled. up to 5 minutes...\r\n2020-03-04 16:11:29 +0100        :NO ACTION NEEDED: No cells found with SOFTWAREUPDATE scheduled by MS\r\n2020-03-04 16:11:30 +0100        :SUCCESS: check if MS SOFTWAREUPDATE is scheduled\r\n2020-03-04 16:11:32 +0100        :SUCCESS: Completed run of command: .\/patchmgr -cells \/root\/cell_group -patch_check_prereq\r\n2020-03-04 16:11:32 +0100        :INFO   : patch_prereq attempted on nodes in file \/root\/cell_group: [zerocell01 zerocell02 zerocell03 zerocell04 zerocell05 zerocell06]\r\n2020-03-04 16:11:32 +0100        :INFO   : Current image version on cell(s) is:\r\n2020-03-04 16:11:32 +0100        :INFO   : zerocell01: 19.2.3.0.0.190621\r\n2020-03-04 16:11:32 +0100        :INFO   : zerocell02: 19.2.3.0.0.190621\r\n2020-03-04 16:11:32 +0100        :INFO   : zerocell03: 19.2.3.0.0.190621\r\n2020-03-04 16:11:32 +0100        :INFO   : zerocell04: 19.2.3.0.0.190621\r\n2020-03-04 16:11:32 +0100        :INFO   : zerocell05: 19.2.3.0.0.190621\r\n2020-03-04 16:11:32 +0100        :INFO   : zerocell06: 19.2.3.0.0.190621\r\n2020-03-04 16:11:32 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/patch_19.3.2.0.0.191119:\r\n2020-03-04 16:11:32 +0100        :INFO   :  - &lt;cell_name&gt;.log\r\n2020-03-04 16:11:32 +0100        :INFO   :  - patchmgr.stdout\r\n2020-03-04 16:11:32 +0100        :INFO   :  - patchmgr.stderr\r\n2020-03-04 16:11:32 +0100        :INFO   :  - patchmgr.log\r\n2020-03-04 16:11:32 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-04 16:11:32 +0100        :INFO   : Exit status:0\r\n2020-03-04 16:11:32 +0100        :INFO   : Exiting.\r\n\r\n[root@zerosita01 patch_19.3.2.0.0.191119]#<\/pre>\n<p style=\"text-align: justify;\"><strong>patch<\/strong><\/p>\n<p style=\"text-align: justify;\">After successfully prereqs check, we can do the patch. For rolling mode, you need to add the parameter &#8220;rolling&#8221; when you call the patchmgr. Doing that, it will patch one by one and just continue with the other cell if the resync from disks at ASM it is finished. And you need to be aware&nbsp;of the <a href=\"https:\/\/support.oracle.com\/epmos\/faces\/DocContentDisplay?id=2546014.1\" target=\"_blank\" rel=\"noopener noreferrer\">EX54 error<\/a>. If you hit this error, the best is to apply in rolling mode.<\/p>\n<p style=\"text-align: justify;\">The process to patch it is interesting because the patch itself copy the image in a different MD device (the one that it is not running), and change the boot to mount this MD. So, you do not upgrade the current system but just change the running image.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 patch_19.3.2.0.0.191119]# .\/patchmgr -cells \/root\/cell_group -patch\r\n********************************************************************************\r\nNOTE Cells will reboot during the patch or rollback process.\r\nNOTE For non-rolling patch or rollback, ensure all ASM instances using\r\nNOTE the cells are shut down for the duration of the patch or rollback.\r\nNOTE For rolling patch or rollback, ensure all ASM instances using\r\nNOTE the cells are up for the duration of the patch or rollback.\r\n\r\nWARNING Do not interrupt the patchmgr session.\r\nWARNING Do not alter state of ASM instances during patch or rollback.\r\nWARNING Do not resize the screen. It may disturb the screen layout.\r\nWARNING Do not reboot cells or alter cell services during patch or rollback.\r\nWARNING Do not open log files in editor in write mode or try to alter them.\r\n\r\nNOTE All time estimates are approximate.\r\n********************************************************************************\r\n\r\n\r\n2020-03-04 16:11:57 +0100        :Working: Check cells have ssh equivalence for root user. Up to 10 seconds per cell ...\r\n2020-03-04 16:11:59 +0100        :SUCCESS: Check cells have ssh equivalence for root user.\r\n2020-03-04 16:12:05 +0100        :Working: Initialize files. Up to 1 minute ...\r\n2020-03-04 16:12:07 +0100        :Working: Setup work directory\r\n2020-03-04 16:12:41 +0100        :SUCCESS: Setup work directory\r\n2020-03-04 16:12:44 +0100        :SUCCESS: Initialize files.\r\n2020-03-04 16:12:44 +0100        :Working: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction. Up to 40 minutes ...\r\n2020-03-04 16:12:58 +0100        :INFO   : Wait correction of degraded md11 due to md partner size mismatch. Up to 30 minutes.\r\n2020-03-04 16:13:00 +0100        :SUCCESS: Copy, extract prerequisite check archive to cells. If required start md11 mismatched partner size correction.\r\n2020-03-04 16:13:00 +0100        :Working: Check space and state of cell services. Up to 20 minutes ...\r\n2020-03-04 16:14:15 +0100        :SUCCESS: Check space and state of cell services.\r\n2020-03-04 16:14:15 +0100        :Working: Check prerequisites on all cells. Up to 2 minutes ...\r\n2020-03-04 16:14:18 +0100        :SUCCESS: Check prerequisites on all cells.\r\n2020-03-04 16:14:18 +0100        :Working: Copy the patch to all cells. Up to 3 minutes ...\r\n2020-03-04 16:15:36 +0100        :SUCCESS: Copy the patch to all cells.\r\n2020-03-04 16:15:38 +0100        :Working: Execute plugin check for Patch Check Prereq ...\r\n2020-03-04 16:15:38 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 22909764 v1.0.\r\n2020-03-04 16:15:38 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:15:38 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 17854520 v1.3.\r\n2020-03-04 16:15:38 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:15:38 +0100        :SUCCESS: No exposure to bug 17854520 with non-rolling patching\r\n2020-03-04 16:15:38 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 22468216 v1.0.\r\n2020-03-04 16:15:38 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:15:39 +0100        :SUCCESS: Patchmgr plugin complete: Prereq check passed for the bug 22468216\r\n2020-03-04 16:15:39 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 24625612 v1.0.\r\n2020-03-04 16:15:39 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:15:39 +0100        :SUCCESS: Patchmgr plugin complete: Prereq check passed for the bug 24625612\r\n2020-03-04 16:15:39 +0100        :SUCCESS: No exposure to bug 22896791 with non-rolling patching\r\n2020-03-04 16:15:39 +0100        :INFO   : Patchmgr plugin start: Prereq check for exposure to bug 22651315 v1.0.\r\n2020-03-04 16:15:39 +0100        :INFO   : Details in logfile \/radump\/exa_stack\/patch_19.3.2.0.0.191119\/patchmgr.stdout.\r\n2020-03-04 16:15:41 +0100        :SUCCESS: Patchmgr plugin complete: Prereq check passed for the bug 22651315\r\n2020-03-04 16:15:42 +0100        :SUCCESS: Execute plugin check for Patch Check Prereq.\r\n2020-03-04 16:15:42 +0100        :Working: check if MS SOFTWAREUPDATE is scheduled. up to 5 minutes...\r\n2020-03-04 16:15:43 +0100        :NO ACTION NEEDED: No cells found with SOFTWAREUPDATE scheduled by MS\r\n2020-03-04 16:15:44 +0100        :SUCCESS: check if MS SOFTWAREUPDATE is scheduled\r\n2020-03-04 16:15:52 +0100 1 of 5 :Working: Initiate patch on cells. Cells will remain up. Up to 5 minutes ...\r\n2020-03-04 16:15:58 +0100 1 of 5 :SUCCESS: Initiate patch on cells.\r\n2020-03-04 16:15:58 +0100 2 of 5 :Working: Waiting to finish pre-reboot patch actions. Cells will remain up. Up to 45 minutes ...\r\n2020-03-04 16:16:58 +0100        :INFO   : Wait for patch pre-reboot procedures\r\n2020-03-04 16:18:46 +0100 2 of 5 :SUCCESS: Waiting to finish pre-reboot patch actions.\r\n2020-03-04 16:18:47 +0100        :Working: Execute plugin check for Patching ...\r\n2020-03-04 16:18:47 +0100        :SUCCESS: Execute plugin check for Patching.\r\n2020-03-04 16:18:47 +0100 3 of 5 :Working: Finalize patch on cells. Cells will reboot. Up to 5 minutes ...\r\n2020-03-04 16:18:59 +0100 3 of 5 :SUCCESS: Finalize patch on cells.\r\n2020-03-04 16:19:16 +0100 4 of 5 :Working: Wait for cells to reboot and come online. Up to 120 minutes ...\r\n2020-03-04 16:20:16 +0100        :INFO   : Wait for patch finalization and reboot\r\n2020-03-04 16:51:25 +0100 4 of 5 :SUCCESS: Wait for cells to reboot and come online.\r\n2020-03-04 16:51:26 +0100 5 of 5 :Working: Check the state of patch on cells. Up to 5 minutes ...\r\n2020-03-04 16:52:40 +0100 5 of 5 :SUCCESS: Check the state of patch on cells.\r\n2020-03-04 16:52:40 +0100        :Working: Execute plugin check for Pre Disk Activation ...\r\n2020-03-04 16:52:41 +0100        :SUCCESS: Execute plugin check for Pre Disk Activation.\r\n2020-03-04 16:52:41 +0100        :Working: Activate grid disks...\r\n2020-03-04 16:52:42 +0100        :INFO   : Wait for checking and activating grid disks\r\n2020-03-04 16:54:27 +0100        :SUCCESS: Activate grid disks.\r\n2020-03-04 16:54:31 +0100        :Working: Execute plugin check for Post Patch ...\r\n2020-03-04 16:54:32 +0100        :SUCCESS: Execute plugin check for Post Patch.\r\n2020-03-04 16:54:33 +0100        :Working: Cleanup\r\n2020-03-04 16:55:08 +0100        :SUCCESS: Cleanup\r\n2020-03-04 16:55:10 +0100        :SUCCESS: Completed run of command: .\/patchmgr -cells \/root\/cell_group -patch\r\n2020-03-04 16:55:10 +0100        :INFO   : patch attempted on nodes in file \/root\/cell_group: [zerocell01 zerocell02 zerocell03 zerocell04 zerocell05 zerocell06]\r\n2020-03-04 16:55:10 +0100        :INFO   : Current image version on cell(s) is:\r\n2020-03-04 16:55:10 +0100        :INFO   : zerocell01: 19.3.2.0.0.191119\r\n2020-03-04 16:55:10 +0100        :INFO   : zerocell02: 19.3.2.0.0.191119\r\n2020-03-04 16:55:10 +0100        :INFO   : zerocell03: 19.3.2.0.0.191119\r\n2020-03-04 16:55:10 +0100        :INFO   : zerocell04: 19.3.2.0.0.191119\r\n2020-03-04 16:55:10 +0100        :INFO   : zerocell05: 19.3.2.0.0.191119\r\n2020-03-04 16:55:10 +0100        :INFO   : zerocell06: 19.3.2.0.0.191119\r\n2020-03-04 16:55:10 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/patch_19.3.2.0.0.191119:\r\n2020-03-04 16:55:10 +0100        :INFO   :  - &lt;cell_name&gt;.log\r\n2020-03-04 16:55:10 +0100        :INFO   :  - patchmgr.stdout\r\n2020-03-04 16:55:10 +0100        :INFO   :  - patchmgr.stderr\r\n2020-03-04 16:55:10 +0100        :INFO   :  - patchmgr.log\r\n2020-03-04 16:55:10 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-04 16:55:10 +0100        :INFO   : Exit status:0\r\n2020-03-04 16:55:10 +0100        :INFO   : Exiting.\r\n\r\n[root@zerosita01 patch_19.3.2.0.0.191119]#<\/pre>\n<p style=\"text-align: justify;\"><strong>Post-patch<\/strong><\/p>\n<p style=\"text-align: justify;\">After patch successfully we can check the running version and if every cell is up.<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 patch_19.3.2.0.0.191119]# dcli -l root -g \/root\/cell_group \"imageinfo\" |grep \"Active image version\"\r\nzerocell01: Active image version: 19.3.2.0.0.191119\r\nzerocell02: Active image version: 19.3.2.0.0.191119\r\nzerocell03: Active image version: 19.3.2.0.0.191119\r\nzerocell04: Active image version: 19.3.2.0.0.191119\r\nzerocell05: Active image version: 19.3.2.0.0.191119\r\nzerocell06: Active image version: 19.3.2.0.0.191119\r\n[root@zerosita01 patch_19.3.2.0.0.191119]#\r\n[root@zerosita01 patch_19.3.2.0.0.191119]# dcli -l root -g \/root\/cell_group \"cellcli -e list cell\"\r\nzerocell01: zerocell01   online\r\nzerocell02: zerocell02   online\r\nzerocell03: zerocell03   online\r\nzerocell04: zerocell04   online\r\nzerocell05: zerocell05   online\r\nzerocell06: zerocell06   online\r\n[root@zerosita01 patch_19.3.2.0.0.191119]#<\/pre>\n<p style=\"text-align: justify;\">Exit the screen session and remove the screen package (to avoid the error when applying the patch for database server):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 patch_19.3.2.0.0.191119]# cd ..\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# exit\r\n[screen is terminating]\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# rpm -qa |grep screen\r\nscreen-4.1.0-0.25.20120314git3c2946.el7.x86_64\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# rpm -e screen-4.1.0-0.25.20120314git3c2946.el7.x86_64\r\n[root@zerosita01 exa_stack]#<\/pre>\n<h3 style=\"text-align: justify;\">4 \u2013 Patch Database Servers<\/h3>\n<p style=\"text-align: justify;\">For Database server, I always prefer to patch the node 1 first, and after the other nodes. To do that, we copy the files to another node that has the ssh key for node 1 (if no, you can use another machine or configure now). You can still do this in one external machine if you want.<\/p>\n<p style=\"text-align: justify;\">Before starting the patch is important to show some details. First, the patch is applied by database server patch orchestrator (basically it is a solo patchmgr). The second, it is for database server we need to inform the target version (the version that we want to patch), this is the Exadata Channel version and can be found in the link description of the patch (marked in red):<\/p>\n<p style=\"text-align: justify;\"><a href=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-DB-Patch.png\" target=\"_blank\" rel=\"noopener noreferrer\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter wp-image-727 size-full\" src=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-DB-Patch.png\" alt=\"\" width=\"774\" height=\"326\" srcset=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-DB-Patch.png 774w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-DB-Patch-300x126.png 300w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-DB-Patch-768x323.png 768w, https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/Exadata-ZDLRA-DB-Patch-624x263.png 624w\" sizes=\"auto, (max-width: 774px) 100vw, 774px\" \/><\/a><\/p>\n<h4 style=\"text-align: justify;\">From Node 2 to Node 1<\/h4>\n<p style=\"text-align: justify;\"><strong>Preparing the other node<\/strong><\/p>\n<p style=\"text-align: justify;\">We need to prepare the other node to patch the node 1. We copy the patches, unzip it, install screen (and start the session), and stop all NFS (if mounted).<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita02 ~]# cd \/radump\/\r\n[root@zerosita02 radump]#\r\n[root@zerosita02 radump]# mkdir exa_stack\r\n[root@zerosita02 radump]#\r\n[root@zerosita02 radump]# cd exa_stack\/\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]# cp \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/19.2.1.1.1-201910-30614042\/EXA-STACK\/patchmgr\/p21634633_193100_Linux-x86-64.zip .\/\r\n[root@zerosita02 exa_stack]# cp \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/19.2.1.1.1-201910-30614042\/EXA-STACK\/dbnode\/p30439212_193000_Linux-x86-64.zip .\/\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]# unzip p21634633_193100_Linux-x86-64.zip\r\nArchive:  p21634633_193100_Linux-x86-64.zip\r\n   creating: dbserver_patch_19.191113\/\r\n  inflating: dbserver_patch_19.191113\/README.txt\r\n  inflating: dbserver_patch_19.191113\/md5sum_files.lst\r\n  inflating: dbserver_patch_19.191113\/patchReport.py\r\n  inflating: dbserver_patch_19.191113\/cellboot_usb_pci_path\r\n  inflating: dbserver_patch_19.191113\/dcli\r\n  inflating: dbserver_patch_19.191113\/exadata.img.env\r\n extracting: dbserver_patch_19.191113\/dbnodeupdate.zip\r\n   creating: dbserver_patch_19.191113\/linux.db.rpms\/\r\n  inflating: dbserver_patch_19.191113\/exadata.img.hw\r\n  inflating: dbserver_patch_19.191113\/patchmgr\r\n  inflating: dbserver_patch_19.191113\/ExadataSendNotification.pm\r\n  inflating: dbserver_patch_19.191113\/ExadataImageNotification.pl\r\n  inflating: dbserver_patch_19.191113\/patchmgr_functions\r\n  inflating: dbserver_patch_19.191113\/imageLogger\r\n  inflating: dbserver_patch_19.191113\/ExaXMLNode.pm\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]# ls -l\r\ntotal 1856868\r\ndrwxrwxr-x 3 root root       4096 Mar  5 12:30 dbserver_patch_19.191113\r\n-rw-r--r-- 1 root root  438739135 Mar  5 12:20 p21634633_193100_Linux-x86-64.zip\r\n-rw-r--r-- 1 root root 1460815642 Mar  5 12:20 p30439212_193000_Linux-x86-64.zip\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]# rpm -Uvh \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/screen-4.1.0-0.25.20120314git3c2946.el7.x86_64.rpm\r\nPreparing...                          ################################# [100%]\r\nUpdating \/ installing...\r\n   1:screen-4.1.0-0.25.20120314git3c29################################# [100%]\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]# screen -L -RR NODE1-From-Node2-Upgrade\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]# umount \/zfs\r\n[root@zerosita02 exa_stack]#<\/pre>\n<p style=\"text-align: justify;\"><strong>Precheck<\/strong><\/p>\n<p style=\"text-align: justify;\">So, from node 2 we check if node 1 is ok with the prechecks (the zip, is the patch that was downloaded, and the target version is the desired for the chosen patch):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita02 dbserver_patch_19.191113]# .\/patchmgr -dbnodes \/root\/db_node01 -iso_repo \/radump\/exa_stack\/p30439212_193000_Linux-x86-64.zip -target_version 19.3.2.0.0.191119 -precheck\r\n\r\n************************************************************************************************************\r\nNOTE    patchmgr release: 19.191113 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)\r\nNOTE\r\nWARNING Do not interrupt the patchmgr session.\r\nWARNING Do not resize the screen. It may disturb the screen layout.\r\nWARNING Do not reboot database nodes during update or rollback.\r\nWARNING Do not open logfiles in write mode and do not try to alter them.\r\n************************************************************************************************************\r\n2020-03-05 12:41:59 +0100        :Working: Verify SSH equivalence for the root user to zeroadm01\r\n2020-03-05 12:41:59 +0100        :SUCCESS: Verify SSH equivalence for the root user to zeroadm01\r\n2020-03-05 12:42:00 +0100        :Working: Initiate precheck on 1 node(s)\r\n2020-03-05 12:45:34 +0100        :Working: Check free space on zeroadm01\r\n2020-03-05 12:45:37 +0100        :SUCCESS: Check free space on zeroadm01\r\n2020-03-05 12:46:07 +0100        :Working: dbnodeupdate.sh running a precheck on node(s).\r\n2020-03-05 12:47:49 +0100        :SUCCESS: Initiate precheck on node(s).\r\n2020-03-05 12:47:49 +0100        :SUCCESS: Completed run of command: .\/patchmgr -dbnodes \/root\/db_node01 -iso_repo \/radump\/exa_stack\/p30439212_193000_Linux-x86-64.zip -target_version 19.3.2.0.0.191119 -precheck\r\n2020-03-05 12:47:50 +0100        :INFO   : Precheck attempted on nodes in file \/root\/db_node01: [zeroadm01]\r\n2020-03-05 12:47:50 +0100        :INFO   : Current image version on dbnode(s) is:\r\n2020-03-05 12:47:50 +0100        :INFO   : zeroadm01: 19.2.3.0.0.190621\r\n2020-03-05 12:47:50 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/dbserver_patch_19.191113:\r\n2020-03-05 12:47:50 +0100        :INFO   :  - &lt;dbnode_name&gt;_dbnodeupdate.log\r\n2020-03-05 12:47:50 +0100        :INFO   :  - patchmgr.log\r\n2020-03-05 12:47:50 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-05 12:47:50 +0100        :INFO   : Exit status:0\r\n2020-03-05 12:47:50 +0100        :INFO   : Exiting.\r\n\r\n[root@zerosita02 dbserver_patch_19.191113]#<\/pre>\n<p style=\"text-align: justify;\"><strong>upgrade<\/strong><\/p>\n<p style=\"text-align: justify;\">If it is ok with the prereqs, we patch node 1 (from node 2):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita02 dbserver_patch_19.191113]# .\/patchmgr -dbnodes \/root\/db_node01 -iso_repo \/radump\/exa_stack\/p30439212_193000_Linux-x86-64.zip -target_version 19.3.2.0.0.191119 -upgrade\r\n\r\n************************************************************************************************************\r\nNOTE    patchmgr release: 19.191113 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)\r\nNOTE\r\nNOTE    Database nodes will reboot during the update process.\r\nNOTE\r\nWARNING Do not interrupt the patchmgr session.\r\nWARNING Do not resize the screen. It may disturb the screen layout.\r\nWARNING Do not reboot database nodes during update or rollback.\r\nWARNING Do not open logfiles in write mode and do not try to alter them.\r\n************************************************************************************************************\r\n2020-03-05 12:52:12 +0100        :Working: Verify SSH equivalence for the root user to zeroadm01\r\n2020-03-05 12:52:13 +0100        :SUCCESS: Verify SSH equivalence for the root user to zeroadm01\r\n2020-03-05 12:52:14 +0100        :Working: Initiate prepare steps on node(s).\r\n2020-03-05 12:52:14 +0100        :Working: Check free space on zeroadm01\r\n2020-03-05 12:52:18 +0100        :SUCCESS: Check free space on zeroadm01\r\n2020-03-05 12:52:50 +0100        :SUCCESS: Initiate prepare steps on node(s).\r\n2020-03-05 12:52:50 +0100        :Working: Initiate update on 1 node(s).\r\n2020-03-05 12:52:50 +0100        :Working: dbnodeupdate.sh running a backup on 1 node(s).\r\n2020-03-05 12:57:34 +0100        :SUCCESS: dbnodeupdate.sh running a backup on 1 node(s).\r\n2020-03-05 12:57:34 +0100        :Working: Initiate update on node(s)\r\n2020-03-05 12:57:35 +0100        :Working: Get information about any required OS upgrades from node(s).\r\n2020-03-05 12:57:45 +0100        :SUCCESS: Get information about any required OS upgrades from node(s).\r\n2020-03-05 12:57:45 +0100        :Working: dbnodeupdate.sh running an update step on all nodes.\r\n2020-03-05 13:12:17 +0100        :INFO   : zeroadm01 is ready to reboot.\r\n2020-03-05 13:12:17 +0100        :SUCCESS: dbnodeupdate.sh running an update step on all nodes.\r\n2020-03-05 13:12:26 +0100        :Working: Initiate reboot on node(s)\r\n2020-03-05 13:12:28 +0100        :SUCCESS: Initiate reboot on node(s)\r\n2020-03-05 13:12:28 +0100        :Working: Waiting to ensure zeroadm01 is down before reboot.\r\n2020-03-05 13:12:52 +0100        :SUCCESS: Waiting to ensure zeroadm01 is down before reboot.\r\n2020-03-05 13:12:52 +0100        :Working: Waiting to ensure zeroadm01 is up after reboot.\r\n2020-03-05 13:15:46 +0100        :SUCCESS: Waiting to ensure zeroadm01 is up after reboot.\r\n2020-03-05 13:15:46 +0100        :Working: Waiting to connect to zeroadm01 with SSH. During Linux upgrades this can take some time.\r\n2020-03-05 13:35:10 +0100        :SUCCESS: Waiting to connect to zeroadm01 with SSH. During Linux upgrades this can take some time.\r\n2020-03-05 13:35:10 +0100        :Working: Wait for zeroadm01 is ready for the completion step of update.\r\n2020-03-05 13:35:10 +0100        :SUCCESS: Wait for zeroadm01 is ready for the completion step of update.\r\n2020-03-05 13:35:10 +0100        :Working: Initiate completion step from dbnodeupdate.sh on node(s)\r\n2020-03-05 13:42:37 +0100        :SUCCESS: Initiate completion step from dbnodeupdate.sh on zeroadm01\r\n2020-03-05 13:42:50 +0100        :SUCCESS: Initiate update on node(s).\r\n2020-03-05 13:42:51 +0100        :SUCCESS: Initiate update on 0 node(s).\r\n[INFO     ] Collected dbnodeupdate diag in file: Diag_patchmgr_dbnode_upgrade_050320125211.tbz\r\n-rw-r--r-- 1 root root 2397370 Mar  5 13:42 Diag_patchmgr_dbnode_upgrade_050320125211.tbz\r\n2020-03-05 13:42:52 +0100        :SUCCESS: Completed run of command: .\/patchmgr -dbnodes \/root\/db_node01 -iso_repo \/radump\/exa_stack\/p30439212_193000_Linux-x86-64.zip -target_version 19.3.2.0.0.191119 -upgrade\r\n2020-03-05 13:42:52 +0100        :INFO   : Upgrade attempted on nodes in file \/root\/db_node01: [zeroadm01]\r\n2020-03-05 13:42:52 +0100        :INFO   : Current image version on dbnode(s) is:\r\n2020-03-05 13:42:52 +0100        :INFO   : zeroadm01: 19.3.2.0.0.191119\r\n2020-03-05 13:42:52 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/dbserver_patch_19.191113:\r\n2020-03-05 13:42:52 +0100        :INFO   :  - &lt;dbnode_name&gt;_dbnodeupdate.log\r\n2020-03-05 13:42:52 +0100        :INFO   :  - patchmgr.log\r\n2020-03-05 13:42:52 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-05 13:42:52 +0100        :INFO   : Exit status:0\r\n2020-03-05 13:42:52 +0100        :INFO   : Exiting.\r\n\r\nYou have new mail in \/var\/spool\/mail\/root\r\n[root@zerosita02 dbserver_patch_19.191113]#<\/pre>\n<p style=\"text-align: justify;\"><strong>Post-patch of Node 1<\/strong><\/p>\n<p style=\"text-align: justify;\">If the patch was Ok, we can finish the patch at node 2. This means exist screen session and remove it:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]# rpm -qa |grep screen\r\nscreen-4.1.0-0.25.20120314git3c2946.el7.x86_64\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]#\r\n[root@zerosita02 exa_stack]# rpm -e screen-4.1.0-0.25.20120314git3c2946.el7.x86_64\r\n[root@zerosita02 exa_stack]#<\/pre>\n<h4 style=\"text-align: justify;\">From Node 1 to Node 2 (or others)<\/h4>\n<p style=\"text-align: justify;\"><strong>Preparing node 1<\/strong><\/p>\n<p style=\"text-align: justify;\">Since we upgraded node 1 in the above we need to reinstall screen and create the session. Check that maybe you need a new rpm version if you upgraded (as an example) from OEL 6 to OEL 7:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 ~]# cd \/radump\/exa_stack\/\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# rpm -Uvh \/zfs\/ZDLRA_PATCHING\/19.2.1.1.1\/screen-4.1.0-0.25.20120314git3c2946.el7.x86_64.rpm\r\nPreparing...                          ################################# [100%]\r\nUpdating \/ installing...\r\n   1:screen-4.1.0-0.25.20120314git3c29################################# [100%]\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# umount \/zfs\/\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# screen -L -RR NODE2-From-Node1-Upgrade\r\n[root@zerosita01 exa_stack]#<\/pre>\n<p style=\"text-align: justify;\"><strong>Precheck<\/strong><\/p>\n<p style=\"text-align: justify;\">We need to precheck the other nodes to check inconsistencies. In this scenario, the file has the list for other nodes (just one):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 dbserver_patch_19.191113]# .\/patchmgr -dbnodes \/root\/db_group_zeroadm02 -iso_repo \/radump\/exa_stack\/p30439212_193000_Linux-x86-64.zip -target_version 19.3.2.0.0.191119 -precheck\r\n\r\n************************************************************************************************************\r\nNOTE    patchmgr release: 19.191113 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)\r\nNOTE\r\nWARNING Do not interrupt the patchmgr session.\r\nWARNING Do not resize the screen. It may disturb the screen layout.\r\nWARNING Do not reboot database nodes during update or rollback.\r\nWARNING Do not open logfiles in write mode and do not try to alter them.\r\n************************************************************************************************************\r\n2020-03-05 13:57:04 +0100        :Working: Verify SSH equivalence for the root user to zeroadm02\r\n2020-03-05 13:57:05 +0100        :SUCCESS: Verify SSH equivalence for the root user to zeroadm02\r\n2020-03-05 13:57:06 +0100        :Working: Initiate precheck on 1 node(s)\r\n2020-03-05 14:00:39 +0100        :Working: Check free space on zeroadm02\r\n2020-03-05 14:00:42 +0100        :SUCCESS: Check free space on zeroadm02\r\n2020-03-05 14:01:12 +0100        :Working: dbnodeupdate.sh running a precheck on node(s).\r\n2020-03-05 14:02:54 +0100        :SUCCESS: Initiate precheck on node(s).\r\n2020-03-05 14:02:54 +0100        :SUCCESS: Completed run of command: .\/patchmgr -dbnodes \/root\/db_group_zeroadm02 -iso_repo \/radump\/exa_stack\/p30439212_193000_Linux-x86-64.zip -target_version 19.3.2.0.0.191119 -precheck\r\n2020-03-05 14:02:55 +0100        :INFO   : Precheck attempted on nodes in file \/root\/db_group_zeroadm02: [zeroadm02]\r\n2020-03-05 14:02:55 +0100        :INFO   : Current image version on dbnode(s) is:\r\n2020-03-05 14:02:55 +0100        :INFO   : zeroadm02: 19.2.3.0.0.190621\r\n2020-03-05 14:02:55 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/dbserver_patch_19.191113:\r\n2020-03-05 14:02:55 +0100        :INFO   :  - &lt;dbnode_name&gt;_dbnodeupdate.log\r\n2020-03-05 14:02:55 +0100        :INFO   :  - patchmgr.log\r\n2020-03-05 14:02:55 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-05 14:02:55 +0100        :INFO   : Exit status:0\r\n2020-03-05 14:02:55 +0100        :INFO   : Exiting.\r\n\r\nYou have new mail in \/var\/spool\/mail\/root\r\n[root@zerosita01 dbserver_patch_19.191113]#<\/pre>\n<p style=\"text-align: justify;\"><strong>upgrade<\/strong><\/p>\n<p style=\"text-align: justify;\">If it is OK, we can do the upgrade:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 dbserver_patch_19.191113]# .\/patchmgr -dbnodes \/root\/db_group_zeroadm02 -iso_repo \/radump\/exa_stack\/p30439212_193000_Linux-x86-64.zip -target_version 19.3.2.0.0.191119 -upgrade\r\n\r\n************************************************************************************************************\r\nNOTE    patchmgr release: 19.191113 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)\r\nNOTE\r\nNOTE    Database nodes will reboot during the update process.\r\nNOTE\r\nWARNING Do not interrupt the patchmgr session.\r\nWARNING Do not resize the screen. It may disturb the screen layout.\r\nWARNING Do not reboot database nodes during update or rollback.\r\nWARNING Do not open logfiles in write mode and do not try to alter them.\r\n************************************************************************************************************\r\n2020-03-05 14:14:24 +0100        :Working: Verify SSH equivalence for the root user to zeroadm02\r\n2020-03-05 14:14:25 +0100        :SUCCESS: Verify SSH equivalence for the root user to zeroadm02\r\n2020-03-05 14:14:26 +0100        :Working: Initiate prepare steps on node(s).\r\n2020-03-05 14:14:26 +0100        :Working: Check free space on zeroadm02\r\n2020-03-05 14:14:30 +0100        :SUCCESS: Check free space on zeroadm02\r\n2020-03-05 14:15:02 +0100        :SUCCESS: Initiate prepare steps on node(s).\r\n2020-03-05 14:15:02 +0100        :Working: Initiate update on 1 node(s).\r\n2020-03-05 14:15:02 +0100        :Working: dbnodeupdate.sh running a backup on 1 node(s).\r\n2020-03-05 14:19:56 +0100        :SUCCESS: dbnodeupdate.sh running a backup on 1 node(s).\r\n2020-03-05 14:19:56 +0100        :Working: Initiate update on node(s)\r\n2020-03-05 14:19:56 +0100        :Working: Get information about any required OS upgrades from node(s).\r\n2020-03-05 14:20:06 +0100        :SUCCESS: Get information about any required OS upgrades from node(s).\r\n2020-03-05 14:20:06 +0100        :Working: dbnodeupdate.sh running an update step on all nodes.\r\n2020-03-05 14:34:37 +0100        :INFO   : zeroadm02 is ready to reboot.\r\n2020-03-05 14:34:37 +0100        :SUCCESS: dbnodeupdate.sh running an update step on all nodes.\r\n2020-03-05 14:34:44 +0100        :Working: Initiate reboot on node(s)\r\n2020-03-05 14:34:47 +0100        :SUCCESS: Initiate reboot on node(s)\r\n2020-03-05 14:34:47 +0100        :Working: Waiting to ensure zeroadm02 is down before reboot.\r\n2020-03-05 14:35:11 +0100        :SUCCESS: Waiting to ensure zeroadm02 is down before reboot.\r\n2020-03-05 14:35:11 +0100        :Working: Waiting to ensure zeroadm02 is up after reboot.\r\n2020-03-05 14:38:04 +0100        :SUCCESS: Waiting to ensure zeroadm02 is up after reboot.\r\n2020-03-05 14:38:04 +0100        :Working: Waiting to connect to zeroadm02 with SSH. During Linux upgrades this can take some time.\r\n2020-03-05 15:05:13 +0100        :SUCCESS: Waiting to connect to zeroadm02 with SSH. During Linux upgrades this can take some time.\r\n2020-03-05 15:05:13 +0100        :Working: Wait for zeroadm02 is ready for the completion step of update.\r\n2020-03-05 15:05:13 +0100        :SUCCESS: Wait for zeroadm02 is ready for the completion step of update.\r\n2020-03-05 15:05:14 +0100        :Working: Initiate completion step from dbnodeupdate.sh on node(s)\r\n2020-03-05 15:12:39 +0100        :SUCCESS: Initiate completion step from dbnodeupdate.sh on zeroadm02\r\n2020-03-05 15:12:53 +0100        :SUCCESS: Initiate update on node(s).\r\n2020-03-05 15:12:53 +0100        :SUCCESS: Initiate update on 0 node(s).\r\n[INFO     ] Collected dbnodeupdate diag in file: Diag_patchmgr_dbnode_upgrade_050320141423.tbz\r\n-rw-r--r-- 1 root root 2351811 Mar  5 15:12 Diag_patchmgr_dbnode_upgrade_050320141423.tbz\r\n2020-03-05 15:12:54 +0100        :SUCCESS: Completed run of command: .\/patchmgr -dbnodes \/root\/db_group_zeroadm02 -iso_repo \/radump\/exa_stack\/p30439212_193000_Linux-x86-64.zip -target_version 19.3.2.0.0.191119 -upgrade\r\n2020-03-05 15:12:54 +0100        :INFO   : Upgrade attempted on nodes in file \/root\/db_group_zeroadm02: [zeroadm02]\r\n2020-03-05 15:12:54 +0100        :INFO   : Current image version on dbnode(s) is:\r\n2020-03-05 15:12:54 +0100        :INFO   : zeroadm02: 19.3.2.0.0.191119\r\n2020-03-05 15:12:54 +0100        :INFO   : For details, check the following files in \/radump\/exa_stack\/dbserver_patch_19.191113:\r\n2020-03-05 15:12:54 +0100        :INFO   :  - &lt;dbnode_name&gt;_dbnodeupdate.log\r\n2020-03-05 15:12:54 +0100        :INFO   :  - patchmgr.log\r\n2020-03-05 15:12:54 +0100        :INFO   :  - patchmgr.trc\r\n2020-03-05 15:12:54 +0100        :INFO   : Exit status:0\r\n2020-03-05 15:12:54 +0100        :INFO   : Exiting.\r\n\r\nYou have new mail in \/var\/spool\/mail\/root\r\n[root@zerosita01 dbserver_patch_19.191113]#<\/pre>\n<p style=\"text-align: justify;\"><strong>Post-patch of other nodes<\/strong><\/p>\n<p style=\"text-align: justify;\">After success, we can exit the session and remove the screen:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 dbserver_patch_19.191113]# exit\r\n[screen is terminating]\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# rpm -qa |grep screen\r\nscreen-4.1.0-0.25.20120314git3c2946.el7.x86_64\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# rpm -e screen-4.1.0-0.25.20120314git3c2946.el7.x86_64\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#<\/pre>\n<h3 style=\"text-align: justify;\">5 &#8211; Post-Patch<\/h3>\n<p style=\"text-align: justify;\">The post-patch is simple, we can just check the versions that we are running. If the upgrade was ok for all servers and switched (if the version is the desired one):<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# dcli -l root -g \/root\/cell_group \"imageinfo\" |grep \"Active image version\"\r\nzerocell01: Active image version: 19.3.2.0.0.191119\r\nzerocell02: Active image version: 19.3.2.0.0.191119\r\nzerocell03: Active image version: 19.3.2.0.0.191119\r\nzerocell04: Active image version: 19.3.2.0.0.191119\r\nzerocell05: Active image version: 19.3.2.0.0.191119\r\nzerocell06: Active image version: 19.3.2.0.0.191119\r\n[root@zerosita01 exa_stack]# dcli -l root -g \/root\/db_group \"imageinfo\" |grep \"Active image version\"\r\n[root@zerosita01 exa_stack]# dcli -l root -g \/root\/db_group \"imageinfo\" |grep \"Image version\"\r\nzerosita01: Image version: 19.3.2.0.0.191119\r\nzerosita02: Image version: 19.3.2.0.0.191119\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# dcli -l root -g \/root\/ib_group \"version\" |grep \"36p\"\r\nzdls-iba01: SUN DCS 36p version: 2.2.14-1\r\nzdls-ibb01: SUN DCS 36p version: 2.2.14-1\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# dcli -l root -g \/root\/cell_group \"ipmitool sunoem led get\" |grep \": SERVICE\"\r\nzerocell01: SERVICE          | OFF\r\nzerocell02: SERVICE          | OFF\r\nzerocell03: SERVICE          | OFF\r\nzerocell04: SERVICE          | OFF\r\nzerocell05: SERVICE          | OFF\r\nzerocell06: SERVICE          | OFF\r\n[root@zerosita01 exa_stack]# dcli -l root -g \/root\/db_group \"ipmitool sunoem led get\" |grep \": SERVICE\"\r\nzerosita01: SERVICE          | OFF\r\nzerosita02: SERVICE          | OFF\r\n[root@zerosita01 exa_stack]#<\/pre>\n<h3 style=\"text-align: justify;\">6 \u2013 Restart CRS and Cluster<\/h3>\n<p style=\"text-align: justify;\">Since at step 1 we stopped the cluster, we can now start CRS and GI:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# \/u01\/app\/19.0.0.0\/grid\/bin\/crsctl start crs\r\nCRS-4123: Oracle High Availability Services has been started.\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# ssh -q zerosita02\r\nLast login: Thu Mar  5 15:17:03 CET 2020 from 99.234.123.138 on ssh\r\nLast login: Thu Mar  5 15:17:10 2020 from zerosita01.zero.flisk.net\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]# \/u01\/app\/19.0.0.0\/grid\/bin\/crsctl start crs\r\nCRS-4123: Oracle High Availability Services has been started.\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]# logout\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# \/u01\/app\/19.0.0.0\/grid\/bin\/crsctl start cluster -all\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# \/u01\/app\/19.0.0.0\/grid\/bin\/crsctl start cluster -all\r\nCRS-4690: Oracle Clusterware is already running on 'zerosita01'\r\nCRS-4690: Oracle Clusterware is already running on 'zerosita02'\r\nCRS-4000: Command Start failed, or completed with errors.\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#<\/pre>\n<h2 style=\"text-align: justify;\">Finishing Patch Apply<\/h2>\n<p style=\"text-align: justify;\">After we check that everything is fine, all the patches were applied (at Storage, Database server, and InfiniBand switches), and there is no HW error (or alerts at storage side), we can finish the patch.<\/p>\n<h3 style=\"text-align: justify;\">For ZDLRA<\/h3>\n<p style=\"text-align: justify;\">If you are patching ZDLRA we need to check the OS system in this case. Since ZDLRA needs some special parameters and the OS was upgraded to the vanilla Exadata version, we need to fix it.<\/p>\n<p style=\"text-align: justify;\">This is done using the script \/<em>opt\/oracle.RecoveryAppliance\/os\/setup_os.sh<\/em> executed in both nodes:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]# \/opt\/oracle.RecoveryAppliance\/os\/setup_os.sh\r\ncat: \/opt\/oracle.SupportTools\/onecommand\/tape.xml: No such file or directory\r\nEnabled rpcbind\r\nStarted rpcbind\r\nSkipping Qlogic setup. No tape selection made.\r\nSkipping LVRADump LVM Creation. It already exists\r\n\/dev\/mapper\/VGExaDb-LVRADump: Linux rev 1.0 ext3 filesystem data, UUID=844a0941-ab23-4524-86a7-493c466b50fa, volume name \"LVRADump\" (needs journal recovery) (large files)\r\nSkipping LVRADump Filesystem Creation. It already exists\r\nSkipping \/radump mountpoint creation, it already exists\r\nSkipping fstab update. LVRADump exists.\r\n\/dev\/mapper\/VGExaDb-LVRADump on \/radump type ext3 (rw,nodev,relatime,data=ordered)\r\nSkipping LVRADump mount, it already exists.\r\nSetting oracle permissions on \/radump\r\nPermissions for oracle Set\r\ntune2fs 1.42.9 (28-Dec-2013)\r\nSetting maximal mount count to -1\r\nSetting interval between checks to 0 seconds\r\nDisabled automatic tune2fs checking of LVRADump\r\nSkipping LVRABackup LVM Creation. It already exists\r\n\/dev\/mapper\/VGExaDb-LVRABackup: Linux rev 1.0 ext3 filesystem data, UUID=36b6cee7-abb6-41c7-80bc-a4080c9180a6, volume name \"LVRABackup\" (needs journal recovery) (large files)\r\nSkipping LVRABackup Filesystem Creation. It already exists\r\nSkipping \/rabackup mountpoint creation, it already exists\r\nSkipping fstab update. LVRABackup exists.\r\n\/dev\/mapper\/VGExaDb-LVRABackup on \/rabackup type ext3 (rw,nodev,relatime,data=ordered)\r\nSkipping LVRABackup mount, it already exists.\r\nSetting oracle permissions on \/rabackup\r\nPermissions for oracle Set\r\ntune2fs 1.42.9 (28-Dec-2013)\r\nSetting maximal mount count to -1\r\nSetting interval between checks to 0 seconds\r\nDisabled automatic tune2fs checking of LVRABackup\r\nSkipping LVOBIndex LVM Creation. It already exists\r\n\/dev\/mapper\/VGExaDb-LVOBIndex: Linux rev 1.0 ext3 filesystem data, UUID=90447c5b-0bf1-4639-bfcd-1144dc1a57e4, volume name \"LVOBIndex\" (needs journal recovery) (large files)\r\nSkipping LVOBIndex Filesystem Creation. It already exists\r\nSkipping \/obindex mountpoint creation, it already exists\r\nSkipping fstab update. LVOBIndex exists.\r\n\/dev\/mapper\/VGExaDb-LVOBIndex on \/obindex type ext3 (rw,nodev,relatime,data=ordered)\r\nSkipping LVOBIndex mount, it already exists.\r\nSetting oracle permissions on \/obindex\r\nPermissions for oracle Set\r\ntune2fs 1.42.9 (28-Dec-2013)\r\nSetting maximal mount count to -1\r\nSetting interval between checks to 0 seconds\r\nDisabled automatic tune2fs checking of LVOBIndex\r\nSkipping LVRANfs LVM Creation. It already exists\r\n\/dev\/mapper\/VGExaDb-LVRANfs: Linux rev 1.0 ext3 filesystem data, UUID=90bf4fa3-385a-4b58-923c-c0a5c6651247, volume name \"LVRANfs\" (needs journal recovery) (large files)\r\nSkipping LVRANfs Filesystem Creation. It already exists\r\nSkipping \/ranfs mountpoint creation, it already exists\r\nSkipping fstab update. LVRANfs exists.\r\n\/dev\/mapper\/VGExaDb-LVRANfs on \/ranfs type ext3 (rw,nodev,relatime,data=ordered)\r\nSkipping LVRANfs mount, it already exists.\r\nSetting oracle permissions on \/ranfs\r\nPermissions for oracle Set\r\ntune2fs 1.42.9 (28-Dec-2013)\r\nSetting maximal mount count to -1\r\nSetting interval between checks to 0 seconds\r\nDisabled automatic tune2fs checking of LVRANfs\r\nSkipping adding fuse group to oracle. It exists.\r\nSkipping updates to fuse.conf. It exists.\r\nSkipping mkdir \/dbfs_obdbfs. It exists.\r\nSkipping mkdir \/dbfs_repdbfs. It exists.\r\nSkipping mkdir \/u01\/okv. It exists.\r\nSkipping mkdir \/ranfs. It exists.\r\nMoved existing \/u01\/app\/oracle\/product\/19.0.0.0\/dbhome_1\/lib\/libnnz19.so link to \/u01\/app\/oracle\/product\/19.0.0.0\/dbhome_1\/lib\/libnnz19.so.old\r\nMoved existing \/u01\/app\/oracle\/product\/19.0.0.0\/dbhome_1\/lib\/libclntsh.so.19.1 link to \/u01\/app\/oracle\/product\/19.0.0.0\/dbhome_1\/lib\/libclntsh.so.19.1.old\r\nMoved existing \/lib64\/libfuse.so.2 link to \/lib64\/libfuse.so.2.old\r\nFound user raext. Skipping\r\nFound user railm. Skipping\r\nSuccessfully modified oracle user\r\nSkipping.  denied ssh access already.\r\nWrote backup of BIOS configuration to '\/opt\/oracle.RecoveryAppliance\/config\/bios.backup.xml'.\r\nHyper-threading is disabled. Nothing to do.\r\nNo bondeth1 interface. Nothing to change.\r\nSkipping mkdir \/u01\/app\/emagent. It exists.\r\nFound uncompress. Skipping link\r\noracle crontab successfully installed.\r\n\/etc\/cron.allow successfully installed.\r\nUpdated perms on diag dir\r\nSkipping \/u01\/app\/19.0.0.0\/grid\/crs\/script\/mount-ob_dbfs.sh, not installed.\r\nSkipping \/u01\/app\/19.0.0.0\/grid\/crs\/script\/mount-rep_dbfs.sh, not installed.\r\nupdate_dbfs_script.pl - completed.\r\nZDLRA Banner already enabled, Nothing to do.\r\nexpanding \/u01...\r\nSpace available on \/u01: 630.37\r\nUnits: GiB\r\nAvailable space GiB: 630\r\nChecking the volume logical configuration...\r\nCurrent configuration: LSize\r\n300.00g\r\ncurrent \/u01 size: 296\r\n\/u01 already expanded... Skipping\r\nroot path set - file exists... Skipping\r\nFixing perms on \/raacfs\r\nFixed perms on \/raacfs\r\nFixing perms on \/osbcat\r\nFixed perms on \/osbcat\r\nSuccessfully setup OS for Recovery Appliance\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# ssh -q zerosita02\r\nLast login: Thu Mar  5 15:23:49 CET 2020 from 99.234.123.138 on ssh\r\nLast login: Thu Mar  5 15:24:40 2020 from zerosita01.zero.flisk.net\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]# \/opt\/oracle.RecoveryAppliance\/os\/setup_os.sh\r\ncat: \/opt\/oracle.SupportTools\/onecommand\/tape.xml: No such file or directory\r\nEnabled rpcbind\r\nStarted rpcbind\r\nSkipping Qlogic setup. No tape selection made.\r\nSkipping LVRADump LVM Creation. It already exists\r\n\/dev\/mapper\/VGExaDb-LVRADump: Linux rev 1.0 ext3 filesystem data, UUID=0868744a-fdae-46ab-9629-c7102bdae0b8, volume name \"LVRADump\" (needs journal recovery) (large files)\r\nSkipping LVRADump Filesystem Creation. It already exists\r\nSkipping \/radump mountpoint creation, it already exists\r\nSkipping fstab update. LVRADump exists.\r\n\/dev\/mapper\/VGExaDb-LVRADump on \/radump type ext3 (rw,nodev,relatime,data=ordered)\r\nSkipping LVRADump mount, it already exists.\r\nSetting oracle permissions on \/radump\r\nPermissions for oracle Set\r\ntune2fs 1.42.9 (28-Dec-2013)\r\nSetting maximal mount count to -1\r\nSetting interval between checks to 0 seconds\r\nDisabled automatic tune2fs checking of LVRADump\r\nSkipping LVRABackup LVM Creation. It already exists\r\n\/dev\/mapper\/VGExaDb-LVRABackup: Linux rev 1.0 ext3 filesystem data, UUID=c4bdfce5-522f-4597-bd37-0298b0cfc052, volume name \"LVRABackup\" (needs journal recovery) (large files)\r\nSkipping LVRABackup Filesystem Creation. It already exists\r\nSkipping \/rabackup mountpoint creation, it already exists\r\nSkipping fstab update. LVRABackup exists.\r\n\/dev\/mapper\/VGExaDb-LVRABackup on \/rabackup type ext3 (rw,nodev,relatime,data=ordered)\r\nSkipping LVRABackup mount, it already exists.\r\nSetting oracle permissions on \/rabackup\r\nPermissions for oracle Set\r\ntune2fs 1.42.9 (28-Dec-2013)\r\nSetting maximal mount count to -1\r\nSetting interval between checks to 0 seconds\r\nDisabled automatic tune2fs checking of LVRABackup\r\nSkipping LVOBIndex LVM Creation. It already exists\r\n\/dev\/mapper\/VGExaDb-LVOBIndex: Linux rev 1.0 ext3 filesystem data, UUID=5dcf5c69-ded6-4fc5-a5f0-3a9f3435681c, volume name \"LVOBIndex\" (needs journal recovery) (large files)\r\nSkipping LVOBIndex Filesystem Creation. It already exists\r\nSkipping \/obindex mountpoint creation, it already exists\r\nSkipping fstab update. LVOBIndex exists.\r\n\/dev\/mapper\/VGExaDb-LVOBIndex on \/obindex type ext3 (rw,nodev,relatime,data=ordered)\r\nSkipping LVOBIndex mount, it already exists.\r\nSetting oracle permissions on \/obindex\r\nPermissions for oracle Set\r\ntune2fs 1.42.9 (28-Dec-2013)\r\nSetting maximal mount count to -1\r\nSetting interval between checks to 0 seconds\r\nDisabled automatic tune2fs checking of LVOBIndex\r\nSkipping LVRANfs LVM Creation. It already exists\r\n\/dev\/mapper\/VGExaDb-LVRANfs: Linux rev 1.0 ext3 filesystem data, UUID=2e2917e3-8c7f-4b23-b46d-247e1a26b2bd, volume name \"LVRANfs\" (needs journal recovery) (large files)\r\nSkipping LVRANfs Filesystem Creation. It already exists\r\nSkipping \/ranfs mountpoint creation, it already exists\r\nSkipping fstab update. LVRANfs exists.\r\n\/dev\/mapper\/VGExaDb-LVRANfs on \/ranfs type ext3 (rw,nodev,relatime,data=ordered)\r\nSkipping LVRANfs mount, it already exists.\r\nSetting oracle permissions on \/ranfs\r\nPermissions for oracle Set\r\ntune2fs 1.42.9 (28-Dec-2013)\r\nSetting maximal mount count to -1\r\nSetting interval between checks to 0 seconds\r\nDisabled automatic tune2fs checking of LVRANfs\r\nSkipping adding fuse group to oracle. It exists.\r\nSkipping updates to fuse.conf. It exists.\r\nSkipping mkdir \/dbfs_obdbfs. It exists.\r\nSkipping mkdir \/dbfs_repdbfs. It exists.\r\nSkipping mkdir \/u01\/okv. It exists.\r\nSkipping mkdir \/ranfs. It exists.\r\nMoved existing \/u01\/app\/oracle\/product\/19.0.0.0\/dbhome_1\/lib\/libnnz19.so link to \/u01\/app\/oracle\/product\/19.0.0.0\/dbhome_1\/lib\/libnnz19.so.old\r\nMoved existing \/u01\/app\/oracle\/product\/19.0.0.0\/dbhome_1\/lib\/libclntsh.so.19.1 link to \/u01\/app\/oracle\/product\/19.0.0.0\/dbhome_1\/lib\/libclntsh.so.19.1.old\r\nMoved existing \/lib64\/libfuse.so.2 link to \/lib64\/libfuse.so.2.old\r\nFound user raext. Skipping\r\nFound user railm. Skipping\r\nSuccessfully modified oracle user\r\nSkipping.  denied ssh access already.\r\nWrote backup of BIOS configuration to '\/opt\/oracle.RecoveryAppliance\/config\/bios.backup.xml'.\r\nHyper-threading is disabled. Nothing to do.\r\nNo bondeth1 interface. Nothing to change.\r\nSkipping mkdir \/u01\/app\/emagent. It exists.\r\nFound uncompress. Skipping link\r\noracle crontab successfully installed.\r\n\/etc\/cron.allow successfully installed.\r\nUpdated perms on diag dir\r\nSkipping \/u01\/app\/19.0.0.0\/grid\/crs\/script\/mount-ob_dbfs.sh, not installed.\r\nSkipping \/u01\/app\/19.0.0.0\/grid\/crs\/script\/mount-rep_dbfs.sh, not installed.\r\nupdate_dbfs_script.pl - completed.\r\nZDLRA Banner already enabled, Nothing to do.\r\nexpanding \/u01...\r\nSpace available on \/u01: 630.37\r\nUnits: GiB\r\nAvailable space GiB: 630\r\nChecking the volume logical configuration...\r\nCurrent configuration: LSize\r\n300.00g\r\ncurrent \/u01 size: 296\r\n\/u01 already expanded... Skipping\r\nroot path set - file exists... Skipping\r\nFixing perms on \/raacfs\r\nFixed perms on \/raacfs\r\nFixing perms on \/osbcat\r\nFixed perms on \/osbcat\r\nSuccessfully setup OS for Recovery Appliance\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]#\r\n[root@zerosita02 ~]# exit\r\nlogout\r\n[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]#<\/pre>\n<h3 style=\"text-align: justify;\">Startup ZDLRA<\/h3>\n<p style=\"text-align: justify;\">And after that we can startup the ZDLRA database (and RA software) that we stopped in the beginning:<\/p>\n<pre class=\"EnlighterJSRAW\" data-enlighter-language=\"raw\">[root@zerosita01 exa_stack]#\r\n[root@zerosita01 exa_stack]# su - oracle\r\nLast login: Thu Mar  5 15:26:22 CET 2020 from 99.234.123.138 on ssh\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$ srvctl start database -d zdlras\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$ sqlplus rasys\/ra\r\n\r\nSQL*Plus: Release 19.0.0.0.0 - Production on Thu Mar 5 15:28:00 2020\r\nVersion 19.3.0.0.0\r\n\r\nCopyright (c) 1982, 2019, Oracle.  All rights reserved.\r\n\r\nLast Successful login time: Thu Mar 05 2020 11:24:37 +01:00\r\n\r\nConnected to:\r\nOracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\r\nVersion 19.3.0.0.0\r\n\r\nSQL&gt; SELECT state FROM ra_server;\r\n\r\nSTATE\r\n-------------\r\nOFF\r\n\r\nSQL&gt; exec dbms_ra.startup;\r\n\r\nPL\/SQL procedure successfully completed.\r\n\r\nSQL&gt; SELECT state FROM ra_server;\r\n\r\nSTATE\r\n-------------\r\nON\r\n\r\nSQL&gt; exit\r\nDisconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production\r\nVersion 19.3.0.0.0\r\n[oracle@zerosita01 ~]$\r\n[oracle@zerosita01 ~]$<\/pre>\n<h2 style=\"text-align: justify;\">Conclusion<\/h2>\n<p style=\"text-align: justify;\">Patching Oracle Engineering System is not complicated, but some details need to be checked to do correctly. The way that we patch (Rolling\/Non-Rolling), files with the hostname, the ssh between servers, version, and files used are important. Several details that were showed above.<\/p>\n<p style=\"text-align: justify;\">For ZDLRA it is more rigid since we need to take care of the ZDLRA database, RA software, and operating system parameters.<\/p>\n<p style=\"text-align: justify;\">It is impossible to describe all the details in one post, maybe one post for every step (like the file with the hostnames of servers that we will apply the patch and pass as parameter of patchmgr, or some details about how to patch in rolling mode). But I tried to cover all the points here (and in my <a href=\"https:\/\/www.fernandosimon.com\/blog\/reaching-exadata-18c\/\">previous post<\/a> about the same topic). With this post, I think that you can have one idea and use it as a guide to patching the Exadata stack. The steps are in order and if you have doubts, comment here.<\/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. Post protected by copyright.\u201d<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>The process to patch Exadata stack and software changed in the last years and it became easier. Now, with patchmgr to be used for all (database servers, storage cells, and switches) the process is much easier to control the steps. Here I will show the steps that are involved in this process. Independent if it [&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_post_was_ever_published":false,"_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}},"categories":[29,60,77,6,5,13,9,12,51],"tags":[100,69,65,135,124,74],"class_list":["post-724","post","type-post","status-publish","format-standard","hentry","category-database","category-database-server","category-engineeredsystems","category-exadata","category-oracle","category-patchmgr","category-storage-server","category-upgrade","category-zdlra","tag-engineered-systems","tag-exadata","tag-oracle","tag-patch","tag-upgrade","tag-zdlra"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v26.8 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Exadata and ZDLRA, Patch Exadata Stack - Fernando Simon<\/title>\n<meta name=\"description\" content=\"Detailed post about how to patch Exadata Stack and software at Engineering System appliances. Includes steps on how to do for ZDLRA.\" \/>\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\/exadata-and-zdlra-patch-exadata-stack\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Exadata and ZDLRA, Patch Exadata Stack - Fernando Simon\" \/>\n<meta property=\"og:description\" content=\"Detailed post about how to patch Exadata Stack and software at Engineering System appliances. Includes steps on how to do for ZDLRA.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/\" \/>\n<meta property=\"og:site_name\" content=\"Fernando Simon\" \/>\n<meta property=\"article:published_time\" content=\"2020-04-21T00:23:35+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2020-07-19T22:08:58+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png\" \/>\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=\"54 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/\"},\"author\":{\"name\":\"Simon\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"headline\":\"Exadata and ZDLRA, Patch Exadata Stack\",\"datePublished\":\"2020-04-21T00:23:35+00:00\",\"dateModified\":\"2020-07-19T22:08:58+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/\"},\"wordCount\":2087,\"commentCount\":4,\"image\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png\",\"keywords\":[\"Engineered Systems\",\"Exadata\",\"Oracle\",\"Patch\",\"Upgrade\",\"ZDLRA\"],\"articleSection\":[\"Database\",\"Database Server\",\"Engineered Systems\",\"Exadata\",\"Oracle\",\"patchmgr\",\"Storage Server\",\"Upgrade\",\"ZDLRA\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/\",\"name\":\"Exadata and ZDLRA, Patch Exadata Stack - Fernando Simon\",\"isPartOf\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png\",\"datePublished\":\"2020-04-21T00:23:35+00:00\",\"dateModified\":\"2020-07-19T22:08:58+00:00\",\"author\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9\"},\"description\":\"Detailed post about how to patch Exadata Stack and software at Engineering System appliances. Includes steps on how to do for ZDLRA.\",\"breadcrumb\":{\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#primaryimage\",\"url\":\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png\",\"contentUrl\":\"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.fernandosimon.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Exadata and ZDLRA, Patch Exadata Stack\"}]},{\"@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:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/image\/\",\"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":"Exadata and ZDLRA, Patch Exadata Stack - Fernando Simon","description":"Detailed post about how to patch Exadata Stack and software at Engineering System appliances. Includes steps on how to do for ZDLRA.","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\/exadata-and-zdlra-patch-exadata-stack\/","og_locale":"en_US","og_type":"article","og_title":"Exadata and ZDLRA, Patch Exadata Stack - Fernando Simon","og_description":"Detailed post about how to patch Exadata Stack and software at Engineering System appliances. Includes steps on how to do for ZDLRA.","og_url":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/","og_site_name":"Fernando Simon","article_published_time":"2020-04-21T00:23:35+00:00","article_modified_time":"2020-07-19T22:08:58+00:00","og_image":[{"url":"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png","type":"","width":"","height":""}],"author":"Simon","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Simon","Est. reading time":"54 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#article","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/"},"author":{"name":"Simon","@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"headline":"Exadata and ZDLRA, Patch Exadata Stack","datePublished":"2020-04-21T00:23:35+00:00","dateModified":"2020-07-19T22:08:58+00:00","mainEntityOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/"},"wordCount":2087,"commentCount":4,"image":{"@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#primaryimage"},"thumbnailUrl":"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png","keywords":["Engineered Systems","Exadata","Oracle","Patch","Upgrade","ZDLRA"],"articleSection":["Database","Database Server","Engineered Systems","Exadata","Oracle","patchmgr","Storage Server","Upgrade","ZDLRA"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/","url":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/","name":"Exadata and ZDLRA, Patch Exadata Stack - Fernando Simon","isPartOf":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#primaryimage"},"image":{"@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#primaryimage"},"thumbnailUrl":"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png","datePublished":"2020-04-21T00:23:35+00:00","dateModified":"2020-07-19T22:08:58+00:00","author":{"@id":"https:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/386da956604bca0d5be5dd52210c1dd9"},"description":"Detailed post about how to patch Exadata Stack and software at Engineering System appliances. Includes steps on how to do for ZDLRA.","breadcrumb":{"@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#primaryimage","url":"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png","contentUrl":"https:\/\/www.fernandosimon.com\/blog\/wp-content\/uploads\/2020\/04\/ZDLRA-PATCH-02-ORG.png"},{"@type":"BreadcrumbList","@id":"https:\/\/www.fernandosimon.com\/blog\/exadata-and-zdlra-patch-exadata-stack\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.fernandosimon.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Exadata and ZDLRA, Patch Exadata Stack"}]},{"@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:\/\/www.fernandosimon.com\/blog\/#\/schema\/person\/image\/","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-bG","_links":{"self":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/724","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=724"}],"version-history":[{"count":0,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/posts\/724\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/media?parent=724"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/categories?post=724"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fernandosimon.com\/blog\/wp-json\/wp\/v2\/tags?post=724"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}