ORA-03113: end-of-file on communication channel 错误定位过程

今天数据库不能启动了，报ORA-03113: end-of-file on communication channel的错误，经过网上搜索相关信息如下：   手动关闭Oracle之后打算再次启动Oracle： $sqlplus ‘/as sysdba’ SQL> startup ORA-03113: end-of-file on communication channel 结果便出现了以上错误。 通过上网查询出错原因，常见的原因有以下几个： 1、Unix核心参数设置不当 2、Oracle执行文件权限不正确／环境变量问题 3、客户端通信不能正确处理 4、数据库服务器崩溃/操作系统崩溃/进程被kill 5、Oracle 内部错误 6、特定SQL、PL/SQL引起的错误 7、空间不够 8、防火墙的问题 因为oracle已经正常运行了一个月，因此unix参数不对、权限环境变量、防火墙这些在首次启动就会发现的问题不应该现在才出现；而对于客户端通信、特定的SQL引起的错误，因为在启动过程中就已经报错，所以也排除。 由此判断，数据库服务崩溃/系统崩溃/进程被kill、Oracle内部错误、空间不够可能是原凶。 首先从最容易查起的原因开始，查询磁盘空间，结果磁盘空间利用不到30%，剩余空间足够； 于是检查Oracle内部错误： $cd $ORACLE_HOME/admin/SID/cdump 发现大量的core，看来原因找到了。但所有的core目录都是空的，没有任何文件。 使用ulimit –a查看，原因core的文件大小为0，这是什么原因导致的core呢？ 现在原因不明，于是检查bdump目录下的日志。 $cd $ORACLE_HOME/admin/SID/bdump $cat alert_SID.log 发现日志量很大，满屏的都是同一个错误，扩展表空间失败： ORA-1654: unable to extend index SID.INDEX by 128 in tablespace TABLESPACE ORA-1653: unable to extend table SID.TABLE by 1024 in tablespace TABLESPACE 看来表空间已经满了并且无法扩展导致oracle出现core的。 $cd $ORACLE_BASE/oradada/SID $ls –lh -rw-r----- 1 oracle oinstall 2.1G Oct 14 15:10 SID_DATA01.DBF -rw-r----- 1 oracle oinstall 201M Oct 14 12:28 SID_INDEX01.DBF 原来是空间已经达到2G，但应该触发扩展才对。 安装数据库时并没有限制SID_DATA01.DBF文件大小。 查看创建表空间的脚本，发现在脚本中对该文件有限制。脚本如下： CREATE TABLESPACE SID_DATA DATAFILE ‘/data/oracle/oradata/SID/SID_DATA01.DBF' SIZE 200M AUTOEXTEND ON NEXT 200M MAXSIZE 2048M’ MAXSIZE UNLIMITED LOGGING ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE BLOCKSIZE 8K SEGMENT SPACE MANAGEMENT MANUAL; 原来是在创建表空间时人为限制了表空间大小最大为2G，这是优化导致的问题，今后在新建数据库时都要记住，数据库要根据用户的使用场景来变更表空间。 很多程序只支持2G大小的文件，所以才定为2G，以避免此类问题，虽然使用的是ext3的文件系统，为了方便解决问题才定为2G。但数据库文件为2.1G，难道是文件太大导致的不能启动？ 似乎问题找到了，只需要修改表空间即可解决问题。 但要修改表空间，首先要启动数据库，才能够修改表空间的参数，问题又绕回来了，数据库启不动。 于是再次在网上搜索资料，表空间满导致数据库启动不了的，还没有人遇见这样的问题，看来我们碰到的问题并不是前面所列出的八种原因，而是一种特殊原因。 尝试过多种启动方式： Startup 直接启动 Startup mount 加载数据库 Startup unmount 不加载数据库 Startup force 强行启动 全是报同一个错误提示：ORA-03113: end-of-file on communication channel 经过几个小时，总结了一下，表空间满应用程序不停向数据库写数据，oracle出现异常，之后无法启动。但要解决数据库空间问题必须先启动。 于是在网上查询是否有办法在不启动数据库的情况下修改表空间，但找了很久没有此类方法。 难道真的要用删除数据库的方法才能够解决？ 细心的人可能发现了我们问题解决过程，startup mount 和startup unmount执行结果都是相同的。或许是启动过程中碰到了什么问题导致无法启动，难道和数据库的文件大小根本没关系？是不是oracle启动时还需要其它文件，而这些文件也增大了？ 于是使用find命令查询大于2G文件 $cd $ORACLE_BASE $find . -size +2097160192c ./product/9.2.0.4/admin/SID/bdump/alert_SID.log ./oradata/SID/SID_DATA01.DBF 真的还有一个，清空该日志文件，启动….成功，再次修改oracle的表空间属性，日志中错误消失。 总结 1、经查询资料，了解到Oracle对自身日志文件有一个限制就是每个日志文件不能大于2G，大于2G以后会出现各种问题。且同样对日志文件有这样限制的软件还有不少，如Squid，RoseHA等。因此以后我们在今后要实际生产环境中部署的时候，一定要针对这一特点手工对Oracle做自动日志切割和清理。 2、千万不要删除oracle的数据库文件，即使备份后恢复数据也会丢掉，因为Oracle的数据文件是与磁盘物理位置有关联的，不像mysql那样。 一次 ORA-03113: end-of-file on communication channel 错误定位过程 2010-01-30 01:44 手动关闭Oracle之后打算再次启动Oracle： $sqlplus ‘/as sysdba’ SQL> startup ORA-03113: end-of-file on communication channel 结果便出现了以上错误。 通过上网查询出错原因，常见的原因有以下几个： 1、Unix核心参数设置不当 2、Oracle执行文件权限不正确／环境变量问题 3、客户端通信不能正确处理 4、数据库服务器崩溃/操作系统崩溃/进程被kill 5、Oracle 内部错误 6、特定SQL、PL/SQL引起的错误 7、空间不够 8、防火墙的问题 因为oracle已经正常运行了一个月，因此unix参数不对、权限环境变量、防火墙这些在首次启动就会发现的问题不应该现在才出现；而对于客户端通信、特定的SQL引起的错误，因为在启动过程中就已经报错，所以也排除。 由此判断，数据库服务崩溃/系统崩溃/进程被kill、Oracle内部错误、空间不够可能是原凶。 首先从最容易查起的原因开始，查询磁盘空间，结果磁盘空间利用不到30%，剩余空间足够； 于是检查Oracle内部错误： $cd $ORACLE_HOME/admin/SID/cdump 发现大量的core，看来原因找到了。但所有的core目录都是空的，没有任何文件。 使用ulimit –a查看，原因core的文件大小为0，这是什么原因导致的core呢？ 现在原因不明，于是检查bdump目录下的日志。 $cd $ORACLE_HOME/admin/SID/bdump $cat alert_SID.log 发现日志量很大，满屏的都是同一个错误，扩展表空间失败： ORA-1654: unable to extend index SID.INDEX by 128 in tablespace TABLESPACE ORA-1653: unable to extend table SID.TABLE by 1024 in tablespace TABLESPACE 看来表空间已经满了并且无法扩展导致oracle出现core的。 $cd $ORACLE_BASE/oradada/SID $ls –lh -rw-r----- 1 oracle oinstall 2.1G Oct 14 15:10 SID_DATA01.DBF -rw-r----- 1 oracle oinstall 201M Oct 14 12:28 SID_INDEX01.DBF 原来是空间已经达到2G，但应该触发扩展才对。 安装数据库时并没有限制SID_DATA01.DBF文件大小。 查看创建表空间的脚本，发现在脚本中对该文件有限制。脚本如下： CREATE TABLESPACE SID_DATA DATAFILE ‘/data/oracle/oradata/SID/SID_DATA01.DBF' SIZE 200M AUTOEXTEND ON NEXT 200M MAXSIZE 2048M’ MAXSIZE UNLIMITED LOGGING ONLINE PERMANENT EXTENT MANAGEMENT LOCAL AUTOALLOCATE BLOCKSIZE 8K SEGMENT SPACE MANAGEMENT MANUAL; 原来是在创建表空间时人为限制了表空间大小最大为2G，这是优化导致的问题，今后在新建数据库时都要记住，数据库要根据用户的使用场景来变更表空间。 很多程序只支持2G大小的文件，所以才定为2G，以避免此类问题，虽然使用的是ext3的文件系统，为了方便解决问题才定为2G。但数据库文件为2.1G，难道是文件太大导致的不能启动？ 似乎问题找到了，只需要修改表空间即可解决问题。 但要修改表空间，首先要启动数据库，才能够修改表空间的参数，问题又绕回来了，数据库启不动。 于是再次在网上搜索资料，表空间满导致数据库启动不了的，还没有人遇见这样的问题，看来我们碰到的问题并不是前面所列出的八种原因，而是一种特殊原因。 尝试过多种启动方式： Startup 直接启动 Startup mount 加载数据库 Startup unmount 不加载数据库 Startup force 强行启动 全是报同一个错误提示：ORA-03113: end-of-file on communication channel 经过几个小时，总结了一下，表空间满应用程序不停向数据库写数据，oracle出现异常，之后无法启动。但要解决数据库空间问题必须先启动。 于是在网上查询是否有办法在不启动数据库的情况下修改表空间，但找了很久没有此类方法。 难道真的要用删除数据库的方法才能够解决？ 细心的人可能发现了我们问题解决过程，startup mount 和startup unmount执行结果都是相同的。或许是启动过程中碰到了什么问题导致无法启动，难道和数据库的文件大小根本没关系？是不是oracle启动时还需要其它文件，而这些文件也增大了？ 于是使用find命令查询大于2G文件 $cd $ORACLE_BASE $find . -size +2097160192c ./product/9.2.0.4/admin/SID/bdump/alert_SID.log ./oradata/SID/SID_DATA01.DBF 真的还有一个，清空该日志文件，启动….成功，再次修改oracle的表空间属性，日志中错误消失。 总结 1、经查询资料，了解到Oracle对自身日志文件有一个限制就是每个日志文件不能大于2G，大于2G以后会出现各种问题。且同样对日志文件有这样限制的软件还有不少，如Squid，RoseHA等。因此以后我们在今后要实际生产环境中部署的时候，一定要针对这一特点手工对Oracle做自动日志切割和清理。 2、千万不要删除oracle的数据库文件，即使备份后恢复数据也会丢掉，因为Oracle的数据文件是与磁盘物理位置有关联的，不像mysql那样。

原文：http://hi.baidu.com/lanbo0829/blog/item/d67b8ac14b35815eb319a83b.html       PS：看过上文后，我确定了我遇见的问题的原因极大可能是由于空间不足导致的，于是进行了文件排查，最后确定了几个位置：       1、${oracle}/admin/bdump/  此目录下的文件数量很可能占了很大空间，如无特殊需要可以删除     2、${oracle}/oradata/   此目录下有相关实例的控制文件，同时里面应该有一文件为undotbs01.dbf的文件，这个是回退文件，为了解决空间不足的问题，对这个文件可以进行操作，具体操作方法见:《UNDOTBS01.DBF太大(16.7G)引起的ORA-01033（转）》地址：http://chevy.iteye.com/admin/blogs/1096236 经过如上的操作后，数据库实例无法启动的问题得到了解决。目前没有发现有不良状况。