ORACLE逻辑DG同步异常
&&&今天在西单开会期间接到同事的电话，反馈某系统ORACLE逻辑备库不同步了，alter.log上没有报错，重启分析进程也无法同步，因为当时正在开会，没有细说，下午来到现场后发现，alert.log有报错，提示ORA-00942表或视图不存在,同时.trace文件也没有相应的表和操作SQL，通过查询同步事件，发现有人在主库创建一张表，对备库端没有处理，导致进程同步中断，现分享一下逻辑DG的常见问题处理思路和解决方法。
一、逻辑DG怎么检查？
1& 检查逻辑DG事件，确认是否存在异常
&& select * from
dba_logstdby_events& order by event_
&& 说明：如果status报错，event列有详细的触发操作语句，常见的多数是主库有新的DDL语句
2& 同步进程是否存在，一般异常终止，同步进程是不存在的
&& SELECT * FROM
v$logstdby_
3& 查看日志是否都已经同步完成
&& select sequence#,applied
from dba_logstdby_log order by sequence#
&& 说明：正常情况下applied列应该都为CURRENT表示已经同步完成，NO表示还没有应用
一、出现异常怎么定位分析？
常见的逻辑DG数据不同步分为两种情况，第一种同步进程不存在，第二种同步进程存在，但是表中数据主备不一致，下面分两种情况过行分析定位
1& 同步进程不存在，主库数据没有同步到备库
&& select * from dba_logstdby_events& order
by event_time desc;
说明：查看报错信息和导致报错的事件，进行跳过处理
&& --停止数据库日志应用
database stop l
--跳过DML操作&
&DBMS_LOGSTDBY.SKIP('DML','CXF','TMP_SAME_FILE');&
--注意，表名要大写哦，否则还会报错的&&
&& --跳过DDL&&&
&DBMS_LOGSTDBY.SKIP('SCHEMA_DDL','CUECM','TMP_1024');--注意，表名要大写哦，否则还会报错的
&& --在主库端对索引做ANALYZE，如果索引在备库不存在，也会导致DG同步异常中断，这个时候就不能用DDL和
&&&&&DML两种跳过了，必须用下面这种方法跳过
&& --跳过ANALYZE TABLE操作
&DBMS_LOGSTDBY.SKIP('ANALYZE
TABLE','%','%',NULL);
--跳过ANALYZE INDEX操作
DBMS_LOGSTDBY.SKIP('ANALYZE INDEX','%','%', NULL);
--启动应用日志&&
alter database start logical sta
2&&同步进程存在，其它表都能同步，个别表无法同步
&&&这种情况，很可能是设置了表级别的对像跳过，可以通过以查查询确认是否手动设置跳过同步
&& select * from
DBA_LOGSTDBY_SKIP;&
然后通过DBMS_LOGSTDBY.UNSKIP()重新同步
三、无法在逻辑DG端进行DDL和DML操作？
&&&有时候跟据业务需要，我们需要在逻辑备库上过行DML操作，此时会报错
这时因为逻辑DG默认启动了数据保护，不允许在备库端进行DML操作，可以通过如下操作，
&& --进行DML操作前
&& --操作过后
session enable
了解以上问题处理技巧以后，常见的逻辑DG问题基本上都可以搞定，想深入学习的朋友建议去学习DBMS_LOGSTDBY系统包看看有哪些功能！好了，今天到此为止吧！有问题QQ交流！
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。DG日志不应用，GAP,主备切换解决思路与办法
DG日志不应用，GAP,主备切换解决思路与办法环境ORACLE 10G OS WINDOWS对于DG故障解决思路，DG日志切换不进行应用，DG出现GAP解决方法，DG主备库切换，当DG出现故障时，第一时间检测alert日志，服务器OS日志,网
DG日志不应用，GAP,主备切换解决思路与办法
环境ORACLE 10G OS WINDOWS
对于DG故障解决思路，DG日志切换不进行应用，DG出现GAP解决方法，DG主备库切换，
当DG出现故障时，第一时间检测alert日志，服务器OS日志,网络是否通畅。
1、当DG出现日志不能传输到备库
一、TNS配置错误，监听配置错误。
二、主备库初始化参数文件配置错误（如archive_log_dest文件位置错误)。
三、备库控制文件过旧，从主库生成一个STANDBY CONTROL过去。
SQL& alter database create standby controlfile as 'c:\control01.ctl';。
四、备库是否应用了Failovers 。
下面模拟备库应用了Failovers 。
alter database recover managed sta
Database altered.
SQL& select PROTECTION_MODE,OPEN_MODE,DB_UNIQUE_NAME,DATABASE_ROLE,SWITCHOVER_STATUS from v$
PROTECTION_MODE
DB_UNIQUE_NAME
DATABASE_ROLE
SWITCHOVER_STATUS
-------------------- -------------------- ------------------------------ ---------------- --------------------
MAXIMUM PERFORMANCE
PHYSICAL STANDBY TO PRIMARY
SQL& select PROTECTION_MODE,OPEN_MODE,DB_UNIQUE_NAME,DATABASE_ROLE,SWITCHOVER_STATUS from v$
PROTECTION_MODE
DB_UNIQUE_NAME
DATABASE_ROLE
SWITCHOVER_STATUS
-------------------- -------------------- ------------------------------ ---------------- --------------------
MAXIMUM PERFORMANCE
READ WRITE
SESSIONS ACTIVE
主库alert文件：
ARC1: All Archive destinations made inactive due to error 394
ARC1: Failed to archive thread 1 sequence 1 (394)
ARCH: Archival stopped, error occurred. Will continue retrying
Wed Oct 30 10:25:54 2013
Errors in file c:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arc1_1236.trc:
ORA-16038: log 2 sequence# 1 cannot be archived
ORA-00394: online log reused while attempting to archive it
ORA-00312: online log 2 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\STANDBY\ONLINELOG\O1_MF_2_96YY5JSW_.LOG'
ARC1: All Archive destinations made inactive due to error 394
10:25:54.796 58942 kcrr.c
kcrrfail: dest:1 err:394 force:0 blast:1
10:25:54.828 20146 kcrr.c
ORA-16038: log 2 sequence# 1 cannot be archived
ORA-00394: online log reused while attempting to archive it
ORA-00312: online log 2 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\STANDBY\ONLINELOG\O1_MF_2_96YY5JSW_.LOG'
10:27:54.734
10:27:54.734 20146 kcrr.c
10:28:54.765
kcrrwkx: work to do 0x1 (start)
10:28:54.781 20146 kcrr.c
这个时候导致主库不再向备库传送日志了,我们只需要重建STANDBY控制文件就行
SQL& alter database create standby controlfile as 'c:\control01.ctl';。
其中当真正主库出现故障的Failovers的时候
一.查看是否有日志GAP,没有应用的日志： -
SQL& SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;
　　SQL& SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
　　如果有，则拷贝过来并且注册
SQL& ALTER DATABASE REGISTER PHYSICAL LOGFILE '路径';
重复查看直到没有应用的日志：
二. 然后停止应用归档：
　　SQL& ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
三. 下面将STANDBY切换为PRIMARY数据库：
　　SQL& ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
SQL& ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;
　　SQL& SELECT DATABASE_ROLE FROM V$DATABASE;
　　DATABASE_ROLE
　　----------------
　　PHYSICAL STANDBY
　　SQL& ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
2、日志传输到备库不能应用。
一、是否产生了GAP 拷贝缺失的日志重新注册日志，如果GAP缺失的归档日志过多，切归档日志已经删除了，那就必须重新搭建DG。
二、是否设置了REDO延迟
下面就简单说说手工处理日志GAP的步骤：
1、在备库检查是否有日志缺失
SQL& select * from V$ARCHIVE_GAP;
2、在主库中查询缺失的日志的所在路径和名称
SQL& SELECT NAME FROM V$ARCHIVED_LOG
如果把日志移动到其他路径，则把日志所在路径换成当前实际所在路径。
3、把日志拷贝到备库上
4、在备库上手工注册上一步中从主库拷贝来的日志
SQL& ALTER DATABASE REGISTER LOGFILE '路径';
5、观察备库的alert日志信息
6、检查备库是否还有日志GAP
SQL& select * from V$ARCHIVE_GAP;
no rows selected
如果有行返回，则重复2-5步，直到查询结果是"no rows selected"。
如果日志只是临时移动到其他地方，过后会再移回原路径，则不用这么大费周折手工去手工处理了，把日志拷回原处后FAL会自动处理GAP。
3、DG主备库切换
1. 查看switchover 状态 -
SQL& SELECT SWITCHOVER_STATUS FROM V$DATABASE; -
to standby
2 切换成备库
如果上面的结果不是to standby 还有会话运行
SQL&Alter database commit to switchover to physical standby w
SQL& ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
Database altered.
3 启动到mount和应用日志状态
SQL& SHUTDOWN IMMEDIATE
SQL& alter database mo
SQL& ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
4. 查看数据库模式
SQL&select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_
SQL&select status,database_mode from v$archive_dest_
1.查看switchover状态 -
SQL& SELECT SWITCHOVER_STATUS FROM V$DATABASE;
TO PRIMARY
2. 切换成主库
如果上面的结果不是to PRIMARY 还有会话运行
SQL& ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY with session shutdown
SQL& ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Database altered.
SQL& alter s
3. 查看数据库模式
SQL&select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_
SQL&select status,database_mode from v$archive_dest_
至此，DG相关简单问题全部以列出。oracle DG 归档日志不能应用问题
[问题点数：40分，结帖人amlu]
oracle DG 归档日志不能应用问题
[问题点数：40分，结帖人amlu]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
本帖子已过去太久远了，不再提供回复功能。博客访问： 207402
博文数量： 63
注册时间：
承接各种oracle db实施/调优/灾难恢复/迁移/故障处理等项目,有需求的朋友们请及时联系我。seward.。大家可以多多交流，学习!
IT168企业级官微
微信号：IT168qiye
系统架构师大会
微信号：SACC2013
分类： Linux
环境ORACLE 10G OS WINDOWS对于DG故障解决思路，DG日志切换不进行应用，DG出现GAP解决方法，DG主备库切换，当DG出现故障时，第一时间检测alert日志，服务器OS日志,网络是否通畅。1、当DG出现日志不能传输到备库& &一、TNS配置错误，监听配置错误。& &二、主备库初始化参数文件配置错误（如archive_log_dest文件位置错误)。& &三、备库控制文件过旧，从主库生成一个STANDBY CONTROL过去。&& & & &SQL> alter database create standby controlfile as 'c:\control01.ctl';。& &四、备库是否应用了Failovers 。&& & & & & & & &下面模拟备库应用了Failovers ,我这个是进行切换过的。备库执行SQL> &alter database recover managed sta&Database altered.
备库SQL> select PROTECTION_MODE,OPEN_MODE,DB_UNIQUE_NAME,DATABASE_ROLE,SWITCHOVER_STATUS from v$
PROTECTION_MODE&&&&& OPEN_MODE& DB_UNIQUE_NAME&&&&&&&&&&&&&&&& DATABASE_ROLE-------------------- ---------- ------------------------------ ----------------SWITCHOVER_STATUS--------------------MAXIMUM PERFORMANCE& MOUNTED&&& primary&&&&&&&&&&&&&&&&&&&&&&& PHYSICAL STANDBYTO PRIMAR
主库SQL> select PROTECTION_MODE,OPEN_MODE,DB_UNIQUE_NAME,DATABASE_ROLE,SWITCHOVER_STATUS from v$
PROTECTION_MODE&&&&& OPEN_MODE& DB_UNIQUE_NAME&&&&&&&&&&&&&&&& DATABASE_ROLE-------------------- ---------- ------------------------------ ----------------SWITCHOVER_STATUS--------------------MAXIMUM PERFORMANCE& READ WRITE standby&&&&&&&&&&&&&&&&&&&&&&& PRIMARYSESSIONS ACTIVE
主库alert文件：ARC1: All Archive destinations made inactive due to error 394ARC1: Failed to archive thread 1 sequence 1 (394)ARCH: Archival stopped, error occurred. Will continue retryingWed Oct 30 10:25:54 2013Errors in file c:\oracle\product\10.2.0\admin\orcl\bdump\orcl_arc1_1236.trc:ORA-16038: log 2 sequence# 1 cannot be archivedORA-00394: online log reused while attempting to archive itORA-00312: online log 2 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\STANDBY\ONLINELOG\O1_MF_2_96YY5JSW_.LOG'ARC1: All Archive destinations made inactive due to error 394***
10:25:54.796 58942 kcrr.ckcrrfail: dest:1 err:394 force:0 blast:1***
10:25:54.828 20146 kcrr.cORA-16038: log 2 sequence# 1 cannot be archivedORA-00394: online log reused while attempting to archive itORA-00312: online log 2 thread 1: 'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\STANDBY\ONLINELOG\O1_MF_2_96YY5JSW_.LOG'***
10:27:54.734***
10:27:54.734 20146 kcrr.c***
10:28:54.765kcrrwkx: work to do 0x1 (start)***
10:28:54.781 20146 kcrr.c这个时候导致主库不再向备库传送日志了,我们只需要重建STANDBY控制文件就行SQL> alter database create standby controlfile as 'c:\control01.ctl';。其中当真正主库出现故障的Failovers的时候一.查看是否有日志GAP,没有应用的日志： && & SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;&　　SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;&　　如果有，则拷贝过来并且注册&& & SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE '路径';&& & 重复查看直到没有应用的日志：&二. 然后停止应用归档：&　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;&三. 下面将STANDBY数据库切换为PRIMARY数据库：　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;&& & 或&& & SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH FORCE;&　　SQL> SELECT DATABASE_ROLE FROM V$DATABASE;&　　DATABASE_ROLE&　　----------------&　　PHYSICAL STANDBY&　　SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;&2、日志传输到备库不能应用。&一、是否产生了GAP 拷贝缺失的日志重新注册日志，如果GAP缺失的归档日志过多，切归档日志已经删除了，那就必须重新搭建DG。
&二、是否设置了REDO延迟下面就简单说说手工处理日志GAP的步骤：1、在备库检查是否有日志缺失SQL> select * from V$ARCHIVE_GAP;2、在主库中查询缺失的日志的所在路径和名称SQL> SELECT NAME FROM V$ARCHIVED_LOG&如果把日志移动到其他路径，则把日志所在路径换成当前实际所在路径。3、把日志拷贝到备库上4、在备库上手工注册上一步中从主库拷贝来的日志SQL> ALTER DATABASE REGISTER LOGFILE '路径';5、观察备库的alert日志信息6、检查备库是否还有日志GAPSQL> select * from V$ARCHIVE_GAP;no rows selected如果有行返回，则重复2-5步，直到查询结果是"no rows selected"。如果日志只是临时移动到其他地方，过后会再移回原路径，则不用这么大费周折手工去手工处理了，把日志拷回原处后FAL会自动处理GAP。
3、DG主备库切换主库： &1. 查看switchover 状态 &SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE; && & & to standby&2 切换成备库&如果上面的结果不是to standby 还有会话运行SQL>Alter database commit to switchover to physical standby w&否则直接SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;&& & &Database altered.&3 启动到mount和应用日志状态&SQL> SHUTDOWN IMMEDIATE&SQL>&SQL> alter database mo&SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;&4. 查看数据库模式&SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_&SQL>select status,database_mode from v$archive_dest_&备库：&1.查看switchover状态 &SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;&& & TO PRIMARY&2. 切换成主库&如果上面的结果不是to PRIMARY 还有会话运行SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY with session shutdown&否则SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;&Database altered.&SQL>&SQL>&SQL> alter s&3. 查看数据库模式&SQL>select dest_name,status,database_mode,recovery_mode,protection_mode from v$archive_dest_&SQL>select status,database_mode from v$archive_dest_&至此，DG相关简单问题全部以列出。
阅读(3302) | 评论(0) | 转发(0) |
相关热门文章
给主人留下些什么吧！~~
请登录后评论。oracle dg 主备切换 DG之主库、备库切换（物理备库）-程序设计-就爱阅读网
您还可以使用以下方式登录
当前位置：&>&&>&&>& > DG之主库、备库切换（物理备库）
oracle dg 主备切换 DG之主库、备库切换（物理备库）
DG之主库、备库切换一．开库与关库顺序开库顺序先启备库，再启主库（启动监听、打开告警日志）关库顺序先关主库，再关备库二．主备库切换1、操作过程一览步骤1：启动备库、监听、告警；步骤2：启动主库、监听、告警；步骤3：主库（bj）查询信息SQL&selectname,dbid,database_role,protection_mode from v$步骤4：备库（sh）上做recoverSQL&recovermanaged standby database dis步骤5：备库上插入数据SQL&insert into scott.emp1 select * from scott.报错虽然备库处于open状态，但它是一个read-only状态。步骤6：查看主库（bj）、备库（sh）日志是否一致SQL&selectmax(sequence#) from v$archived_log wh或SQL&selectmax(sequence#) from v$archived_log；举例：主库：&备库：上图表明已经归档的最大序列号均为34，说明日志是同步的，可以进行主备库切换。步骤7：主库（bj）下检查是否可以切换SQL&selectname,database_role,protection_mode,switchover_status from v$switchover_status显示&TO STANDBY&表示允许做切换。步骤8：备库（sh）下检查是否可以切换SQL&selectname,database_role,protection_mode,switchover_status from v$说明：备库是不允许主动去切成主库的，NOT ALLOWED状态说明正常。步骤9：检查主库（bj）上的会话SQL&select username,sid from v$session where查看是否仍有用户使用数据库，若仍有人使用，是不允许切换的，切换前要通知确保无用户使用。步骤10：主库（bj）变为物理备库（sh）若没有会话，将主库（bj）变为物理备库（sh）SQL& ALTER DATABASECOMMIT TO SWITCHOVER TO PHYSICAL STANDBY;若有会话的话，关闭会话，将主库（bj）变为物理备库（sh）SQL& alter database commit to switchover to physical standby 步骤11：关闭、重启之前的主库（bj）到mount状态SQL& SHUTDOWN IMMEDIATE;SQL& STARTUP MOUNT;SQL& selectswitchover_status from v$SWITCHOVER_STATUS--------------------TO PRIMARY注：在这个时候，两个数据库都应该处于备库状态。步骤12：查证备库的转换状态SQL& SELECTSWITCHOVER_STATUS FROM V$DATABASE; SWITCHOVER_STATUS-----------------TO_PRIMARY &&可以转换为主库，说明是备库状态步骤13：将目标物理备库（sh）转换为主库SQL& ALTER DATABASECOMMIT TO SWITCHOVER TO PRIMARY（WITHSESSION SHUTDOWN）;步骤14：完成备库（sh）到主库转换，物理备库启动到open若物理备库（bj）在最近一次启动时不是处于只读模式 opened in read-only mode，直接将数据库打开，然后下一步。SQL& select status fromv$STATUS------------MOUNTEDSQL& ALTER DATABASE OPEN;SQL& select switchover_statusfrom v$SWITCHOVER_STATUS--------------------TO STANDBY若物理备库（bj）在最近一次启动时是只读模式，则先将数据库正常关闭再起库。SQL& SHUTDOWN IMMEDIATE;SQL& STARTUP;步骤15：在新备库（bj）上重新开启日志应用SQL& ALTER DATABASERECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;步骤16：在新的主库（sh）上切换日志，开始传输数据给备库SQL& ALTER SYSTEM SWITCHLOGFILE;SQL& /SQL& select max(sequence#)from v$archived_MAX(SEQUENCE#)--------------56SQL& col name for a50;SQL& select NAME ,SEQUENCE# from v$archived_ 查看归档日志步骤17：在备库（bj）上查看归档，两值相等说明备库能收到日志SQL& select max(sequence#)from v$archived_MAX(SEQUENCE#)--------------56SQL& col name for a50;SQL& select NAME ,SEQUENCE# from v$archived_ 查看归档日志2、总结主备库切换重点时间轴&&&&&&&&&&&&&主库备库查询能否切换（应该显示允许）&&备库查询能否切换（应该显示不允许）切换为物理备库&切换到mount状态&&查看备库转换状态&转换为主库&切换到mount状态启动到open&&&&启动到open状态开启日志应用&&切换日志&查看归档序列号查看归档序列号&查询状态：备库查询状态：主库***********************************************声明************************************************原创作品，出自 &深蓝的blog& 博客，欢迎转载，转载时请务必注明出处（http://blog.csdn.net/huangyanlong）。表述有错误之处，请您留言，不胜感激。提醒：点击目录，更有助于您的查看。*****************************************************************************************************就爱阅读网友整理上传,为您提供最全的知识大全,期待您的分享，转载请注明出处。
您可能也喜欢这些