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
BD. Physical standby will not allow you to run tests (which will usually require INSERT/UPDATE operstions).
That is not correct, as a physical can be set to “snapshot standby database” and reverted by to “physical standby database” with minimal efort (just a command end enough space)
Oracle 12c has “SNAPSHOT STANDBY DATABASE” option available for physical standby. This would allow the DBA to put the physical standby into this mode and allow developers to test on a read/write version of production. During this time, arch redo files are still transported to standby but not applied. Once testing is completed, the DBA can flashback the standby DB and it can resume as an active physical standby again.
Allowing write access on a logical standby database to production data is not anywhere near as easily recoverable and can easily invalidate the DB as being a valid standby. It would require a full recovery to be considered a “production copy standby” – during which time production data loss can not be guaranteed.
Therefore, from the requirements given, if we want to achieve all of this with only a single standby instance it should be in state “C” most of the time (satisfies requirement 1 and 3) and can be converted into state “B” as required (satisfies requirement 1 and 2).
I believe given answer of BC is correct.
Correct: B,D – two standby DB’s, one logical and one phyisical standby.
Requirements 2 & 3 eliminates solution B,C.
Third requirement is satisfied by ‘B’.
Second requirement can’t be satisfied by ‘C’ if the database **at the same time** should be used for other purposes.
As usual insufficient definition of task leads to different interpretations.
For testing (“3”), there should be a Physical Standby Database, and it should be converted to Snapshot Standby Database, and then back to Physical Standby Database
Also note that Oracle recomends having more that one Standby Database, if a Physical is converted to Snapshot, as no Disaster Recovery is available while the Physical is set as a Snapshot.
https://docs.oracle.com/database/121/SBYDB/manage_ps.htm#SBYDB4801
For generating reports (“2”), either physical or logical would do, but the remaining phrase (“used for other purposes”) would imply a Logical Standby Database (only minor DML would be acceptable in a Physical)
For recovering with Zero Data Loss (“1”) either we have syncronous transport (and preferably apply – SYNC AND AFFIRM) or Real Time Query (which implies data in both ends are equal)
SO:
B & D would be my answers
C,D would be correct.
C for a physical standby.
D for a logical standby.
I think that is about two distinct solutions not about a conjugation of two solutions!
I think that is:
A – This is not true! A Far Sync instance is only necessary for a large distance or a network with no bandwidth or a bad performance.
B – This is correct! This permit a zero data loss disaster recovery (1); This permit to run a report (2) in the state of “snapshot standby database”, not recommended (because a delay or gap) but, this is possible and they can run the report in the production yet. If the others purpose in this question is “disaster recovery”, they complete this requirement.
C – This is correct! This permit a zero data loss disaster recovery (1); This permit to run a report (2) in your state, this is possible and they can run the report in the production when this database is converted to “snapshot standby database” for tests.
D – This is not true! A logical standby database does not permit a test like in production, the replicated schema is in a read-only state.
E – This is wrong! This is a replica of a production database and doesn’t can be used by developers to change data in production;
Someone else?
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.
Chunn could you please share with me your mail or Facebook account i need to contact you very urgent to discuss some points clearly.
I think is C and D
C – Physical Standby that can be converted to Snapshot
D- Logical Standby for reports and “other purposes”