一次資料檔案COPY

開始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部落格 ” ，連結：http://blog.itpub.net/8242091/viewspace-663291/，如需轉載，請註明出處，否則將追究法律責任。