ORA-03113: end-of-file on communication channel 错误定位过程（转）
手动关闭Oracle之后打算再次启动Oracle：$sqlplus ‘/as sysdba’SQL> startupORA-03113: end-of-file on communication channel结果便出现了以上错误。通过上网查询出错原因，常见的原因有以下几个：1、Unix核心参数设置不当2、Oracle执行文件权限不正确／环境变量问题3、客户端通信不能正确处理4、数据库服务器崩溃/操作系统崩溃/进程被kill5、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 TABLESPACEORA-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 UNLIMITEDLOGGINGONLINEPERMANENTEXTENT MANAGEMENT LOCAL AUTOALLOCATEBLOCKSIZE 8KSEGMENT 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> startupORA-03113: end-of-file on communication channel结果便出现了以上错误。通过上网查询出错原因，常见的原因有以下几个：1、Unix核心参数设置不当2、Oracle执行文件权限不正确／环境变量问题3、客户端通信不能正确处理4、数据库服务器崩溃/操作系统崩溃/进程被kill5、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 TABLESPACEORA-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 UNLIMITEDLOGGINGONLINEPERMANENTEXTENT MANAGEMENT LOCAL AUTOALLOCATEBLOCKSIZE 8KSEGMENT 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

经过如上的操作后，数据库实例无法启动的问题得到了解决。目前没有发现有不良状况。

?

?

?

?