[zt] 手工處理Standby 歸檔間隔(gap)的問題
從9i以後,一般都不需要手工處理缺失的日誌,FAL自動會幫我們處理這些問題。
但是,並非我們就完全不用手工處理了,比如,你的磁碟空間爆滿,歸檔日誌在傳到備庫前被轉移到其他地方,這種情況下FAL是不能解決問題的,需要手工處理一下。
下面就簡單說說手工處理日誌GAP的步驟:
1、在備庫檢查是否有日誌缺失
SQL> select * from V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 99 109
從上面的資訊可以看出,備庫中缺失了99到109的日誌。
2、在主庫中查詢缺失的日誌的所在路徑和名稱
SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND DEST_ID=1 AND SEQUENCE# BETWEEN 99 AND 109;
NAME
--------------------------------------------------------------------------------
/u01/archivelog/1_99_626106231.arc
/u01/archivelog/1_100_626106231.arc
/u01/archivelog/1_101_626106231.arc
/u01/archivelog/1_102_626106231.arc
/u01/archivelog/1_103_626106231.arc
/u01/archivelog/1_104_626106231.arc
/u01/archivelog/1_105_626106231.arc
/u01/archivelog/1_106_626106231.arc
/u01/archivelog/1_107_626106231.arc
/u01/archivelog/1_108_626106231.arc
/u01/archivelog/1_109_626106231.arc
如果把日誌移動到其他路徑,則把日誌所在路徑換成當前實際所在路徑。
3、把日誌複製到備庫上
sftp> get 1_99_626106231.arc
Fetching /u01/archivelog/archive/1_99_626106231.arc to 1_99_626106231.arc
/u01/archivelog/archive/1_99_626106231.arc 100% 17KB 17.0KB/s 00:00
sftp> mget 1_10*
Fetching /u01/archivelog/archive/1_100_626106231.arc to 1_100_626106231.arc
/u01/archivelog/archive/1_100_626106231.arc 100% 4962KB 2.4MB/s 00:02
......
Fetching /u01/archivelog/archive/1_10_626106231.dbf to 1_10_626106231.dbf
/u01/archivelog/archive/1_10_626106231.dbf 100% 40KB 40.0KB/s 00:00
4、在備庫上手工註冊上一步中從主庫複製來的日誌
SQL> ALTER DATABASE REGISTER LOGFILE '/u01/archivelog/1_99_626106231.arc';
Database altered.
......
SQL> ALTER DATABASE REGISTER LOGFILE '/u01/archivelog/1_109_626106231.arc';
Database altered.
5、稍等片刻,觀察備庫的alert日誌資訊
Sun Aug 12 20:38:47 2007
Media Recovery Log /u01/archivelog/1_99_626106231.arc
Media Recovery Log /u01/archivelog/1_100_626106231.arc
Media Recovery Log /u01/archivelog/1_101_626106231.arc
Media Recovery Log /u01/archivelog/1_102_626106231.arc
......
從以上資訊,可以看出之前註冊的日誌已經被正常應用。
6、檢查備庫是否還有日誌GAP
SQL> select * from V$ARCHIVE_GAP;
no rows selected
如果有行返回,則重複2-5步,直到查詢結果是"no rows selected"。
如果日誌只是臨時移動到其他地方,過後會再移回原路徑,則不用這麼大費周折手工去手工處理了,把日誌拷回原處後FAL會自動處理GAP。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/35489/viewspace-557272/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 手工清除歸檔處理歸檔空間滿
- standby無法使用歸檔日誌問題處理
- DATAGUARD中手工處理日誌GAP
- standby缺失primary歸檔,手工同步恢復
- 在DATAGUARD中手工處理日誌GAP的方法
- tempfile檔案過大問題處理 for logical standby
- 週末又一次歸檔空間不足問題處理
- Oracle_dg歸檔丟失問題處理Oracle
- 使用RMAN增量備份處理Dataguard因歸檔丟失造成的gap
- ORACLE DATAGUARD中手工處理日誌v$archive_GAP的方法OracleHive
- [zt]Logical standby同步故障的處理過程
- sysaux表空間檔案損壞的處理(zt)UX
- 一次資料庫不能歸檔問題的處理資料庫
- oracle對於時間間隔的處理Oracle
- 【轉】 一次資料庫不能歸檔問題的處理資料庫
- 手動處理DataGuard間隔
- Standby OS i/o問題導致Primary 庫不能正常歸檔問題
- 【故障處理】RAC環境第二節點無法歸檔的詭異問題處理
- oracle 10g rac+asm 歸檔路徑磁碟組空間滿問題處理Oracle 10gASM
- 數字轉時間間隔格式處理
- 歸檔目錄空間不足造成的問題
- 手工ftp拷貝歸檔及指令碼自動恢復Standby方式FTP指令碼
- Standby和Primary DB出現通訊問題後的arch gap 傳輸問題
- 處理TEMP表空間滿的問題
- [記錄]Standby相關引數及gap問題解決
- 一次dg 因密碼檔案與gap引起歸檔日誌無法應用的處理密碼
- sysaux 表空間不足問題處理UX
- [zt] 總結logminer使用及各種問題處理
- [zt] 處理LOB(大物件)表enqueue HW問題的一個方法物件ENQ
- 記一次:歸檔檔案系統問題導致資料庫hang處理資料庫
- 處理Linux刪除檔案後空間未釋放的問題Linux
- 傳輸表空間及問題處理
- 【問題處理】通過調整資料檔案的位置解決磁碟空間緊張的問題
- 關於時間 PHP 處理包遇到的問題時間序列化差值問題PHP
- dataguard standby備庫磁碟空間滿(ZT)
- Redo Gap 處理與優化優化
- DG發現gap處理流程
- oracle資料庫歸檔日誌空間滿引起的錯誤處理Oracle資料庫