|
|
===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)理论上也可能存在,因为监听器核心机制没有彻底重写。
|
|