Database Reference
In-Depth Information
Block corruption in a Data Guard environment can automatically be repaired
The previously mentioned Far Sync Standby configuration about which you will read
later in the chapter requires Active Data Guard. So do related technologies.
There are other features that depend on Active Data Guard but they do not directly
relate to this discussion.
Please refer to the licensing guide for more information
Active Data Guard can also be used as a scalability tool for web-based content. Multiple standby databases
opened read-only, with the Active Data Guard option enabled can provide real-time data access to web servers. This
significantly scales data access. Updates to the data occur only on the primary database through a controlled user
interface, and changes are immediately propagated to the reader farm through Real-Time Query.
Data protection modes
Data Guard offers three different data protection modes. Depending on the business requirements, Data Guard can
be set up for maximum performance without affecting the operation of the primary database; alternatively, it can be
set up to ensure zero data loss. There are advantages and disadvantages to all three options.
Maximum Protection Mode
This mode provides the highest level of protection from data loss, ensuring that there will be no data lost should the
primary database experience an unplanned outage. To achieve this level of protection, the standby database has to
acknowledge that the redo generated by a transaction on the primary has been written into its standby redo logs (this
is of course in addition to the primary database's online redo logs) before the transaction can be committed on the
primary. If the primary database can't write to the designated standby database's SRLs, it will shut down. If it didn't
the configuration could not guarantee zero data loss. Obtaining this zero data loss guarantee comes at a price: the
application's commit time can increase compared to a different protection mode proportionally to the network round
trip time, and the primary database may shut down as a consequence of a network problem.
For exactly this reason the Maximum Protection Mode can potentially do more harm than good. Environments
where an RPO of 0 is required usually need a protection mode similar to Maximum Protection, but as you read
earlier these environments tend to have their own dedicated hardware and storage. If you are considering the use of
Maximum Protection Mode you should have multiple standby databases as destinations for your redo on different
networks each with its own hardware. Otherwise you run a high risk that the primary database shuts down! An
implementation of Maximum Protection Mode is therefore out of the scope of this chapter.
Maximum Performance mode
This mode dictates that the performance and availability of the primary database are not affected by the standby
database. The default protection mode, maximum performance, has no redo write dependency between the primary
and standby databases; in other words, the primary database commits transactions independently of the standby
database. Because of this, many businesses introduce regular, forced log switches on the primary database using the
archive_lag_target initialization parameter.
Maximum Performance can still help you work towards a low Recovery Point Objective by employing Real Time
Apply on the standby database. Using this protection mode your primary and standby database(s) usually are in an
asynchronous configuration.
 
Search WWH ::




Custom Search