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 [phone]c

./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 [phone]c

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

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