环境: 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 时做的特殊处理. 而现实中, 尤其是乙方服务的角色, 这类非普遍的问题碰到的几率也还蛮高的. 主要考验的就是经验和排错思路了.
来源: http://www.linuxidc.com/Linux/2018-12/155796.htm