| Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback |
| Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition | ||
|
|
||
 |
||||||||||||
Solution Type Problem Resolution Sure Solution 1585356.1 : Different Checksum(md5sum) For The Oracle Binaries In Two Different Nodes Of An Exadata Rack.
After patching md5sum and cksum are found to be different for oracle binaries in the two different nodes of an exadata rack. Created from <SR 3-7772158783> Applies to:Linux OS - Version Oracle Linux 5.0 and laterOracle Exadata Storage Server Software - Version 11.2.2.1.0 and later Oracle Exadata Hardware - Version 11.2.0.1 and later Exadata Database Machine V2 - Version All Versions and later Exadata Database Machine X2-2 Hardware - Version All Versions and later Information in this document applies to any platform. SymptomsAfter patching , checksum(md5sum or cksum) of the Oracle binaries of the cluster nodes of an Exadata Rack are found to be different. [oracle@db01 ~]$ dcli -l oracle -g /opt/oracle.SupportTools/onecommand/dbs_group md5sum /u01/app/oracle/product/11.2.0.3/dbhome_1/bin/oracle Size of executable 'oracle' and number of patches applied on both ORACLE_HOMEs are the same.
ChangesApplied a bundle patch. CauseOracle binaries contain information about the various tools used in the linking including their versions. When the binaries are compared using a binary comparison utility the following information is seen. Node1
B5ECD59 ed 06 09 00 00 00 00 5e ed 06 09 00 00 00 00 94 ef 06 09 00 00 00 00 94 ee 06 09 00 00 00 00 b2 f2 06 09 00 00 00 00 .......^............................... B5ECD80 00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e 31 2e 32 20 32 30 30 38 30 37 30 34 20 28 52 65 64 20 48 61 74 20 34 2e 31 .GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1 B5ECDA7 2e 32 2d 35 31 29 00 00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e 31 2e 32 20 32 30 30 38 30 37 30 34 20 28 52 65 64 20 .2-51)..GCC: (GNU) 4.1.2 20080704 (Red B5ECDCE 48 61 74 20 34 2e 31 2e 32 2d 35 31 29 00 00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e 31 2e 32 20 32 30 30 38 30 37 30 Hat 4.1.2-51)..GCC: (GNU) 4.1.2 2008070 Node 2: B5ECD59 ed 06 09 00 00 00 00 5e ed 06 09 00 00 00 00 94 ef 06 09 00 00 00 00 94 ee 06 09 00 00 00 00 b2 f2 06 09 00 00 00 00 .......^............................... B5ECD80 00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e 31 2e 32 20 32 30 30 38 30 37 30 34 20 28 52 65 64 20 48 61 74 20 34 2e 31 .GCC: (GNU) 4.1.2 20080704 (Red Hat 4.1 B5ECDA7 2e 32 2d 34 38 29 00 00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e 31 2e 32 20 32 30 30 38 30 37 30 34 20 28 52 65 64 20 .2-48)..GCC: (GNU) 4.1.2 20080704 (Red B5ECDCE 48 61 74 20 34 2e 31 2e 32 2d 34 38 29 00 00 47 43 43 3a 20 28 47 4e 55 29 20 34 2e 31 2e 32 20 32 30 30 38 30 37 30 Hat 4.1.2-48)..GCC: (GNU) 4.1.2 2008070 Above it is seen that the version of the GCC compiler recorded in the binary is different in each node.This leads to md5sum generating non-identical MD5 hash for the oracle binary across the nodes. SolutionNo action is needed if only a mismatch in the md5sum/cksum across nodes is observed, with no other issues present. As illustrated above, it can result due to differences in the OS package versions present in the nodes at time of relink. If other issues are present and the possibility of a corrupted binary must be eliminated, a relink of the oracle binary can be executed on each node after having confirmed that the package versions of the toolchain (glibc, gcc, cpp, ld, etc) are identical across the nodes. One such binary comparison utility is available at http://www.dettus.net/dhex/ Attachments This solution has no attachment |
||||||||||||
|
||||||||||||