好的，我们来详细解析 ORA-00135 错误。我将按照您的要求，先进行官方正式的说明，再用通俗易懂的语言进行解释。
官方正式说明
错误信息结构组成说明
Oracle数据库的错误信息通常由以下几部分组成：
- ORA-00135: 这是唯一的错误代码，用于精准识别问题类型。
- 错误消息文本:
instance (process) <number> is not known to ORACLE。这段文本描述了问题的核心：指定的进程不为 ORACLE 所知。 - 原因 (Cause): 官方文档中会详细解释导致此错误的技术背景。
- 行动 (Action): 官方文档会提供解决此错误需要执行的具体步骤。
详细解释
- 错误代码: ORA-00135
- 错误信息:
instance (process) <number> is not known to ORACLE - 中文翻译: 实例（进程）<编号> 不为 ORACLE 所知。
原因 (Cause)
ORA-00135 是一个与 Oracle 后台进程管理相关的内部错误。它发生在 Oracle 的进程监视器（PMON）或其他内部机制尝试访问或管理一个其内部数据结构中不存在或不认识的进程时。
具体原因可能包括：
- 内部状态不一致: Oracle 实例维护着其所有后台进程和服务器进程的内部列表或数据结构（在内存中）。当系统尝试引用一个其进程控制块（PCB）或其他跟踪机制中不存在的进程标识符（PID）时，就会触发此错误。
- 进程清理过程中的竞争条件: 在实例关闭、进程异常终止或实例恢复期间，PMON 正在清理进程资源，而另一个内部组件几乎同时尝试访问同一个即将被清除的进程，导致短暂的"找不到进程"状态被捕获并记录为错误。
- 软件缺陷: 在极少数情况下，这可能是 Oracle 内核代码中的一个缺陷，导致进程被从内部列表中过早地移除或从未被正确注册。
发生场景
- 数据库实例关闭期间: 特别是在执行
SHUTDOWN ABORT之后，或在一个混乱的关闭过程中，PMON 正在清理大量进程时。 - 实例恢复期间: 在一个实例异常终止后，下一个启动的实例进行崩溃恢复，清理前一个实例的遗留进程时。
- 内部操作期间: 在执行某些需要遍历和验证后台进程状态的内部数据库操作时。
相关原理
- PMON (Process Monitor): 一个核心的Oracle后台进程，负责清理失败的用户进程、服务器进程，并释放这些进程所占用的资源（如锁、闩）。
- 进程跟踪: Oracle 内核需要跟踪其创建的所有进程。它为每个进程维护一个内部条目，包含其状态、上下文等信息。ORA-00135 表明系统无法找到给定进程ID对应的内部条目。
- 错误与恢复: 这个错误通常是在 Oracle 自身的错误处理或恢复路径中抛出的。它本身通常不是一个导致实例失败的根本原因，而更像是一个在处理另一个问题（如进程失败）时出现的次级症状。
相关联的其他ORA-错误
- ORA-00134:
instance (process) <number> is not an active instance (process) in this ORACLE group- 这是一个非常相似的错误，经常与 ORA-00135 结伴出现。ORA-00134 表示进程存在于某个组但不活跃，而 ORA-00135 表示进程完全未知。 - ORA-00600 [内部错误代码]: 某些导致进程状态不一致的根本原因可能最终表现为一个内部错误。
- ORA-02700, ORA-02701 等: 这些是与操作系统相关的底层进程创建/管理错误。
定位原因、分析过程
- 定位: 错误几乎总是出现在数据库的告警日志（
alert_<SID>.log）中。 - 分析过程:
a. 首要检查 - 告警日志: 搜索ORA-00135。查看错误发生的时间戳以及其前后的日志条目。关键是看数据库在报错时正在执行什么操作（例如，正在关闭、正在启动进行恢复）。
b. 关联错误: 检查附近是否有ORA-00134、ORA-00600或其他错误，这些可能提供根本原因的线索。
c. 分析模式: 此错误是一次性事件还是重复发生？这是最重要的区分点。如果它只在与实例关闭或崩溃恢复相关的日志中出现一次，并且实例之后成功打开或关闭，则可以认为是正常的清理行为。如果它在实例正常运行时重复出现，则可能预示更严重的问题。
d. 检查操作系统: 在错误发生的时间点附近，检查操作系统的系统日志（如/var/log/messages）是否有硬件错误、OOM（内存不足） killer 活动或其他可能导致进程意外终止的问题。
解决方案
重要提示：与 ORA-00134 类似，ORA-00135 在绝大多数情况下是一个暂时的、无害的错误，不需要任何干预。
-
无需操作（最常见且推荐的方案）:
如果该错误出现在实例关闭或崩溃恢复的日志中，并且实例最终成功启动或关闭，则可以安全地忽略此错误。它只是记录了PMON在清理过程中遇到的一个短暂状态。无需采取任何纠正措施。 -
彻底重启实例（如果错误持续存在）:
在极其罕见的情况下，如果此错误阻止了实例的正常启动（例如，恢复过程被卡住），最直接的解决方法是执行一次彻底的清理和重启。- 关闭实例: 如果可能，尝试再次执行
SHUTDOWN IMMEDIATE。 - 清理残留进程: 在操作系统级别，确保所有与 Oracle 相关的进程都已终止。
- Linux/Unix: 使用
ps -ef | grep ora_和ps -ef | grep LOCAL=NO查找残留进程。使用kill -9 <pid>强制终止任何找到的残留进程。 - Windows: 使用任务管理器确保所有
ORACLE.EXE和oracle.exe进程都已结束。
- Linux/Unix: 使用
- 重新启动: 在干净的环境下重新启动实例。
- 关闭实例: 如果可能，尝试再次执行
-
调查根本原因（如果错误频繁出现）:
如果此错误在实例正常运行时频繁且重复地出现（而不仅仅是在关闭/恢复时），则可能表明存在更深层次的问题，需要调查：- 操作系统/硬件稳定性: 检查内存、磁盘和CPU是否有问题。运行硬件诊断工具。
- Oracle软件问题: 考虑应用最新的补丁集或PSU（补丁集更新），因为可能存在已知的、已修复的软件缺陷。
相关SQL语句和命令
此错误与内部进程状态有关，无法用SQL语句解决。主要的诊断工具是日志分析和操作系统命令。
-- 在数据库正常运行后，可以查询进程视图以确认状态正常（用于事后确认）
SELECT pid, spid, program, background FROM v$process;
# 关键的操作系统诊断命令
# 查看告警日志的实时输出或搜索历史错误
tail -f $ORACLE_BASE/diag/rdbms/<db_name>/<SID>/trace/alert_<SID>.log
grep ORA-00135 $ORACLE_BASE/diag/rdbms/<db_name>/<SID>/trace/alert_<SID>.log
# 检查操作系统进程状态 (Linux/Unix)
ps -ef | grep ora_ | grep -v grep
ps -eo pid,ppid,cmd,etime | grep -i oracle
# 强制杀死残留进程 (必要时使用)
kill -9 <orphaned_pid>
通俗易懂的语言讲解
ORA-00135 是什么？
想象一下，Oracle数据库实例就像一个大型公司的办公室，有很多员工（进程）在工位上工作。ORA-00135错误就像是：公司的保安（PMON进程）接到指令，要去检查一个工位上的员工，但他翻遍整个公司花名册，都找不到这个员工的工号。 保安在值班日志上记下：“员工XXX不为本公司所知！”
详细解释
- Oracle实例: 就是这个正在运行的“公司办公室”。
- 后台进程: 就是在“办公室”里工作的“员工”。
- PMON进程: 它是公司的“保安主任”或“后勤经理”，负责管理所有员工，特别是如果有员工突然消失，他要去清理他的工位。
- ORA-00135: 保安主任（PMON）根据一个指令（可能是系统派发的任务），要去找一个工号为XXX的员工。但是他查遍了公司的HR系统（Oracle内部的进程跟踪表），根本找不到这个工号的任何记录。于是他上报一个错误：“此人不在我司花名册上！”
为什么会发生？（常见原因）
- 指令发错了（内部小故障）: 公司的内部系统（Oracle内核）可能因为一个小故障，生成了一条错误的指令，让保安去查一个根本不存在的工号。
- 清理工位时的混乱: 公司突然解散一个部门（实例异常关闭），保安主任正忙着清理工位，在处理过程中，临时收到一个查询某个正在被清理的工位的请求，导致一时“查无此人”。
- 花名册信息滞后: 保安手上的花名册（Oracle内部数据结构）更新慢了一拍，没有及时记录某个员工已经离职。
怎么解决？
原则：和ORA-00134一样，这通常只是“记录日志”，公司运营不受影响，不用处理。
具体该怎么做：
-
最佳方案：忽略它: 如果这个错误只是出现在告警日志里，但你的数据库最后成功启动了或者成功关闭了，那就完全不用管它。保安主任记录这个错误只是走个流程，他自己会处理后续事宜。你的干预反而是添乱。
-
如果公司因此停摆（极其罕见）:
如果因为这个错误导致数据库启动不了（就像保安主任因为找不到人而卡在那，不让公司开门），解决办法也很粗暴有效：- 清空办公室，重新上班: 确保所有旧“员工”（Oracle进程）都离开了办公室。在Linux上，用
ps -ef | grep ora命令看看有没有“赖着不走”的进程，如果有，就用kill -9命令“请”他们离开。 - 重新开业: 清场之后，再次启动数据库（
STARTUP）。这次就是一个全新的开始，“花名册”是空的，所有员工重新登记，错误自然就解决了。
- 清空办公室，重新上班: 确保所有旧“员工”（Oracle进程）都离开了办公室。在Linux上，用
什么时候需要担心？
只有当这个错误不是在关店或混乱开业时出现，而是在正常营业时间（数据库正常运行时）反复出现，才需要引起注意。这可能意味着公司的HR系统（Oracle软件）有更深层次的bug，或者办公室的硬件（服务器内存、磁盘）有问题，导致员工名册频繁出错。这时就需要请“总部的专家”（Oracle支持）来看了。
总结一下：ORA-00135是一个内部状态暂时性不一致的错误。它几乎是ORA-00134的“孪生兄弟”，通常发生在数据库关闭或崩溃恢复的混乱过程中。它的最重要特性是：几乎总是可以自我修复，无需人工干预。 你的首要任务是查看数据库的最终状态。如果数据库运行正常，就忽略这个错误日志。
欢迎关注我的公众号《IT小Chen》
扫一扫
6574
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
