ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 一次数据文件COPY

一次数据文件COPY

原创 Linux操作系统 作者:westzq1984 时间:2010-05-21 10:10:38 0 删除 编辑
开始COPY文件的时候,老是无法正常执行,报
    RMAN-03002: failure of copy command at 09/06/2006 19:31:09
    ORA-00235: controlfile fixed table inconsistent due to concurrent update
    RMAN-06010: error while looking up datafile: /dev/rdblv_data4_021

想到这个时候没有连接catalog,可能连接catalog会缓解,于是测试,一切正常。

后来查了下metalink,有点像Bug 2391697: ORA-235 DOING BACKUP WITH RMAN IN NOCATALOG MODE
数据文件太多时有这个问题,刚好这个库有6000+的数据文件。9207修复

ESS800真的是奇慢无比,COPY速度大概在65M/s,拷贝了2组:
    第一组  800G,20通道,100个8G大小的文件,3小时20分钟
    第二组  480G,10通道,60个8G大小的文件,1小时55分钟
    
拷贝完成后执行后offline正常,switch datafile的时候速度很缓慢,看到其每执行一个switch,就要同步catalog,
于是把catalog断开,switch datafile很快完成。

在将表空间置为read write的时候,很长时间无法返回,查了下,进程在等待调用DBWR返回,而DBWR一直处于繁忙状态
truss了下DBWR,发现其在缓慢调用kfcntl
        517286: kfcntl(3610, 12, 0x0FFFFFFFFFFFD4A0)            = 0
        517286: kfcntl(3610, F_GETFL, 0x0000000000000000)       = 71303170
        517286: kfcntl(3610, 12, 0x0FFFFFFFFFFFD480)            = 0
怀疑是对于每个数据文件在做重复操作
这时,由于执行了read write语句,导致数据库的其他会话在CI队列上HANG住。

查了下metalink,疑为Bug 4430964 - ALTER TABLESPACE READ WRITE slow with very large buffer cache [ID 4430964.8],9206版本受到影响,相关BUG还有5162834,5092032 ,该BUG在9208修复
该BUG的描述为当修改表空间状态为read write / begin backup时,ORACLE对于每个数据文件都要扫描一次BUFFER CACHE,而不是正常情况下的一个表空间扫描一次。这次迁移的成都表空间有大量数据文件(800多个)以及大的BUFFER CACHE(64G),所以无法及时READ WRITE.

杀掉了数据库所有链接,期望有所好转,结果不见效,truss跟踪的结果是,速度仍然很缓慢

最后修改buffer_cache到1G,重新执行,调用kfcntl速度有提升,执行了43分钟总算把表空间给read write起来了

看来List of Bug Fixes by Problem Type / Known Issues 这些文档还是要多看,熟悉相关的BUG
 

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

请登录后发表评论 登录
全部评论

注册时间:2009-04-06

  • 博文量
    251
  • 访问量
    1042184