共計 7220 個字符，預計需要花費 19 分鐘才能閱讀完成。
丸趣 TV 小編給大家分享一下 Red Hat 6.5 安裝 Oracle 10g 故障有哪些，希望大家閱讀完這篇文章之后都有所收獲，下面讓我們一起去探討吧！
1、OS 版本兼容
OS 與 Database Software 之間的兼容性問題是我們需要考慮的第一關。在 Oracle 10g 時代，Linux 普遍版本是 4.x，所以對于我們安裝的 Red Hat 6.5，在安裝兼容性檢查過程中是會報錯的。
這個問題還是比較好解決的。原則上 6.5 版本和之前 Linux 版本沒有本質的差異。而且，我們在選擇 Linux 安裝的時候，還是盡可能選擇高版本的進行嘗試。解決這個問題的方法就是要“騙”過 Oracle 軟件的安裝過程。
Oracle 檢驗版本，主要是查看 /etc/redhat-release 文件中的版本信息。我們手工將其修改之后，就可以了。
– 修改前
[root@SimpleLinux ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.5 (Santiago)
– 修改后
[root@SimpleLinux ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 4.8 (Santiago)
檢驗通過。
2、圖形界面激活報錯 libXp.so
安裝軟件過程中，使用圖形化界面方式進行安裝。運行 runInstaller 腳本，報錯。
[oracle@CRSimpleLinux database]$ ./runInstaller
Starting Oracle Universal Installer…
Checking installer requirements…
Checking operating system version: must be redhat-3, SuSE-9, redhat-4, UnitedLinux-1.0, asianux-1 or asianux-2
Passed
All installer requirements met.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2014-05-19_12-33-59PM. Please wait …[oracle@CRSimpleLinux database]$ Exception in thread main java.lang.UnsatisfiedLinkError: /tmp/OraInstall2014-05-19_12-33-59PM/jre/1.4.2/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.action.LoadLibraryAction.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(Unknown Source)
at sun.awt.DebugHelper. clinit (Unknown Source)
at java.awt.Component. clinit (Unknown Source)
筆者對 libXp 并不陌生，在過去 32bit 系統安裝 10g 中，是需要安裝 libXp 包的。所以在之前已經安裝了 libXp。
[oracle@CRSimpleLinux database]$ rpm -qa | grep libXp
libXpm-3.5.10-2.el6.x86_64
libXp-1.0.0-15.1.el6.x86_64
不僅是 XWindows 工具，直接通過本機操作也無法啟動界面工具。解決的線索在于報錯目錄中的 i386。筆者服務器是 64bit 的，和 32bit 不同，很多安裝（包括依賴包）都是需要 32bit 軟件版本進行支持。猜測是執行中需要安裝 32bit 版的 libXp。
[root@CRSimpleLinux packages]# rpm -ivh libXp-1.0.0-15.1.el6.i686.rpm
warning: libXp-1.0.0-15.1.el6.i686.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
Preparing… ########################################### [100%]
1:libXp ########################################### [100%]
安裝之后，libXp 兩個版本均存在于系統中。
[root@CRSimpleLinux packages]# rpm -qa | grep libXp
libXpm-3.5.10-2.el6.x86_64
libXp-1.0.0-15.1.el6.x86_64
libXp-1.0.0-15.1.el6.i686
之后啟動腳本正常。
[oracle@CRSimpleLinux database]$ ./runInstaller
Starting Oracle Universal Installer…
Checking installer requirements…
Checking operating system version: must be redhat-3, SuSE-9, redhat-4, UnitedLinux-1.0, asianux-1 or asianux-2
Passed
All installer requirements met.
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2014-05-19_12-40-28PM. Please wait …[oracle@CRSimpleLinux database]$
這個問題告誡我們，凡事不能想當然，在 64bit 環境中，安裝數據庫許多軟件包是需要 32bit 和 64bit 同時安裝。
3、ins_ctx.mk 編譯 link 錯誤
在安裝過程中，進入持續運行狀態之后，在 link 步驟 Oracle 終止操作，報錯說 link 失敗。檢查錯誤日志，如下內容：
INFO: chmod 751 /u01/app/oracle/product/10.2.0/db_1/bin/ctxlc
INFO: gcc -m32 -o ctxhx -L/u01/app/oracle/product/10.2.0/db_1/ctx//lib32/ -L/u01/app/oracle/product/10.2.0/db_1/lib32/ -L/u01/app/oracle/product/10.2.0/db_1/lib32/stubs/ /u01/app/oracle/product/10.2.0/db_1/ctx/lib/ctxhx.o -L/u01/app/oracle/product/10.2.0/db_1/ctx/lib/ -ldl -lm -lctxhx -Wl,-rpath,/u01/app/oracle/product/10.2.0/db_1/ctx/lib -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lxml10 -lcore10 -lunls10 -lsnls10 -lnls10 -lcore10 -lnls10 `cat /u01/app/oracle/product/10.2.0/db_1/lib/
INFO: sysliblist`
INFO: /usr/bin/ld: crt1.o: No such file: No such file or directory
INFO: collect2: ld returned 1 exit status
INFO: make: *** [ctxhx] Error 1
INFO: End output from spawned process.
INFO: ———————————-
INFO: Exception thrown from action: make
Exception Name: MakefileException
Exception String: Error in invoking target install of makefile /u01/app/oracle/product/10.2.0/db_1/ctx/lib/ins_ctx.mk . See /u01/app/oracle/oraInventory/logs/installActions2014-05-12_06-22-42PM.log for details.
Exception Severity: 1
INFO: *** Cancel Dialog: ***
INFO: User Selected: Stop installation of all products.
INFO: Error in invoking target install of makefile /u01/app/oracle/product/10.2.0/db_1/ctx/lib/ins_ctx.mk . See /u01/app/oracle/oraInventory/logs/installActions2014-05-12_06-22-42PM.log for details.
INFO: Setting variable PREREQ_CONFIG_LOCATION to . Received the value from variable association.
查詢后，發現是安裝依賴包的問題。在 32bit 環境下，我們使用 rpm 直接安裝或者 yum 安裝時，只安裝 32bit 版本就可以了。但是在 64bit 環境下，是需要將兩個版本的均進行安裝。這個過程中是需要嚴格遵守文檔對安裝包的要求。安裝完全包之后，錯誤消失。
4、ins_emdb.mk 問題
安裝包均安裝完全之后，繼續安裝時依然在 link 階段報錯。
INFO: make[1]: Leaving directory `/u01/app/oracle/product/10.2.0/db_1/sysman/lib
INFO: /u01/app/oracle/product/10.2.0/db_1/sysman/lib/snmccolm.o: could not read symbols: File in wrong format
INFO: collect2: ld returned 1 exit status
make[1]: *** [/u01/app/oracle/product/10.2.0/db_1/sysman/lib/nmccollector] Error 1
make: *** [nmccollector] Error 2
INFO: End output from spawned process.
INFO: ———————————-
INFO: Exception thrown from action: make
Exception Name: MakefileException
Exception String: Error in invoking target collector of makefile /u01/app/oracle/product/10.2.0/db_1/sysman/lib/ins_emdb.mk . See /u01/app/oracle/oraInventory/logs/installActions2014-05-12_06-34-52PM.log for details.
Exception Severity: 1
這個問題是比較復雜的，筆者查詢了很多資料也沒有一個確切的回應。最后在網絡上檢索到一位前輩的解決之道。
首先點擊 ignore 跳過步驟，后面就可以直接完成 runInstaller 腳本執行。在 $ORACLE_HOME/bin 目錄下，修改 oracle 文件為 oracle.bin。
創建文件 oracle 在相同目錄，內容如下：
#!/bin/bash
export DISABLE_HUGETLBFS=1
exec $ORACLE_HOME/bin/oracle.bin $@
EOF
保存后使用 chmod a+x oracle 命令對文件進行權限修改。經過這種策略修改之后，Oracle 后續的 dbca 過程創建數據庫執行正常。
但是，在后臺進程中也表現出點問題，我們通過 ps –ef 不能看到常見 pmon 等后臺進程，只有 oracle.bin 的系列對象。
[root@CRSimpleLinux packages]# ps -ef | grep pmon
root 542 406 0 12:57 pts/1 00:00:00 grep pmon
[root@CRSimpleLinux packages]# ps -ef | grep oracle
root 326 32748 0 12:32 pts/0 00:00:00 su – oracle
oracle 327 326 0 12:32 pts/0 00:00:00 -bash
oracle 389 1 0 12:34 ? 00:00:00 /u01/app/oracle/product/10.2.0/db_1/bin/oracle.bin (LOCAL=NO)
oracle 391 1 0 12:34 ? 00:00:00 /u01/app/oracle/product/10.2.0/db_1/bin/oracle.bin (LOCAL=NO)
oracle 399 1 0 12:35 ? 00:00:00 /u01/app/oracle/product/10.2.0/db_1/bin/oracle.bin (LOCAL=NO)
oracle 401 1 0 12:35 ? 00:00:00 /u01/app/oracle/product/10.2.0/db_1/bin/oracle.bin (LOCAL=NO)
oracle 3172 1 0 May13 ? 00:00:02 /u01/app/oracle/product/10.2.0/db_1/bin/oracle.bin
oracle 3181 1 0 May13 ? 00:00:00 /u01/app/oracle/product/10.2.0/db_1/bin/oracle.bin
oracle 3183 1 0 May13 ? 00:00:01 /u01/app/oracle/product/10.2.0/db_1/bin/oracle.bin
（篇幅原因，有省略……）
其余尚未發現兼容問題。
5、Memory Notification in alert log
安裝完成后，監控 alert log 信息確定數據庫運行正常。發現數據庫日志中階段性提示內存變動。
Mon May 12 19:39:09 2014
Memory Notification: Library Cache Object loaded into SGA
Heap size 3596K exceeds notification threshold (2048K)
KGL object name :XDB.XDbD/PLZ01TcHgNAgAIIegtw==
Mon May 12 19:39:09 2014
Memory Notification: Library Cache Object loaded into SGA
Heap size 3567K exceeds notification threshold (2048K)
Details in trace file /u01/app/oracle/admin/chinaredb/udump/chinaredb_ora_20268.trc
KGL object name :XDB.XDA8XlWX/h+P3gQFeMmGQWfg==
進入 10g 之后，一些內存、文件告警通知機制被引入到 Oracle 運行過程中。對一些性能關注點，如 SGA 對象、Swap 使用，Oracle 是有自己的控制機制的。一旦超過了設置閾值，就會在 alert log 中記錄下來，提醒用戶。
這個 memory notification 很簡單，就是 SGA 中引入了比較大的 library cache 對象之后，就會自動寫入進去，從性能上也沒有什么大問題。如果需要解決就是修改內部的控制閾值，不要讓提示過于頻繁發生。
SQL alter system set _kgl_large_heap_warning_threshold =8388608 scope=spfile ;
SQL shutdown immediate
SQL startup
內部參數_kgl_large_heap_warning_threshold 就起到這個作用。修改參數后重新啟動數據庫，報錯信息不再出現。
看完了這篇文章，相信你對“Red Hat 6.5 安裝 Oracle 10g 故障有哪些”有了一定的了解，如果想了解更多相關知識，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！
