ORACLE DATAGUARD CONCEPTS

系統版本：

SQL> select * from v$version 
  2  /

BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
PL/SQL Release 11.2.0.4.0 - Production
CORE    11.2.0.4.0  Production

DATAGUARD的分類大致分爲三種

1. physical
2. logical
3. snapshot

Physical standby database

Provides a physically identical copy of the primary database, with on
disk database structures that are identical to the primary database on
a block-for-block basis. The database schema, including indexes, are
the same. A physical standby database is kept synchronized with the
primary database, through Redo Apply, which recovers the redo data
received from the primary database and applies the redo to the
physical standby database.

As of Oracle Database 11g release 1 (11.1), a physical standby
database can receive and apply redo while it is open for read-only
access. A physical standby database can therefore be used concurrently
for data protection and reporting.

Logical standby database

Contains the same logical information as the production database,
although the physical organization and structure of the data can be
different. The logical standby database is kept synchronized with the
primary database through SQL Apply, which transforms the data in the
redo received from the primary database into SQL statements and then
executes the SQL statements on the standby database.

A logical standby database can be used for other business purposes in
addition to disaster recovery requirements. This allows users to
access a logical standby database for queries and reporting purposes
at any time. Also, using a logical standby database, you can upgrade
Oracle Database software and patch sets with almost no downtime. Thus,
a logical standby database can be used concurrently for data
protection, reporting, and database upgrades.

Snapshot Standby Database

A snapshot standby database is a fully updatable standby database.

Like a physical or logical standby database, a snapshot standby
database receives and archives redo data from a primary database.
Unlike a physical or logical standby database, a snapshot standby
database does not apply the redo data that it receives. The redo data
received by a snapshot standby database is not applied until the
snapshot standby is converted back into a physical standby database,
after first discarding any local updates made to the snapshot standby
database.

A snapshot standby database is best used in scenarios that require a
temporary, updatable snapshot of a physical standby database. Note
that because redo data received by a snapshot standby database is not
applied until it is converted back into a physical standby, the time
needed to recover from a primary database failure is directly

最基本dataguard模式如下圖：

dg的三個服務：

Redo Transport Services

Control the automated transfer of redo data from the production
database to one or more archival destinations.

Apply Services

Apply redo data on the standby database to maintain transactional
synchronization with the primary database. Redo data can be applied
either from archived redo log files, or, if real-time apply is
enabled, directly from the standby redo log files as they are being
filled, without requiring the redo data to be archived first at the
standby database.

Role Transitions

Change the role of a database from a standby database to a primary
database, or from a primary database to a standby database using
either a switchover or a failover operation.

其中apply services 也分爲

1. redo apply
2. sql apply

其示意圖分別如下
redo apply

sql apply

redo 傳輸協議要做的事情

Redo transport services perform the following tasks:

Transmit redo data from the primary system to the standby systems in the configuration

Manage the process of resolving any gaps in the archived redo log files due to a network failure

Automatically detect missing or corrupted archived redo log files on a standby system and automatically retrieve replacement archived redo log files from the primary database or another standby database

dg 保護的三種模式:

Maximum availability This protection mode provides the highest level
of data protection that is possible without compromising the
availability of a primary database. Transactions do not commit until
all redo data needed to recover those transactions has been written to
the online redo log and to the standby redo log on at least one
synchronized standby database. If the primary database cannot write
its redo stream to at least one synchronized standby database, it
operates as if it were in maximum performance mode to preserve primary
database availability until it is again able to write its redo stream
to a synchronized standby database.

This protection mode ensures zero data loss except in the case of
certain double faults, such as failure of a primary database after
failure of the standby database.

Maximum performance This is the default protection mode. It provides
the highest level of data protection that is possible without
affecting the performance of a primary database. This is accomplished
by allowing transactions to commit as soon as all redo data generated
by those transactions has been written to the online log. Redo data is
also written to one or more standby databases, but this is done
asynchronously with respect to transaction commitment, so primary
database performance is unaffected by delays in writing redo data to
the standby database(s).

This protection mode offers slightly less data protection than maximum
availability mode and has minimal impact on primary database
performance.

Maximum protection This protection mode ensures that no data loss
will occur if the primary database fails. To provide this level of
protection, the redo data needed to recover a transaction must be
written to both the online redo log and to the standby redo log on at
least one synchronized standby database before the transaction
commits. To ensure that data loss cannot occur, the primary database
will shut down, rather than continue processing transactions, if it
cannot write its redo stream to at least one synchronized standby
database.

我們一般用的都是最大性能模式：
Maximum performance
這樣對主庫的影響最低。

另外datagurad已經和rac,rman,flashback database 深度整合了。

那麼掌握dg，除了dg的基本部署，多節點部署，與之相關的rac,rman,flashback等等，都需要DBA進行深度掌握，沒辦法，學不完是我們大ORACLE的一大特點。

再水一下，貼上DATAGURAD的benefits吧：

Data Guard offers these benefits:

Disaster recovery, data protection, and high availability

Data Guard provides an efficient and comprehensive disaster recovery
and high availability solution. Easy-to-manage switchover and failover
capabilities allow role reversals between primary and standby
databases, minimizing the downtime of the primary database for planned
and unplanned outages.

Complete data protection

Data Guard can ensure zero data loss, even in the face of unforeseen
disasters. A standby database provides a safeguard against data
corruption and user errors. Because the redo data received from a
primary database is validated at a standby database, storage level
physical corruptions on the primary database do not propagate to the
standby database. Similarly, logical corruptions or user errors that
cause the primary database to be permanently damaged can be resolved.

Efficient use of system resources

The standby database tables that are updated with redo data received
from the primary database can be used for other tasks such as backups,
reporting, summations, and queries, thereby reducing the primary
database workload necessary to perform these tasks, saving valuable
CPU and I/O cycles.

Flexibility in data protection to balance availability against
performance requirements

Oracle Data Guard offers maximum protection, maximum availability, and
maximum performance modes to help enterprises balance data
availability against system performance requirements.

Automatic gap detection and resolution

If connectivity is lost between the primary and one or more standby
databases (for example, due to network problems), redo data being
generated on the primary database cannot be sent to those standby
databases. Once a connection is reestablished, the missing archived
redo log files (referred to as a gap) are automatically detected by
Data Guard, which then automatically transmits the missing archived
redo log files to the standby databases. The standby databases are
synchronized with the primary database, without manual intervention by
the DBA.

Centralized and simple management

The Data Guard broker provides a graphical user interface and a
command-line interface to automate management and operational tasks
across multiple databases in a Data Guard configuration. The broker
also monitors all of the systems within a single Data Guard
configuration.

Integration with Oracle Database

Data Guard is a feature of Oracle Database Enterprise Edition and does
not require separate installation.

Automatic role transitions

When fast-start failover is enabled, the Data Guard broker
automatically fails over to a synchronized standby site in the event
of a disaster at the primary site, requiring no intervention by the
DBA. In addition, applications are automatically notified of the role
transition.