將RAC的備份恢復到單機。

資料庫恢復時， set newname極慢的原因，初步分析如下：

查詢各 session的等待事件：

SQL> select s.sid, s.serial#, s.paddr, p.pid, s.event, s.p1, s.program from v$session s, v$process p where s.paddr = p.addr ;

……………………….

       315         35 0000000CD3144DC8         23 rdbms ipc reply                                   5 rman@p24fdbqd (TNS V1-V3)

       332          1 0000000CD6176370          5 CSS initialization                                0 oracle@p24fdbqd (DBW0)

發現一個 rman程式在等待ipc （程式間通訊），引數是 5，也就是在等待pid為 5的程式，即DBW0 。

而DBW0正在等待“ CSS initialization”，但是這個等待是在尋找 OCR和VOTEDISK 才會發生的，單例項不應該有。

根據 DBW0的trace 檔案，DBW0在確實在尋找 ASM裡的東西，認為自己應該在叢集裡：

ORA-01186: file 201 failed verification tests

ORA-01157: cannot identify/lock data file 201 - see DBWR trace file

ORA-01110: data file 201: '+DATA/xxx/tempfile/temp.263.750902335'

ORA-01157: cannot identify/lock data file 201 - see DBWR trace file

ORA-01110: data file 201: '+DATA/xxx/tempfile/temp.263.750902335'

ORA-17503: ksfdopn:2 Failed to open file +DATA/xxx/tempfile/temp.263.750902335

ORA-15001: diskgroup "DATA" does not exist or is not mounted

ORA-15077: could not locate ASM instance serving a required diskgroup

ORA-29701: unable to connect to Cluster Manager

並且將錯誤日誌記錄在 /oracle/product/10.2.0/db_1/log/xxx/client 目錄下。

日誌裡只有一條簡單的資訊：

2013-12-17 16:15:27.672: [ CSSCLNT][2479832160]clsssInitNative: connect failed, rc 9

這個日誌的數量非常之大，今天就產生 400多個，到目前已經有33萬多

[oracle@xxx client]$ pwd

/oracle/product/10.2.0/db_1/log/p24fdbqd/client

[oracle@xxx client]$ ll | grep "Dec 17" | grep -v 2012 | wc -l

482

[oracle@xxxclient]$ ll | wc -l

335132

由於這些日誌的名稱是 cssN.log的形式，N 是自增的數字，因此每生成一個 log檔案，就必須遍歷整個目錄來獲取最大的數字。

因此慢應該是由兩部分時間組成，一個是連線 CSS服務超時（應該是由於控制檔案是從 RAC備份而來），一個是遍歷 /oracle/product/10.2.0/db_1/log/xxx/client 資料夾，這也符合使用者反應的，新裝的環境恢復很快，往後越來越慢的現象。

任何定時查詢叢集、 ASM相關資訊的SQL ，如監控程式，也會頻繁產生此類錯誤日誌。

建議先清空 /oracle/product/10.2.0/db_1/log/xxx/client 資料夾觀察一下。

處理結果:

將/oracle/product/10.2.0/db_1/log/xxx/client重新命名，發現會自動重建，然後各項操作速度就非常快了。

解決set newname 極慢的問題

相關文章