暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / DG不同步问题

DG不同步问题

IT那活儿 2022-02-25
993

点击上方“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 standbysql>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 namesql>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 standbydgmgrl /edit database 'standby db unique name here' set property StandbyFileManagement='MANUAL';exitsql>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 namedgmgrl /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 namesql>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 06 ONLINE ONLINE FILE MISSING 0
确认主库数据文件：
SQL> select file#,name from v$datafile where file# in (5,6);FILE# NAME---------- ------------------------------------------------------------------5 /oradata/lmis/LMIS01.dbf6 /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/UNNAMED000056 /app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006
检查没有运行MRP，并且在待机状态下创建文件后可以启用：
STANDBY_FILE_MANAGEMENTSQL> 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_managementNAME TYPE VALUE------------------------------------ ----------- ------------------------------standby_file_management string MANUALSQL> 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 200set pagesize 999col status for a10SELECT DEST_ID,SEQUENCE#,APPLIEDFROM v$archived_logWHERE first_time>sysdate-35ORDER 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 site2）. 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 2021MRP0 started with pid=30, OS id=102010MRP0: Background Managed Standby Recovery process started (sss)started logmerger processThu Oct 09 11:39:03 2021Managed Standby Recovery not using Real Time ApplyMRP0: Background Media Recovery terminated with error 1111Errors 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 fileORA-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 fileORA-01111: name for data file 12 is unknown - rename to correct fileORA-01110: data file 12: '/u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012'Slave exiting with ORA-1111 exceptionErrors 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 fileORA-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 fileORA-01111: name for data file 12 is unknown - rename to correct fileORA-01110: data file 12: '/u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012'Recovery Slave PR00 previously exited with exception 1111MRP0: 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 2021MRP0 started with pid=30, OS id=102513MRP0: Background Managed Standby Recovery process started (sss)started logmerger processThu Oct 09 11:41:14 2021Managed Standby Recovery not using Real Time ApplyParallel Media Recovery started with 24 slavesWaiting for all non-current ORLs to be archived...All non-current ORLs have been archived.Thu Oct 09 11:41:14 2021Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSIONMedia Recovery Log /u01/sss/SSS/archivelog/2021_10_03/o1_mf_1_13523_b2wzmf1b_.arcThu Oct 09 11:41:36 2021
告警日志已经说明归档已经正常应用了，也可以查看一下V$MANAGED_STANDBY视图,确认一下MRP进程是否启用。


主备不同步

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


由于某种原因，可能导致备库的归档丢失，这需要我们手动来进行处理。
示例问题描述：
备库的归档日志没有增加，一直等待一个。
1. 查询问题：
SQL> SELECT * FROM V$ARCHIVE_GAP;THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#---------- ------------- --------------1        6434       6435SQL>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 6424NAME 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那活儿（上海新炬王翦团队）

数据库
文章转载自IT那活儿，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论