ITPub博客

首页 > 数据库 > Oracle > ADG Standby_file_management参数导致备份故障

ADG Standby_file_management参数导致备份故障

原创 Oracle 作者:pingdanorcale 时间:2020-04-29 17:28:04 0 删除 编辑

近在加主库添加数据文件时导致备库无法被应用,警告日志报如下错误:

Media Recovery Waiting for thread 1 sequence 921276 (intransit)

Recovery of Online Redo Log: Thread 1 Group 72 Seq 921276Reading mem 0

  Mem# 0:+DATA/ractd/onlinelog/group_72.393.965631001

File #2172 added to control file as 'UNNAMED02172'because

the parameter STANDBY_FILE_MANAGEMENT is set toMANUAL

The file should be manually created to continue.

MRP0: Background Media Recovery terminated with error1274

Errors in file /u01/app/oracle/diag/rdbms/ractd/racdb1/trace/racdb1_pr00_8585508.trc:

ORA-01274: cannot add datafile '+ /data/tb01' -file could not be created

Mon Apr 18 17:21:10 2018

Managed Standby Recovery not using Real Time Apply

Mon Apr 18 17:21:17 2018

Recovery interrupted!

Mon Apr 18 17:21:39 2018

Recovered data files to a consistent state at change15893497106246

Mon Apr 18 17:21:39 2018

……………….

Mon Apr 18 17:21:40 2018

Mon Apr 18 17:21:40 2018

 LMS 3: 0 GCSshadows cancelled, 0 closed, 0 Xw survived

 LMS 1: 0 GCSshadows cancelled, 0 closed, 0 Xw survived

Mon Apr 18 17:21:40 2018

 LMS 2: 0 GCSshadows cancelled, 0 closed, 0 Xw survived

 Set master nodeinfo

 Submitted allremote-enqueue requests

 Dwn-cvts replayed,VALBLKs dubious

 All grantableenqueues granted

Mon Apr 18 17:22:00 2018

 Submitted all GCSremote-cache requests

 Fix write in gcsresources

Mon Apr 18 17:22:01 2018

RFS[233]: Selected log 71 for thread 1 sequence 921277dbid -357299396 branch 822617764

Mon Apr 18 17:22:01 2018

RFS[218]: Selected log 108 for thread 2 sequence 83914dbid -357299396 branch 822617764

Mon Apr 18 17:22:01 2018

Archived Log entry 124723 added for thread 2 sequence83913 ID 0xffffffffeab48e3c dest 1:

Reconfiguration complete

Mon Apr 18 17:22:02 2018

Block change tracking service stopping.

Mon Apr 18 17:22:02 2018

Stopping background process CTWR

Mon Apr 18 17:22:03 2018

MRP0: Background Media Recovery process shutdown (racdb1)

Mon Apr 18 17:22:06 2018

Archived Log entry 124724 added for thread 1 sequence921276 ID 0xffffffffeab48e3c dest 1:

Mon Apr 18 17:23:13 2018

RFS[233]: Selected log 72 for thread 1 sequence 921278dbid -357299396 branch 822617764

Mon Apr 18 17:23:19 2018

Archived Log entry 124725 added for thread 1 sequence921277 ID 0xffffffffeab48e3c dest 1:

Mon Apr 18 17:24:20 2018

RFS[233]: Selected log 71 for thread 1 sequence 921279dbid -357299396 branch

 

从警告日志 看,备库中一些归档日志无法被应用。原本以为是添加数据文件加到本地(asm),查看主库时添加的数据文件,一切正常,查看从备库的日志来看,File #2172 added to control file as 'UNNAMED02172' because

the parameter STANDBY_FILE_MANAGEMENT is set toMANUAL 原来是参数STANDBY_FILE_MANAGEMENT设置了手动,导致MRP0进程无法启动。

 

为什么这样 原理如下:

以上问题主要是因为:Standby_file_management参数为STANDBY_FILE_MANAGEMENT=MANUAL造成不会自动管理数据文件,主库增加了数据文件,备库不会自动增加,

因此若不处理 UNNAMED02172 这个数据文件的话,则备库在应用redo时就会出错,提示找到文件,就会出现不能应用日志的情况。要想能正常应用日志,先处理 UNNAMED02172 的文件,处理后备库先应用unname文件,然后才能按日志的顺序应用。

若数据库应用日志的先后顺序是这样:redo1->redo2->redo3……..,在添加数据文件时,当时redo用到了 

处理过程如下:

1. 调整standby_file_management参数为 manual

alter system set standby_file_management= manual scope=both sid=’*’;

 

2. 通过 control file 手工创建数据文件

SQL>  alter database create datafile
'
/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED02162 ' as '+data/datafile/';

 3. standby_file_management 设置为 auto

SQL>  alter system set standby_file_management=autoscope=both sid=’*’;

 

4.  启动恢复

SQL>  alter database recover managed standby databasedisconnect from session;

 

5. 检查一下是否同步

SQL> select to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') from v$datafile;

 

结论:

一般在添加数据文件时需要主要如下参数:

备库

standby_file_management

db_FILES

DB_FILE_NAME_convert

LOG_FILE_NAME_CONVERT

查看应用日志状态:

select value from v$dataguard_stats wherename='apply lag';


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10201716/viewspace-2689305/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
全部评论

注册时间:2009-01-02

  • 博文量
    34
  • 访问量
    85890