定位amdu无法使用的根因并解决

环境： OEL 5.7 +Oracle 10g + amdu_X86-64

现象： 我的两套实验环境，一套单实例，一套RAC，操作系统都是OEL 5.7，数据库都是Oracle 10g，上传同样的amdu介质。一个正常，一个报错：

--报错环境：

[oracle@rac1-server lib]$ amdu

amdu: symbol lookup error: amdu: undefined symbol: hac_kpuhh

--正常环境：

[oracle@db10 ~]$ amdu

amdu_2018_12_10_22_24_52/

直接去网上或是MOS搜索，都没有相关匹配的文章。

从报错本身来看就是hac_kpuhh这个没有被定义，那么同样的OS和oracle版本，为何会有差异呢？

回顾amdu的配置步骤都是相同的，如下：

unzip /tmp/amdu_X86-64.zip

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:`pwd`

export PATH=$PATH:`pwd`

此时想到ldd这个命令可以用于打印程序或者库文件所依赖的共享库列表，就用来比对下有无差异：

--报错环境：

[oracle@rac1-server enmo]$ ldd amdu

linux-vdso.so.1 =>  (0x00007fff987ff000)

libskgxp11.so => /home/oracle/enmo/libskgxp11.so (0x00007f06c48ca000)

libclntsh.so.11.1 => /s01/oracle/product/10.2.0/db_1/lib/libclntsh.so.11.1 (0x00007f06c338f000)

libnnz11.so => /s01/oracle/product/10.2.0/db_1/lib/libnnz11.so (0x00007f06c2eee000)

libdl.so.2 => /lib64/libdl.so.2 (0x00000031f8200000)

libm.so.6 => /lib64/libm.so.6 (0x00000031f7e00000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00000031f8600000)

libnsl.so.1 => /lib64/libnsl.so.1 (0x00000031fb200000)

libc.so.6 => /lib64/libc.so.6 (0x00000031f7a00000)

libaio.so.1 => /usr/lib64/libaio.so.1 (0x00007f06c2cda000)

/lib64/ld-linux-x86-64.so.2 (0x00000031f7600000)

[oracle@rac1-server enmo]$

--正常环境：

[oracle@db10 enmo]$ ldd amdu

linux-vdso.so.1 =>  (0x00007fff34288000)

libskgxp11.so => /home/oracle/enmo/libskgxp11.so (0x00007f97d6b97000)

libclntsh.so.11.1 => /home/oracle/enmo/libclntsh.so.11.1 (0x00007f97d482c000)

libnnz11.so => /home/oracle/enmo/libnnz11.so (0x00007f97d43cf000)

libdl.so.2 => /lib64/libdl.so.2 (0x0000003668e00000)

libm.so.6 => /lib64/libm.so.6 (0x0000003668a00000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003669200000)

libnsl.so.1 => /lib64/libnsl.so.1 (0x000000366ce00000)

libc.so.6 => /lib64/libc.so.6 (0x0000003668600000)

libaio.so.1 => /usr/lib64/libaio.so.1 (0x00007f97d41bb000)

/lib64/ld-linux-x86-64.so.2 (0x0000003668200000)

[oracle@db10 enmo]$

通过比对看到了差异：对于报错的环境，libclntsh.so.11.1和libnnz11.so这两个库文件都是指向的10g环境路径下的；而正常环境是应该会指向解压amdu的所在路径下相关文件。

找到了差异性，解决也就简单了，去看10g环境下这两个文件究竟：

[oracle@rac1-server lib]$ ls -l /s01/oracle/product/10.2.0/db_1/lib/libclntsh*

lrwxrwxrwx 1 oracle oinstall      17 Feb 16  2014 /s01/oracle/product/10.2.0/db_1/lib/libclntsh.so -> libclntsh.so.10.1

-rwxr-xr-x 1 oracle oinstall 25433819 Feb 16  2014 /s01/oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1

lrwxrwxrwx 1 oracle oinstall      17 Sep 25 22:30 /s01/oracle/product/10.2.0/db_1/lib/libclntsh.so.11.1 -> libclntsh.so.10.1

[oracle@rac1-server lib]$ ls -l /s01/oracle/product/10.2.0/db_1/lib/libnnz11*

lrwxrwxrwx 1 oracle oinstall 11 Sep 25 22:28 /s01/oracle/product/10.2.0/db_1/lib/libnnz11.so -> libnnz10.so

--临时重命名这两个可能导致问题的链接文件：

mv /s01/oracle/product/10.2.0/db_1/lib/libclntsh.so.11.1 /s01/oracle/product/10.2.0/db_1/lib/libclntsh.so.11.1.bak1210

mv /s01/oracle/product/10.2.0/db_1/lib/libnnz11.so /s01/oracle/product/10.2.0/db_1/lib/libnnz11.so.bak1210

再次测试amdu命令已经恢复正常使用：

[oracle@rac1-server ~]$ amdu

amdu_2018_12_10_22_35_00/

此时再去对应ldd的结果也恢复正常，不再赘述。

总结：本文最主要的是通过ldd命令对比正常和异常两个环境的输出定位出了问题所在。至于为何这个环境会有这个区别，当定位到这个问题时，我也回忆起是因为之前测试安装新版本ogg时做的特殊处理。而现实中，尤其是乙方服务的角色，这类非普遍的问题碰到的几率也还蛮高的。主要考验的就是经验和排错思路了。

更多Oracle相关信息见 Oracle 专题页面 https://www.linuxidc.com/topicnews.aspx?tid=12

Linux公社的RSS地址 ： https://www.linuxidc.com/rssFeed.aspx

本文永久更新链接地址： https://www.linuxidc.com/Linux/2018-12/155796.htm