Data Guard Interview Questions & Answers
1) What
are the types of Oracle Data Guard?
Oracle
Data Guard classified in to two types based on way of creation and method used
for Redo Apply. They are as follows.
1. Physical
standby (Redo Apply technology)
2. Logical
standby (SQL Apply Technology)
3. Snapshot
standby (not applied until the snapshot standby is Converted)
2)
What are the advantages in using Oracle Data Guard?
Following
are the different benefits in using Oracle Data Guard feature in your
environment.
1. High
Availability.
2. Data
Protection.
3. Off
loading Backup operation to standby database.
4. Automatic
Gap detection and Resolution in standby database.
5. Automatic
Role Transition using Data Guard Broker.
3) What
are the different services available in Oracle Data Guard?
Following
are the different Services available in Oracle Data Guard of Oracle database.
1. Redo
Transport Services.
2. Log
Apply Services.
3. Role
Transitions.
Control the automated transfer of redo data from
the production database to one or more archival destinations.
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.
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.
4) What
are the different Protection modes available in Oracle Data Guard?
Data
Guard protection modes implement rules that controls how the configuration will
respond to failures, enabling you to achieve specific objectives for data
protection, availability, and performance.
Following
are the different protection modes available in Data Guard of Oracle database
you can use any one based on your application requirement.
1. Maximum
Protection
2. Maximum
Availability
3. Maximum
Performance (Default Mode)
a)
Maximum Performance
–
Emphasis is on primary database performance over data protection.
– Requires ASYNC (the default method) redo transport so that the LGWR process never waits for acknowledgment from the standby database.
– Network connection between primary and standby OR the availability of the standby database DO NOT IMPACT the primary database performance
– Requires ASYNC (the default method) redo transport so that the LGWR process never waits for acknowledgment from the standby database.
– Network connection between primary and standby OR the availability of the standby database DO NOT IMPACT the primary database performance
b)
Maximum Availability
– first
emphasis is on availability and second priority is zero data loss protection.
– requires SYNC redo transport so primary database performance may be impacted in waiting for acknowledgment from the standby (it doesn’t mean indefinite wait in case standby database fails, maximum wait will be equal to parameter NET_TIMEOUT seconds).
– requires SYNC redo transport so primary database performance may be impacted in waiting for acknowledgment from the standby (it doesn’t mean indefinite wait in case standby database fails, maximum wait will be equal to parameter NET_TIMEOUT seconds).
c)
Maximum Protection
– Utmost
priority is on data protection.
– Also requires SYNC redo transport.
– Unlike ‘Maximum Availability’ it does not consider the NET_TIMEOUT parameter, which means If the primary does not receive acknowledgment from a SYNC standby database, it will stall primary and eventually abort it, preventing any unprotected commits from occurring.
– Highly recommended to use a minimum of two SYNC standby databases at different locations if using ‘Maximum Protection’ to have high availability of primary database.
– Also requires SYNC redo transport.
– Unlike ‘Maximum Availability’ it does not consider the NET_TIMEOUT parameter, which means If the primary does not receive acknowledgment from a SYNC standby database, it will stall primary and eventually abort it, preventing any unprotected commits from occurring.
– Highly recommended to use a minimum of two SYNC standby databases at different locations if using ‘Maximum Protection’ to have high availability of primary database.
5) How
to check what protection mode of primary database in your Oracle Data Guard?
By using
following query you can check protection mode of primary database in your
Oracle Data Guard setup.
SQL>
select protection_mode from v$database;
PROTECTION_MODE
——————————–
——————————–
MAXIMUM
PERFORMANCE
6) How
to change protection mode in Oracle Data Guard setup?
By using
following query your can change the protection mode in your primary database
after setting up required value in corresponding LOG_ARCHIVE_DEST_n parameter
in primary database for corresponding standby database.
ALTER
DATABASE SET STANDBY DATABASE TO MAXIMUM [PROTECTION|PERFORMANCE|AVAILABILITY];
Example:
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMUM
PROTECTION;
7) What
are the advantages of using Physical standby database in Oracle Data Guard?
Advantages
of using Physical standby database in Oracle Data Guard are as follows.
§ High Availability.
§ Load balancing
(Backup and Reporting).
§ Data Protection.
§ Disaster Recovery.
8)
What is physical standby database in Oracle Data Guard?
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.
9) What is Logical standby database in
Oracle Data Guard?
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.
10) What is Snapshot standby database in
Oracle Data Guard?
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
proportional to the amount of redo data that needs to be applied.
11) What
are the advantages of Logical standby database in Oracle Data Guard?
§ Better usage of
resource
§ Data Protection
§ High Availability
§ Disaster Recovery
12) What
is Switchover and Failover?
A switchover is
a role reversal between the primary database and one
of its standby databases. A switchover ensures no
data loss. This is typically done for planned maintenance of the primary
system. During a switchover, the primary database transitions to a standby
role, and the standby database transitions to the primary role.
A failover is
when the primary database is unavailable. Failover is performed only in the
event of a failure of the primary database, and the failover results in a transition of a standby database to the
primary role. The database administrator can configure Data Guard to ensure no data loss.
13)
What is data guard in simple language?
Your
primary database is running and you want to reduce downtime because of
unplanned outages. You create a replica of this primary database (termed as
standby database).
You regularly ship redo generated in the primary database to standby database and apply it there. So that is our ‘Data Guard’ standby database and it is in a continuous state of recovery, validating and applying redo to remain in sync with the primary database.
You regularly ship redo generated in the primary database to standby database and apply it there. So that is our ‘Data Guard’ standby database and it is in a continuous state of recovery, validating and applying redo to remain in sync with the primary database.
14) Your standby database was out
of reach because of network issue. How will you synchronize it with primary
database again?
Data
Guard automatically re-synchronizes the standby following network or standby
outages using redo data that has been archived at the primary.
15)
What is Redo Transport Services (RTS)?
This
process takes care of the transmission of redo from a primary database to the
standby database.
Below is
how Redo Transport Services (RTS) works:
1) Log
Network Server (LNS) reads redo information from the redo buffer in SGA of
PRIMARY Database
2) Log Network Server (LNS) passes redo to Oracle Net Services for transmission to the STANDBY database
3) Remote File Server (RFS) records the redo information transmitted by the LNS at the STANDBY database
4) Remote File Server (RFS) writes it to a sequential file called a standby redo log file (SRL) at the STANDBY database
2) Log Network Server (LNS) passes redo to Oracle Net Services for transmission to the STANDBY database
3) Remote File Server (RFS) records the redo information transmitted by the LNS at the STANDBY database
4) Remote File Server (RFS) writes it to a sequential file called a standby redo log file (SRL) at the STANDBY database
** For
multi-standby configuration, the primary database has a separate LNS process
for each standby database.
** Two redo transport methods are supported with the LNS process: synchronous (SYNC) or asynchronous (ASYNC).
** Two redo transport methods are supported with the LNS process: synchronous (SYNC) or asynchronous (ASYNC).
16)
What is the difference between SYNC and ASYNC redo transport method?
Synchronous
transport (SYNC)
Also
known as a “zero data loss” redo transport menthod.
Below is
how it works:
1) Log
Network Server (LNS) reads redo information from the redo buffer in SGA of
PRIMARY Database
2) Log Network Server (LNS) passes redo to Oracle Net Services for transmission to the STANDBY database
3) Remote File Server (RFS) records the redo information transmitted by the LNS at the STANDBY database
4) Remote File Server (RFS) writes it to a sequential file called a standby redo log file (SRL) at the STANDBY database
5) Remote File Server (RFS) transmits an acknowledgement back to the LNS process on the primary database
6) Log Network Server (LNS) notifies the LGWR that transmission is complete on the primary database.
7) Log Writer (LGWR) acknowledges the commit to the user.
2) Log Network Server (LNS) passes redo to Oracle Net Services for transmission to the STANDBY database
3) Remote File Server (RFS) records the redo information transmitted by the LNS at the STANDBY database
4) Remote File Server (RFS) writes it to a sequential file called a standby redo log file (SRL) at the STANDBY database
5) Remote File Server (RFS) transmits an acknowledgement back to the LNS process on the primary database
6) Log Network Server (LNS) notifies the LGWR that transmission is complete on the primary database.
7) Log Writer (LGWR) acknowledges the commit to the user.
Asynchronous
transport (ASYNC)
Unlike
SYNC, Asynchronous transport (ASYNC) eliminates the requirement that the LGWR
wait for acknowledgement from the LNS. This removes the performance impact on
the primary database irrespective of the distance between primary and standby
locations. So if the LNS is unable to keep pace and the log buffer is recycled
before the redo can be transmitted to the standby, the LNS automatically
transitions to reading and sending from the Online Redo logs. Once the LNS is
caught up, it automatically transitions back to reading & sending directly
from the log buffer.
Below is
how it works:
1) Log
Network Server (LNS) reads redo information from the redo buffer in SGA of
PRIMARY Database
2) Log Network Server (LNS) passes redo to Oracle Net Services for transmission to the STANDBY database
3) Remote File Server (RFS) records the redo information transmitted by the LNS at the STANDBY database
4) Remote File Server (RFS) writes it to a sequential file called a standby redo log file (SRL) at the STANDBY database
2) Log Network Server (LNS) passes redo to Oracle Net Services for transmission to the STANDBY database
3) Remote File Server (RFS) records the redo information transmitted by the LNS at the STANDBY database
4) Remote File Server (RFS) writes it to a sequential file called a standby redo log file (SRL) at the STANDBY database
so step
5, 6 & 7 as discussed above for SYNC are not applicable here.
The only
drawback of ASYNC is the increased potential for data loss. Say a failure
destroyed the primary database before any transport lag was reduced to zero,
this means any committed transactions that were a part of the transport lag
will be lost. So it is highly advisable to have enough network bandwidth to
handle peak redo
generation rates when using ASYNC method.
generation rates when using ASYNC method.
17) How
Synchronous transport (SYNC) can impact the primary database performance?
SYNC
guarantees protection for every transaction that the database acknowledges as
having been committed but at the same time LGWR must wait for confirmation that
data is protected at the standby before it can proceed with the next
transaction. It can impact primary database performance and it depends on
factors like
> the
amount of redo information to be written
> available network bandwidth
> round-trip network latency (RTT)
> standby I/O performance writing to the SRL.
> distance betweeen primary and standby databases as network RTT increases with distance.
> available network bandwidth
> round-trip network latency (RTT)
> standby I/O performance writing to the SRL.
> distance betweeen primary and standby databases as network RTT increases with distance.
18)
What is Data Guard’s Automatic Gap Resolution?
Your
database is using ASYNC transport method and the instance load is at the peak.
The LNS is unable to keep pace and the log buffer is recycled before the redo
can be transmitted to the standby, the LNS automatically transitions to reading
and sending from the Online Redo logs. Once the LNS is caught up, it
automatically transitions back to reading & sending directly from the log
buffer.
Now in some cases there can be two or more log
switches before the LNS has completed sending the redo information from online
redo log files and in meantime if any such required online redo log files were
archived then those redo information will be transmitted via Data Guard’s gap
resolution process “Automatic Gap Resolution”.
OR
In some other case when your network or the standby
database is down and your primary system is one busy system, so before the
connection between the primary and standby is restored, a large log file gap
will be formed.
Automatic Gap Resolution will take care of such scenarios by following below action plan:
1) ARCH
process on the primary database continuously ping the standby database during
the outage to determine its status.
2) As soon as the standby is restored, the ARCH ping process queries the standby control file (via its RFS process) to determine the last complete log file that the standby received from the primary database.
3) Data Guard determines which log files are required to resynchronize the standby database and immediately begins transmitting them using additional ARCH processes.
4) LNS process at primary database will also attempt and succeed in making a connection to the standby database and will begin transmitting current redo. So first all the ARCH files are applied and then current redo log.
2) As soon as the standby is restored, the ARCH ping process queries the standby control file (via its RFS process) to determine the last complete log file that the standby received from the primary database.
3) Data Guard determines which log files are required to resynchronize the standby database and immediately begins transmitting them using additional ARCH processes.
4) LNS process at primary database will also attempt and succeed in making a connection to the standby database and will begin transmitting current redo. So first all the ARCH files are applied and then current redo log.
The Data
Guard architecture enables gaps to be resolved quickly using multiple
background ARCH processes
19)
What is the difference between Physical standby and Logical standby database?
Data
Guard Apply process in standby database can apply redo information directly and
in that case it will be called physical standby.
OR It can apply SQL and in that case it will be called Logical standby.
OR It can apply SQL and in that case it will be called Logical standby.
Physical
Standby:
In this
case standby database is an exact, block-by-block, physical replica of the
primary database.
The change vectors received by RFS process are directly applied to the standby database by using media recovery.so here the apply process read data blocks, assemble redo changes from mappings, and then apply redo changes to data blocks directly.
Physical Standby is the best choice for disaster recovery (DR) based upon their simplicity, transparency, high performance, and good data protection.
The change vectors received by RFS process are directly applied to the standby database by using media recovery.so here the apply process read data blocks, assemble redo changes from mappings, and then apply redo changes to data blocks directly.
Physical Standby is the best choice for disaster recovery (DR) based upon their simplicity, transparency, high performance, and good data protection.
Logical
Standby:
In this
case standby database uses SQL Apply method to “mine” the redo by converting it
to logical change records, and then building SQL
transactions and applying SQL to the standby database.
transactions and applying SQL to the standby database.
As this
process of replaying the workload is more complex than the Physical Standby’s
process, so it requires more memory, CPU, and I/O.
One good
advantage here is that a logical standby database can be opened read-write
while SQL Apply is active which means you can update (create/insert/delete etc)
local tables and schemas in the logical standby database.
20) How
is Data Guard Apply process works if primary and secondary database involves
Oracle RAC?
If
Primary database is RAC but standby is Non-RAC:
Each
primary Oracle RAC instance ships its own thread of redo that is merged by the
Data Guard apply process at the standby and applied in SCN order to the standby
database.
If both Primary and standby databases are RAC:
If both Primary and standby databases are RAC:
If the
standby is also an Oracle RAC database, only one instance (the apply instance)
will merge and apply changes to the standby database. If the apply instance
fail for any reason, the apply process will automatically failover to a
surviving instance in the Oracle RAC standby database when using the Data Guard
broker.
21) What is Active Data Guard Option (Oracle Database 11g
Enterprise Edition)?
For
physical standby database, prior to 11g, the database would have to be in the
mount state when media recovery was active which means you were not able to
query the standby database during media recovery stage as there was no
read-consistent view.
Active
Data Guard 11g features solve the read consistency
problem by use of a “query” SCN. The media recovery process on the standby
database will advance the query SCN after all the changes in a transaction have
been applied. The query SCN will appear to user as the CURRENT_SCN column in
the V$DATABASE view on the standby database. So Read-only users will only be
able to see data up to the query SCN, and hence guaranteeing the same read
consistency as the primary database.
This
enables a physical standby database to be open as read-only while media
recovery is active, making it useful for doing read-only workloads.
Also, if
you need read-write access to the standby database, you can use SQL Apply
method of dataguard.
22)
What are the important database parameters related to Data Guard corruption
prevention?
On the
primary database:
a)
DB_ULTRA_SAFE
Values
can be DATA_AND_INDEX or DATA_ONLY. Setting DB_ULTRA_SAFE at the primary will
also automatically set DB_ LOST_WRITE_PROTECT=TYPICAL on the primary database.
In Oracle Database 11g Release 2 (11.2), the primary database automatically attempts to repair the corrupted block in real time by fetching a good version of the same block from a physical standby database.
In Oracle Database 11g Release 2 (11.2), the primary database automatically attempts to repair the corrupted block in real time by fetching a good version of the same block from a physical standby database.
On the standby database:
a)
DB_BLOCK_CHECKSUM=FULL
DB_BLOCK_CHECKSUM
detects redo and data block corruptions and detect corruptions on the primary
database and protect the standby database. This parameter requires minimal CPU
resources.
b)
DB_LOST_WRITE_PROTECT=TYPICAL
A lost write can occur when an I/O subsystem acknowledges the completion of a write, while in fact the write did not occur in persistent storage.
This will create a stale version of the data block. When the DB_LOST_WRITE_PROTECT initialization parameter is set, the database records buffer cache block reads in the redo log, and this information is used to detect lost writes.
A lost write can occur when an I/O subsystem acknowledges the completion of a write, while in fact the write did not occur in persistent storage.
This will create a stale version of the data block. When the DB_LOST_WRITE_PROTECT initialization parameter is set, the database records buffer cache block reads in the redo log, and this information is used to detect lost writes.
You set
DB_LOST_WRITE_PROTECT to TYPICAL in both primary and standby databases.
23)
What is Switchover event?
Switchover
is useful for minimizing downtime during planned maintenance. It is a planned
event in which Data Guard reverses the roles of the primary and a standby
database.
The
primary database runs unaffected while we are making the required changes on
our standby database (e.g. patchset upgrades, full Oracle version upgrades,
etc).
Once changes are complete, production is switched over to the standby site running at the new release.
Once changes are complete, production is switched over to the standby site running at the new release.
This
means regardless of how much time is required to perform planned maintenance,
the only production database downtime is the time required to execute a
switchover, which can be less than 60 seconds
Below operations happens when switchover command is executed:
Below operations happens when switchover command is executed:
1.
primary database is notified that a switchover is about to occur.
2. all users are disconnected from the primary.
3. a special redo record is generated that signals the End Of Redo (EOR).
4. primary database is converted into a standby database.
5. the final EOR record is applied to standby database, this guarantees that no data has been lost, and it converts the standby to the primary role.
2. all users are disconnected from the primary.
3. a special redo record is generated that signals the End Of Redo (EOR).
4. primary database is converted into a standby database.
5. the final EOR record is applied to standby database, this guarantees that no data has been lost, and it converts the standby to the primary role.
24)
What is Failover event?
The
Failover process is similar to switchover event except that the primary
database never has the chance to write an EOR record as this is an unplanned
event.
Whether
or not a failover results in data loss depends upon the Data Guard protection
mode:
a) Maximum Protection >> No Data Loss
b) Maximum Availability >> No Data
Loss (except when there was a previous failure (e.g. a network failure) that
had INTERRUPTED REDO TRANSPORT and allowed the primary database to move ahead
of standby)
c) Maximum Performance (ASYNC) >> may
lose any committed transactions that were not transmitted to the standby
database before the primary database failed.
Failover
event can be of two types:
1)
Manual
Administrator
have complete control of primary-standby role transitions. It can lengthen the
outage by the amount of time required for the administrator to be notified and
manual execution of command.
2) Automatic
It uses
Data Guard’s Fast-Start Failover feature which automatically detects the
failure, evaluates the status of the Data Guard configuration, and, if
appropriate, executes the failover to a previously chosen standby database.
25) Which tools can be used for
Data Guard Management?
1)
SQL*Plus – traditional method, can prove most tedious to use
2) Data Guard broker – automates and centralizes the creation, maintenance, and monitoring of a Data Guard configuration. Simplifies and automates many administrative
tasks. It has its own command line (DGMGRL) and syntax.
3) Enterprise Manager – requires that the Data Guard broker be enabled. a GUI to the Data Guard broker, replacing the DGMGRL command line and interfacing directly with the broker’s monitor processes.
2) Data Guard broker – automates and centralizes the creation, maintenance, and monitoring of a Data Guard configuration. Simplifies and automates many administrative
tasks. It has its own command line (DGMGRL) and syntax.
3) Enterprise Manager – requires that the Data Guard broker be enabled. a GUI to the Data Guard broker, replacing the DGMGRL command line and interfacing directly with the broker’s monitor processes.
26)
What is Data Guard 11g snapshot standby?
With 11g,
you can thoroughly test your changes on a true replica of your production
system and database using actual production workload.
Data Guard 11g physical standby can now be converted to a snapshot standby, independent of the primary database, that is open read-write and able to be used for preproduction testing. It uses Flashback Database and sets a guaranteed restore point (GRP) at the SCN before the standby was open read-write.
Data Guard 11g physical standby can now be converted to a snapshot standby, independent of the primary database, that is open read-write and able to be used for preproduction testing. It uses Flashback Database and sets a guaranteed restore point (GRP) at the SCN before the standby was open read-write.
NOTE:
Primary database redo continues to be shipped to a snapshot standby, and while
not applied, it is archived for later use.
You can
convert this snapshot database back into a synchronized physical standby
database when testing is complete. Redo Apply process at standby will take care
that all
primary database redo archived while a snapshot standby is applied until it is caught up with the primary database.
primary database redo archived while a snapshot standby is applied until it is caught up with the primary database.
27)
What is the difference between Recovery Point Objective(RPO) and Recovery Time
Objective (RTO)?
A)
Recovery Point Objective(RPO)
RPO
concerns with data. It is the amount of data you are willing to lose when the
failure occurs in your database system. Usually people define data loss in
terms of time, so possible values can be 5 seconds of data loss, 2 hours of
data loss etc.
Remember
that each standby database has its own set of attributes and parameters. It
means you can mix zero data loss standby databases with minimal data loss
standby
databases in the same Data Guard configuration
databases in the same Data Guard configuration
If you have decided that
you want to implement zero data loss strategy, then you should really focus on
Networks and Data Loss
B)
Recovery Time Objective (RTO)
RTO is
defined as how fast you can get back up and running (whereas RPO is concerned
with data loss)
So with
your RPO strategy you lost say only about 6 seconds of data as you committed to
your client but with RTO you need to formulate how fast clients can connect
back to the database system after the data loss has occurred.
28)
What are Standby Redo Log (SRL) files?
The SRL
files are where the Remote File Server (RFS) process at your standby database
writes the incoming redo so that it is persistent on disk for recovery. SRL
files are important for better redo transport performance and data protection.
SRL are
MUST in Maximum Availability or Maximum Protection mode and OPTIONAL (but
recommended) in Maximum Performance mode.
If there
are no Standby Redo Log (SRL) files, then at each log switch in the primary
database, the RFS process on the standby database that is serving an
asynchronous standby destination has to create an archive log of the right
size. While the RFS is busy doing creating the archive log file, the LNS
process at the primary database has to wait, getting further and further behind
the LGWR (in case of Maximum Performance mode). That is why it recommended to
have Standby Redo Log (SRL) files in Maximum Performance mode also.
We
generally configure them on our primary database as well in preparation for a
role transition b/w primary-standby.
Also, do
not multiplex SRLs. Since Data Guard will immediately request a new copy of the
archive log if an SRL file fails, there is no real need to have more than one
copy of each.
Active Data Guard - Answers to
Frequently Asked Questions
The Active Data Guard Option is an evolution of Data Guard technology that incorporates significant innovation (multiple patents pending) designed for a specific purpose - to improve production database performance for critical transactions. Active Data Guard enables read-only access to a physical standby database while Redo Apply is active. Queries and reports can be offloaded from the production system to a synchronized physical standby database - all queries at the standby database return up-to-date results. An Active Data Guard Option license must be purchased in addition to Oracle Enterprise Edition in order to utilize these new capabilities.
Active Data Guard and Oracle Data Guard 11g are related technologies, each having a different area of focus. Oracle Data Guard provides a comprehensive set of capabilities for data availability and protection that are included with Oracle Database Enterprise Edition.
Licensing requirements for Active Data Guard and Oracle Data Guard 11g features are summarized in the following table:
The Active Data Guard Option is an evolution of Data Guard technology that incorporates significant innovation (multiple patents pending) designed for a specific purpose - to improve production database performance for critical transactions. Active Data Guard enables read-only access to a physical standby database while Redo Apply is active. Queries and reports can be offloaded from the production system to a synchronized physical standby database - all queries at the standby database return up-to-date results. An Active Data Guard Option license must be purchased in addition to Oracle Enterprise Edition in order to utilize these new capabilities.
Active Data Guard and Oracle Data Guard 11g are related technologies, each having a different area of focus. Oracle Data Guard provides a comprehensive set of capabilities for data availability and protection that are included with Oracle Database Enterprise Edition.
Licensing requirements for Active Data Guard and Oracle Data Guard 11g features are summarized in the following table:
|
Capabilities and corresponding license requirements
|
Oracle Enterprise Edition 11g
|
Active Data Guard Option
|
Advanced Compression Option
|
|
All Data Guard 10g features
|
X
|
||
|
New Data Guard 11g features (excludes Active Data
Guard and Advanced Compression features)
|
X
|
||
|
Real-time Query, enables a physical standby to be
open read-only while Redo Apply is active
|
X
|
||
|
The ability to enable RMAN block change tracking on
a physical standby database
|
X
|
||
|
Data Guard Redo Transport compression
|
X
|
Additional frequently asked questions include:
Must I purchase Active Data
Guard if I am not using Real-time Query or RMAN block change tracking on my
standby database?
No. An Oracle Database Enterprise Edition license is the only license required to use Data Guard features other than those explicitly included with the Active Data Guard Option as described in the table above.
No. An Oracle Database Enterprise Edition license is the only license required to use Data Guard features other than those explicitly included with the Active Data Guard Option as described in the table above.
I am already using Data
Guard 10g, do I need to purchase Active Data Guard when I upgrade to Oracle
Database 11g ?
No - as long as you do not enable the Real-time Query feature or RMAN block change tracking on your physical standby database. Thus your physical standby database could be open read-only, but it cannot be applying redo at the same time. Similarly, you can perform RMAN incremental backups your physical standby, but you cannot perform fast RMAN incremental backups using RMAN block change tracking. You must only purchase the Active Data Guard Option if you wish to use either or both of these features.
No - as long as you do not enable the Real-time Query feature or RMAN block change tracking on your physical standby database. Thus your physical standby database could be open read-only, but it cannot be applying redo at the same time. Similarly, you can perform RMAN incremental backups your physical standby, but you cannot perform fast RMAN incremental backups using RMAN block change tracking. You must only purchase the Active Data Guard Option if you wish to use either or both of these features.
Separate from Active Data Guard - Oracle states that
Data Guard 11g continues to be an included feature of Oracle Enterprise
Edition. What are the new Data Guard features that are included in Data
Guard 11g?
Data Guard 11g has many new features that enhance its
value for data protection and availability, and just as with
previous Data Guard releases, these new features are included with Oracle
Database Enterprise Edition at no extra charge.
I thought a Data Guard
physical standby could always be opened read-only and/or used for incremental
backups - why do I need the Active Data Guard Option ?
Previous capabilities did not allow Redo Apply to be active while a physical standby database was open read-only, and did not enable RMAN block change tracking on the standby database. This resulted in (a) read-only access to data that was frozen as of the time that the standby database was opened read-only, (b) failover and switchover operations that could take longer to complete due to the backlog of redo data that would need to be applied, and (c) incremental backups that could take up to 20x longer to complete - even on a database with a moderate rate of change. Previous capabilities are still included with Oracle Data Guard 11g, no additional license is required to use previous capabilities.
Previous capabilities did not allow Redo Apply to be active while a physical standby database was open read-only, and did not enable RMAN block change tracking on the standby database. This resulted in (a) read-only access to data that was frozen as of the time that the standby database was opened read-only, (b) failover and switchover operations that could take longer to complete due to the backlog of redo data that would need to be applied, and (c) incremental backups that could take up to 20x longer to complete - even on a database with a moderate rate of change. Previous capabilities are still included with Oracle Data Guard 11g, no additional license is required to use previous capabilities.
Why would I use Active Data
Guard and not just add another node to my primary Oracle RAC cluster to enhance
performance ?
Oracle RAC offers many advantages for scalability and high availability that are well understood and embraced by thousands of Oracle customers. Active Data Guard is designed to address a different requirement where customers wish to physically isolate the overhead of processing ad-hoc queries and reports from their OLTP system by using a completely independent, synchronized replica of the production database. If the customer requirement can be addressed using read-only access to an up-to-date replica of the production database, then Active Data Guard is an ideal solution.
Oracle RAC offers many advantages for scalability and high availability that are well understood and embraced by thousands of Oracle customers. Active Data Guard is designed to address a different requirement where customers wish to physically isolate the overhead of processing ad-hoc queries and reports from their OLTP system by using a completely independent, synchronized replica of the production database. If the customer requirement can be addressed using read-only access to an up-to-date replica of the production database, then Active Data Guard is an ideal solution.
Why would I use Active Data
Guard and not simply use SQL Apply (logical standby) that is included with Data
Guard 11g ?
If read-only access satisfies the requirement - Active Data Guard is a closer fit for the requirement, and therefore is much easier to implement than any other approach. Active Data Guard supports all datatypes and is very simple to implement. An Active Data Guard replica can also easily support additional uses - offloading backups from the primary database, serve as an open read-write test system during off-peak hours (Snapshot Standby), and provide an exact copy of the production database for disaster recovery - fully utilizing standby servers, storage and software while in standby role.
If read-only access satisfies the requirement - Active Data Guard is a closer fit for the requirement, and therefore is much easier to implement than any other approach. Active Data Guard supports all datatypes and is very simple to implement. An Active Data Guard replica can also easily support additional uses - offloading backups from the primary database, serve as an open read-write test system during off-peak hours (Snapshot Standby), and provide an exact copy of the production database for disaster recovery - fully utilizing standby servers, storage and software while in standby role.
With the availability of Active Data Guard, what role
does SQL Apply (logical standby) continue to play?
Use SQL Apply for the following requirements: (a) when you require read-write access to a synchronized standby database but do not modify primary data, (b) when you wish to add local tables to the standby database that can also be updated, or (c) when you wish to create additional indexes to optimize read performance. The ability to handle local writes makes SQL Apply better suited to packaged reporting applications that often require write access to local tables that exist only at the target database. SQL Apply also provides rolling upgrade capability for patch sets and major database releases. This rolling upgrade functionality can also be used by physical standby databases beginning with Oracle 11g using Transient Logical Standby.
Use SQL Apply for the following requirements: (a) when you require read-write access to a synchronized standby database but do not modify primary data, (b) when you wish to add local tables to the standby database that can also be updated, or (c) when you wish to create additional indexes to optimize read performance. The ability to handle local writes makes SQL Apply better suited to packaged reporting applications that often require write access to local tables that exist only at the target database. SQL Apply also provides rolling upgrade capability for patch sets and major database releases. This rolling upgrade functionality can also be used by physical standby databases beginning with Oracle 11g using Transient Logical Standby.
My reporting application makes
some temporary writes which require read-write access to the standby database,
even though the writes do not modify primary data. How can I use it with Active
Data Guard?
Active Data Guard does not support any writes to the physical standby database. That said, it is possible that limited writes needed by the reporting application can be directed back to the primary database or to a local database that is on the same server as the standby database, using Oracle database links. For further details, refer to the Active Data Guard best practices paper on the MAA OTN site.
Active Data Guard does not support any writes to the physical standby database. That said, it is possible that limited writes needed by the reporting application can be directed back to the primary database or to a local database that is on the same server as the standby database, using Oracle database links. For further details, refer to the Active Data Guard best practices paper on the MAA OTN site.
How do I collect stats from
an Active Data Guard replica given that it is open read-only ?
This is described in Metalink Note 454848.1 that details installation and usage of standby statspack.
This is described in Metalink Note 454848.1 that details installation and usage of standby statspack.
Post a Comment: