DG不同步问题

IT那活儿发布于2023-01-11 13:20 / 3303人阅读

DG不同步问题

点击上方“IT那活儿”，关注后了解更多内容，不管什么活儿，干就完了！！！

Dg主要进程介绍

RFS: 在备库上启用的进程，远程文件服务器，接受重做日志（redo log 和 arch log）；

LNSn：本地网络服务，复制传送 redo 日志；

MRP: 管理恢复进程，如果是物理 DG ，用于对 redo log 做 recovery；

LSP: 逻辑备用进程，在逻辑 DG,将从 redo log 中抽取的 sql 进行应用。

主备磁盘大小不一致

主库加表空间，导致备库无法添加

1. 由于主备磁盘大小不一致的时候，当主库磁盘还有空间，备库磁盘没有空间时，主库加表空间，而参数db_file_name_convert转换到备库，备库无法增加数据文件就会报错，错误将如下图所示：

这种情况是可避免的，所以建议给主库添加表空间时，关注下备库的磁盘使用情况，或者保证主备磁盘大小一致。

2. Mos给出的两种情况解决办法为：

1）when Data Guard setup is managed via sqlplus

Ensure Disk / file system space issue is addressed and then follow this on the standby
sql>alter system set standby_file_management=manual scope=both sid=*;
sql>alter database create datafile
/oracle/app/oracle/product/10.2.0.1/db_1/dbs/UNNAMED00038 as new;
Note:- It assumes that database files are using Oracle Managed File (OMF),
else keyword "new" has to be replaced by actual file name
sql>alter system set standby_file_management=auto scope=both sid=*;
sql>alter database recover managed standby database disconnect from session;

2）when Data Guard setup is managed via Data Guard Broker or OEM（当开启OEM时）

Ensure Disk / file system space issue is addressed and then follow this on the standby
dgmgrl /
edit database standby db unique name here set property StandbyFileManagement=MANUAL;
exit
sql>alter database create datafile
/oracle/app/oracle/product/10.2.0.1/db_1/dbs/UNNAMED00038 as new;
Note:- It assumes that database files are using Oracle Managed File (OMF),
else keyword "new"has to be replaced by actual file name
dgmgrl /
edit database standby db unique name here set property StandbyFileManagement=AUTO;
edit database standby db unique name here set state=ONLINE;
exit

3. 示例（ASM单实例）

1）处理方法：对备库的ASM磁盘进行扩容，与主库追平。

2）解决方法实例2：Mos的解决。

sql>alter system set standby_file_management=manual scope=both sid=*;
sql>alter database create datafile
/oracle/app/oracle/product/10.2.0.1/db_1/dbs/UNNAMED00038 as new;
Note:- It assumes that database files are using Oracle Managed File (OMF),
else keyword "new" has to be replaced by actual file name
sql>alter system set standby_file_management=auto scope=both sid=*;
sql>alter database recover managed standby database disconnect from session;

检查是否需要恢复文件：

SQL> select * from v$recover_file where error like %FILE%;

FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- ----------------------------------------------------------------- ---------- -------------------
5 ONLINE ONLINE FILE MISSING 0
6 ONLINE ONLINE FILE MISSING 0

确认主库数据文件：

SQL> select file#,name from v$datafile where file# in (5,6);

FILE# NAME
---------- ------------------------------------------------------------------
5 /oradata/lmis/LMIS01.dbf
6 /oradata/lmis/LMIS02.dbf

识别在（备库）中创建的虚拟文件名：

SQL> select file#,name from v$datafile where file# in (5,6);

FILE# NAME
---------- ------------------------------------------------------------------
5 /app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005
6 /app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006

检查没有运行MRP，并且在待机状态下创建文件后可以启用：

STANDBY_FILE_MANAGEMENT

SQL> alter system set standby_file_management=manual scope=both;

System altered.

SQL> alter database create datafile/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005 as /oradata/lmisdbdg/LMIS01.dbf;

Database altered.

SQL> alter database create datafile/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006 as /oradata/lmisdbdg/LMIS02.dbf;

Database altered.

检查虚拟文件是否被修复：

SQL> select * from v$recover_file where error like %FILE%;

no rows selected

启用STANDBY_FILE_MANAGEMENT为AUTO并启动MRP：

SQL> show parameter standby_file_management

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL
SQL> alter system set standby_file_management=AUTO scope=both;
System altered.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Database altered.

创建文件后，MRP将开始在备用数据库上应用存档。

检查主备库归档应用情况：

set linesize 200
set pagesize 999
col status for a10
SELECT DEST_ID,
SEQUENCE#,
APPLIED
FROM v$archived_log
WHERE first_time>sysdate-35
ORDER BY SEQUENCE#,DEST_ID;

主库实例归档日志信息：

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM 
V$ARCHIVED_LOG ORDER BY SEQUENCE#;

备库实例归档日志信息：

SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM 
V$ARCHIVED_LOG ORDER BY SEQUENCE#;

oracle关闭mrp进程卡死

案例：DG备库报错ORA-600[2619]致使mrp进程异常终止

告警日志发现有报错ORA-600[2619]，并因此导致mrp进程异常终止，这是什么原因导致的呢，一般ORA-600都为oracle数据库一些内部错误。

接下来分析下过程：

1. 由于之前有做过清理归档的动作，因为之前告警目录空间满；

2. 尝试手工拉起mrp进程，发现不成功，尝试应用日志时同样是报错ORA-600[2619]；

3. 通过MOS查询匹配到：

ORA-600[2619] During Physical Standby Recovery [1138913.1]
ORA-600[2619] is raised due to an invalid next_change# detected in archive log.

In this case, it is caused by the archive log disk space ran out on standby site, causing that archive log not fully written on disk. This lead to ORA-600[2619] when the archive log was applied.

--Mos给出的处理方法：

1）. Clear the disk space where archive log stored on standby site
2）. Copy the problem archive log (eg: 4_77799_650412287.dbf) from the primary site and replace the one on the standby,
then restart Managed Recovery.
Archive log should be applied properly now.

4. 结合之前空间满的事实，怀疑是否该归档文件也存在尚未完全写入到磁盘的情况；

5. 主备库比对这个归档日志的大小，发现大小是一致的；

6. 通过md5sum比对主备库该归档日志，发现md5不一样，这说明该归档文件还是存在差异；

7. 将备库的这个归档文件mv重命名备份，然后将主库的这个归档文件重新拷贝到备库，重新比对数据文件确认一致；

8. 再次尝试拉起mrp进程，发现不再报错，解决问题。

总结：在这种情况下，是由于备用站点的归档日志磁盘空间用完了，导致归档日志没有完全写入磁盘。当应用归档日志时，这会导致 ORA-600[2619]。

DataGuard 归档无法同步

oracle 启动mrp进程,DataGuard MRP进程crash：ORA-01111

DataGuard 归档无法同步的情况：

查看主库LNS进程存在表示，主库正常向备库传送归档日志。

但备库的MRP进程不在，判断是否存在归档的GAP：

SQL> SELECT THREAD#,LOW_SEQUENCE#,HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

no rows selected

不存在GAP，手动启动MRP进程，仍无法启动查看告警日志，找到关键内容如下：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSIONAttempt to start background Managed Standby Recovery process (sss)

Thu Oct 09 11:38:58 2021

MRP0 started with pid=30, OS id=102010

MRP0: Background Managed Standby Recovery process started (sss)

started logmerger process

Thu Oct 09 11:39:03 2021

Managed Standby Recovery not using Real Time Apply

MRP0: Background Media Recovery terminated with error 1111

Errors in file /dba/oracle/diag/rdbms/sss/sss/trace/sss_pr00_102070.trc:

ORA-01111: name for data file 12 is unknown - rename to correct file

ORA-01110: data file 12: /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012

ORA-01157: cannot identify/lock data file 12 - see DBWR trace file

ORA-01111: name for data file 12 is unknown - rename to correct file

ORA-01110: data file 12: /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012

Slave exiting with ORA-1111 exception

Errors in file /dba/oracle/diag/rdbms/sss/sss/trace/sss_pr00_102070.trc:

ORA-01111: name for data file 12 is unknown - rename to correct file

ORA-01110: data file 12: /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012

ORA-01157: cannot identify/lock data file 12 - see DBWR trace file

ORA-01111: name for data file 12 is unknown - rename to correct file

ORA-01110: data file 12: /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012

Recovery Slave PR00 previously exited with exception 1111

MRP0: Background Media Recovery process shutdown (sss)

可以看到数据库尝试启动MRP进程，但后台进行介质恢复时，被错误1111码终端(即ORA-01111)，ORA-01111提示数据文件12是未知的。

而后续的ORA-01110报错显示该数据文件的位置应该是$ORACLE_HOME/UNNAMED00012文件。

实际在该路径下是查找不到该文件的：

find /u01/oracle/product/11.2.0.3.0/dbs/ -name UNNAMED00012

那么问题就来了，为什么数据库需要找到该文件进行恢复？

DG的备库是通过归档日志进行恢复的。

在归档获取正确的情况下，会把主库的对数据的更新内容都传递到备库进行应用。也就是说上面报错在于，主库传过来一条更新记录，对于备库是无法判断的。

通过网上查找相关答案，发现原来当主库异常宕机重启之后，数据库会进行自动恢复，也就是Instance Recovery，这部分缺失的数据被记录再Redo之中，在异常关闭后，传输到备库的归档中并不包含这部分内容，而主库通过一个临时的数据文件(UNNAMED命名方式)恢复后，这部分被恢复的记录在后续的归档中被传输到备库，当备库恢复到这个归档时，备库无法自动去创建这个UNNAMED临时数据文件。

解决方法：

停止备库归档应用(实际已停止，非必要)，同步归档将备库归档自动管理该为手动，手工创建该数据文件，启动归档应用进程，将归档管理由手动转自动。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL SCOPE=MEMEORY;

SQL> ALTER DATABASE CREATE DATAFILE /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012 as /u01/oradata/sss/sys07.dbf

SQL> ALTER SYSTEM SET standby_file_management=AUTO SCOPE=MEMORY;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION

到这里查看告警日志：

Attempt to start background Managed Standby Recovery process (sss)

Thu Oct 09 11:41:08 2021

MRP0 started with pid=30, OS id=102513

MRP0: Background Managed Standby Recovery process started (sss)

started logmerger process

Thu Oct 09 11:41:14 2021

Managed Standby Recovery not using Real Time Apply

Parallel Media Recovery started with 24 slaves

Waiting for all non-current ORLs to be archived...

All non-current ORLs have been archived.

Thu Oct 09 11:41:14 2021

Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION

Media Recovery Log /u01/sss/SSS/archivelog/2021_10_03/o1_mf_1_13523_b2wzmf1b_.arc

Thu Oct 09 11:41:36 2021

告警日志已经说明归档已经正常应用了，也可以查看一下V$MANAGED_STANDBY视图,确认一下MRP进程是否启用。

主备不同步

主备不同步，备库归档丢失

由于某种原因，可能导致备库的归档丢失，这需要我们手动来进行处理。

示例问题描述：

备库的归档日志没有增加，一直等待一个。

1. 查询问题：

SQL> SELECT * FROM V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1        6434       6435
SQL>select name ,sequence# from v$archived_log;
NAME SEQUENCE#
-------------------------------------------------------------------------- ------
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6414_1000748999.dbf 6414
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6417_1000748999.dbf 6417
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6420_1000748999.dbf 6420
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6421_1000748999.dbf 6421
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6419_1000748999.dbf 6419
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6418_1000748999.dbf 6418
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6425_1000748999.dbf 6425
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6426_1000748999.dbf 6426
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6423_1000748999.dbf 6423
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6422_1000748999.dbf 6422
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6424_1000748999.dbf 6424

NAME SEQUENCE#
-------------------------------------------------------------------------- ------
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6366_1000748999.dbf 6366
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6427_1000748999.dbf 6427
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6428_1000748999.dbf 6428
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6429_1000748999.dbf 6429
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6509_1000748999.dbf 6509
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6431_1000748999.dbf 6431
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6432_1000748999.dbf 6432
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6430_1000748999.dbf 6430
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6433_1000748999.dbf 6433
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6436_1000748999.dbf 6436

2. 解决问题：

需要查看主库存不存在归档日志，分两种情况讨论：

1）如果存在的话拷贝到备库然后手工注册；

Scp到备库后，备库注册alter database register logfile XXX；

2）如果不存在的话生成基于SCN的备份集。

查看备库最小的scn号：

select to_char(current_scn) from v$database;
select min(checkpoint_change#) from v$datafile;
select min(checkpoint_change#) from v$datafile_header;

比对最小的scn，然后再备库生成基于SCn的备份集：

backup as compressed backupset incremental from scn $MIN  
database format /backup/inc_%d_%T_%s_%p;
backup current controlfile for standby format /backup/inc.ctl;

然后scp 传输到备库上，备库恢复备份集：

shutdown abort;
startup nomount;
restore standby controlfile from "/backup/inc.ctl";
alter database mount;
catalog start with "/backup/" NOPROMPT;
shutdown immediate;
startup mount;
recover database;

重新开启实时应用归档：

alter database recover managed standby database disconnect from session using current logfile;

文章总结

当dg出现主备不同步时，首先查看日志看由于什么问题导致的，之后看是由于主备断了同步，mrp进程断掉还是由于磁盘空间不够导致的，主要的恢复方法为当主库是否存在归档：

若主库存在归档可直接拷过去注册应用即可；

若主库不存在归档，则需要基于scn号的增量恢复。

本文作者：李晓红

本文来源：IT那活儿（上海新炬王翦团队）

云服务器 GPU云服务器 dts同步常见问题不同步邮件不同步 webrtc视频不同步

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/129653.html

DG备库读写测试方案

DG备库读写测试方案 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin:0...

IT那活儿 2023-01-11 13:19 评论0 收藏856
DBASK问答集萃（2）

摘要：新晋技术专家下面是墨天轮部分新晋的技术专家。大家可以点击往期阅读墨天轮技术专家邀请函了解详情，申请成为我们的技术专家，加入专家团队，与我们一起创建一个开放互助的数据库技术社区。新关联公众号墨天轮是一个开放互助的数据库技术社区。引言近期我们在DBASK小程序增加了数据库 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的专题栏目和一些新的技术...

liuchengxu 2019-07-25 12:40 评论0 收藏0

发表评论

登陆后可评论

0条评论

IT那活儿

男|高级讲师

我要关注我要私信

TA的文章

消息中间件故障分析一例

阅读 1247·2023-01-11 13:20
RAC双节点crash回复一例

阅读 1555·2023-01-11 13:20
ORA-600处理一例

阅读 1008·2023-01-11 13:20
双节点RAC实例2 HANG 故障分析一例

阅读 1675·2023-01-11 13:20
RAC集群节点1重启分析一例

阅读 3968·2023-01-11 13:20
CRS启动报错CRS-1656处理分享

阅读 2510·2023-01-11 13:20
oracle 12CR2打补丁报错处理一例

阅读 1305·2023-01-11 13:20
分布式缓存组件故障分析及监控优化

阅读 3474·2023-01-11 13:20

资讯专栏INFORMATION COLUMN

上云采购季！| 2核2G4M爆款云服务器低至59元/年，更有多台、长期优惠，快来选购！

DG不同步问题

点击上方“IT那活儿”，关注后了解更多内容，不管什么活儿，干就完了！！！

本文作者：李晓红

本文来源：IT那活儿（上海新炬王翦团队）

相关文章

DG备库读写测试方案

DBASK问答集萃（2）

发表评论

0条评论

IT那活儿

男|高级讲师

TA的文章

消息中间件故障分析一例

RAC双节点crash回复一例

ORA-600处理一例

双节点RAC实例2 HANG 故障分析一例

RAC集群节点1重启分析一例

CRS启动报错CRS-1656处理分享

oracle 12CR2打补丁报错处理一例

分布式缓存组件故障分析及监控优化

最新活动