Fetching gap sequence in thread 1, gap sequence 41842-41873
FAL[client]: Trying FAL server: XDSL
Tue Dec 18 13:44:03 2012
FAL[client]: Failed to request gap sequence for thread 1 gap sequence 41842-41873
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.
Alert log da yukardaki gibi bir uyari alindiginda, bazi archive loglarin alinamadigini veya standby tarafina alinmissa bile bozuldugu için apply edilemedigi sonucunu çikarabiliriz.
Öncelikle kontrollerimizi yapalim;
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS --------- ------------ ---------- ---------- ---------- ---------- ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 ARCH CONNECTED 0 0 0 0 MRP0 WAIT_FOR_GAP 1 41842 0 0 RFS WRITING 1 41963 538625 2048 RFS WRITING 1 41965 458753 2048 RFS WRITING 1 41964 516097 2048 RFS RECEIVING 0 0 0 0
Durumu WAIT_FOR_GAP olan v$archived_log tablosunda görünmeyecektir.
select THREAD#, DEST_ID, SEQUENCE#, applied, archived from v$archived_log where dest_id=3 and applied='NO' order by SEQUENCE#;
THREAD# DEST_ID SEQUENCE# APP ARC
---------- ---------- ---------- --- ---
1 3 41874 NO YES
1 3 41875 NO YES
1 3 41876 NO YES
1 3 41877 NO YES
1 3 41878 NO YES
1 3 41879 NO YES
1 3 41880 NO YES
1 3 41881 NO YES
1 3 41882 NO YES
1 3 41883 NO YES
1 3 41884 NO YES
1 3 41885 NO YES
1 3 41886 NO YES
1 3 41887 NO YES
1 3 41888 NO YES
1 3 41889 NO YES
1 3 41890 NO YES
1 3 41891 NO YES
1 3 41892 NO YES
1 3 41893 NO YES
1 3 41894 NO YES
1 3 41895 NO YES
1 3 41896 NO YES
1 3 41897 NO YES
1 3 41898 NO YES
1 3 41899 NO YES
1 3 41900 NO YES
1 3 41901 NO YES
1 3 41902 NO YES
1 3 41903 NO YES
1 3 41904 NO YES
1 3 41905 NO YES
1 3 41906 NO YES
1 3 41907 NO YES
1 3 41908 NO YES
35 rows selected.
–yukardaki hata, bazi loglarin arsivlnemedigini gösteriir. Bunun birkaç nedeni olabilir aslinda.
*prod tarafinda archive loglar olmayabilir.
*standby tarafina loglar eksik veya yanlis gelmis olabilir.
*loglar CONTROL_FILE_RECORD_KEEP_TIME degerinden eski olabilir.
Bu durumu çözmek için,
*eger loglar standby’da yoksa, baska bir ortamdan scp ile standbya kopyalanir veya backuptan restore edilir.
Gap’taki eksik archiveloglar kopyalandiktan sonra veya restore edildikten sonra standby’da asagidaki komut gapteki her archivelog için çalistirilir.
alter database register or replace logfile '/arcdsl11/XDSL/1_41842_751682847.arc';
gap durmunu kontrol için asagidaki sorgu da kullanilabilir.
SQL> select * from v$archive_gap ;
Asagidaki linkten de faydalanilabilir.
http://oraexplorer.com/2010/05/oracle-10-2-0-3-gap-resolution-of-physical-standby-appears-to-hang/