{"id":720,"date":"2020-04-13T17:32:17","date_gmt":"2020-04-13T20:32:17","guid":{"rendered":"http:\/\/www.fernandosimon.com\/blog\/?p=720"},"modified":"2020-07-19T19:09:26","modified_gmt":"2020-07-19T22:09:26","slug":"zdlra-patch-the-recovery-appliance","status":"publish","type":"post","link":"https:\/\/www.fernandosimon.com\/blog\/zdlra-patch-the-recovery-appliance\/","title":{"rendered":"ZDLRA, Patch the Recovery Appliance"},"content":{"rendered":"

The proceed to patch\/upgrade ZDLRA is not complicated, but as usual, some details need to be checked before starting the procedure. Since it is one engineering system based at Exadata, the procedure has one part that (maybe) needs to upgrade this stack too. But, is possible to upgrade just the recovery appliance library.<\/p>\n

Whatever if need or no to upgrade the Exadata stack, the upgrade for recovery appliance library is the same. The commands and checks are the same. The procedure described in this post cover the upgrade of the recovery appliance library. For Exadata stack, it is in another post.<\/p>\n

Where we are<\/h2>\n

Before even start the patch\/upgrade it is important to know exactly which version you are running. To do this execute the command racli version at you database node:<\/p>\n

[root@zeroinsg01 ~]# racli version\r\nRecovery Appliance Version:\r\n        exadata image: 19.2.3.0.0.190621\r\n        rarpm version: ra_automation-12.2.1.1.2.201907-30111072.x86_64\r\n        rdbms version: RDBMS_12.2.0.1.0_LINUX.X64_RELEASE\r\n        transaction  : kadjei_julpsu_ip2\r\n        zdlra version: ZDLRA_12.2.1.1.2.201907_LINUX.X64_RELEASE\r\n[root@zeroinsg01 ~]#<\/pre>\n
With this, we can discover the ZDLRA version running (12.2.1.1.2.201907 in this case), and the Exadata image version (19.2.3.0.0.190621).<\/p>\n
<\/p>\n
Supported versions<\/h2>\n
Whatever what it is needed to upgrade, the startup point it is the note 1927416.1<\/a> that cover the supported versions for ZDLRA. There it is possible to find all the supported versions for the recovery appliance library as well as the Exadata versions. Please, not upgrade the Exadata stack with a version that is not listed on this page.<\/p>\n
In the note, it is possible to choose what version is the target. Here in this post, my target version is 19.2.1.1.1-202001-31014797, patch 31014797 (Patch 31014797: ZDLRA 19.2.1.1.1.202001 (JAN) INTERIM PATCH 3)<\/a>. So, with this is possible to check what we can use and do. The first thing to check is the compatibility matrix between the ZDLRA version and the Exadata version.<\/p>\n
Since we know the version that we are running at our Exadata image and the version that we want to go as ZDLRA, we can see if we are compatible.<\/p>\n
\"\"<\/a><\/p>\n
Look the image above, it is marked the versions that are the target, and the Exadata that is actually running. And as you can see, this pair is supported, and we can continue. But before, some details.<\/p>\n
It can occur that when you are jumping a lot of versions that you need to upgrade more than one version. Maybe it is possible that you need to first apply one intermediate version of Exadata Software or ZDLRA before you reach your desired version.<\/p>\n
Another thing that you need to take care of is the switch version for your Exadata.  Again, if you are jumping a lot of versions, maybe you need to upgrade the InfiniBand\/RCoE more than one time, first to intermediate version and after to the desired one.<\/p>\n
Who does what?<\/h2>\n
Different from Exadata Patch for Oracle Home and Grid Infrastructure (where you are responsible to apply the patches for them), it is ZDLRA itself that upgrades OH and GI. So, the patch\/upgrade for ZDLRA includes the needed PSU\u2019s for GI and OH.<\/p>\n
But it is fundamental to check the readme of the ZDLRA release that will be applied. In this case, since the actual version for GI and OH is 12.2 and the target is 19c (for both), some details need to be checked because the requirements need to be ok.<\/p>\n
In this case, the readme can be used as a guide, but also de default documentation for GI update and upgrade docs can be used too. The ZDLRA patch will fix\/set some parameters for the operational system, but this does not cover all the corners.<\/p>\n
It is important to say\/write that if something is wrong with the system, it is a requirement to open SR to the ZDLRA team. ZDLRA is one engineering system more closed than Exadata, every change needs to be validated previously. <\/strong><\/p>\n
The ZDLRA patch will run the cluvfy for GI and this will point what needs to be fixed. One example of something that needs to fix previously is the HAIP. It needs to be removed. I wrote one post on how to do that, you can access it here<\/a>.<\/p>\n
Since this patch\/upgrade will do the GI upgrade from 12.2 to 19c we can use the note 2542082.1<\/a> as a base to do a crosscheck if something is needed to be fixed when (or if) pointed by cluvfy. Some examples are hugepages that need to be increased, and NTP that need to clean some file that remains in the system.<\/p>\n
The idea to do the crosscheck manually previously is avoiding errors during the racli upgrade. One example for HAIP:<\/p>\n
[root@zeroinsg01 ~]# \/opt\/oracle.RecoveryAppliance\/bin\/racli upgrade appliance --step=2;\r\nCreated log \/opt\/oracle.RecoveryAppliance\/log\/racli_upgrade_appliance.log\r\n\r\nStep [2 of 5]: <racli upgrade appliance>\r\n\r\nMon Dec  9 13:20:16 2019: Start: Upgrade Recovery Appliance - Step [PreCheck]\r\n...\r\n...\r\nMon Dec  9 13:40:32 2019: Failed: Cluster Pre Check -\r\nVerifying Physical Memory \r\n...\r\nVerifying Kernel retpoline support ...PASSED\r\n\r\nPre-check for cluster services setup was unsuccessful.\r\nChecks did not pass for the following nodes:\r\n        zeroinsg02,zeroinsg01\r\n\r\n\r\nFailures were encountered during execution of CVU verification request \"stage -pre crsinst\".\r\n\r\nVerifying Node Connectivity ...FAILED\r\nzeroinsg02: PRVG-11068 : Highly Available IP (HAIP) is enabled on the nodes\r\n            \"zeroinsg01,zeroinsg02\".\r\n\r\nzeroinsg01: PRVG-11068 : Highly Available IP (HAIP) is enabled on the nodes\r\n            \"zeroinsg01,zeroinsg02\".\r\n\r\nVerifying RPM Package Manager database ...INFORMATION\r\nPRVG-11250 : The check \"RPM Package Manager database\" was not performed because\r\nit needs 'root' user privileges.\r\n\r\n\r\nCVU operation performed:      stage -pre crsinst\r\nDate:                         Dec 9, 2019 1:38:46 PM\r\nCVU home:                     \/u01\/app\/19.0.0.0\/grid\/\r\nUser:                         oracle\r\n Failed: 1 ()\r\n at \/u01\/app\/oracle\/product\/12.2.0.1\/dbhome_1\/perl\/lib\/site_perl\/5.22.0\/RA\/Install.pm line 1417.\r\n[root@zeroinsg01 ~]#<\/pre>\n
Patching\/Upgrading<\/h2>\n
1 – Download the release<\/h3>\n
Depending on what you need or want to upgrade you need to download one or more patches. For this post, I will use just the recovery appliance rpm.<\/p>\n
So, the first was to download the patch Recovery Appliance 19.2.1.1.1-202001-31014797:<\/p>\n
\"\"<\/a><\/p>\n
This release contains all the PSU\u2019s and patchsets needed for the upgrade (if needed). But one detail is needed to download base release (for GI and OH) if you are upgrading the version of ZDLRA.<\/p>\n
Reading the readme of the Recovery Appliance patch we can see that it will upgrade the GI and OH to 19c. The patch for ZDLRA includes just the PSU\u2019s, it does not contain the initial release of the GI 19c and OH 19c<\/strong>. You need to download it separately.<\/p>\n
In this post, I will do that. So, it is needed to download the packages for the RDBMS Binary zip file (V982063-01.zip) and Grid Binary zip file (V982068-01.zip) from https:\/\/edelivery.oracle.com<\/a>. If you do not download it, you will receive an error when trying to do the patch.<\/p>\n
2- Where put the files<\/h3>\n
All the files for ZDLRA needs to be stored at \/radump at the database server node 01.<\/strong> It is fixed in the procedure and it is a requirement.<\/p>\n
As best practices, I recommend that before copy the new files, remove all older patches from \/radump in both nodes<\/strong>. And this include files that are inside the ZDLRA patch (like ra_init_param_check.pl, load_init_param.sh, load_init_param.pl,  dbmsrsadm.sql, dbmsrsadmpreq.sql, prvtrsadm.sql, ra_preinstall.pl).<\/p>\n
So, I copied the files from my NFS to \/radump:<\/p>\n
[oracle@zeroinsg01 ~]$ cd \/radump\/\r\n[oracle@zeroinsg01 radump]$\r\n[oracle@zeroinsg01 radump]# cp \/tmp\/zfs\/EXADATA_PATCHING\/19c\/Exadata-Patch\/19c-Grid\/V982068-01.zip \/radump\/\r\n[oracle@zeroinsg01 radump]# cp \/tmp\/zfs\/EXADATA_PATCHING\/19c\/Exadata-Patch\/19c-OH\/V982063-01.zip \/radump\/\r\n[oracle@zeroinsg01 radump]$ cp \/tmp\/zfs\/ZDLRA_PATCHING\/19.2.1.1.1-202001-31014797\/p31014797_192111_Linux-x86-64.zip \/radump\/\r\n[oracle@zeroinsg01 radump]$<\/pre>\n
Files copied:<\/p>\n