關於10g DG中的ORA-19527和ORA-00312錯誤解決樣本，ora-19527ora-00312
這幾天在搭建10g DG Windows 2008 R2的測試環境，主要是明天要去給一客戶重新搭建一套生產庫的DG，其中發現一些問題，特此記錄一下
由於將要部署到生產環境，所以考慮線上搭建DG的方案，即不停庫的情況下，而問題主要就是出在不停庫時，用RAMN建立STANDBY的時候
通常線上搭建DG，主要是下面幾個步驟：
1. 確保主庫開啟歸檔，並開啟force logging模式
2. 主庫線上修改spifle，alter system set .... scope=both;並建立pfile
首先要確保所需修改的參支援線上修改，可以查看視圖v$parameter
SQL> select distinct issys_modifiable from v$parameter;
ISSYS_MODIFIABLE
---------------------------
DEFERRED
FALSE
IMMEDIATE
說明：
DFERRED：動態參數，修改後對當前活躍的session無效
FALSE：靜態參數，修改後需重啟資料庫
IMMEDIATE：動態參數，修改後立即對所有session生效
SQL> select name,issys_modifiable,value from v$parameter where name='xxxx'; xxxx為要修改的參數名
在需要改的幾個參數中，只有db_unique_name不支援線上修改
SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(ora10gpd,ora10gst)' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=ora10gpd' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=ora10gst LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=ora10gst' scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE scope=both;
SQL> alter system set LOG_ARCHIVE_DEST_STATE_2=ENABLE scope=both;
SQL> alter system set FAL_SERVER=ora10gst scope=both;
SQL> alter system set FAL_CLIENT=ora10gpd scope=both;
SQL> alter system set STANDBY_FILE_MANAGEMENT='AUTO' scope=both;
所以如果生產庫想不停庫搭建DG的話，那麼就要使用原有的db_unique_name，通常和db_name是同一個名字
修改完spfile以後，用它建立一個pfile，供備庫使用，create pfile from spfile;
3. 主庫建立standby redo logfile，alter database add standby logfile group # datafile ('xxxx') size 50M; xxxx指定路徑和檔案名稱
4.建立listener.ora和tnsnames.ora，把產生的檔案複製到備庫相應位置並修改
5. 主庫建立備庫控制檔案、資料檔案、歸檔記錄檔備份組
rman target /
RMAN> backup full database format 'c:\backup\full_%d_%I_%U' include current controlfile for standby plus archivelog format 'c:\backup\arc_%d_%I_%U';
或者：
run
{
allocate channel d1 type disk;
backup format 'C:\backup\df_%d_%I_%U' database;
sql 'alter system archive log current';
backup format 'C:\backup\al_%d_%I_%U' archivelog all;
backup current controlfile for standby format 'C:\backup\cf_%d_%I_%U';
release channel d1;
}
6. 把pfile參數檔案，密碼檔案，拷貝到備庫%ORACLE_HOME%\database\下
7. 建立備庫執行個體(ora10g)及相關目錄
C:\Users\Administrator>oradim -new -sid ora10g
C:\oracle\product\10.2.0\fast_recovery_area
C:\oracle\product\10.2.0\admin\
C:\oracle\product\10.2.0\admin\adump
C:\oracle\product\10.2.0\admin\bdump
C:\oracle\product\10.2.0\admin\cdump
C:\oracle\product\10.2.0\admin\dpdump
C:\oracle\product\10.2.0\admin\pfile
C:\oracle\product\10.2.0\admin\udump
8. 把主庫備份組拷貝到備庫並進行恢複，主要是3個步驟
① nomount狀態下恢複備庫控制檔案， RMAN> restore controlfile from 'C:\backup\xxxx'; xxxx為含有備庫控制檔案的備份片名稱
② mount狀態下恢複資料庫，RMAN> restore database;
③ 恢複備庫歸檔記錄檔，RMAN> restore archivelog all;
或在做完第①步後，在主庫open，備庫nomount狀態下串連到RMAN執行：
rman target sys/oracle@ora10gpd auxiliary /
run
{
allocate channel C1 device type disk;
allocate auxiliary channel C2 device type disk;
duplicate target database for standby nofilenamecheck;
release channel C1;
release channel C2;
}
9. 備庫建立standby redo logfile，大小位置需和主庫一致
10. 完成恢複並啟動mpr0進程，即啟用redo apply，alter database recover managed standby database disconnect from session;
如果一切順利，那麼此時備庫就會開始逐一應用主庫傳過來的歸檔記錄檔
但，事實沒有這麼簡單，在我實際做下來的結果是，主庫的redo log記錄檔無法傳遞到備庫，備庫的alert log日誌會報 ORA-19527 和 ORA-00312 錯誤，如下：
ORA-19527: 必須重新命名物理備用重做日誌
ORA-00312: 聯機日誌 1 線程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\REDO01.LOG'
這是由於10g以後，oracle為了加快swtichover的速度，在can become a primary之前就去clear the online logfiles了，而如果沒有設定log_file_name_convert，這個時候oracle可能就不能識別哪怕是冷備copy過來的路徑檔案名稱都一模一樣的redo logfile，解決方案就是在主庫參數中添加log_file_name_convert，原來沒有用這個參數，是因為主備庫的log記錄檔路徑都一樣（因為用了同一個資料庫執行個體名ora10g）
SQL> alter system set log_file_name_convert='C:\oracle\product\10.2.0\oradata\ora10g','C:\oracle\product\10.2.0\oradata\ora10g' scope=spfile;
log_file_name_convert 這個參數非線上可修改，必須重啟後才會生效：
這就有點尷尬，生產庫就必須重啟一下，也就是說必須停一下庫，哪怕只是幾分鐘，不過當設定完成，重啟standby，apply日誌以後，看到alert log日誌中果然可以看到clear online logfiles了，問題得到解決
備庫alert log日誌會提示以下內容：
Thu Jul 17 10:49:21 2014Thu Jul 17 10:51:25 2014
注意看備庫警示日誌中提示的開始清除redo logfile的時間和window目錄中這幾個檔案建立的時間，就是在清除線上記錄檔的你那一刻，在備庫產生了相應的檔案。
也就是說，當啟用redo apply 的時候，備庫先會提示無法讀取參數中配置的線上記錄檔，那後就會去清除該日誌，並自動產生該檔案，就是這麼個過程
當然，alert log還會繼續提示也不存在sandby redo logfile，如下：
Media Recovery Waiting for thread 1 sequence 66
Thu Jul 17 10:51:25 2014
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 2100
RFS[2]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:51:25 2014
Errors in file c:\oracle\product\10.2.0\admin\ora10g\udump\ora10g_rfs_2100.trc:
ORA-00313: 無法開啟日誌組 4 (用於線程 1) 的成員
ORA-00312: 聯機日誌 4 線程 1: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORA10G\STDREDO04.LOG'
ORA-27041: 無法開啟檔案
OSD-04002: 無法開啟檔案
O/S-Error: (OS 2) 系統找不到指定的檔案。
這個standby redo logfile和online redo logfile又有些不同，如果碰到無法開啟，資料庫不會去清除並自動建立，而是需要我們手動去建立
但可以從v$log視圖中發現，該檔案是已經存在於備庫控制檔案中的（因為主庫在建立備庫控制檔案備份的時候，就已經建立好了嘛），那就無法用語句再建立一次，會提示該檔案已存在（而實際上物理並不存在），可以先drop掉，再重新建立，如果添加或刪除主庫online redo logfile，那麼需要先把standby_file_management參數的值改為manual，之後再改回auto
如果standby redo logfile配置有問題，那麼當切換保護模式到maximize availability或maximize protection時，會報：
ORA-16072: a minimum of one standby database destination is required
此時即使已經配置了LOG_ARCHIVE_DEST_2中已經配置了LGWR SYNC AFFIRM，open資料庫時會報：
ORA-03113: end-of-file on communication channel
這是因為，最高可用和最大保護這兩種模式必須使用LGWR進程來寫到standby redo logfile，如果這個條件不能保證，那麼就無法開啟資料庫，強制斷開與資料庫的連結，以提供對資料庫的最大範圍的安全保護
等這些日誌都順利在備庫建立後，備庫就可以開始同步應用主庫歸檔日誌了：
Thu Jul 17 10:51:25 2014
RFS[1]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_66_9WGGKFWB_.ARC'
Thu Jul 17 10:51:30 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_66_9WGGKFWB_.ARC
Thu Jul 17 10:51:50 2014
RFS[2]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_67_9WGGKFVT_.ARC'
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:52:16 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_67_9WGGKFVT_.ARC
Media Recovery Waiting for thread 1 sequence 68 (in transit)
Thu Jul 17 10:57:20 2014
RFS[2]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_68_9WGGL635_.ARC'
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:57:22 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_68_9WGGL635_.ARC
Media Recovery Waiting for thread 1 sequence 69 (in transit)
Thu Jul 17 10:57:35 2014
RFS[2]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_69_9WGGWJCK_.ARC'
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:57:38 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_69_9WGGWJCK_.ARC
Media Recovery Waiting for thread 1 sequence 70 (in transit)
Thu Jul 17 10:57:51 2014
RFS[2]: Archived Log: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_70_9WGGWZ9C_.ARC'
Primary database is in MAXIMUM PERFORMANCE mode
Thu Jul 17 10:57:53 2014
Media Recovery Log C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORA10GST\ARCHIVELOG\2014_07_17\O1_MF_1_70_9WGGWZ9C_.ARC
Media Recovery Waiting for thread 1 sequence 71 (in transit)
可以看到，此時 sequence 70已經在備庫上應用，在等待主庫傳sequence 71的日誌了
Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
