Linux 5中Oracle 11g中的Ulimit设置

Question

当(甲骨文推荐为65536)时，"Ulimit“设置过低( 1024)是否有问题？这是针对Linux 5上的Oracle 64位11g。

这是一个令人遗憾的设置，似乎缺乏它的建议。但我也知道，所讨论的数据库服务器是Oracle数据保护本地备用服务器，应该只需要从其主数据库服务器(通过重做日志传送)连接一两个。

本地备用数据库服务器在几个月内挂起了大约3次，然后需要重新启动。我无法访问此服务器，因此依赖于其他人查看日志等。对内核参数的正常检查发现了"ulimit“的低值。有没有人见过这种“低”价值会导致绞盘或崩盘？

Answer 1

Linux 5不存在。您正在使用Linux2或Linux3，或者您是在说rhel5吗？

回到问题:从来没有见过任何内核崩溃，因为ulimit输出太低。只是有些软件不能正常工作，甚至无法启动。你应该提出，但这不太可能是你的问题的根本原因。

大多数关系数据库引擎(至少oracle、mysql和postgresql)都会打开大量文件。

Answer 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错误消息，许多人可以指出这一点，包括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