Oracle 故障排除 ORA-03113 ORA-03113: 通信通道的文件结尾 ORA-03113: end-of-file on communication channel

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638 QQ号:47079569 邮箱： [email protected]

ORA-03113: end-of-file on communication channel

ORA-03113: 通信通道的文件结尾

Oracle 数据库 – 企业版 – 9.2.0.1 到 12.1.0.1 版本 [ 发布 9.2 到 12.1 版 ]
此文件信息可应用于任何平台

*** 于 2016/1/11 进行相关性检测 ***

ORA-3113“ 通信通道文件终端 ” 错误是常见错误，通常反映在客户端进程中，与 Oracle 数据库相连。这一错误表明 ‘ 连接不到 Oracle 服务进程 ’ 。因为是常见错误，可以收集更多信息更易于判断哪里出错 — 错误本身并不表明错误原因。例如， ORA-3113 可能是以下任何一种情况：

服务器崩溃

服务器进程在 O/S 水平中断

Oracle 内部出错 (ORA-600 / ORA-7445) / 服务器中止

客户端错误处理多个连接

等等。。。一系列可能原因 !!

本文讲解了针对 ORA-3113 错误应该搜集哪些信息，这种错误通常与其他错误一起出现，比如：

ORA-1041 内部错误 . hostdef 扩展不存在

ORA-3114 未连接到 ORACLE  ( 使用 PL/SQL 时，这种错误会出现在 ORA-3113 之前 )

ORA-1012 未登录

这些都表明，与 Oracle 断开连接

这篇笔记是更新后的版本，已存档

Note 17613.1 – ORA-03113 在 Unix 操作系统中 – 要搜集什么信息
要参考以往信息，请参考 Note 17613.1

故障排除步骤：

请尽可能多的从以下几项中搜集信息，并提交到 Oracle Support 。如果一个步骤产生了输出文件 / 跟踪文件，这可能就是 Oracle Support 需要的，能够帮助判断错误原因。一次提供的信息越多，就越有可能快速解决问题。注意，有些章节是不可用的。

如果是在网页上浏览这篇文章，点击以下链接即可，也可以手动进入相关章节。

在什么情况下会出现 ORA-3113 呢？

A. 试图启动 Oracle 时 ? -> Section A

B. 试图连接到数据库时 ? -> Section B

C. 客户端运行 SQL / PLSQL 时出错 ? -> Section C

D. 服务器跟踪文件出现 ORA-3113 ? -> Section D

浏览在本文末尾处 E 部分的清单也很有用。它涵盖了与所有错误部分相关的一些问题。

试图启动 Oracle 时

启动数据库时有几个阶段 . 如果 ORA-3113 出现在启动阶段 , 就中止实例，启动下面的序列 . 错误出现在任何一步 , 请参阅下面的相关注意事项 :
a. 启动任意所需服务 错误见 A1

例如：在 Windows 上 , 启动 Oracle 服务 SID

b. 使用 SYSDBA 身份连接 . 错误见 A1

例如 : sqlplus /nolog

SQL> 连接 / as sysdba

c. 启动 nomount. 错误见 A1

SQL> 启动 nomount

d. 安装数据库 . 错误见 A1 和 A2

SQL> 调整数据库装入 ;

e. 恢复数据库 错误见 A3

SQL> 恢复数据库

f. 打开数据库 错误见 A4

SQL> 调整数据库打开方式 ;

g. 等待 3 分钟直到发出选择指令 . 错误见 A4

SQL> 从 DBA_OBJECTS 选择计数 (*);

A1) 连接 SYSDBA 或启动 nomount 错误

软件 / 环境也会有一些基本性错误

如果使用 DBA 身份不能连接到 SQLPlus

这些步骤涵盖了 ORA-3113, ORA-12547 这样的错误

TNS: 断开连接

或是类似的连接 Oracle 、启动实例 NOMOUNT 出错

检查下列事项 :

A1.1) 如果可能的话重新启动服务器，启动前禁止 Oracle 自动启动。这看起来很剧烈，但有助于确保你是从在统一的起始点开始工作。

A1.2) 请检查您的环境点，配置 ORACLE_HOME 和 ORACLE_SID 。

检查 the USER_DUMP_DEST 和 BACKGROUND_DUMP_DEST 以及

这种环境下用于用户追踪文件的默认追踪目录或是生成的警报日志目录。这些有助于指出问题的原因。

Eg: ORA-600[SKGMINVALID] 也许表明了在 UNIX 系统中共享内存 UNIX 参数问题。

要证明发现的任何踪追踪文件 / 警报日志条目真的和 “ 连接 ” 命令相关， 可以通过重新发出 “ 连接 ” 命令，并在报错时检查新的跟踪文件 / 警报条目。

A1.3) 只有 UNIX:

一些 UNIX 平台需要正确设置 LD_LIBRARY_PATH 来解决任何动态链接库

As the user with the problem:

% script /tmp/ldd.out

% cd $ORACLE_HOME/bin

% ldd oracle

% exit

如果 ‘ldd’ 命令不存在，就进入下一步。列出的所有行显示出一个完整的库文件。 检查所有行，如果出现 “ 未找到 ” ，联系 Oracle 支持，并输出 /tmp/ldd.out 。

A1.4) 只有 UNIX:

你的 ‘oracle’ 执行也许会损坏 . 通过脚本命令重新连接，举例：

使用 ‘oracle’ 身份登录 .

% script /tmp/relink.out

% cd $ORACLE_HOME/rdbms/lib

% mv $ORACLE_HOME/bin/oracle $ORACLE_HOME/bin/oracle.dd.mon.yy

% rm -f ./oracle

% make -f ins_rdbms.mk ioracle

% exit

视版本而定，可能要用到 “ 重新连接【所有】 ” 命令，而不是上面的 “ 操作 ” 命令。请参考 Note 131321.1 – 怎样在 UNIX 上重新连接 Oracle 数据库软件

如果有任何报错， Oracle Support 需要参看 /tmp/relink.out 文件中的内容。

A1.5) 如果启动 NOMOUNT 报错 :

查看 init.ora/spfile ，此文件用于启动数据库。它提供了用于配置实例的详细配置信息。为帮助隔离问题，启动实例时使用一个非常基本的 init.ora/ spfile 也许很有用。如果有用，就可以一次增加 / 介绍参数来看个别设置是否有问题。

要正确更改 SPFILE 的内容，请参考：

Note 137483.1 – 如何修改 SPFILE 参数文件的内容

A1.6) 检查服务器端跟踪文件，也许会有更多关于潜在问题的提示信息，

看 Section C 可以找到关于如何检查服务器追踪文件的详细信息

A1.7) 确保下面几个有可用磁盘空间：

a. 你的 USER_DUMP_DEST 和 BACKGROUND_DUMP_DEST 所在位置

这些参数被诊断性基础设施忽略， Oracle 数据库 11g 第 1 版（ 11.1 ）介绍过这些基础设施，将这使跟踪和核心文件放到了由 DIAGNOSTIC_DEST 初始化参数控制的位置。

请参考 :

Note 422893.1 – 11g 了解自动诊断信息库 (12c 也是一样 )

b. 您的审核目的地（ UNIX ）

默认值为 $ORACLE_HOME/rdbms/audit

A1.8) 只有 Windows:

如果服务器的 sqlnet.ora 文件包含身份验证服务，超出 Oracle 服务范围，就会导致 ORA-3113 错误。

举例，如果 sqlnet.ora 文件包含参数： SQLNET.AUTHENTICATION_SERVICES = (NTS) ，而 Oracle 数据库从 Windows NT 域移动到 Active Directory ，或者如果引入一个域控制器，就会出现错误，需要尝试启动数据库。去掉 SQLNET.AUTHENTICATION_SERVICES ，这样 Oracle 不必找一个不存在的 KDC （ Kerberos 域控制器）。

A2) 安装数据库报错

首先检测 A1 中所有条目。

如果在安装数据库时报错，可能是控制文件或数据文件有问题，或是打开这些文件所需要的资源出错。

A2.1) 控制文件的指定位置是在 theinit.ora/ SPFILE 。依次使用每个控制文件尝试安装。

例如： “ 关闭中止 ”

修改 init.ora/ spfile ，指向唯一一个控制文件，

“ 启动 NOMOUNT”

“ 改变数据库装入 ”

重复每个控制文件，看控制文件是否有效。

A2.2) 如果知道所有数据文件和联机日志的位置，重新创建控制文件也是可能的，也可以恢复一个旧的备份控制文件。还原任何备份或发出 CREATE CONTROLFILE 命令之前备份当前的控制文件。

这个步骤此处没有介绍。

A2.3) 只有 Linux/UNIX:

‘strace’ 命令可以用来在错误发生前帮助跟踪 Oracle 。 UNIX 平台通常有一个 “ 桁架 ” （或 ‘TUSC’ ）命令。

% truss -o /tmp/truss.out -f sqlplus

保证 /tmp/truss.out 文件安全 – Oracle Support 也许需要看。

请参考 :

Note 110888.1 – 如何追踪 Unix 系统调用

A3) 恢复数据库报错

恢复数据库过程中出现 ORA-3113 通常和数据库崩溃有关，或是重做流导致服务进程中断。

应该生产一种服务器追踪文件来解决这类问题。

看 Section C ，有更多关于如何从 USER_DUMP_DEST 和 BACKGROUND_DUMP_DEST 中找到追踪文件的详细信息。

A3.1) 如果 “ 恢复数据库 ” 很快失败，收集无线电到故障点会有帮助，因为这有利于找出问题的所在。

在恢复数据库前使用下列命令：

SQL> alter session set max_dump_file_size=unlimited;

SQL> alter session set events

2> ‘10228 trace name context forever, level 10’;

SQL> RECOVER DATABASE

这会导致重做信息被写入到该用户的跟踪文件。重做的最后几个项目可能有助于确定哪个文件有问题。

A3.2) 如果数据库中没有很多数据文件，就只能迅速地按顺序恢复每个文件，来确认问题有没有减少。

SQL> select name from v$datafile;

然后对每个文件：

SQL> RECOVER DATAFILE ‘full_file_name’

如果获取到的一个问题文件，就备份该文件，并使用标准恢复选项，就像处理丢失文件。

A4) 调试数据库打开时报错

打开数据库要执行很多操作，因此，有必要确定下一步骤之前收集一切跟踪信息。但是，以下可能有助于更快地隔离问题：

A4.1) 将文件移出 USER_DUMP_DEST and BACKGROUND_DUMP_DEST 目录，因为这些步骤会留下很多痕迹。

A4.2) 编辑 init.ora/spfile 并添加下列行 :

event=”10046 trace name context forever, level 12″

event=”10015 trace name context forever, level 1″

event=”10228 trace name context forever, level 1″

如果在 init.ora 文件中已经有了 “EVENT=” 行，就直接进入下面的其他 “ 事件 =” 行。在 SPFILE 设定事件，请参考

Note 160178.1 – 如何在 SPFILE 中设置事件

这些行会跟踪：

启动 REDO 期间的 SQL 和 BIND 活动

事务回滚所需信息

A4.3) 按照本部分的开头介绍的启动实例。

一旦发生错误，将上述事件从 init.ora/ spfi 文件中移除并关闭。

按照 Section C 内容收集跟踪文件和警报日志

启动时 ORA-3113 问题 ORA-3113 issues at startup

Note 422646.1 – ORA-03113: 关于数据库启动的通信通道文件终端
Note 466056.1 – 数据库启动失败报错 ORA – 3113

Note 311166.1 – 启动 NOMOUNT 期间在 ksihsmrini 出现 ORA-3113 and ORA-7445
Note 811656.1 – 设置事件时数据库启动失败报错 ORA-1041 or ORA-3113

Note 435989.1 – 启动升级失败， ORA-03113 和 ORA-00600[KCCCHB_3] 出现警告
Note 360834.1 – 使用非默认 NLS 时连续停机 / 启动导致 ORA-3113 Note 810046.1 – 数据库启动失败报错 ORA-03113 ，而 ORA-00600[4 ： kgstmLdiToMicroTs] 出现在警报日志

Note 1498721.1 – 启动出现 ORA-3113 ，警报日志文件不被追加

(B)  ORA-3113 试图使用 Oracle 网络连接到数据库

如果出现问题， Oracle Net （或的 Net8 SQL * NET2 ）应报告网络相关的错误，同时与远程 Oracle 服务进程建立连接。

一个 ORA-3113 意味着已经建立连接，然后又断开连接。这样的话，遵循 Section C 的步骤。

(C) 客户端运行 SQL / PLSQL 时出现 ORA-3113

如果已连接到 Oracle 之后出现 ORA-3113 错误，很有可能是 “ORACLE” 可执行程序意外终止。

C1) 确认连接到哪个数据库，得到下列 INIT.ORA/ SPFILE 参数值：

参数默认值 ~~~~~~~~~ ~~~~~~~

USER_DUMP_DEST $ORACLE_HOME/rdbms/log

BACKGROUND_DUMP_DEST $ORACLE_HOME/rdbms/log

CORE_DUMP_DEST $ORACLE_HOME/dbs

Eg: To find these log into SQL*Plus and issue:

SQL> show parameter dump

在 Oracle11g 和 12c 中改变位置，请参考 :

Note 422893.1 – 11g 了解自动诊断信息库（ 12C 也是一样）。

C2) 在 “USER_DUMP_DEST” 中检测 Oracle 跟踪文件。找到正确的跟踪文件是很重要的。

在 UNIX 上 :

使用 “LS-ltr’ 命令按时间顺序列出文件，最新跟踪文件出现在最后。跟踪文件通常会

追踪文件通常是这种形式： ‘ <SID> _ora_ <PID> .trc’.

在 Windows 上 :

点击 Windows 资源管理器 “ 修改 ” 列，按照修改日期对文件进行排序。文件通常是这种形式 ： ‘ORA <PID> .TRC’.

如果不能确定哪些文件可能相关，将当前所有跟踪文件移动到不同目录，重现该问题。

C3) 在 ‘BACKGROUND_DUMP_DEST’ 中检测警报日志以及其他跟踪文件，这些文件与错误几乎同一时间产生。

应该命名为： ‘alert_ <SID> .log’.

在 Oracle11g 和 12c 中改变位置，请参考 :

Note 438148.1 – 在 11g 中查找警报日志文件（ 12C 也是一样）。

C4) 只有 UNIX:

如果没有跟踪文件，在 CORE_DUMP_DEST 中检查 “ 核心 ” 转储。检查如下 :

% cd $ORACLE_HOME/dbs # Or your CORE_DUMP_DEST

% ls -l core*

如果有名为 “ 核心 ” 的文件，检查它的时间与这个问题的时间是否匹配。如果有名为 “core_<PID>” 的目录，检查其中的每一个核心文件。得到正确的核心文件很重要。从这个 “ 核心 ” 文件中获得堆栈跟踪。检查下面每个序列看看如何做到这一点 – 其中之一应该适用于你的平台。

请参考 Note 1812.1 – TECH: 从 Unix 上的核心文件得到堆栈跟踪

如果你有 dbx:

% script /tmp/core.stack

% dbx $ORACLE_HOME/bin/oracle core

(dbx) where

(dbx) quit

% exit

如果你有 sdb:

% script /tmp/core.stack

% sdb $ORACLE_HOME/bin/oracle core

% exit

如果你有 xdb:

% script /tmp/core.stack

% xdb $ORACLE_HOME/bin/oracle core

(xdb) t

(xdb) q

% exit

如果你有 adb:

% script /tmp/core.stack

% adb $ORACLE_HOME/bin/oracle core

% exit

C5) 尝试确定 错误发生时正在执行的 SQL 命令。

例如：是特定的 SQL 语句还是 PL / SQL 块导致错误？

在许多情况下，它会在列在 “ 当前的 SQL 语句 ” 标题下产生的跟踪文件中，或是在光标下面靠近跟踪文件的中间，也叫做 “ 当前光标 NN” 行。

如果跟踪文件不显示失败语句，那么 SQL_TRACE 可以用于帮助确定失败语句，只要问题可以重现。 SQL_TRACE 适用于大多数客户端工具 :

例如 : 产品 操作

~~~~~~~ ~~~~~~

SQL*Plus Issue ‘ALTER SESSION SET SQL_TRACE TRUE;’

Pro* EXEC SQL ALTER SESSION SET SQL_TRACE TRUE;

这将迫使服务器端 SQL 跟踪文件，详细信息见 C2 。跟踪文件将暗示正在执行什么 SQL 命令。

C6) 如果无法找到任何跟踪文件，而问题可以重现，那么 SQL * 网络跟踪可能有助于显示发送到 “ORACLE” 进程的最新操作是什么。

Oracle 网络 (SQL*Net V2) 跟踪，请参考

Note 16564.1 – TECH: SQL*Net V2 在 Unix 上 – 一个设置客户端跟踪的快速指南

C7) 基于以上搜集的信息，尝试拼凑能够重现该问题的小测试案例。这个很重要，有两点原因：

a) 如果这个问题看起来并不像已知问题，就会给 Oracle Support 一个小的测试案例。

b) 给你个简单的方法检查，是否有补丁能解决这个问题。

C8) 如果一个语句被分解是总是出现 ORA-3113 错误，那就得多花些时间收集更多的信息，比如 :

– 该语句的执行计划

– 表定义，列定义

– 限制信息，触发器等

即：关于失败语句的其他信息。

例如：如果一个 SELECT 操作失败，也许在不同的优化模式下运行会成功。

C9) 检查你的服务器管理员是否有任何脚本，能中止长时间运行或 CPU 密集型进程。如果有人在 O / S 级中止你的服务进程， ORA-3113 进程就会出现。 ( 例如 : kill -9 on UNIX).

现有的连接因为 ORA-3113 出错

Note 1300824.1 – 使用 DCD 时出现 ORA-3113 ORA-3114 或是 ORA-12151 .
Note 1104673.1 – 由于 ORA-3113 终端文件在通信通道上，与数据库的连接终止
Note 578940.1 – 运行 Utlrp.sql 时出现 ORA-03113 And ORA-03114
Note 413922.1 – 执行 Utlrp.sql 时出现 ORA-03113 错误
Note 1125213.1 – 运行 “adadmin”, “adpatch” or “adutlrcmp.sql” 时出现 ORA-03113, ORA-03114, ORA-01041
Note 1096687.1 – 由于新的主机上出现 ORA-3113 和 ORA1403 ， RMAN 复制或还原失败

Note 603714.1 – 10.2.0.4 Catupgrd.sql 失败，由于 ORA-03113 产生了 SYS.KU$_XMLSCHEMA_VIEW
Note 1208712.1 – 试图创建物化视图时出现 ORA-03113 ORA-07445 错误

(D) 服务器跟踪报告 ORA-3113

D1) 服务器跟踪报告 ORA-3113 是不正常的。

不过，如果服务器与客户端或数据库链接失联，就会发生这种情况。处理方法与客户端进程中出现 ORA-3113 一样，按照 Section C 的步骤

D2) 可以将以下事件添加到 init.ora/ SPFILE ，以便在出现错误时，收集尽可能多的信息 :

event=”3113 trace name errorstack level 3″

如果你 init.ora 文件中已经有了 “EVENT=” 行，

就直接进入下面的其他 “ 事件 =” 行。

在 SPFILE 设定事件，请参考

Note 160178.1 – 如何在 SPFILE 中设置事件

(E) 附加检查 / 信息

E1) 是这个工具遇到错误，还是你在做类似操作时使用的工具里出现 ORA-3113 ？

如果问题在 SQL*Plus 重现，就将它用在以下所有测试中。

E2) 只有 Linux/UNIX :

检查问题是否只限于：

[] 一个特定的 Linux / Unix 用户，

[] 任意一个 Linux/ Unix 用户

或是 [] 任何 Linux/ Unix 用户，除了 Oracle 用户。

E3) 检查问题是否只限于：

[] 一个特定的 ORACLE 登录

或是 [] 有权访问相关表格的 ORACLE 登录。

E4) 如果是个客户端 – 服务器设置，那么这种情况是源于：

[] 任意一个客户端

还是 [] 一个特定的客户端

还是 [] 一组客户端？

如果是，这些客户端有什么共同点？

如：软件版本。

E5) 你有没有另外的服务器或数据库版本，能够使同样的操作正常运行？

E6) 确保在下列位置有可用磁盘空间：

a. 你的 USER_DUMP_DEST 和 BACKGROUND_DUMP_DEST 位置

( 或者 DIAGNOSTIC_DEST for 11g and 12c).

b. 你的 AUDIT 目的地 (Linux/Unix)

默认值为 $ORACLE_HOME/rdbms/audit