A Data Guard environment has this configuration and these attributes:
1. The primary database prima is in the local region.
2. A physical standby database physt1 is in the local region.
3. A physical standby database physt2 is in a remote region.
4. The primary ships redo to physt1.
5. physt1 ships redo physt2.
6. physt1 and physt2 have Real-Time Query enabled.
A sequence has been created with this SQL statement in the primary database:
CREATE SEQUENCE a NOCACHE SESSION:
Which two statements are true?
A.
The sequence is usable on physt1 and physt2.
B.
The sequence is usable on physt1 but not usable on physt2.
C.
The sequence is usable on physt2 if physt1 becomes unavailable, but only if an alternative redo destination has been configured on the primary database.
D.
physt2 will no longer receive redo if physt1 becomes unavailable, unless LOG_ARCHIVE_DEST_n has the ALTERNATE attribute specified on the primary
database.
E.
physt2 will no longer receive redo if physt1 becomes unavailable, unless LOG_ARCHIVE_DEST_n has the ALTERNATE attribute specified on physt1.
Explanation:
Note: LOG_ARCHIVE_DEST_n specifies an alternate archiving destination to be used when the original destination fails.
The ALTERNATE attribute is optional. If an alternate destination is not specified, then redo transport services do not automatically change to another destination if
the original destination fails.https://docs.oracle.com/cd/B28359_01/server.111/b28294/log_arch_dest_param.htm
https://docs.oracle.com/database/121/SQLRF/statements_6017.htm#SQLRF01314
Incorrect!
https://docs.oracle.com/database/121/SBYDB/manage_ps.htm#SBYDB5164
Sequences created with the ORDER or NOCACHE options cannot be accessed on an Oracle Active Data Guard standby.
Wim J – you are actually incorrect. When NOCACHE is specified on a SESSION sequence, you do not get a syntax error – but the clause is ignored. Therefore, this is a little bit of a trick question.
From your own provided link:
“Session sequences support most of the sequence properties that are specified when the sequence is defined. However, the CACHE/NOCACHE and ORDER/NOORDER options are not relevant to session sequences and are ignored.
Session sequences must be created by a read/write database but can be accessed on any read/write or read-only databases (either a regular database temporarily open read-only or a standby database).”
Correct: A,C,D
Session sequences support most of the sequence properties that are specified when the sequence is defined. However, the CACHE/NOCACHE and ORDER/NOORDER options are not relevant to session sequences and are **ignored**.
Using Sequences in Oracle Active Data Guard:
In an Oracle Active Data Guard environment, sequences created by the primary database with the default CACHE and NOORDER options can be accessed from standby databases as well.
Also, the terminal standby should have a LOG_ARCHIVE_DEST_n parameter defined that points back to the primary.
Sequences created with the ORDER or NOCACHE options cannot be accessed on an Oracle Active Data Guard standby.
Hi,
Bear in mind that is a SESSION SEQUENCE, that is, its values are only visibles in the session of the primary database that creates it. That doesn’t mind that you can use the sequence as an object (ie, not values generated in primary) from any standby with Real Time query enabled, althoug standby is a cascaded standby. Hence C is invalid.
E is valid by definition
K. rgds
i’m a bit confused by the comments here… please correct me if I’m wrong:
the first 3 options are regarding a sequence, and since it’s a session sequence, it’s valid on all standby’s -> A
D & E are about redo transport… and E makes no sense, since it doesn’t matter what kind of konfiguration a standby has when it’s not availeble -> D
A, D
For all that’s been written (usability of SESSION sequences, log shipping)
A,D
A,D
A and D are correct.
Dont confuse Session sequences with Global sequences. The requirement of CACHE, NOORDER is for GLobal sequences.