Scribd
Upload
108 views3 pages

Oracle Data Guard

Uploaded by

Atthulai
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
108 views3 pages

Oracle Data Guard

Uploaded by

Atthulai
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

ORACLE DATA GUARD

Oracle Data Guard is used to create and maintain up to nine standby copies of a production database, to
assist with disaster recovery and data corruption. This is called a Data Guard configuration. The standby
databases can be on the same machine as the production database, or spread over remote data centres,
as long as they can communicate with the production database.
The standby databases are initially created from an RMAN backup and are then kept identical to
production by transmitting redo log data from the primary database and then applying the logs to each
standby database. This is called a transactionally consistent copy, and is better than disk mirroring
because the redo logs are created from database changes while they are still in memory, so if any data
gets corrupted when it is copied to disk at the primary, this is not mirrored to the standby databases.
Oracle itself ensures that data is logically and physically consistent before it is applied to a standby
database.
If you need to take the production database down, or if you get an unplanned outage, Data Guard can
switch the production workload to any standby database, so minimising downtime. If you are upgrading
software, you can also use standby databases to roll out the upgrades, so proving them in a non-
production environment before applying them to production.
Any of these databases, production or standby, can be a single-instance Oracle database or an Oracle
RAC database. A standby database can be either a physical standby database or a logical standby
database. A physical standby database is identical to the primary database on a block-for-block basis. A
logical standby database is logically the same as the production database, but the physical organization
and structure of the data can be different and it is more flexible as it can be used for reporting, and
database upgrades, as well as providing protection from production failures.

Data protection schemes


Oracle Data Guard has three different types of protection mode, depending on whether data protection,
data availability or application performance is most important to you.
Maximum protection mode ensures that no data loss will occur if the primary database fails. The redo
data needed to recover each transaction must be written to both the local online redo log and to the
standby redo log on at least one standby database before the transaction commits and if it cannot be
written to at least one standby log the production database shuts down.
Maximum availability mode is identical to maximum protection mode, except that the primary database
does not shut down if it cannot write to a standby redo log. Instead, the primary database switches to
maximum performance mode until the problem is resolved.
Sometimes during a problem the redo log data will not be delivered in the right time sequence. In this
case, gaps will appear in the redo data, and the redo logs cannot be applied until all those gaps are
resolved. This is sorted out automatically by Data Guard, and once the data arrives and the gaps are
resolved, Data Guard will automatically put the primary database back into maximum availability mode. In
this mode, there will be no data loss if the primary database fails, provided a complete set of redo data
has been sent to at least one standby database.
The default mode is Maximum Performance, and this prioritises performance over data protection.
However if your network has enough bandwidth so the redo data can be transmitted without problems,
then data protection should not be an issue. A transaction is committed as soon as the redo data needed
to recover that transaction is written to the primary database online redo log. The redo data stream is
written asynchronously to at least one standby database, so there is no guarantee that the standby
databases are exact copies of production.
Oracle Data Guard Multi-Instance Redo Apply Works with the In-Memory Column
Store

RMAN Configuration in Data Guard


You can find some general RMAN information in the RMAN section.
Data Guard provides consistent copies of a production database, so it is possible to use those copies for
backup purposes. However because a logical standby database is not a block-for-block copy of the
primary database, you cannot use a logical standby database to back up the primary database (but you
can backup from a physical standby database).
An RMAN recovery catalog is required in a Data Guard environment to track all the various database
backups. Only the primary database is explicitly registered to the RMAN catalog and RMAN will
automatically register any physical standby databases if they are connected as targets.
Every database in a Data Guard configuration has a DB_UNIQUE_NAME and the recovery catalog uses
this to record which physical files and backups are associated with each database. Backups are
associated with the database that created them.
With Data Guard, it is possible to back up a tablespace on a physical standby database and restore and
recover it on the primary database. Similarly, you can back up a tablespace on a primary database and
restore and recover it on a physical standby database
.
If you backup a database to disk, then Data Guard does not make this backup available to any other
database for restores. This is because the databases in a Data Guard configuration can be in different
sites, and the disks may not be accessible to another site. If a backup goes to tape, then that backup is
accessible by all the databases in the configuration.
However, if you need to restore a production database from a standby disk backup, it is possible to FTP
the backup to the production site then catalog the backup to the production database.
The database control files are interchangeable. For example, you can restore a standby control file to a
primary database. This means that it is possible to just back up control files and archived logs from the
standby system and so minimise any performance impact on production.
However please note that Oracle best practice is to take backups of all control files and databases at both
the primary and the standby databases as this gives maximum protection from failure and obviates the
need to reconfigure backups if you failover between sites.

TSM backup considerations


The backups use the standard Oracle TDPO/RMAN configuration, but it must be possible to backup and
recover the database from either the primary or the standbye. To achieve this, you need two different
TSM clients defined, one for the primary and one for the standby database, and assuming the primary
and standby databases are on separate servers, you need two tdpo.opt files, one on each server. Then
for a Unix/Linux implementation you need two dsm.opt files, one for each client and two corresponding
stanzas within your dsm.sys file.

Oracle Storage
 Oracle Files
 Oracle RMAN
 Oracle RAC
 Dataguard
 Oracle ASM

Lascon updTES
I retired 2 years ago, and so I'm out of touch with the latest in the data storage world. The Lascon site has
not been updated since July 2021, and probably will not get updated very much again. The site hosting is
paid up until early 2023 when it will almost certainly disappear.
Lascon Storage was conceived in 2000, and technology has changed massively over those 22 years. It's
been fun, but I guess it's time to call it a day. Thanks to all my readers in that time. I hope you managed
to find something useful in there.
All the best
DISCLAIMER - By entering and using this site, you accept the conditions and limitations of use
Click here to see the Full Site Index       Click here to see the Cookie Policy       Click here to see
the Privacy Policy                             ©2019 and later, A.J.Armstrong

You might also like