解决物理standby 归档日志损坏ORA-00334

本文主要是介绍解决物理standby 归档日志损坏ORA-00334，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

解决物理standby 归档日志损坏ORA-00334
 分类： Oracle2014-06-28 10:49:07
物理备库归档日志损坏导致mrp进程没有起来，datagurad不同步

standby trace log日志

Errors in file /app//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.

这篇关于解决物理standby 归档日志损坏ORA-00334的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！