(VR虚拟现实)物理DATAGUARD主备切换对OGG(DML)同步影响测试
oracle dataguard原理(一)

oracle dataguard原理(一)Oracle DataGuard原理详解介绍Oracle DataGuard是Oracle数据库提供的一种数据冗余和灾难恢复解决方案。
它通过实时数据复制和自动故障转移来提供数据保护和高可用性。
本文将从浅入深,逐步解释Oracle DataGuard的相关原理。
数据冗余•数据冗余是指将数据库中的数据复制到另一个位置,以保护数据免受硬件故障、自然灾害和人为错误的影响。
•在Oracle DataGuard中,数据冗余是通过将主数据库中的数据异步或同步复制到一个或多个备用数据库实现的。
•备用数据库是主数据库的精确副本,它可以提供故障转移和灾难恢复的能力。
主备同步•主备同步是指主数据库和备用数据库之间的数据复制是实时的并保持同步。
•在Oracle DataGuard中,主备同步有两种模式,即同步模式和异步模式。
•同步模式要求主数据库将数据写入本地磁盘后,等待至少一个备用数据库确认接收并写入数据,确保数据一致性和可靠性。
•异步模式允许主数据库立即提交事务,并异步地将数据发送给备用数据库。
这种模式下,主备数据库之间可能存在一定的数据延迟。
数据传输•数据传输是指主数据库将数据发送给备用数据库的过程。
•在Oracle DataGuard中,数据传输可以通过物理复制或逻辑复制来实现。
•物理复制是将主数据库的物理数据文件复制到备用数据库。
这种复制方式效率高,适用于大型数据库。
•逻辑复制是将主数据库的逻辑数据写入备用数据库。
这种复制方式可以跨不同操作系统平台和数据库版本。
自动故障转移•自动故障转移是指在主数据库发生故障时,备用数据库可以自动接管主数据库的功能。
•Oracle DataGuard提供了故障切换的功能,可以迅速将备用数据库切换为主数据库,实现连续的应用程序可用性。
•故障切换是基于Oracle Grid Infrastructure和Fast-Start Failover技术实现的,它能够在故障发生时自动检测和处理。
数据库主备切换与故障演练的策略与实施

数据库主备切换与故障演练的策略与实施在现代信息技术的发展中,数据库的安全性和稳定性对于企业运维工作至关重要。
在数据库管控中,数据库主备切换和故障演练是保障系统连续运行和数据安全的重要手段。
本文将探讨数据库主备切换与故障演练的策略与实施。
一、数据库主备切换策略数据库主备切换是指在数据库主节点故障时,实现业务的快速切换到备节点。
主备切换的策略是确保数据库能够快速响应故障状况,并实现无感知的切换。
下面是几种常用的数据库主备切换策略:1. 双向同步策略:双向同步策略允许主节点和备节点之间的数据同步。
当主节点发生故障时,备节点会接管主节点的工作,并实现业务的快速切换。
同时,备节点也需要实时同步主节点的数据,以确保业务连续性。
2. 虚拟IP切换策略:虚拟IP切换策略是通过配置虚拟IP地址,将业务请求发送到主节点或备节点,实现数据库的无感知切换。
当主节点发生故障时,虚拟IP 会切换到备节点,保障业务的正常运行。
3. 心跳检测与监控策略:心跳检测与监控策略通过监听主节点和备节点之间的心跳信号来实现主备切换。
当主节点出现故障时,备节点会通过心跳信号感知主节点的状态,并自动切换为主节点,保障数据库的高可用性。
二、数据库故障演练的策略与实施数据库故障演练是为了测试数据库系统在真实故障情况下的应对能力和恢复速度。
通过模拟各种灾难性故障,可以及时发现并修复存在的问题,提高数据库系统的容灾能力。
下面是一些数据库故障演练的策略与实施建议:1. 制定详细的演练计划:在进行数据库故障演练之前,需要制定详细的演练计划。
演练计划包括演练的目标、演练的内容、演练的步骤和演练的时间安排等。
制定详细的演练计划可以保证演练的顺利进行,并避免可能的操作失误。
2. 模拟真实故障场景:在故障演练中,需要模拟真实的故障场景,例如:数据库主节点故障、数据丢失、网络中断等情况。
通过模拟真实故障场景,可以更好地测试数据库系统的恢复能力,并发现潜在的问题。
dataguard物理主备库切换错误记录

dataguard物理主备库切换错误记录主备库切换时有点小错误,记录如下:主库:selectLOG_MODE,CONTROLFILE_TYPE,OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVE R_STATUS from v$database;LOG_MODE CONTROL OPEN_MODE PROTECTION_MODE DATABASE_ROLE------------ ------- ---------- -------------------- ----------------SWITCHOVER_STATUS--------------------ARCHIVELOG CURRENT READ WRITE MAXIMUM PROTECTION PRIMARYTO STANDBYSQL> alter database commit to switchover to physical standby;Database altered.SQL> shutdown immediate;ORA-01507: database not mountedORACLE instance shut down.SQL> startup mountselectLOG_MODE,CONTROLFILE_TYPE,OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVE R_STATUS from v$database;LOG_MODE CONTROL OPEN_MODE PROTECTION_MODE DATABASE_ROLE------------ ------- ---------- -------------------- ----------------SWITCHOVER_STATUS--------------------ARCHIVELOG STANDBY MOUNTED MAXIMUM PROTECTION PHYSICAL STANDBYTO PRIMARY备库:selectLOG_MODE,CONTROLFILE_TYPE,OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVE R_STATUS from v$database;LOG_MODE CONTROL OPEN_MODE PROTECTION_MODE DATABASE_ROLE------------ ------- ---------- -------------------- ----------------SWITCHOVER_STATUS--------------------ARCHIVELOG STANDBY MOUNTED MAXIMUM PROTECTION PHYSICAL STANDBY SWITCHOVER PENDINGSQL> alter database commit to switchover to primary;alter database commit to switchover to primary*ERROR at line 1:ORA-16139: media recovery requiredSQL> ![oracle@linux2 ~]$ tail /oracle/oradata/standby/bdump/alert_stand.logEnd-Of-REDO archived log file has not been recoveredArchived log files detected beyond End-Of-REDOIncomplete recovery SCN:0:234931 archive SCN:0:265075Database not available for switchoverEnd-Of-REDO archived log file has been receivedEnd-Of-REDO archived log file has not been recoveredArchived log files detected beyond End-Of-REDOIncomplete recovery SCN:0:234931 archive SCN:0:265075Switchover: Media recovery required - standby not in limboORA-16139 signalled during: alter database commit to switchover to primary...SQL> alter database recover managed standby database disconnect from session;Database altered.SQL> ![oracle@linux2 ~]$ tail /oracle/oradata/standby/bdump/alert_stand.logCompleted: alter database recover managed standby database disconnect from sessionTue Apr 15 09:08:37 2008Media Recovery Log /oracle/oradata/standby/arch/1_29_651601678.dbfMedia Recovery Log /oracle/oradata/standby/arch/1_30_651601678.dbfMedia Recovery Log /oracle/oradata/standby/arch/1_31_651601678.dbfMedia Recovery Log /oracle/oradata/standby/arch/1_32_651601678.dbfMedia Recovery Log /oracle/oradata/standby/arch/1_33_651601678.dbfMedia Recovery Log /oracle/oradata/standby/arch/1_34_651601678.dbfMedia Recovery Log /oracle/oradata/standby/arch/1_35_651601678.dbfMedia Recovery Log /oracle/oradata/standby/arch/1_36_651601678.dbfSQL> select LOG_MODE,CONTROLFILE_TYPE,OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVE R_STATUS from v$database;LOG_MODE CONTROL OPEN_MODE PROTECTION_MODE DATABASE_ROLE------------ ------- ---------- -------------------- ----------------SWITCHOVER_STATUS--------------------ARCHIVELOG STANDBY MOUNTED MAXIMUM PROTECTION PHYSICAL STANDBYTO PRIMARYSQL> alter database commit to switchover to primary;Database altered.SQL> alter database open;Database altered.SQL> select LOG_MODE,CONTROLFILE_TYPE,OPEN_MODE,PROTECTION_MODE,DATABASE_ROLE,SWITCHOVE R_STATUS from v$database;LOG_MODE CONTROL OPEN_MODE PROTECTION_MODE DATABASE_ROLE------------ ------- ---------- -------------------- ----------------SWITCHOVER_STATUS--------------------ARCHIVELOG CURRENT READ WRITE MAXIMUM PROTECTION PRIMARY TO STANDBY。
DATAGUARD实施和维护总结

DATAGUARD实施和维护总结1、DATAGUARD原理STANDBY一旦创建,DATAGUARD就会通过将主数据库的REDO传递给STANDBY数据库,然后在STANDBY中应用REDO实现数据库的同步。
有两种类型的STANDBY:物理STANDBY和逻辑STANDBY物理STANDBY提供与主数据库完全一样的拷贝(块到块),数据库SCHEMA,包括索引都是一样的。
它是直接应用REDO实现同步的。
逻辑STANDBY则不是这样,在逻辑STANDBY中,逻辑信息是相同的,但物理组织和数据结构可以不同,它和主库保持同步的方法是将接收的REDO转换成SQL语句,然后在STANDBY上执行SQL语句。
逻辑STANDBY除灾难恢复外还有其它用途,比如用于用户进行查询和报表。
DATAGUARD包含三个服务(日志传输、日志应用和角色转换)日志传输服务控制REDO数据的传输(传输日志,实施数据库保护模式)--------------STANDBY上通过起用RFS进程接收REDO数据。
日志应用服务则一方面自动应用日志,另一方面自动检测STANDBY缺少的REDO,并从主数据库或其它STANDBY 中自动查询出丢失的REDO。
DATAGUARD的几种保护模式:最大保护,最大可用,最大性能最大保护是指除非REDO在至少一个STANDBY中可用,否则事务不能提交。
如果在某个STANDBY中不可用,则主数据库的操作被停止。
最大可用是指如果STANDBY不可用,主数据库仍然可以处理事务,只是在问题被纠正后,STANDBY和主数据库进行再同步。
这样的一个问题是:当再同步之前有必要FAILOVER时,有些数据可能会丢失。
最大性能是指主数据库的提交操作不等待STANDBY。
物理STANDBY可能的模式:只读模式(OPEN READONLY)和恢复模式(MANANGED RECOVERY)2、物理DATAGUARD实施主数据库的准备工作:FORCE LOGGING,ENABLE ARCHIVING,一个本地归档目的地。
OracleDataguard数据同步复制的容灾技术方案

OracleDataguard数据同步复制的容灾技术方案2007-02-28 15:20:07标签:容灾方案OracleDataguard是ORACLE 提供的一种高可用性(HIGH AVAILABLE)的数据库方案,它是在主节点与备用节点间通过日志同步来保证数据的同步,可以实现快速切换与灾难性恢复。
中软公司自主研发的基于Dataguard同步引擎的Oracle数据库异地同步解决方案RS5,能够对安全、高效的实现数据库远程实时备份,最大限度保证用户的数据安全。
一、设计目标最大程度上保证数据的可用与可恢复,做到灾难事件发生时的数据零丢失。
二、方案概述针对关键业务数据灾难防护的需求,制定本地备份策略结合异地实时备份的高可靠性方案。
1. 本地备份策略本地备份是数据库容灾重要的组成部分。
通过配置RMAN的备份策略,可以实现备份和还原数据库文件、归档日志和控制文件。
根据具体应用环境,可以订制备份的方式和频率,例如每周的全备和每日的增量备份。
在数据库出现问题的时候,可以使用RMAN备份、归档日志及在线日志恢复数据。
2. 异地实时同步异地实施同步可以最大限度的保证数据安全,避免因各类事故造成的损失。
ORACLE Dataguard是基于数据库复制的方式来实现的、目前最流行的高可用解决方案之一。
在此基础上,我们开发了一套直观便捷的管理界面,使系统不仅可以实现数据库数据的实时快速复制,而且使系统的实施和管理方便而快捷。
数据库复制的原理主要是通过日志文件的传送、分析和应用来实现的,在应用事务发生后主数据中心通过数据复制引擎将日志传输到备份数据中心,备份数据中心的数据库对日志中记载的事务执行重演操作,实现对备份数据中心数据库数据的更新。
本方案采用高性能、基于Log分析(主要是Redo Log)的Oracle数据库复制解决方案,它可以复制数据库中大量的数据更新(如在数千个表上的每秒数千个操作)到一个或多个Oracle 目标实例中。
GoldenGate TDM容灾方案与DataGuard容灾方案的对比

GoldenGate TDM容灾方案与DataGuard容灾方案的对比物理standby我们知道物理standby与primary数据库完全一模一样(默认情况下,当然也可以不一样,事无绝对嘛),Dataguard通过redo应用维护物理standby数据库。
通常在不应用恢复的时候,可以以read-only模式打开,如果数据库指定了flashback area的话,也可以被临时性的置为read-write模式。
物理standby所使用的redo应用技术使用最底层的恢复机制,这种机制能够绕过sql级代码层,因此效率最高。
逻辑standby逻辑standby有三种工作模式:最大保护(Maximum protection):必须确保redo写到至少一个standby数据库,才提交本事务.这种模式能够确保绝无数据丢失。
要实现这一步当然是有代价的,它要求所有的事务在提交前其redo不仅被写入到本地的online redo log,还要同时提交到standby数据库的standby redo log,并确认redo数据至少在一个standby数据库可用(如果有多个的话),然后才会在primary 数据库上提交。
如果出现了什么故障导致standby数据库不可用的话,primary数据库会被shutdown。
?最高性能(Maximum performance):这种模式提供在不影响primary数据库性能前提下最高级别的数据保护策略。
事务可以随时提交,当前primary数据库的redo数据也需要至少写入一个standby数据库,不过这种写入可以是不同步的。
如果网络条件理想的话,这种模式能够提供类似最高可用性的数据保护而仅对primary数据库有轻微的性能影响。
?最高可用性(Maximum availability):必须确保redo写到至少一个standby数据库,才提交本事务.这种模式提供在不影响primary数据库可用前提下最高级别的数据保护策略。
Oracle11G数据库DataGuard灾备切换方案
Oracle 11G数据库DataGuard灾备切换方案、检查1、确定MRP进程在正常运行real-time apply real-time apply SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;2、确定有足够的归档进程在所有的主备库实例上查询参数LOG_ARCHIVE_MAX_PROCESSES,确定其值大于等于4, 但不会太大3、确定目标备库的REDO为clear状态虽然在发起SWITCHOVER TO PRIMARY命令时,备库的REDO会自动转换为CLEAR 状态,但依然建议在SWITCHOVER前REDO为CLEAR状态。
确保正确设置了 LOG_FILE_NAME_CONVERT参数。
AND L.STATUS NOT IN (\UNUSED’,、CLEARING’,’CLEARING_CURRENT’);如果如上的查询有结果,4、确定没有大量的GAP5、确定主库以及目标备库的所有文件都为ONLINE主备库分别执行如下SQL,查看tempfile是否正常,如果备库上缺失文件则需要进行处、切换1、检查主库是否可切换至STANDBY如上的SQL查询结果如果为〃TO STANDBY”或者〃SESSIONS ACTIVE〃表示主库可切换至STANDBY,如果不为这两个值,则说明REDO传输存在问题。
2、停止主库第一个节点以外的所有实例(RAC)最好使用shutdown normal或者shutdown immediate方式停止数据库。
如果使用了shutdown abort将其他节点进行了关闭,则需等待RAC reconfig完成,且第一个节点将其余REDO正常前滚或回滚3、切换主库至STANDBY角色如果遇到ORA-16139报错,且V$DATABASE视图中DATABASE_ROLE字段的值已为“ PHYSICAL STANDBY”,则可继续(这种问题的出现其中一个可能是数据库有大量的数据文件)。
物理DATAGUARD主备切换对OGG(DML)同步影响测试
物理DATAGUARD主备切换对OGG〔DML〕同步影响测试一、环境介绍注:如何搭建环境在此文档中不做描述。
切换前纪录:主库:OGG查询库:通过表中的数据比拟可以看到主库与OGG查询库为同步状态。
主库后台日志:可以看到当前主库归档日志为48号,在线日志为49号〔未归档〕DG灾备库后台日志:可以看到当前灾备库已经Media Recovery的归档日志为48号,等待的下个日志为49号综上,可以判断出主库与灾备库当前为同步状态。
二、DG主备切换:主库操作:1. Alter system switch logfile; 主库后台日志:备库后台日志:2. 在主库关闭OGG查询库同步进程3.查看主库状态并切换主->备主库操作:主库后台日志:备库后台日志:4. 启动主库到mount状态,并查看主库状态主库操作:可以看到已经转变为备库5.查看备库状态并切换备->主备库操作:原主库后台日志:原备库后台日志:6. 查看当前原备库状态可以看到已经转变为主库7. 在原主库开启DG同步原主库后台日志:8. 在原备库对表test.testtb进行一系列dml操作,并切换日志备库操作:原备库后台日志:可以看到当前已经归档的日志文件为52号。
原主库后台日志:可以看到当前原主库已经Media Recovery到第52号归档文件,正在等待53号归档文件通过后台日志,可以确认当前主备切换后的DG体系,同步正常。
三、DG主备再切换〔即复原为最初的主备状态〕1.查看原备库〔即当前的主库〕状态并切换备->主原备库操作:原备库后台日志:原主库后台日志:2. 启动原备库到mount状态,并查看切换后状态可以看到当前原备库已经切换为备库。
3.查看原主库状态并进行切换备->主原主库操作:可以看到原主库已经切换为主库原主库后台日志:4. 在原备库启动DG同步原备库后台日志:5. 测试切换后DG同步情况主库操作:主库后台日志:可以看到当前主库已经归档到第55号归档日志文件备库后台日志:可以看到当前备库已经Media Recovery到第55号归档日志文件,正在等待第66号归档日志通过后台日志比拟可以看出主备库DG当前同步情况正常6.查看主库中表test.testtb与OGG查询库数据〔此时OGG同步为开启〕主库:可以看到在切换后原备库进行的DML操作都同步到了原主库OGG查询库:可以看到此时由于OGG还没有开启,故在主备切换后操作的数据没有被同步从上面的过程中可以看到OGG的抽取能正常启动,并到当前最新的日志。
数据库集群故障转移与主备切换实践
数据库集群故障转移与主备切换实践近年来,随着数据量的不断增长和对数据可用性要求的提高,数据库集群逐渐成为企业中存储和管理数据的常用方式。
然而,即使通过构建数据库集群可以提高配置的可用性,但仍然无法完全避免出现故障的可能性。
因此,为了保证企业数据的连续性和正常运行,实施数据库集群的故障转移与主备切换措施就显得尤为重要。
一、数据库集群故障转移数据库集群故障转移是指当一个数据库节点发生故障时,集群能够自动将工作转移到其他健康节点上,并且在可容忍的时间内恢复对外服务。
通过故障转移,数据库集群能够确保数据连续性和可用性,最大程度地减少业务中断时间。
在实际应用中,通常采用主从复制的方式来实现数据库集群的故障转移。
主从复制通过将主节点(Master)的数据复制到多个从节点(Slave)上,实现数据的冗余存储。
当主节点发生故障时,系统将自动将从节点切换为主节点,保证数据的连续性。
同时,主从复制还可以提供数据读写的负载均衡功能,提高数据库的整体性能。
为了实现数据库集群故障转移,首先需要选择一种合适的自动故障转移工具,如MySQL的MHA(Master High Availability)或PXC(Percona XtraDB Cluster),PostgreSQL的Patroni等。
这些工具都提供了自动监控和故障转移功能,能够快速检测到节点故障,并实现自动切换。
其次,需要经过合理的配置和部署,确保数据库集群的可靠性和高可用性。
这包括设置适当的节点数量、合理分配主从角色、制定故障转移策略等。
此外,还需要定期进行集群故障和切换的测试,以确保整个系统的稳定性。
二、主备切换实践主备切换是一种主动的、手动触发的操作,用于在数据库主节点发生故障或需要维护时,将备节点切换为主节点。
与故障转移不同,主备切换需要人工干预,但在某些场景下,仍然是必须的选择。
要实施数据库主备切换,首先需要设置好备节点并将数据复制到备节点上。
这可以通过主从复制或者其他数据同步工具来完成。
dataguard 原理
dataguard 原理
DataGuard是Oracle数据库提供的一种高可用性和灾难恢复解决方案。
它通过在主数据库和备份数据库之间实时复制和传输归档日志,确保在主数据库故障时可以快速切换到备份数据库并继续工作。
数据保护的原理是基于物理日志文件的持续备份和传输。
在正常运行时,主数据库将产生归档日志,这些日志会被连续地传输到备份数据库。
备份数据库将这些日志应用到自己的副本中,使得备份数据库与主数据库保持同步。
一旦主数据库发生故障,可以通过手动或自动切换到备份数据库。
此时,备份数据库会将主数据库中未完全发送的归档日志自动应用并保持最新状态,保证数据一致性。
DataGuard还包括实时应用备份数据库的模式,以提供实时报告和查询。
此模式下,客户可以从备份数据库读取数据,而不会影响主数据库的性能。
这种架构提供了性能增强和高可用性。
DataGuard通过提供物理级别的数据保护,不仅可以应对硬件故障,还可以应对人为错误、自然灾害和系统故障等各种灾难情况。
它还支持异地灾备,即将备份数据库部署在远离主数据库的地理位置,确保即使发生严重灾难,如地震或洪水,数据库仍然可用。
总之,DataGuard原理是基于实时复制和传输归档日志,使得备份数据库与主数据库保持同步,并通过自动应用归档日志保持数据的一致性。
它提供高可用性和灾难恢复解决方案,可应对各种硬件故障和灾难情况,确保数据库的可用性和数据完整性。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
物理DATAGUARD主备切换对OGG(DML)同步影响测试一、环境介绍
注:如何搭建环境在此文档中不做描述。
测试表:test.testtb
切换前纪录:
主库:
OGG查询库:
通过表中的数据比较可以看到主库与OGG查询库为同步状态。
主库后台日志:
可以看到当前主库归档日志为48号,在线日志为49号(未归档)
DG灾备库后台日志:
可以看到当前灾备库已经Media Recovery的归档日志为48号,等待的下个日志为49号综上,可以判断出主库与灾备库当前为同步状态。
二、DG主备切换:主库操作:
1. Alter system switch logfile; 主库后台日志:
备库后台日志:
2. 在主库关闭OGG查询库同步进程
3.查看主库状态并切换主->备主库操作:
主库后台日志:
备库后台日志:
4. 启动主库到mount状态,并查看主库状态主库操作:
可以看到已经转变为备库
5.查看备库状态并切换备->主备库操作:
原主库后台日志:
原备库后台日志:
6. 查看当前原备库状态
可以看到已经转变为主库7. 在原主库开启DG同步
原主库后台日志:
8. 在原备库对表test.testtb进行一系列dml操作,并切换日志备库操作:
原备库后台日志:
可以看到当前已经归档的日志文件为52号。
原主库后台日志:
可以看到当前原主库已经Media Recovery到第52号归档文件,正在等待53号归档文件
通过后台日志,可以确认当前主备切换后的DG体系,同步正常。
三、DG主备再切换(即还原为最初的主备状态)
1.查看原备库(即当前的主库)状态并切换备->主
原备库操作:
原备库后台日志:
原主库后台日志:
2. 启动原备库到mount状态,并查看切换后状态
可以看到当前原备库已经切换为备库。
3.查看原主库状态并进行切换备->主原主库操作:
可以看到原主库已经切换为主库原主库后台日志:
4. 在原备库启动DG同步
原备库后台日志:
5. 测试切换后DG同步情况主库操作:
主库后台日志:
可以看到当前主库已经归档到第55号归档日志文件
备库后台日志:
可以看到当前备库已经Media Recovery到第55号归档日志文件,正在等待第66号归档日志通过后台日志比较可以看出主备库DG当前同步情况正常
6.查看主库中表test.testtb与OGG查询库数据(此时OGG同步为开启)
主库:
可以看到在切换后原备库进行的DML操作都同步到了原主库
OGG查询库:
可以看到此时由于OGG还没有开启,故在主备切换后操作的数据没有被同步7.启动OGG查询库同步
从上面的过程中可以看到OGG的抽取能正常启动,并到当前最新的日志。
8.查询主库与OGG查询库test.testtb数据是否一致(此时OGG同步以正常开启,并同步)主库:
OGG查询库:
可以看到当前主库与查询库数据一致,在切换后产生的DML都已经同步完成。
9. 检查OGG是否能正常同步
主库:
OGG查询库:
可以看到此时OGG同步一切正常。
四、测试结果
结论:DATAGUARD主备SWITCHOVER切换不会影响切换回原状态后的OGG使用。
注意:
1.要求灾备库必须开启force_logging与supplemental_log,如为ddl同步(本文档未测试)则需要关闭回收站,否则OGG无法抽取主备切换后的归档日志。
查看方式:
修改方式:
2.由于本测试中所用到的均为ORACLE DATABASE单机,如在RAC环境中,则需要注意DG切换回原状态后的归档位置。