opatch lsinv doesn’t show Patching level of clusternodes

cluster_patch

 

 

 

We had a strange behaviour while running the „opatch lsinv“ in our Clusterware environment.

The opatch tool doesn’t show at the end the patchlevel and the name of the nodes itself.

It seems that during a lot of patch actions on this cluster that we lost the information inside the inventory.xml file that the CRS is equal true.

After researching of MOS we found a solution for this problem described in Doc-ID 1053393.1.

There ist a possibility to Update a flag CRS=true via the runinstaller in the GRID environment.

So the steps to fix this problem are the following

Our environment is a two node Oracle Enterprise Linux RAC Cluster with GI Software 12.1.0.2.


/u01/app/12.1.0.2/grid/oui/bin/runInstaller 
    -updateNodelist ORACLE_HOME="/u01/app/12.1.0.2/grid" CRS=true

Starting Oracle Universal Installer...

Checking swap space: must be greater than 500 MB. Actual 24575 MB Passed
The inventory pointer is located at /etc/oraInst.loc

'UpdateNodeList' was successful.

The "opatch lsinv" command show now the correct Patching Level and name of the Cluster nodes.

node1
Patch level status of Cluster nodes :

Patching Level Nodes
-------------- -----
1146027977 node2,node1

--------------------------------------------------------------------------------
node2
Patch level status of Cluster nodes :

Patching Level Nodes
-------------- -----
1146027977 node2,node1

--------------------------------------------------------------------------------
OPatch succeeded.

Additonal information

Check the software Patching level via the following command and compare the output with the „opatch lsinv“ as shown above.

[oracle@node1 ~]$crsctl query crs softwarepatch
Oracle Clusterware patch level on node node1 is [1146027977]

Yes, it is a good idea from time to time to check if both commands have the same output and also to update the opatch tool in your environment.

The latest opatch version can be downloaded via MOS link https://updates.oracle.com/download/6880880.html

 

 

 

Advertisements

Oracle Exadata and the glibc vulnerability (CVE-2015-7547)

Ora_Security_Patch

 

I think most of us heard about the „glibc“ vulnerability (CVE-2015-7547). We had a lot of Exadata Servers  and so we discuss how we could install the new rpm’s.

Yes, it seems to be no problem while My Oracle Support Doc-ID 2108582.1 describes what we had to do and by the way at the end of this procedure you had to reboot every DB Node and also every Cell Server. (While rebooting the Cell Server please read before the Doc-ID. 1188080.1.)

The note 2108582.1 said it is not necessary to do a relink but is this correct?

I was a little bit confused and I checked the Oracle Documentation and My Oracle Support again and I found  another Doc ID 1467060.1 „Relinking Oracle Home FAQ ( Frequently Asked Questions) “ which said that if you install an OS Patch than Oracle recommend to do a relink.

And in the Oracle Database Administrator Guide  was written that Oracle recommend to do an relink after Patching the OS.

We found for us a solution because we install the new rpm’s in conjunction with the Jan-2016 Patchbundle. During the Patchbundle Installation the relink was done automatically.

Keep in mind that Oracle Documentation recommend to do a relink no matter what an MOS Doc-ID said.