设为首页 加入收藏

TOP

oracle11g dataguard中standby库文件坏块的修复过程(一)
2015-11-21 01:29:04 来源: 作者: 【 】 浏览:0
Tags:oracle11g dataguard standby 文件 修复 过程

问题描述:

机房断电了,所以primary和standby库都是直接断电,然后我都设置了开机自启动oracle,所以第二天我来看的时候,primary和standby都启动了,归档日志也传输到standby了,但是日志应用后报错,有文件坏块,所以需要修复。

1,查看alert日志报警信息

Recovered data files to a consistent state at change 11550152086
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_22925.trc:
ORA-00448: normal completion of background process
Wed Oct 14 19:34:41 2015
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_mrp0_22923.trc:
ORA-00600: internal error code, arguments: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
MRP0: Background Media Recovery process shutdown (powerdes)
Wed Oct 14 21:32:47 2015
Standby controlfile consistent with primary
Wed Oct 14 21:32:48 2015
Archived Log entry 4608 added for thread 1 sequence 38105 ID 0xca2ab4eb dest 3:
RFS[3]: Selected log 4 for thread 1 sequence 38106 dbid -903205653 branch 821708334

2,查看powerdes_pr00_22925.trc文件

[oracle@localhost ~]$ more /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_22925.trc Trace file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_22925.trc Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production With the Partitioning, Oracle Label Security, OLAP, Data Mining, Oracle Database Vault and Real Application Testing options ORACLE_HOME = /oracle/app/oracle/product/11.2.0/dbhome_1 System name: Linux Node name: localhost.localdomain Release: 2.6.39-400.17.1.el6uek.x86_64 Version: #1 SMP Fri Feb 22 18:16:18 PST 2013 Machine: x86_64 Instance name: powerdes Redo thread mounted by this instance: 1 Oracle process number: 45 Unix process pid: 22925, image: oracle@localhost.localdomain (PR00) *** 2015-10-14 19:34:30.199 *** SESSION ID:(1251.3) 2015-10-14 19:34:30.199 *** CLIENT ID:() 2015-10-14 19:34:30.199 *** SERVICE NAME:(SYS$USERS) 2015-10-14 19:34:30.199 *** MODULE NAME:() 2015-10-14 19:34:30.199 *** ACTION NAME:() 2015-10-14 19:34:30.199 Started Parallel Media Recovery *** 2015-10-14 19:34:30.206 4132 krsh.c Managed Standby Recovery not using Real Time Apply Dumping database incarnation table: Resetlogs 0 scn and time: 0x0000.000e6c20 07/25/2013 12:18:54 Recovery target incarnation = 2, activation ID = -903170837 Influx buffer limit = 100000 min(50% x 213003, 100000) *** 2015-10-14 19:34:30.676 Start recovery at thread 1 ckpt scn 11550151590 logseq 0 block 0 *** 2015-10-14 19:34:30.827 Media Recovery add redo thread 1 *** 2015-10-14 19:34:30.950 Media Recovery Log /data/oracle/oradgdata/standby_archive/1_38052_821708334.dbf Log read is SYNCHRONOUS though disk_asynch_io is enabled! *** 2015-10-14 19:34:32.628 *** 2015-10-14 19:34:32.628 4132 krsh.c MRP0: Background Media Recovery terminated with error 448 ORA-00448: normal completion of background process ----- Redo read statistics for thread 1 ----- Read rate (SYNC): 32690Kb in 1.90s => 16.80 Mb/sec Total redo bytes: 32690Kb Longest record: 14Kb, moves: 25/43465 moved: 0Mb (0%) Longest LWN: 904Kb, reads: 5685 Last redo scn: 0x0002.b0715c4c (11550153804) Change vector header moves = 5271/83624 (6%) ---------------------------------------------- *** 2015-10-14 19:34:32.728 Media Recovery drop redo thread 1 Waiting for ksv slaves to exit Waiting for ksv slaves to exit Waiting for ksv slaves to exit Waiting for ksv slaves to exit Waiting for ksv slaves to exit Waiting for ksv slaves to exi
首页 上一页 1 2 3 4 5 6 7 下一页 尾页 1/7/7
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
分享到: 
上一篇MongoDB查询语句简要分析 下一篇[实验-视频过程]oracle热备份-整..

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容: