都是crosscheck惹的禍,備份歸檔失敗
備份是大事,有的時候睡覺都驚醒,忘備份了
如果備份不細檢查備份環節就更可怕了
RMAN> list archivelog all;
List of Archived Log Copies
Key Thrd Seq S Low Time Name
------- ---- ------- - --------- ----
1224 2 107 X 25-DEC-07 /home/oracle/archive/2_107_640546001.arc
1225 2 108 X 25-DEC-07 /home/oracle/archive/2_108_640546001.arc
1226 2 109 X 26-DEC-07 /home/oracle/archive/2_109_640546001.arc
1228 2 110 X 26-DEC-07 /home/oracle/archive/2_110_640546001.arc
1229 2 111 X 26-DEC-07 /home/oracle/archive/2_111_640546001.arc
1231 2 112 X 26-DEC-07 /home/oracle/archive/2_112_640546001.arc
1232 2 113 X 26-DEC-07 /home/oracle/archive/2_113_640546001.arc
1234 2 114 X 26-DEC-07 /home/oracle/archive/2_114_640546001.arc
1235 2 115 X 26-DEC-07 /home/oracle/archive/2_115_640546001.arc
1236 2 116 X 26-DEC-07 /home/oracle/archive/2_116_640546001.arc
檢視系統的歸檔,看到status為X,並沒有在意,直接備份
但備份以後,發現RMAN不識別狀態為X的歸檔,
RMAN> run
2> {
3> allocate channel c1 device type disk connect 'sys/baan@baan1';
4> allocate channel c2 device type disk connect 'sys/baan@baan2';
5> backup archivelog all delete all input;
6> }
released channel: ORA_DISK_1
released channel: ORA_DISK_2
allocated channel: c1
channel c1: sid=918 instance=baan1 devtype=DISK
allocated channel: c2
channel c2: sid=1080 instance=baan2 devtype=DISK
Starting backup at 21-MAR-08
current log archived
channel c1: starting archive log backupset
channel c1: specifying archive log(s) in backup set
input archive log thread=1 sequence=385 recid=1808 stamp=649954597
input archive log thread=1 sequence=386 recid=1811 stamp=649954670
channel c1: starting piece 1 at 21-MAR-08
根本沒有去讀第2個節點的歸檔,crosscheck archivelog all;以後,狀態為available,
rman才重新識別,太可怕了,如果沒有注意的話,一旦出現介質故障,就毀了
channel c2: starting piece 1 at 21-MAR-08
channel c1: finished piece 1 at 21-MAR-08
piece handle=+BACKUP/baan/backupset/2008_03_21/annnf0_tag20080321t145751_0.271.649954675 tag=TAG20080321T145751 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:03
channel c1: deleting archive log(s)
archive log filename=/home/oracle/archive/1_385_640546001.arc recid=1808 stamp=649954597
archive log filename=/home/oracle/archive/1_386_640546001.arc recid=1811 stamp=649954670
channel c2: finished piece 1 at 21-MAR-08
piece handle=+BACKUP/baan/backupset/2008_03_21/annnf0_tag20080321t145751_0.273.649954675 tag=TAG20080321T145751 comment=NONE
channel c2: backup set complete, elapsed time: 00:05:19
channel c2: deleting archive log(s)
archive log filename=/home/oracle/archive/2_212_640546001.arc recid=1388 stamp=643726675
archive log filename=/home/oracle/archive/2_213_640546001.arc recid=1389 stamp=643727323
archive log filename=/home/oracle/archive/2_214_640546001.arc recid=1391 stamp=643727824
archive log filename=/home/oracle/archive/2_215_640546001.arc recid=1392 stamp=643728326
archive log filename=/home/oracle/archive/2_216_640546001.arc recid=1393 stamp=643728836
archive log filename=/home/oracle/archive/2_217_640546001.arc recid=1395 stamp=643729304
archive log filename=/home/oracle/archive/2_218_640546001.arc recid=1396 stamp=643729580
archive log filename=/home/oracle/archive/2_219_640546001.arc recid=1397 stamp=643730043
archive log filename=/home/oracle/archive/2_220_640546001.arc recid=1399 stamp=643730527
archive log filename=/home/oracle/archive/2_221_640546001.arc recid=1400 stamp=643730960
archive log filename=/home/oracle/archive/2_222_640546001.arc recid=1401 stamp=643731342
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/175005/viewspace-214917/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 都是髒資料惹的禍
- Oracle RAC啟動失敗-軟連結惹的禍Oracle
- 都是標量子查詢惹的禍
- 都是weblogic和ejb惹的禍Web
- TSM備份時因歸檔日誌丟失而導致備份失敗
- Rman Crosscheck刪除失效歸檔-備份恢復ROS
- 誤刪歸檔日誌除導致備份歸檔日誌失敗
- 都是指標資料成員“惹的禍”指標
- 刪除歸檔物理檔案備份失敗!ORA-19625
- XP系統故障 都是“防火牆”惹的禍(轉)防火牆
- RMAN-ERROR:因為找不到過期和丟失的歸檔日誌而備份失敗Error
- 備份歸檔日誌報錯ORA-19625: crosscheck archivelog allROSHive
- rman備份但丟失一個資料檔案,但有歸檔備份
- 城市擁堵加劇,都是網際網路快車惹的禍?
- Oracle dg歸檔同步失敗Oracle
- Mysql備份失敗案例(一)MySql
- 非歸檔無備份下控制檔案丟失的恢復
- rman備份的時候讀取v$session_longops失敗導致備份失敗SessionGo
- RMAN基於備份控制檔案恢復失敗
- ###都是設計模式惹的禍-----下面不知道該怎麼寫了###設計模式
- dg丟失歸檔,使用rman增量備份恢復
- 利用增量備份恢復gap歸檔丟失DG
- 歸檔模式無備份丟失資料檔案後恢復模式
- 歸檔模式有備份丟失資料檔案後恢復模式
- Rman Crosscheck刪除失效歸檔ROS
- 備份之歸檔重做日誌備份
- oracle 如何不備份已經備份的歸檔Oracle
- 沒備份,歸檔日誌存在,丟失資料檔案的恢復
- 備份歸檔日誌
- 利用增量備份恢復因歸檔丟失造成的DG gap
- Oracle RMAN 不完全恢復(只有資料檔案備份,丟失歸檔日誌備份)Oracle
- rman全庫備份備份歸檔日誌檔案
- 【備份恢復】恢復 丟失已歸檔重做日誌檔案
- 都是密碼惹的禍——由windows server 2008忘記密碼想到的密碼WindowsServer
- 備份歸檔日誌檔案
- rman恢復--歸檔模式有備份,丟失資料檔案的恢復模式
- rman恢復--歸檔模式無備份,丟失資料檔案的恢復模式
- 故障分析 | DDL 導致的 Xtrabackup 備份失敗