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

如果自己搞不定可以找诗檀软件专业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.212.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_HOMEORACLE_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数据库11g1版(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不必找一个不存在的KDCKerberos域控制器)。

A2) 安装数据库报错

首先检测A1中所有条目。

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

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

例如:关闭中止

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

启动NOMOUNT”

改变数据库装入

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

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

这个步骤此处没有介绍。

       A2.3)  只有 Linux/UNIX:

‘strace’命令可以用来在错误发生前帮助跟踪OracleUNIX平台通常有一个桁架(或‘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期间的SQLBIND活动

重做应用

事务回滚所需信息

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[4kgstmLdiToMicroTs]出现在警报日志

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

     注意:

     Oracle11g12c中改变位置,请参考:

    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’.

        Oracle11g12c中改变位置,请参考:

     Note 438148.111g中查找警报日志文件(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-3113ORA1403RMAN复制或还原失败

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

关注刘相兵的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

Speak Your Mind

沪公网安备 31010802001379号

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569