（Oracle推荐65536）时，“Ulimit -Hn”是否设置得太低（在1024）？ 这适用于Linux 5上的Oracle 64位11g。
这是其中一个设置，似乎是远远不及其build议。 但是我也知道有问题的数据库服务器是Oracle Data Guard本地备用数据库，应该只有一个或两个来自其主数据库服务器（用于传送重做日志）。
本地备用数据库服务器在多个月内“挂起”了大约3次，然后需要重新启动。 我没有访问这个服务器，所以要依靠别人去查看日志等等。内核参数的健全性检查揭示了“ulimit -Hn”的低值。 有没有人看到“低”价值导致挂起或崩溃？
Linux 5不存在。 你正在使用Linux 2或Linux 3.或者你在谈论rhel5？
回到问题：由于ulimit没有看到任何内核崩溃 – 输出太低。 只有一些软件无法正常工作，甚至无法启动。 恕我直言，你应该提高它，但它不可能是你的问题的根本原因。
大多数的关系数据库引擎（至lessoracle的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的不可预知的行为，包括挂起到数据库的连接或无法以pipe理员身份连接（甚至是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