数据库restore时遇到1119错误

今夜天高云淡,夜色迷人,正跟LP在餐馆吃饭,没事聊聊天,忽然电话响起,美好画面就此打破。。。
客户紧急求助,让我立马赶赴现场解决故障,没法,跟LP致歉,然后飞奔出去,打着飞的就奔赴现场。
故障情况如下:客户主服务器重大故障,盘阵损坏,暂时无法使用或者修复,不过磁带机上有Rman备份,因此选择了一台备用机进行修复,服务器为AIX4.3,Oracle为10g,单机,所有备份归档都有(这就放心了)。。。
客户在做恢复时报错(一颗心立马揪了起来。。。不会备份的文件有问题吧),错误代码为ORA-01119和ORA-27040,也就是说,在restore文件到新服务器存储的时候报错,无法restore备份。
感到客户现场,气氛有点紧张,呵呵,原来客户领导也在,这不给咱压力嘛。
开始了解详细的用户操作步骤,从描述上看,备机与原服务器的os版本相同,补丁也都打完全了,数据库版本也一致,存储空间和目录也都与原来一样,用户将磁带机连好后,将初始化参数文件复制到相应位置,创建了口令文件,nomount数据库后,通过rman将控制文件restore到相应的目录中,mount数据库后开始restore数据文件,在数据文件restore到一个undo表空间的文件时报错。
听上去好像用户也没有任何操作错误,检查了一下,确实备机与主机环境基本上一样,为什么会报ORA-01119和ORA-27040错误呢?还是先亲自试试看吧。
在mount状态下,我开始逐一测试restore文件,结果发现,并不是所有的数据文件都不能restore,有些可以正常restore出来,但有些数据文件不行,而且发现了一个很明显的现象,不能restore出来的文件一般都比较大。
分析ORA-01119和ORA-27040错误原因,一般来说主要是存储空间不够,没有目录操作权限之类,但如果是这种原因,那应该在相应目录下所有文件都不能创建,但现在的情况是大文件创建不行,小文件没问题。。。说到这里,可能大部分人都猜到了——对地,就是大文件的问题。。。这也算是经典问题了,很多平台都有,这次是aix,上次我还遇到过在hp unix上。
经过检查,发现备机上确实没有调整文件大小限制,需要进行调整。在aix上影响文件大小限制的主要有两个地方,一个是文件系统类型本身,需要使用large file enable filesystem,例如如果使用jfs2系统,默认就支持大文件;另一个是os上一个核心参数的设置。
可以使用下面的方法取消文件大小限制:
找到 /etc/security/limits文件,把fszie改为-1,-1表示文件大小无限制(当然也可以设置为有限制,如果限制为4GB,可以将fszie设置为 4GB/512 的值),在设置后重新连接会话,设置生效。
找到问题原因了,自然后面的restore、recover就没问题了,该故障解决完成,我还来得及继续回家跟LP欣赏夜景去。。。


注意:Oracle的有些文件需要注意这个问题,如果用到这些文件,最好将文件大小设置为无限制,主要要关注的文件有:
1、数据文件(设置了自动扩展,一般可以扩展到8gb-128GB,大文件表空间的数据文件可以扩展到128TB)
2、告警和trace文件,尤其是一些bug或者异常产生的trace文件
3、Rman备份文件
4、exp或者expdp的导出文件

 

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/22235/viewspace-591452/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/22235/viewspace-591452/

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值