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，通过日志，查看了 这个数据文件状态值： SYS@gtadb2=>select file#,STATUS,name from v$datafile where file#=41;      FILE# STATUS   NAME ---------- -------------- -------------------------------------------------- 41 RECOVER   /ORACLE_DBFS_02/gtadb2/gta_data_06.dbf --查看一下是否主备是否有gap 文件 SYS@gtadb2=>select * from v$archive_gap; 未选定行    3，通过dbv 查看是否存在逻辑坏块：正常, [oracle@gtadb2 ~]$ 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 ,以及日志应用：     SYS@gtadb2=>select * from v$archive_gap;     SYS@gtadb2=>select sequence#,first_time,next_time,applied from v$archived_log order by  sequence#;  --准正常  f: 纳闷中.  g: standby 库，为open_read only 状态值，看看到底怎么样，此时报错出来了，有了报错，就好办事. 报错如下;           SYS@gtadb2=>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      SYS@gtadb2=> alter database mount standby database;     数据库已更改。    已用时间:  00: 00: 06.43    SYS@gtadb2=>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库上恢复，还是不行，同时查看告 警日志，问题出来了，报错如下，说是有几个日志没有接受到。   SYS@gtadb2=>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 ,(当时的实际经验和资源)