如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com
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
Eg:
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
% id
% 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
* t
…
* q
% 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
$c
…
$q
% 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
Comment