A customer asks you to propose the most appropriate solution for this set of requirements:
1. We need a disaster recovery solution that enables us to fail over from our production database with zero
data loss.
2. We want to generate reports from the proposed standby database at the same time that it is used for other
purposes.
3. Developers may need to test occasionally on a copy of the live database.
You have to already confirmed that there are no unsupported data types on the primary database.
Which two solutions would you recommend?
A.
a remote physical standby database with RedoRoutes via a far sync instance
B.
a snapshot standby database with synchronous redo transport
C.
a physical standby database with real-time query enabled
D.
a logical standby database
E.
a read mostly implementation of a physical standby database
Correct Ans: D, E
Here there are no unsupported data types on the primary database so the Logical standby would be appropriate option in this case to run reports against (you can still enable synchronous redo transport) and can use other purposes. You cal also set GUARD to protect the logical standby to restrict changes if needed.
Read mostly implementation of a physical standby database would provide minimal changes to the physical standby via database links to primary at the same time since it is a Physical Standby you can convert to Snapshot standby to test with live copy of production.
Leaving a snapshot standby database in your configuration with synchronous redo transport is not an appropriate solution since it will blowup your FRA and not feasible.
If it is just a physical standby with real-time query will provide reporting solution but may not be a right choice in this specific requirement.
Benefits of Implementing a Logical Standby Database:
– Provides an efficient use of system resources
– Open, independent, and active production database
– Additional indexes and materialized views can be created for improved query performance
– Reduces workload on the primary database by offloading the following workloads to a –
logical standby database: – Reporting– Summations – Queries
Read-Mostly Applications:
– Reporting applications that are predominantly read-only, but require limited read-write database access are referred to as “read-mostly” applications. Active Data Guard enables a standby database to support the read-only portion of read-mostly applications if writes are redirected to the primary database or a local database.