DATAGUARD中手工處理日誌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。
但是,並非我們就完全不用手工處理了,比如,你的磁碟空間爆滿,歸檔日誌在傳到備庫前被轉移到其他地方,這種情況下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/231499/viewspace-63845/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- ORACLE 11G DATAGUARD 日誌中斷處理方案Oracle
- Oracle DataGuard歸檔日誌丟失處理方法Oracle
- 使用RMAN增量備份處理Dataguard因歸檔丟失造成的gap
- shell日誌顏色處理
- orbeon form 的日誌處理ORBORM
- ES & Filebeat 使用 Pipeline 處理日誌中的 @timestamp
- dataguard ORA-17628 處理
- node錯誤處理與日誌
- SQLServer 2008中事務日誌已滿問題處理SQLServer
- ELK 處理 Spring Boot 日誌,不錯!Spring Boot
- 如何在zuul上做日誌處理Zuul
- 搭建node服務(1):日誌處理
- SpringBoot第十三篇:日誌處理Spring Boot
- 指令碼處理iOS的Crash日誌指令碼iOS
- 利用 ELK 處理 Percona 審計日誌
- OracleDG資料庫gap處理一列Oracle資料庫
- Oracle 11.2.0.4 Dataguard兩則故障處理Oracle
- Flink 在又拍雲日誌批處理中的實踐
- 基於go開發日誌處理包Go
- node專案錯誤處理與日誌
- SQLServer資料庫日誌太大處理方式SQLServer資料庫
- logback下日誌輸出前處理操作——以日誌脫敏為例
- 『無為則無心』Python日誌 — 67、logging日誌模組處理流程Python
- 如何在DATAGUARD中新增刪除聯機日誌
- oracle10g DataGuard的日誌傳輸方式Oracle
- Spark SQL:實現日誌離線批處理SparkSQL
- 對 Hyperf 做的那些事 3(日誌處理)
- 從0寫一個Golang日誌處理包Golang
- SpringBoot部落格開發之AOP日誌處理Spring Boot
- 手工rm刪除歸檔日誌對備份歸檔日誌的影響
- 結合 AOP 輕鬆處理事件釋出處理日誌事件
- 關於11G DataGuard 日誌傳輸的案例
- 基於flink和drools的實時日誌處理
- syslog強大而安全的日誌處理系統
- Golang 快速讀取處理大日誌檔案工具Golang
- 日誌伺服器搭建之多伺服器日誌轉發與格式化處理伺服器
- PG啟動流程StartupXlog函式回放日誌前處理函式
- mysqlbinlog 處理二進位制日誌檔案的工具MySql