Linux 5 上 Oracle 11g 中的 Ulimit 設置
當（Oracle 推薦 65536）時，“Ulimit -Hn”設置太低（在 1024 處）是否存在問題？這適用於 Linux 5 上的 Oracle 64 位 11g。
這是似乎嚴重缺乏其推薦的設置之一。但我也知道，有問題的數據庫伺服器是一個 Oracle Data Guard 本地備用伺服器，並且應該只有一個或兩個來自其主數據庫伺服器的連接（以傳送重做日誌）。
本地備用數據庫伺服器在幾個月內“掛起”了大約 3 次，然後需要重新啟動。我無權訪問此伺服器，因此請依靠其他人查看日誌等。對核心參數的完整性檢查發現“ulimit -Hn”的值較低。有沒有人見過“低”值導致掛起或崩潰？
Linux 5 不存在。您正在使用 linux 2 或 linux 3。或者您可能在談論 rhel5？
回到問題：由於 ulimit -Hn 輸出太低，從未見過任何核心崩潰。只是有些軟體無法正常執行，甚至無法啟動。恕我直言，您應該提出它，但這不太可能是您問題的根本原因。
大多數關係數據庫引擎（至少 oracle mysql 和 postgresql）都會打開很多文件。
“掛起”是否適用於 Linux 核心或 Oracle 伺服器（即 Oracle RDBMS 軟體）？
我不希望核心有任何掛起。但是對於標準的 Oracle 物理備用伺服器來說，打開文件描述符數量的最大硬限制值如此之低確實是不夠的。
現場範例：
ps -ef | grep oracle | wc -l # how many processes approx. 65 lsof | grep oracle | wc -l # how many files approx. 1343用完打開的文件描述符會導致 Oracle 出現不可預知的行為，包括掛起與數據庫的連接或無法以管理員身份連接（甚至
sqlplus / as sysdba）。通常不可能確定一個 ORA-xxxx 錯誤消息的情況，許多可以表明這一點，包括 ORA-01116、ORA-12535、ORA-00376。請記住，僅當備用物理伺服器能夠成為 PRIMARY 數據庫並從客戶端連接中獲取更多程序時，它才可用，在這種情況下，事情會變得非常糟糕：
ps -ef | grep oracle | wc -l # how many processes approx. 241 lsof | grep oracle | wc -l # how many files approx. 7342