request gap sequence is Failed

日誌出現如下的報錯資訊

 

Fri Apr  2 21:37:45 2010

FAL[client]: Failed to request gap sequence

 GAP - thread 1 sequence 168065-168164

 DBID 3642507004 branch 645772988

FAL[client]: All defined FAL servers have been attempted.

-------------------------------------------------------------

Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization

parameter is defined to a value that is sufficiently large

enough to maintain adequate log switch information to resolve

archivelog gaps.

-------------------------------------------------------------

 

出現這個問題的一種情況是FAL_SERVER資料庫已經沒有序列號為上述的歸檔日誌了，這非常容易理解。還有一種情況是FAL_SERVER資料庫有上述序列號的歸檔日誌，這又如何理解呢？我在實踐中碰到過這種情況，當時168065之前的歸檔日誌是一段時間從主庫獲取的，這之後主庫與備庫的日誌傳送被我禁用，之後，當主庫到了168164之後的日誌點後，重新開啟了主庫與備庫的日誌傳送，這樣子168065-168164的歸檔日誌就缺失了，也出現了以上的報錯。這個問題出來後，採取瞭如下的措施：將FAL_SERVER資料庫傳送備庫歸檔日誌路徑禁用掉，之後經過一段時間重新將該歸檔路徑啟動，結果發現歸檔日誌又自動開始傳送了。在備庫可以看到如下的日誌，可以清楚地看到備庫日誌傳送程式RFS重啟了。

 

Fri Apr  2 21:52:07 2010

RFS[11]: Successfully opened standby log 11: '+DATA/ark/onlinelog/group_11.600.715219947'

Fri Apr  2 21:53:05 2010

RFS[10]: Successfully opened standby log 12: '+DATA/ark/onlinelog/group_12.601.715219949'

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[12]: Assigned to RFS process 659520

RFS[12]: Identified database type as 'physical standby'

Fri Apr  2 22:04:43 2010

Redo Shipping Client Connected as PUBLIC

-- Connected User is Valid

RFS[13]: Assigned to RFS process 553208

RFS[13]: Identified database type as 'physical standby'

RFS[13]: Successfully opened standby log 11: '+DATA/ark/onlinelog/group_11.600.715219947'

Fri Apr  2 22:10:38 2010

RFS[12]: Archived Log: '/arc/archive/ark/1_168065_645772988.arc'

Fri Apr  2 22:10:43 2010

Media Recovery Log /arc/archive/ark/1_168065_645772988.arc

 

據此，我的理解是，RFS[10]和RFS[11]這兩個備庫日誌傳送程式在啟動時並沒有獲取備庫缺少某些舊歸檔日誌的資訊，因此它只獲取168164之後，由主庫新生成的日誌，而在備庫恢復到168065這個歸檔日誌時，才發現還缺少一些舊的日誌，但RFS[10]和RFS[11]不會被告知這個資訊，因此它們不會去獲取舊的日誌。而當重啟日誌傳送後，RFS[12]和RFS[13]這兩個新的日誌傳送程式會被告之備庫目前還缺一些舊的日誌，這兩個程式就去主庫嘗試獲取前面缺的日誌，發現後，就開始了舊日誌的傳送。