当 (Oracle 建议 65536) 时,“Ulimit -Hn”设置得太低(1024)是否存在问题?这是针对 Linux 5 上的 Oracle 64 位 11g。
这是似乎严重不符合建议的设置之一。但我还知道,有问题的数据库服务器是 Oracle Data Guard 本地备用服务器,实际上应该只与其主数据库服务器有一两个连接(用于传输重做日志)。
本地备用数据库服务器在几个月内“挂起”了大约 3 次,然后需要重新启动。我无法访问此服务器,因此依靠其他人查看日志等。对内核参数的健全性检查发现“ulimit -Hn”的值很低。有没有人见过这个“低”值导致挂起或崩溃?
答案1
Linux 5 不存在。您使用的是 linux 2 或 linux 3。或者您是在谈论 rhel5?
回到问题:从未见过由于 ulimit -Hn 输出太低而导致内核崩溃的情况。只是有些软件无法正常工作,甚至无法启动。恕我直言,你应该提出这个问题,但它不太可能是问题的根本原因。
大多数关系数据库引擎(至少是 oracle、mysql 和 postgresql)都会打开很多文件。
答案2
“挂起”适用于 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。
请记住,备用物理服务器是仅有的如果它能够成为主数据库,并且从客户端的连接中获得更多进程,那么它是可用的,在这种情况下事情会变得非常糟糕:
ps -ef | grep oracle | wc -l # how many processes approx.
241
lsof | grep oracle | wc -l # how many files approx.
7342