Oracle Active Data Guard调整案例

简介:

客户的Oracle 11gR2 Active Data Guard环境,主数据库的standby_file_management=AUTO,备用数据库的standby_file_management=MANUAL,导致在主数据库为表空间添加的数据文件操作没有同步到备用数据库,在$ORACLE_HOME/dbs目录下也没有创建类似UNNAMED00003的文件,备用数据库有如下的告警日志:
  Tue Sep 02 17:37:36 2014
  File #3 added to control file as 'UNNAMED00003' because
  the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
  The file should be manually created to continue.
  MRP0: Background Media Recovery terminated with error 1274
  Errors in file /u01/app/oracle/diag/rdbms/d012dg/d012band/trace/d012band_pr00_5702078.trc:
  ORA-01274: cannot add datafile '/oradata1/d012band/tsmisc06.dbf' - file could not be created
  Managed Standby Recovery not using Real Time Apply
  Recovery interrupted!
  Recovered data files to a consistent state at change 866102511
  Tue Sep 02 17:37:46 2014
  MRP0: Background Media Recovery process shutdown (d012band)
  Tue Sep 02 17:52:14 2014
  RFS[1]: Selected log 8 for thread 1 sequence 19136 dbid 2134147111 branch 809469738
  Tue Sep 02 17:52:25 2014
  Archived Log entry 511 added for thread 1 sequence 19135 ID 0x7f340827 dest 1:
  Tue Sep 02 17:53:23 2014
  alter database recover managed standby database using current logfile disconnect from session
  Attempt to start background Managed Standby Recovery process (d012band)
  Tue Sep 02 17:53:23 2014
  MRP0 started with pid=42, OS id=7471452
  MRP0: Background Managed Standby Recovery process started (d012band)
  started logmerger process
  Tue Sep 02 17:53:29 2014
  Managed Standby Recovery starting Real Time Apply
  Tue Sep 02 17:53:30 2014
  Errors in file /u01/app/oracle/diag/rdbms/d012dg/d012band/trace/d012band_dbw0_4784178.trc:
  ORA-01186: file 3 failed verification tests
  ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
  ORA-01111: name for data file 3 is unknown - rename to correct file
  ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
  如果能够找到/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003文件,可以参考文章:《11gR2 Active Data Guard调整案例[1]》http://blog.itpub.net/23135684/viewspace-759592/
  File 3 not verified due to error ORA-01157
  MRP0: Background Media Recovery terminated with error 1111
  Errors in file /u01/app/oracle/diag/rdbms/d012dg/d012band/trace/d012band_pr00_8716760.trc:
  ORA-01111: name for data file 3 is unknown - rename to correct file
  ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
  ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
  ORA-01111: name for data file 3 is unknown - rename to correct file
  ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
  Managed Standby Recovery not using Real Time Apply
  Slave exiting with ORA-1111 exception
  Errors in file /u01/app/oracle/diag/rdbms/d012dg/d012band/trace/d012band_pr00_8716760.trc:
  ORA-01111: name for data file 3 is unknown - rename to correct file
  ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
  ORA-01157: cannot identify/lock data file 3 - see DBWR trace file
  ORA-01111: name for data file 3 is unknown - rename to correct file
  ORA-01110: data file 3: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00003'
  Recovery Slave PR00 previously exited with exception 1111
  MRP0: Background Media Recovery process shutdown (d012band)
  Completed: alter database recover managed standby database using current logfile disconnect from session
 解决这个问题的关键是手动创建新添加的数据文件,参考如下的内容解决该问题:
  How to resolve MRP stuck issues on a physical standby database? (文档 ID 1221163.1)
  ......
  Solution 10 Add the new datafiles to the standby database manually.
  1) Please take a hot backup of new datafiles from the primary database.
  2) Create a new standby controlfile from the primary database by
  SQL>alter database create standby controlfile as '/tmp/controlf.ctl';
  If datafiles are on ASM, please follow the note below and you could ignore the rest of steps:
  Note 734862.1 Step By Step Guide On How To Recreate Standby Control File
  When Datafiles Are On ASM And Using Oracle Managed Files
  Or you could modify the wrong datafile name in the standby controlfile by alter database rename command. For example,
  SQL> ALTER DATABASE RENAME FILE '' to '';
  3) If the new datafile location on the primary is different from the standby, please make sure
  db_file_name_convert init parameter is set on the standby database.
  Note 47325.1 Init.ora Parameter "DB_FILE_NAME_CONVERT" Reference Note
  If db_file_name_convert init parameter has already been set, then you could ignore this step.
  4) Cancel the managed recovery
  SQL>alter database recover managed standby database cancel;
  5) set standby_file_management=manual on the standby database and shutdown the standby database.
  SQL>alter system set standby_file_management=manual sid='*';
  SQL>shutdown immediate;
  6) Copy the hot backup of the new datafiles and the new standby controlfile to the standby.
  Please make sure the controlfiles are located in the right location with right names
  according to the init parameter control_files. Please make sure the copied datafiles are
  located in the right location as well according to name from v$datafile.
  7) startup the standby database in mount mode and set standby_file_management=auto.
  SQL>startup mount;
  SQL>alter system set standby_file_management=auto sid='*';
  8) Start the managed recovery.
  SQL>alter database recover managed standby database disconnect;
  ......
  --end--

最新内容请见作者的GitHub页:http://qaseven.github.io/

相关文章
|
21天前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—Oracle数据库文件有坏快损坏的数据恢复案例
一台Oracle数据库打开报错,报错信息: “system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。管理员联系我们数据恢复中心寻求帮助,并提供了Oracle_Home目录的所有文件。用户方要求恢复zxfg用户下的数据。 由于数据库没有备份,无法通过备份去恢复数据库。
|
27天前
|
存储 Oracle 关系型数据库
oracle数据恢复—Oracle数据库文件大小变为0kb的数据恢复案例
存储掉盘超过上限,lun无法识别。管理员重组存储的位图信息并导出lun,发现linux操作系统上部署的oracle数据库中有上百个数据文件的大小变为0kb。数据库的大小缩水了80%以上。 取出&并分析oracle数据库的控制文件。重组存储位图信息,重新导出控制文件中记录的数据文件,发现这些文件的大小依然为0kb。
|
14天前
|
存储 Oracle 关系型数据库
服务器数据恢复—华为S5300存储Oracle数据库恢复案例
服务器存储数据恢复环境: 华为S5300存储中有12块FC硬盘,其中11块硬盘作为数据盘组建了一组RAID5阵列,剩下的1块硬盘作为热备盘使用。基于RAID的LUN分配给linux操作系统使用,存放的数据主要是Oracle数据库。 服务器存储故障: RAID5阵列中1块硬盘出现故障离线,热备盘自动激活开始同步数据,在同步数据的过程中又一块硬盘离线,RAID5阵列瘫痪,上层LUN无法使用。
|
2月前
|
存储 Oracle 关系型数据库
数据库数据恢复—Oracle ASM磁盘组故障数据恢复案例
Oracle数据库数据恢复环境&故障: Oracle ASM磁盘组由4块磁盘组成。Oracle ASM磁盘组掉线 ,ASM实例不能mount。 Oracle数据库故障分析&恢复方案: 数据库数据恢复工程师对组成ASM磁盘组的磁盘进行分析。对ASM元数据进行分析发现ASM存储元数据损坏,导致磁盘组无法挂载。
|
3月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
3月前
|
Oracle 关系型数据库 数据库
Oracle数据恢复—异常断电导致Oracle数据库数据丢失的数据恢复案例
Oracle数据库故障: 机房异常断电后,Oracle数据库启库报错:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。数据库没有备份,归档日志不连续。用户方提供了Oracle数据库的在线文件,需要恢复zxfg用户的数据。 Oracle数据库恢复方案: 检测数据库故障;尝试挂起并修复数据库;解析数据文件。
|
2月前
|
Oracle 关系型数据库 数据库
oracle数据恢复—Oracle数据库文件损坏导致数据库打不开的数据恢复案例
打开oracle数据库时报错,报错信息:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。急需恢复zxfg用户下的数据。 出现上述报错的原因有:控制文件损坏、数据文件损坏、数据文件与控制文件的SCN不一致等。数据恢复工程师对数据库文件做进一步检测分析后发现sysaux01.dbf文件有坏块。修复sysaux01.dbf文件,启动数据库依然有许多查询报错。export和data pump工具无法使用,查询告警日志并分析报错,确认发生上述错误的原因就是sysaux01.dbf文件损坏。由于该文件损坏,从数据库层面无法修复数据库。由于system和用户表空间的数据文件是正常的,
|
5月前
|
SQL Oracle 关系型数据库
关系型数据库Oracle Data Guard
【7月更文挑战第11天】
46 1
|
5月前
|
Oracle 关系型数据库 数据库
|
Oracle 关系型数据库 数据库