解決物理standby 歸檔日誌損壞ORA-00334
物理備庫歸檔日誌損壞導致mrp程式沒有起來，datagurad不同步
standby trace log日誌
Errors in file /app/oracle/diag/rdbms/crds3dbdg/crds3db/trace/crds3db_pr00_1395.trc (incident=96300):
ORA-00353: 日誌損壞接近塊 16152 更改 875606062 時間 01/02/2014 13:11:57
'/orasjrz/crds3db/oraarch/2_8556_798146541.arc'
Incident details in: /app/oracle/diag/rdbms/crds3dbdg/crds3db/incident/incdir_96300/crds3db_pr00_1395_i96300.trc
Completed: alter database recover managed standby database using current logfile disconnect
Errors with log /orasjrz/crds3db/oraarch/3_8491_798146541.arc
MRP0: Background Media Recovery terminated with error 354
Errors in file /app/oracle/diag/rdbms/crds3dbdg/crds3db/trace/crds3db_pr00_1395.trc:
ORA-00354: 損壞重做日誌塊標頭
ORA-00353: 日誌損壞接近塊 16152 更改 875606062 時間 01/02/2014 13:11:57
ORA-00334: 歸檔日誌: '/orasjrz/crds3db/oraarch/2_8556_798146541.arc'
Managed Standby Recovery not using Real Time Apply
Thu Jan 23 10:07:26 2014
Sweep [inc2][96299]: completed
Recovery interrupted!
Thu Jan 23 10:07:26 2014
Sweep [inc][96300]: completed
Thu Jan 23 10:07:26 2014
Dumping diagnostic data in directory=[cdmp_20140123100726], requested by (instance=1, osid=1395 (PR00)), summary=[incident=96300].
Recovered data files to a consistent state at change 875605791
MRP0: Background Media Recovery process shutdown (crds3db)
Thu Jan 23 10:09:09 2014
RFS[23]: Selected log 32 for thread 3 sequence 8941 dbid -1664027027 branch 798146541
Thu Jan 23 10:09:10 2014
Archived Log entry 27271 added for thread 3 sequence 8940 ID 0x9cd0ed6d dest 1:
exit
Thu Jan 23 10:21:23 2014
RFS[24]: Selected log 22 for thread 2 sequence 9076 dbid -1664027027 branch 798146541
Thu Jan 23 10:21:23 2014
Archived Log entry 27272 added for thread 2 sequence 9075 ID 0x9cd0ed6d dest 1:
Thu Jan 23 10:24:59 2014
RAC primary：
把主庫歸檔傳到備庫
ASMCMD> cp thread_2_seq_8556.13009.835796493 /home/grid/
copying +oraarch/crds3db/archivelog/2014_01_02/thread_2_seq_8556.13009.835796493 -> /home/grid//thread_2_seq_8556.13009.835796493
ASMCMD> exit
[grid@his2 ~]$ cd /home/grid/
[grid@his2 ~]$ ls
cvuqdisk-1.0.9-1.rpm Desktop oradiag_grid thread_2_seq_8556.13009.835796493
[grid@his2 ~]$ exit
logout
[root@his2 ~]# cd /home/grid/
[root@his2 grid]# scp thread_2_seq_8556.13009.835796493 hisdg:/orasjrz/crds3db/oraarch/2_8556_798146541.arc
The authenticity of host 'hisdg (192.168.20.11)' can't be established.
RSA key fingerprint is d5:95:c6:d9:02:45:00:a1:75:ac:84:f9:5a:6a:00:ca.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'hisdg,192.168.20.11' (RSA) to the list of known hosts.
password:
thread_2_seq_8556.13009.835796493 100% 11MB 10.6MB/s 00:00
STANDBY DATABASE
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
SQL> select process,status,sequence#,thread# from v$managed_standby;
PROCESS STATUS SEQUENCE# THREAD#
--------- ------------ ---------- ----------
ARCH CLOSING 8939 3
ARCH CLOSING 9074 2
ARCH CONNECTED 0 0
ARCH CLOSING 9326 1
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 8940 3
RFS IDLE 0 0
RFS IDLE 0 0
PROCESS STATUS SEQUENCE# THREAD#
--------- ------------ ---------- ----------
RFS IDLE 0 0
RFS IDLE 9075 2
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 9327 1
16 rows selected.
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
SQL> select process,status,sequence#,thread# from v$managed_standby;
PROCESS STATUS SEQUENCE# THREAD#
--------- ------------ ---------- ----------
ARCH CLOSING 8939 3
ARCH CLOSING 9074 2
ARCH CONNECTED 0 0
ARCH CLOSING 9326 1
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 8940 3
RFS IDLE 0 0
RFS IDLE 0 0
PROCESS STATUS SEQUENCE# THREAD#
--------- ------------ ---------- ----------
RFS IDLE 0 0
RFS IDLE 9075 2
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 9327 1
16 rows selected.
SQL> alter database recover managed standby database using current logfile disconnect;
Database altered.
SQL> /
Database altered.
STANDBY TRACE LOG 日誌分析程式已經正常起來了
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (crds3db)
Thu Jan 23 10:07:19 2014
MRP0 started with pid=36, OS id=1393
MRP0: Background Managed Standby Recovery process started (crds3db)
started logmerger process
Thu Jan 23 10:07:24 2014
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /orasjrz/crds3db/oraarch/2_8556_798146541.arc
Media Recovery Log /orasjrz/crds3db/oraarch/1_8776_798146541.arc
Media Recovery Log /orasjrz/crds3db/oraarch/3_8491_798146541.arc
alter database recover managed standby database using current logfile disconnect
Attempt to start background Managed Standby Recovery process (crds3db)
Thu Jan 23 10:24:59 2014
MRP0 started with pid=36, OS id=1525
MRP0: Background Managed Standby Recovery process started (crds3db)
started logmerger process
Thu Jan 23 10:25:04 2014
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 2 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log /orasjrz/crds3db/oraarch/2_8556_798146541.arc
Media Recovery Log /orasjrz/crds3db/oraarch/1_8776_798146541.arc
Media Recovery Log /orasjrz/crds3db/oraarch/3_8491_798146541.arc
Completed: alter database recover managed standby database using current logfile disconnect
Thu Jan 23 10:25:37 2014
Media Recovery Log /orasjrz/crds3db/oraarch/3_8492_798146541.arc
Media Recovery Log /orasjrz/crds3db/oraarch/2_8557_798146541.arc
Thu Jan 23 10:25:51 2014
Media Recovery Log /orasjrz/crds3db/oraarch/2_8558_798146541.arc
Media Recovery Log /orasjrz/crds3db/oraarch/1_8777_798146541.arc
Media Recovery Log /orasjrz/crds3db/oraarch/1_8778_798146541.arc
sql>select process,status,sequence#,thread# from v$managed_standby;
PROCESS STATUS SEQUENCE# THREAD#
--------- ------------ ---------- ----------
ARCH CLOSING 9075 2
ARCH CLOSING 9074 2
ARCH CONNECTED 0 0
ARCH CLOSING 8940 3
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
RFS IDLE 0 0
RFS WRITING 8941 3
RFS IDLE 0 0
RFS IDLE 0 0
PROCESS STATUS SEQUENCE# THREAD#
--------- ------------ ---------- ----------
RFS IDLE 0 0
RFS WRITING 9076 2
RFS IDLE 0 0
RFS IDLE 0 0
RFS WRITING 9327 1
MRP0 APPLYING_LOG 8778 1
17 rows selected.
-----------------------------------------------------end----------------------------------------------
轉載時候提示原作者或者以路徑連線方式 請您尊重筆著
技術群：132304250
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29065182/viewspace-1074414/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- REDO日誌損壞,非歸檔模式資料檔案恢復模式
- data guard 歸檔日誌管理 （standby）
- Oracle資料庫恢復：歸檔日誌損壞案例一則Oracle資料庫
- redo日誌損壞
- 重做日誌檔案損壞測試
- 建立測試物理Standby日誌
- 聯機日誌檔案損壞問題
- 當前聯機日誌檔案損壞
- standby庫歸檔日誌路徑小節
- 使用歸檔日誌分析解決歸檔日誌迅速增長問題(logmnr)
- dataguard之物理standby 日誌切換
- DATAGUARD_standby刪除歸檔日誌的指令碼指令碼
- standby無法使用歸檔日誌問題處理
- 歸檔日誌損壞驗證：Corrupt archivelog giving unclear errors [ID 1359971.1]HiveError
- 歸檔和非歸檔恢復實驗，ORA-00312 ORA-00313日誌損壞
- 損壞聯機日誌 恢復
- Oracle 控制檔案損壞解決方案Oracle
- 歸檔日誌
- 【Oracle】歸檔日誌管理-設定歸檔日誌路徑以及歸檔日誌冗餘Oracle
- 一次日誌檔案損壞的恢復
- inactive狀態日誌組檔案損壞的恢復
- 歸檔模式下的日誌檔案丟失的解決方法模式
- oracle歸檔日誌Oracle
- Oracle 歸檔日誌Oracle
- 歸檔日誌挖掘
- PostgreSQL 歸檔日誌SQL
- 通過RMAN設定standby接收日誌後主庫歸檔日誌才可刪除
- INACTIVE日誌組損壞的修復
- 聯機日誌損壞恢復實驗
- 損壞聯機日誌的恢復方法
- 硬碟物理故障解決方法之電路板損壞修復方案硬碟
- SQL Server 2005日誌檔案損壞的處理方法SQLServer
- 聯機日誌檔案損壞後的恢復方法[轉帖]
- Oracle重做日誌檔案損壞或丟失後的恢復Oracle
- 單個控制檔案損壞的解決方法
- ORA-00257歸檔日誌寫滿的解決方法
- 控制檔案/歸檔日誌
- 使用dbverify檢測物理損壞