DG 一次大意操作总结:

发布时间:2016-12-11 4:45:45 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"DG 一次大意操作总结:",主要涉及到DG 一次大意操作总结:方面的内容,对于DG 一次大意操作总结:感兴趣的同学可以参考一下。

DG 一次大意操作总结: 环境: ORACLE 11.2 DG 主备    操作: 备库上查询一些数据文件,报错信息:  :同时查看主备的alter ,trace 日志,一切正常。 1, alter database recover managed standby  database cancel;  standby trace文件: 报错一:  Parallel Media Recovery started with 24 slaves Warning: Datafile 41 (/ORACLE_DBFS_02/gtadb2/gta_data_06.dbf) is offline during full database recovery and will not be  recovered Waiting for all non-current ORLs to be archived... 报错二: Completed: alter database recover managed standby database cancel Wed May 29 16:18:19 2013 Errors in file /u01/app/oracle/diag/rdbms/gtadcsys2/gtadb2/trace/gtadb2_ora_24041.trc: ORA-00604: ?.? SQL 绾у. 2 ?虹.?.. ORA-16000: ?.??版.搴.互杩.??..璁块. Wed May 29 16:20:00 2013 Errors in file /u01/app/oracle/diag/rdbms/gtadcsys2/gtadb2/trace/gtadb2_ora_24041.trc: ORA-00604: ?.? SQL 绾у. 2 ?虹.?.. ORA-16000: ?.??版.搴.互杩.??..璁块. Wed May 29 16:29:49 2013 2,通过日志,查看了 这个数据文件状态值: [email protected]=>select file#,STATUS,name from v$datafile where file#=41;      FILE# STATUS  NAME ---------- -------------- -------------------------------------------------- 41 RECOVER  /ORACLE_DBFS_02/gtadb2/gta_data_06.dbf --查看一下是否主备是否有gap 文件 [email protected]=>select * from v$archive_gap; 未选定行    3,通过dbv 查看是否存在逻辑坏块:正常, [[email protected] ~]$ dbv file=/ORACLE_DBFS_02/gtadb2/gta_data_06.dbf blocksize=8192 feedback=50 DBVERIFY: Release 11.2.0.3.0 - Production on 星期三 5月 29 17:43:35 2013 Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved. DBVERIFY - 开始验证: FILE = /ORACLE_DBFS_02/gtadb2/gta_data_06.dbf ................................................................................ . DBVERIFY - 验证完成 检查的页总数: 4096 处理的页总数 (数据): 0 失败的页总数 (数据): 0 处理的页总数 (索引): 0 失败的页总数 (索引): 0 处理的页总数 (其他): 1 处理的总页数 (段)  : 0 失败的总页数 (段)  : 0 空的页总数: 4095 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数        : 0 最高块 SCN            : 0 (0.0) 4 通过recover 恢复也不行【根据报错:ORA-00604,ORA-16000】。 通过http://www.bitscn.com/pdb/oracle/200604/17688.html 这篇文章 : 猜测有可能是BUG(公司抠门,没有MOS账号) ,只能百百度,问问高人指点。一顿狂聊,交流后,有了些思路(这里主要3Q吴sir,他就是传说 中的那种,高手在民间.) 5 晚上申请停机2个小时,晚上00点开始,业务基本都歇业了,数据备份(data dmp)10点开始,花了将近2个半小时。   重启主题操作:主备查找问题  a, 备份(rman) primary : controlfile ,pfile . standby: controfile,pfile   b, 通过 alter database recover managed standby database cancel; 禁用standby 接收primary过来的log 应用。  c, 关库: 先主后备,(其实没有什么大的操作话,在b 执行以后,就可以先关闭standby库.)  d, 开库: 先备后主, 查看standby 告警日志。以及 数据文件转状态,有否改变。  e, 通过 alter database recover managed standby database disconnect from session;接收日志,查看主备 gap ,以及日志应用:     [email protected]=>select * from v$archive_gap;     [email protected]=>select sequence#,first_time,next_time,applied from v$archived_log order by  sequence#;  --准正常  f: 纳闷中.  g: standby 库,为open_read only 状态值,看看到底怎么样,此时报错出来了,有了报错,就好办事. 报错如下;           [email protected]=>startup nomount;        ORACLE 例程已经启动。      Total System Global Area 2.2982E+10 bytes      Fixed Size         2238736 bytes      Variable Size 1.6844E+10 bytes      Database Buffers         6106906624 bytes      Redo Buffers   28905472 bytes      [email protected]=> alter database mount standby database;     数据库已更改。    已用时间:  00: 00: 06.43    [email protected]=>alter database open read only;    alter database open read only    *    第 1 行出现错误:    ORA-10458: standby database requires recovery    ORA-01152: ?? 41 ???????????    ORA-01110: ???? 41: '/ORACLE_DBFS_02/gtadb2/gta_data_06.dbf'  h:重新出现这个错,说明,这才是重点,前面的报错只是辅助。通过报错,意思需要回复。 但是在standby库上恢复,还是不行,同时查看告 警日志,问题出来了,报错如下,说是有几个日志没有接受到。   [email protected]=>select * from v$archive_gap;     未选定行     ----主备还是一样?     i:思考了一下,问什么出现这样的问题了,先不思索,直接找告警日志对应的 gap sequence 24442-24541 ,发现库已经没有了,上周归档 已近清理了一次,有没有rman 全备。  j; 看来,要重新配置了!   报错信息:  Completed:  alter database mount standby database ARC3: Archival started ARC0: STARTING ARCH PROCESSES COMPLETE Thu May 30 00:49:39 2013 Using STANDBY_ARCHIVE_DEST parameter default value as /ORACLE_ARCH/archive_log Thu May 30 00:49:44 2013 Primary database is in MAXIMUM PERFORMANCE mode RFS[1]: Assigned to RFS process 9101 RFS[1]: No standby redo logfiles available for thread 1  RFS[1]: Opened log for thread 1 sequence 43824 dbid -552250768 branch 803954866 Thu May 30 00:49:54 2013 RFS[2]: Assigned to RFS process 9105 RFS[2]: No standby redo logfiles available for thread 1  RFS[2]: Opened log for thread 1 sequence 43823 dbid -552250768 branch 803954866 Archived Log entry 43742 added for thread 1 sequence 43823 rlc 803954866 ID 0xdf1abe50 dest 2: Thu May 30 00:50:19 2013 alter database open read only AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access Signalling error 1152 for datafile 41! Beginning standby crash recovery. Serial Media Recovery started Managed Standby Recovery starting Real Time Apply Media Recovery Waiting for thread 1 sequence 24442 Fetching gap sequence in thread 1, gap sequence 24442-24541 Thu May 30 00:51:20 2013 Standby crash recovery need archive log for thread 1 sequence 24442 to continue. Please verify that primary database is transporting redo logs to the standby database. Wait timeout: thread 1 sequence 24442  Standby crash recovery aborted due to error 16016. Errors in file /u01/app/oracle/diag/rdbms/gtadcsys2/gtadb2/trace/gtadb2_ora_8980.trc: ORA-16016: ?? 1 sequence# 24442 ???????? Recovery interrupted! Completed standby crash recovery. Signalling error 1152 for datafile 41! Errors in file /u01/app/oracle/diag/rdbms/gtadcsys2/gtadb2/trace/gtadb2_ora_8980.trc: ORA-10458: standby database requires recovery ORA-01152: ?? 41 ??????????? ORA-01110: ???? 41: '/ORACLE_DBFS_02/gtadb2/gta_data_06.dbf' ORA-10458 signalled during: alter database open read only...  k: 思考,这段时间自己做了神马操作,突然想到了是否上次的问题,哎,太大意了! l: 警示: 以后任何操作以后,都得需要认证检测一下,不能粗心大意了! m; 问题,确定来源, 最后只能补救,唯一能做的就是 重置主备DG ,(当时的实际经验和资源)                                                                                                                                              

上一篇:android 中 系统日期时间的获取
下一篇:struct的三种初始化方法

相关文章

相关评论