Recently I executed the upgrade of Oracle GI to 19c version, from 18.104.22.168 to 22.214.171.124 version. But one step that was not showed there was that, because of requirements, the GI was upgraded from 126.96.36.199 to 188.8.131.52. This upgrade is a just Release Update (RU) apply and opatchauto command.
But during this upgrade, from 18.2 to 18.6, I faced (more than one time – 5 to be precise) errors during the update because of the MGMTDB errors. I got these errors:
ORA-12514, TNS: Listener does not currently know of service requested in connect descriptor
CRS-10407: (:CLSCRED1079:)Credential domain does not exist.
Here I will show how to solve these errors, how to identify if everything was fine and if you can continue. Be careful that it is an example, always open a support SR to identify the source of the error.
Recently I made an Exadata stack upgrade/update to the last 19.2 version (184.108.40.206.0.191012) and I upgraded the GI from 18c to 19c (last 19c version – 220.127.116.11.191015) and after that, TFA does not work.
Since I don’t want to complete execute a TFA clean and reinstallation I tried to find the error and the solution. Here I want to share with you the workaround (since there is no solution yet) that I discovered and used to fix the error.
The actual environment is:
Old Grid Infrastructure: Version 18.104.22.168.190416
New Grid Infrastructure: Version 22.214.171.124.191015
Exadata domU: Version 126.96.36.199.0.191012 running kernel 4.1.12-124.30.1.el7uek.x86_64
After upgrade the GI from 18c to 19c, the TFA does not work. If you try to start it or collect log using it, you can receive errors. In the environment described here, the TFA was running fine with the 18c version, and the rootupgrade script from 18c to 19c does not report an error.
And to be more precise, the TFA upgrade from 18c to 19c called by rootupgrade was ok (according to the log – I will show later). But even after that, the error occurs.
The provided solution as usual (by MOS support): download the lastest TFA and reinstall the actual one. Unfortunately, I not like this approach because can lead to an error during GI upgrade for next releases (like 20) and updates (19.6 as an example).
The idea to reimage ODA is to refresh the environment without the need to jump from one by one to reach the last available version, or even rescue the system from S.O. failure/crash. The process to do a reimage can be check in the official documentation but unfortunately can be very tricky because the information (the order and steps) are not 100% clear. The idea is to show you how to reimage using version 18 (18.3 in this example), that represents the last available.
Here I cover in raw, undocumented and uncommented mode the process to update and upgrade your Exadata using the last version of everything. AND since Oracle 18c was released to use with Oracle Exadata (from SQL Maria), this post include the Oracle 18c upgrade for Grid Infrastructure and Oracle database binaries installation.
Since one friend was decommissioning one old Exadata X2 (running after the end of life), I used to do some tests and here you will find the commands, outputs, images that I use to (in order):
Apply the patch 188.8.131.52.180116 for Oracle Grid Infrastructure 12.1.
Update the Infiniband switches to last version 2.2.7-1.
Apply the patch for Exadata Storage Server using the last version, 184.108.40.206.0.180125.3.
Apply the patch for Exadata Database Servers using the last version, 220.127.116.11.0.180125.3
Upgrade the Oracle Grid Infrastructure 12.1 to Grid Infrastructure 12.2, applying PSU 18.104.22.168.180116 at same time.
Upgrade the Oracle Grid Infrastructure 12.2 to Oracle Grid Infrastructure 18c.
Install Oracle database binaries for Oracle Database 18c and Create a test Oracle Rac Instance.