重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛

标题: ORACLE监听器显示"正常运行时间 (Uptime)" 限制 [打印本页]

作者: Inkcup 时间: 2026-4-2 10:45
标题: ORACLE监听器显示"正常运行时间 (Uptime)" 限制
===Oracle监听器明明运行了九百多天，但只显示运行了三百多天===

这个问题是监听器存在一个显示限制。

Oracle 监听器内部用一个 32位的计数器（单位是百分之一秒，即 csec）来记录运行时长。这个计数器的上限是 2^31 - 1，即 2,147,483,647。

计算一下上限对应的实际天数：

按 csec 计算：2,147,483,647 个百分之一秒

换算成秒：2,147,483,647 ÷ 100 = 21,474,836.47 秒

换算成天：21,474,836.47 ÷ 3600 ÷ 24 ≈ 248.55 天

也就是说，当监听器运行超过约 248 天后，内部计数器会溢出归零。之后 lsnrctl status 显示的时间会从 0 天重新开始计算。

“实际运行九百多天，显示三百多天”，这正好符合溢出重置的特征：

第一个 248 天：运行至约 248 天时重置

第二个 248 天：运行至约 496 天时重置

第三个 248 天：运行至约 744 天时重置

然后继续累积到 300 多天

900 天 ÷ 248 天 ≈ 3.6 次重置，显示的 300 多天正好是最后一次重置后累积的时长。

=====如何确认这个判断？=====

你可以验证一下监听器的启动时间，看它是否与你预期的 900 多天前一致：

# 查看监听器日志文件，找到最早的启动记录
# 日志路径通常为 $ORACLE_HOME/network/log/listener.log
# 或从 lsnrctl status 输出中找到 "Listener Log File" 路径

grep "START" /path/to/listener.log | head -1

这个命令会显示监听器第一次启动的时间，如果该时间确实是 900 多天前，就证实了溢出重置的判断。

=====备注=====

1.不影响监听功能。仅显示值不准确，监听器连接转发功能完全正常。
2.可以理解为设计上的限制，Oracle 官方文档没有明确说明上限，但这个 248 天限制在行业内是已知情况。
3.早期版本（10g、11g）明确存在此限制。较新版本（如 23c）理论上也可能存在，因为监听器核心机制没有彻底重写。

欢迎光临重庆思庄Oracle、KingBase、PostgreSQL、Redhat认证学习论坛 (http://bbs.cqsztech.com/)