说明：本文为面向Oracle (Active) Data Guard初学者的指导手册
标签：Oracle DG、Data Guard、Oracle ADG、Active Data Guard、ADG体系结构
注意：文中删去了不需要的多余部分，让初学者一目了然一学就会
版本区别：ADG(≥11g引入)是DG的超集，他们的基本功能和配置都一样
名称区别：其实ADG就是对DG进行了加强然后换了个更好听的名字（PS:加强了好几圈）
插件简介：Data Guard Broker是Oracle开发的一款管理维护DG/ADG的工具
系统安装：对于Oracle 11gR2的安装本文不再指导，用户可以自行搜索相关文章
温馨提示：如果您发现本文哪里写的有问题或者有更好的写法请留言或私信我进行修改优化
★ 相关文章
※ Oracle HA篇+DG/ADG 基础知识（本文）
※ 搭建DG（备用数据库类型：物理备用数据库）（Physical Standby Database）
※ 搭建DG（备用数据库类型：逻辑备用数据库）（Logical Standby Database）
【本文大纲】
体系结构（ADG）（摘自19c官方文档）
Oracle Data Guard（特性总结）（适用20c）
Oracle Active Data Guard（特性总结）（适用20c）
按版本显示DG/ADG的功能
DG/ADG相关视图（适用20c）
★ 体系结构（ADG）（摘自19c官方文档）
★ Oracle Data Guard（特性总结）（适用20c）
高可用性
Oracle Data Guard的易于管理的切换和故障转移功能允许在主数据库和备用数据库之间进行角色反转，从而最大程度地减少了计划内和计划外停机的主数据库停机时间。
全面的数据保护
Oracle Data Guard即使在无法预料的灾难面前也可以确保零数据丢失。备用数据库可防止所有类型的计划外中断，包括数据损坏和管理错误。因为从主数据库接收到的重做数据在备用数据库中得到验证，所以主数据库上可能发生的物理损坏不会传播到备用数据库。在备用数据库上执行的附加验证还可以防止逻辑块内损坏和丢失写入损坏传播到备用数据库。同样，诸如存储管理员意外删除文件之类的管理错误也不会传播到备用数据库。
有效利用系统资源
用从主数据库接收的重做数据更新的备用数据库表可以用于其他任务，例如备份，报告，求和和查询，从而减少了执行这些任务所需的主数据库工作量，节省了宝贵的CPU和I / O个周期。
数据保护的灵活性，以平衡可用性和性能要求
Oracle Data Guard提供最大的保护，最大的可用性和最佳的性能模式，以帮助企业在数据可用性与系统性能要求之间取得平衡。
自动间隙检测和分辨率
如果主数据库与一个或多个备用数据库之间的连接丢失（例如，由于网络问题），则在主数据库上生成的重做数据将无法发送到那些备用数据库。重新建立连接后，Oracle Data Guard会自动检测丢失的归档重做日志文件（称为间隙），然后将丢失的归档重做日志文件自动传输到备用数据库。备用数据库与主数据库同步，无需DBA手动干预。
集中且简单的管理
Oracle Data Guard代理提供了图形用户界面和命令行界面，以在Oracle Data Guard配置中跨多个数据库自动执行管理和操作任务。该代理还监视单个Oracle Data Guard配置中的所有系统。
与Oracle数据库集成
Oracle Data Guard是Oracle数据库企业版的一项功能，不需要单独安装。
自动角色转换
启用快速启动故障转移后，如果主站点发生灾难，Oracle Data Guard Broker将自动故障转移到同步备用站点，而无需DBA的干预。此外，还会自动向应用程序通知角色转换。
★Oracle Active Data Guard（特性总结）（适用20c）
✔ 名词解释：ADG全称Active Data Guard，它是Oracle数据库自带的功能模块，用来实现数据库高可用。
✔ 原理描述：ADG通过将源端的操作复制到一个或多个备用数据库上，从而实现备用库和主库的一致
✔ 常见用途：灾备、读写分离
✔ 稳定评测：稳定性高
✔ 维护难易：维护简单
✔ 功能支持：支持全部功能
✔ 资源消耗：低
✔ 异构支持：不支持异构
✔ 带宽占用：中
✔ 拓扑结构：一对一、一对多
✔ 通信机制：双向
✔ 传输协议：TCP
✔ 端口使用：一般为1521
✔ 产品授权：Active Data Guard是Oracle Database Enterprise Edition的授权选项
✔ 包含关系：ADG是DG的超集
✔ 优点概述：
※ 比传统DG即时性更高、可用性更高
※ 充分利用现有的物理备用数据库
※ 通过将处理任务转移到备用数据库来提高主数据库的性能
※ 通过将快速增量备份从主数据库卸载到活动备用数据库来提高备份性能
※ 允许活动备用数据库自动修复在主数据库上检测到的块损坏，对用户和应用程序透明（反之亦然）
※ 提供实时数据访问以进行报告
✔ 优点详情（适用19c）
※ REAL-TIME QUERY - PERFORMANCE AND ROI
Active Data Guard enables the offloading of read-only reporting applications, ad-hoc queries, data
extracts, and so on, to an up-to-date physical standby database while also providing disaster
protection. Active Data Guard is unique in having a highly parallelized apply process for best
performance while also enforcing the same read consistency model at the standby as is enforced at
the primary database. No other physical or logical replication solution does this.
Offloading work to an Active Data Guard standby database yields two significant benefits.
• Increased ROI in standby systems by productively using them at all times, putting an end to
expensive assets that sit idle until an outage occurs.
• Eliminating risk of the unknown through continuous user-validation that an active standby is ready
for failover if needed. An active standby is already working, all the time.
※ AUTOMATIC BLOCK REPAIR – HIGH AVAILABILITY
Block-level data loss usually results from intermittent random I/O errors, as well as memory
corruptions that get written to disk. When Oracle Database reads a block and detects corruption it
marks the block as corrupt and reports the error to the application. No subsequent read of the block
will be successful until the block is recovered manually unless you are using Active Data Guard.
Active Data Guard automatically performs block media recovery that is transparent to the application.
Active Data Guard repairs physical corruption on a primary database using a good version of the block
retrieved from the standby. Conversely, corrupt blocks detected on the standby database are
automatically repaired using the good version from the primary database.
Physical corruption on an active standby database is also detected and automatically repaired even in
cases where a block has never been changed at the primary database or read by applications running
at the standby. This is done by enabling Data Guard lost-write protection at both primary and standby
databases; a standard best practice for detecting silent corruption resulting from transactions that use
stale data. Lost-write protection has a secondary benefit of dramatically increasing the overall level of
validation for physical corruption performed at a standby database. Lost-write validation occurs at the
standby database for every block that is read at the primary, whether or not the data is changed.
Reading the standby version of the block in this manner triggers additional checks for physical block
corruption to detect faults that occur only at the standby database and not at the primary.
15 WHITE PAPER / Oracle (Active)
Data Guard 19c
※ FAR SYNC – ZERO DATA LOSS PROTECTION AT ANY DISTANCE
The impact that synchronous zero data loss protection has on database performance can lead to
undesirable compromises. Customers with large distance between sites must compromise on
protection and use asynchronous transport, accepting data loss in return for acceptable performance.
Customers who absolutely require zero data loss must compromise on geo-protection and locate all
sites within the same metropolitan area. Before Oracle Database 12c, the only viable option to achieve
zero data loss across long distances is a 3-site architecture characterized by one or more of:
expensive proprietary storage arrays, special purpose network devices, multiple Data Guard standby
databases (local and remote), and complex administrative procedures.
Active Data Guard Far Sync, a new capability for Oracle Database 12c Release 1, eliminates
compromise by extending zero data loss protection to any standby database located at any distance
from a primary database, and doing so at minimal expense and without additional complexity.
Far Sync is a new type of Active Data Guard transport destination, referred to as a far sync instance,
that receives redo synchronously from a primary database and forwards that redo asynchronously to
as many as 29 remote destinations. A far sync instance is a light-weight entity that manages only a
control file and log files. It requires a fraction of the CPU, memory, and I/O of a standby database. It
does not have user data files, nor does it run Redo Apply. Its only purpose is to transparently offload
the primary database of the overhead of transmitting redo to remote destinations. Far Sync can also
save network bandwidth by offloading the primary database of overhead from redo transport
compression incurred when using Oracle Advanced Compression.
Take for example an existing Data Guard configuration that uses asynchronous transport between a
primary in New York, and a standby in London. Upgrade to Active Data Guard and implement zero
data loss by simply deploying a far sync instance at a third location within synchronous replication
distance (estimated at 30-150 miles) of New York, (see figure 3). Any server that is compatible with
the primary will suffice. No proprietary storage, no special network devices, no additional licensing,
and no complex management are required. If the primary fails, the same failover command used in
any Data Guard configuration or automatic failover using Fast-Start Failover will quickly transition the
database in London to the primary role, with zero data loss.
Figure 4: Active Data Guard Far Sync – Zero Data Loss Failover at Any Distance
※ DATABASE ROLLING UPGRADES USING ACTIVE DATA GUARD
Companies are placing increasing priority on reducing planned downtime and risk when introducing
change to a mission critical production environment. Database rolling upgrades provide two
advantages:
• Minimizing downtime: Database upgrades and many other types of planned maintenance that alter
the physical structure of a database (other than changing the actual structure of a user table), can
be implemented at the standby while production continues to run at the primary database. Once all
changes have been validated, a switchover moves the production applications to the standby
database, enabling the original primary to be upgraded while users run on the new version. Total
planned downtime is limited to the brief time required to switch production to the standby.
• Minimizing risk: All changes are implemented and thoroughly tested at the standby database with
zero risk for users running on the production version. Oracle Real Application Testing enables real
application workload to be captured on the production system and replayed on the standby for the
most accurate possible test result – real production workload running on a complete copy of the
production database in a tightly controlled environment where it is impossible to impact production
service levels. Even in cases where maintenance could otherwise be performed online at a
production database, database rolling upgrades can be used by those who prefer to perform
maintenance on a separate copy completely isolated from production.
Database Rolling Upgrades using Active Data Guard, a new capability for Oracle Database 12c
Release 1, addresses concerns for complexity by replacing forty-plus manual steps required to
perform a transient logical rolling upgrade (See Appendix B) with three PL/SQL packages that
automate much of the process.
Database Rolling Upgrades using Active Data Guard can be used for version upgrades starting with
the first patchset of Oracle Database 12c Release 1. This means that the manual procedure included
with Data Guard and described in Appendix B of this paper must still be used for rolling upgrades from
Oracle Database 11g to Oracle Database 12c, or when upgrading from the initial Oracle Database 12c
release to the first patchset of Oracle Database 12c Release 1 or beyond.
This new Active Data Guard rolling upgrade capability can be used for other maintenance tasks that
alter database structure. Such tasks include:
• Adding partitioning to non-partitioned tables
• Changing BasicFiles LOBs to SecureFiles LOBs
• Changing XMLType stored as CLOB to XMLtype stored as binary XML
• Compressing tables
※ APPLICATION CONTINUITY
Fast Application Notification (FAN) is a capability of Oracle Database that quickly delivers exception
conditions to an application, but it does not report the outcome of the last transaction nor recover an
in-progress request from an application perspective. As a result, outages can become visible leading
to inconvenience for users and lost revenue. Users could also unintentionally make duplicate
purchases and submit multiple payments for the same invoice. Developers would have no alternative
other than to write and maintain custom application code to address these shortcomings, complicating
support and ongoing development.
Application Continuity was a new application-independent capability in Oracle Database 12c that
recovers incomplete requests from an application perspective and masks many system,
communication, and hardware failures, and storage outages from the end-user. It also ensures that
end-user transactions are executed no more than once. Application Continuity is included with Active
Data Guard.
※ GLOBAL DATA SERVICES
Oracle Global Data Services (GDS) was a new capability for Oracle Database 12c that extends
familiar RAC-style connect-time and run-time load balancing, service failover and workload
management capabilities to a collection of replicated databases, be it within a single datacenter or
across multiple datacenters. GDS is included with the Active Data Guard
★ 按版本显示DG/ADG的功能
area
New Capability Available with Oracle Database 19c
Active Data Guard
DML operations on the Read Only Standby are redirected to the Primary database to allow for some reporting applications that make infrequent writes to run on the ADG Standby.
You can enable the Oracle Database In-Memory Column store and Data Guard Multi-instance Redo apply at the same time on an Active Data Guard standby database.
Data Guard
You can dynamically change the fast-start failover target without disabling fast-start failover
Without impacting your current environment, you can test how fast-start failover will work by using the observe-only mode of fast-start failover.
The process of flashing back a physical standby to a point in time that was captured on the primary is simplified by automatically replicating restore points from primary to the standby
When flashback or point-in-time recovery is performed on the primary database, a standby that is in mounted mode can automatically follow the same recovery procedure performed on the primary
area
New Capability Available with Oracle Database 18c
Active Data Guard
Users on the standby will be able to continue exactly where they left off after a role change (switchover of failover) with the same performance as the Buffer Cache is now maintained over the role change operation.
Global Temporary tables and Sequences can be created dynamically while connected to the standby removing the requirement that they be precreated at the Primary before they can be used.
Log in security is enhanced to allow user accounts that exceed their login failure count to be locked across the entire Data Guard environment.
Users can now be moved during a Data Guard Role transition using the drain service capability and any users attached to the standby in read mode no longer get disconnected but maintain their state through the role change operation.
Data Guard
Lost writes can now be detected on the Primary database even if a standby is not available using shadow tablespaces.
Primary database nologging operations can be automatically repaired on the standby on Oracle’s Engineered Systems and in Oracle’s Cloud.
area
New Capability Available with Oracle Database 12c Release 2
Active Data Guard
Multi-Instance Redo Apply for Physical Standby databases. When the
standby is a Real Application Cluster all the nodes in the cluster are used to apply redo thereby increasing the rate at which the standby can keep up with high workload production databases.
The Oracle Database In-Memory feature can be used on Active Data Guard Standby databases when those standbys are on Oracle Engineered Systems or running in Oracle’s Cloud.
Tuning queries and redo apply performance can now be done completely on the standby database using Oracle’s Automatic Workload Repository (AWR) and the SQL Tuning Advisor.
Users can now be moved during a Data Guard Role transition using the drain service capability and any users attached to the standby in read mode no longer get disconnected but maintain their state through the role change operation.
The Automatic Block Repair feature can now detect and repair almost all potential block corruptions at the Primary or Standby databases.
Full Data Guard Broker support for DBMS_ROLLING upgrades.
RMAN and Enterprise Manager can be used to create Far Sync instances
Data Guard
The Database Creation Assistant (DBCA) and the Enterprise Manager Command Line Interface (EMCLI) can now be used to create standby databases
Failover an individual PDB from a standby container database to another Primary container using the Broker MIGRATE command in Multitenant databases
★ DG/ADG相关视图（适用20c）
视图 数据库 描述
DBA_LOGSTDBY_EVENTS
仅逻辑
包含有关逻辑备用数据库活动的信息。它可用于确定当SQL Apply将重做应用于逻辑备用数据库时发生失败的原因。
DBA_LOGSTDBY_HISTORY
仅逻辑
显示s的历史记录巫婆和fOracle Data Guard配置中的逻辑备用数据库的溢出。它通过显示在所有角色转换中在本地系统上处理或创建的重做日志流的完整顺序来完成此任务。（角色转换后，将启动新的日志流，并由新的主数据库增加日志流的序列号。）
DBA_LOGSTDBY_LOG
仅逻辑
显示为逻辑备用数据库注册的日志文件。
DBA_LOGSTDBY_NOT_UNIQUE
仅逻辑
标识没有主索引和非空唯一索引的表。
DBA_LOGSTDBY_PARAMETERS
仅逻辑
包含SQL Apply使用的参数列表。
DBA_LOGSTDBY_SKIP
仅逻辑
列出要由SQL Apply跳过的表。
DBA_LOGSTDBY_SKIP_TRANSACTION
仅逻辑
列出所选的跳过设置。
DBA_LOGSTDBY_UNSUPPORTED
仅逻辑
标识包含不支持的数据类型的架构和表（以及这些表中的列）。准备创建逻辑备用数据库时，请使用此视图。
DBA_ROLLING_UNSUPPORTED 仅逻辑 显示这些表中的模式，表和列，这些模式，表和列包含使用DBMS_ROLLINGPL / SQL软件包进行逻辑备用数据库的滚动升级操作所不支持的数据类型。在执行滚动升级之前，请使用此视图DBMS_ROLLING来确定不支持的升级。
V$ARCHIVE_DEST
主，物理，快照和逻辑
描述Oracle Data Guard配置中的所有目标，包括每个目标的当前值，模式和状态。
注意：此视图中的信息在实例关闭期间不会持久存在。
V$ARCHIVE_DEST_STATUS
主，物理，快照和逻辑
显示已归档的重做日志目标的运行时和配置信息。
注意：此视图中的信息在实例关闭期间不会持久存在。
V$ARCHIVE_GAP
物理，快照和逻辑
显示信息以帮助您确定已归档的重做日志文件中的间隙。
V$ARCHIVED_LOG
主，物理，快照和逻辑
显示控制文件中的归档重做日志信息，包括归档重做日志文件的名称。
V$DATABASE
主，物理，快照和逻辑
提供控制文件中的数据库信息。包括有关快速启动故障转移的信息（仅适用于Oracle Data Guard Broker）。
V$DATABASE_INCARNATION
主，物理，快照和逻辑
显示有关所有数据库化身的信息。每当使用该RESETLOGS选项打开数据库时，Oracle数据库都会创建一个新的化身。该V$DATABASE视图中还包含有关当前和先前版本的记录。
V$DATAFILE
主，物理，快照和逻辑
提供控制文件中的数据文件信息。
V$DATAGUARD_CONFIG
主，物理，快照和逻辑
列出使用DB_UNIQUE_NAME和定义的唯一数据库名称LOG_ARCHIVE_CONFIG 初始化参数。
V$DATAGUARD_STATS
主，物理，快照和逻辑
显示各种Oracle Data Guard统计信息，包括应用滞后和传输滞后。可以在备用数据库的任何实例上查询此视图。如果在主数据库上查询，则不返回任何行。有关示例和更多信息，另请参见为角色转换选择目标备用数据库。
V$DATAGUARD_STATUS
主，物理，快照和逻辑
显示并记录通常由警报日志或服务器进程跟踪文件中的任何消息触发的事件。
V$FS_FAILOVER_STATS
主
显示有关系统上发生的快速启动故障转移的统计信息。
V$LOG
主，物理，快照和逻辑
包含来自联机重做日志文件的日志文件信息。
V$LOGFILE
主，物理，快照和逻辑
包含有关联机重做日志文件和备用重做日志文件的信息。
V$LOG_HISTORY
主，物理，快照和逻辑
包含来自控制文件的日志历史记录信息。
V$LOGSTDBY_PROCESS
仅逻辑
提供有关SQL Apply所发生情况的动态信息。当您在逻辑备用数据库上的SQL Apply过程中诊断性能问题时，此视图非常有用，对于其他问题也可能有帮助。
V$LOGSTDBY_PROGRESS
仅逻辑
显示逻辑备用数据库上SQL Apply的进度。
V$LOGSTDBY_STATE
仅逻辑
从V$LOGSTDBY_PROCESS和V$LOGSTDBY_STATS视图合并有关SQL Apply和逻辑备用数据库的运行状态的信息。
V$LOGSTDBY_STATS
仅逻辑
在SQL Apply期间显示LogMiner统计信息，逻辑备用数据库的当前状态和状态信息。如果未运行SQL Apply，则将清除统计信息的值。
V$LOGSTDBY_TRANSACTION
仅逻辑
显示有关逻辑备用数据库上SQL Apply正在处理的所有活动事务的信息。
V$MANAGED_STANDBY
物理和快照
显示与物理备用数据库有关的Oracle数据库进程的当前状态信息。
注意：此视图中的信息在实例关闭期间不会持久存在。
V$REDO_DEST_RESP_HISTOGRAM
主
包含配置为SYNC传输的目的地的响应时间信息。
注意：此视图中的信息在实例关闭期间不会持久存在。
V$STANDBY_EVENT_HISTOGRAM
物理
包含物理备用数据库的应用延迟值的直方图。每秒重做应用过程会在相应的应用滞后桶中进行输入。（此视图仅返回已在实时查询模式下打开的物理备用数据库上的行。）
注意：此视图中的信息在实例关闭期间不会持久存在。
V$STANDBY_LOG
物理，快照和逻辑
包含来自备用重做日志文件的日志文件信息。
