Skip navigation

Hello Oracle Community,

Sharing this recent experience around enabling X11 on Exadata after running into similarly the same confusion back in 2016 and now in 2018.


First, we had ran into an issue with enabling X11 on Exadata compute nodes in May-June 2016 which was ultimately resolved by installing additional RPMs to support X11.

We had worked with several hardware and software versions of Exadata prior to that and never needed to install the additional RPMs before.

There were other issues preventing DBAs, for example, from running X11 based tools like dbca or runInstaller.

Some of them were due to X11 forwarding not being enabled in the sshd_config file or the firewall rules or the issues with the DISPLAY variable ,

especially when running X11 based tools over the VPN connection.


We had an SR opened for that issue and we were told that there were some recent changes to the Exadata image and several X11 RPMs didn't make it anymore as far as being part of the default Exadata image.


Fast forward 2+ years and we are in a very similar situation in 2018.

More specifically, Exadata machines that were deployed with the image version from January 2018 were "missing" a few X11 RPMs while Exadata machines deployed with the image version from May 2018 didn't require any additional X11 RPMs.


The moral of this story , as I see it, is that this well tested Oracle Support DocID is still your good friend when it comes to troubleshooting X11 on Exadata compute nodes.

Unable to run graphical tools (gui) (runInstaller, dbca and dbua) on Exadata - 18.1.X.X.X (Doc ID 1969308.1)


Thank you for reading, Slava Urbanovich


Sharing this recent experience around having to replace an IB switch in the Exalogic machine due to the hardware failure.

It has started as a fairly simple maintenance related to a hardware failure on the redundant equipment - such as IB switch in Exalogic machine.


Hardware failures do happen and IB switches are no exception to that rule. Also, IB switches in Exalogic machines aren't customer serviceable units or CRUs.

Thus everything looks fairly simple, right ? With either ASR or OEM or something else  reporting a hardware failure an SR gets created, initial troubleshooting and RCA are done and Oracle Field Engineer has been scheduled to replace the failed IB switch.

So far so good.


At the agreed upon time, Oracle FE shows up at your datacenter , replaces the IB switch, matches the firmware on the replacement switch to the healthy one, configures ILOM and management on the new IB switch, declares "Mission Accomplished" (remember that banner on the carrier?) and leaves.


You also run Exachk report and it comes back clean - life is good, right ? Wrong. Very wrong unfortunately.


Even though IB switch isn't customer serviceable indeed, restoring configuration on it is.

Essentially, if you - the customer - haven't followed this MOS document immediately after Exalogic IB switch replacement you are exposed for a big problem.

Exalogic Infiniband Switch Replacement - Follow-up Actions (Restoration) (Doc ID 2218689.1)


How big of a problem one may ask ? Think of the complete outage of all VMs running on that Exalogic machine, all at once.

This is what just happened to one of our customer.


The moral of the story here is very simple - don't accept FEs report that everything is good since everything is good just from the HW perspective.

Your freshly replaced IB switch still has no configuration on it and in a case of the IB fail-over attempt, planned or un-planned, your Exalogic customers could get agitated very quickly.


Make sure to follow all the steps from this document and perform a fail-over test for at least one of the VMs.

Hope this article saves you from a major Exalogic outage or at least allows you to recover from it as quickly as possible.

Thank you for reading, Slava Urbanovich