Standby_file_management引數導致日誌無法應用

最近在加主庫新增資料檔案時導致備庫無法被應用，警告日誌報如下錯誤：

Media Recovery Waiting for thread 1 sequence 921276 (in transit)

Recovery of Online Redo Log: Thread 1 Group 72 Seq 921276 Reading mem 0

  Mem# 0: +DATA/ractd/onlinelog/group_72.393.965631001

File #2172 added to control file as 'UNNAMED02172' because

the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL

The file should be manually created to continue.

MRP0: Background Media Recovery terminated with error 1274

Errors in file /u01/app/oracle/diag/rdbms/ractd/racdb1/trace/racdb1_pr00_8585508.trc:

ORA-01274: cannot add datafile '+ /data/tb01' - file could not be created

Mon Apr 18 17:21:10 2018

Managed Standby Recovery not using Real Time Apply

Mon Apr 18 17:21:17 2018

Recovery interrupted!

Mon Apr 18 17:21:39 2018

Recovered data files to a consistent state at change 15893497106246

Mon Apr 18 17:21:39 2018

……………….

Mon Apr 18 17:21:40 2018

Mon Apr 18 17:21:40 2018

 LMS 3: 0 GCS shadows cancelled, 0 closed, 0 Xw survived

 LMS 1: 0 GCS shadows cancelled, 0 closed, 0 Xw survived

Mon Apr 18 17:21:40 2018

 LMS 2: 0 GCS shadows cancelled, 0 closed, 0 Xw survived

 Set master node info

 Submitted all remote-enqueue requests

 Dwn-cvts replayed, VALBLKs dubious

 All grantable enqueues granted

Mon Apr 18 17:22:00 2018

 Submitted all GCS remote-cache requests

 Fix write in gcs resources

Mon Apr 18 17:22:01 2018

RFS[233]: Selected log 71 for thread 1 sequence 921277 dbid -357299396 branch 822617764

Mon Apr 18 17:22:01 2018

RFS[218]: Selected log 108 for thread 2 sequence 83914 dbid -357299396 branch 822617764

Mon Apr 18 17:22:01 2018

Archived Log entry 124723 added for thread 2 sequence 83913 ID 0xffffffffeab48e3c dest 1:

Reconfiguration complete

Mon Apr 18 17:22:02 2018

Block change tracking service stopping.

Mon Apr 18 17:22:02 2018

Stopping background process CTWR

Mon Apr 18 17:22:03 2018

MRP0: Background Media Recovery process shutdown (racdb1)

Mon Apr 18 17:22:06 2018

Archived Log entry 124724 added for thread 1 sequence 921276 ID 0xffffffffeab48e3c dest 1:

Mon Apr 18 17:23:13 2018

RFS[233]: Selected log 72 for thread 1 sequence 921278 dbid -357299396 branch 822617764

Mon Apr 18 17:23:19 2018

Archived Log entry 124725 added for thread 1 sequence 921277 ID 0xffffffffeab48e3c dest 1:

Mon Apr 18 17:24:20 2018

RFS[233]: Selected log 71 for thread 1 sequence 921279 dbid -357299396 branch

 

從警告日誌 看，備庫中一些歸檔日誌無法被應用。原本以為是新增資料檔案加到本地（asm），檢視主庫時新增的資料檔案，一切正常，檢視從備庫的日誌來看，File #2172 added to control file as 'UNNAMED02172' because

the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL 原來是引數STANDBY_FILE_MANAGEMENT設定了手動，導致MRP0程式無法啟動。

 

為什麼這樣 原理如下：

以上問題主要是因為：Standby_file_management引數為STANDBY_FILE_MANAGEMENT =MANUAL造成不會自動管理資料檔案，主庫增加了資料檔案，備庫不會自動增加，

正常備庫應用的是歸檔檔案，但主庫新增資料檔案時，，此時會有一部分資料不在歸檔日誌中，但這部分資料會等主資料庫恢復完後 'UNNAMED02172' 等這樣的檔案命名儲存此資料，此檔案儲存在DBS中，從作業系統中進去檢視卻看不到這個檔案。同時這個資料也會傳到備庫對應的目錄中。

若資料庫應用日誌的先後順序是這樣：redo1->redo2->redo3 ……..，在新增資料檔案時，當時redo用到了                                                 因此若不處理UNNAMED02172這個資料檔案的話，則備庫在應用redo時就會出錯，提示找到檔案，就會出現不能應用日誌的情況。要想能正常應用日誌，先處理UNNAMED02172的檔案，處理後備庫先應用unname檔案，然後才能按日誌的順序應用。

 

處理過程如下：

1. 調整standby_file_management引數為 manual

alter system set standby_file_management= manual scope=both sid=’*’;

 

2. 透過 control file 手工建立資料檔案

SQL>  alter database create datafile
' /u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED02162 ' as '+data/datafile/';

 3. 將 standby_file_management 設定為 auto

SQL>  alter system set standby_file_management=auto scope=both sid=’*’;

 

4.  啟動恢復

SQL>  alter database recover managed standby database disconnect from session;

 

5. 檢查一下是否同步

SQL> select to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') from v$datafile;

 

結論：

一般在新增資料檔案時需要主要如下引數：

備庫

standby_file_management

db_FILES

DB_FILE_NAME_convert

LOG_FILE_NAME_CONVERT

檢視應用日誌狀態：

select value from v$dataguard_stats where name='apply lag';