一次 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那样。

  1. No comments yet.
(will not be published)
*