Streams with DataGuard design advice

Question

I have two 10gR2 RAC installs with DataGuard physical copy mode. We will call the main system A and the standby system B. I have a third 10gR2 RAC install with two-way Streams Replication to system A. We will call this RAC system C.
When I have a failure scenario with system A, planned or unplanned, I need for system C's Streams Replication to start replicating with system B. When the system A is available again I need for system C to start replicating with system A again.
I am sure this is possible, and I am not the only one that wants to do something like this, but how? What are the pitfals?
Any advice on personal experience with this would be greatly appreciated!

Answer 1

Nice concept and I can only applaud to its ambitions.
+"I am sure this is possible, and I am not the only one that wants to do something like this".+
I would like to share your confidence, but i am afraid there are so many pitfalls than success will depends on how much pain you and you hierarchy can cope with.
Some thoughts:
Unless your dataguard is Synchronous, at the very moment where A fails, there will be missing TXN in C,
which may have been applied in B as Streams is quite fast. This alone tells us that a forced switch cannot
be guarantee consistent : You will have errors and some nasty one such as sequence numbers consumed
on A (or B) just before the crash, already replicated to B (or A)but never shipped to C. Upon awake C will
re-emit values already known on B (dup key on index?)
I hope you don't sell airplane ticket for in such a case you can sell some seats twice.
Does C have to appear as another A or is it allowed to have a different DB_NAME? (How will you set C in B?
is C another A which retakes A name or is C a distinct source).if C must have the same DB_NAME, the global
name must be the same. Your TNS construction will be have to cope with 2 identical TNS entry in your network
referring to 2 different hosts and DB. Possible with cascade lines at (ADDRESSES= ... , but to be tested.
If C is another A then C must have the same DB_name as LCR do have their origin DB name into them.
If C has a distinct name from A it must have its on apply process, not a problem it will be idle while A is alive,
but also a capture that capture nothing while A is alive, for it is Capture site who is supposed to send the ticks
to advance counters on B. Since C will be down in normal time, you will have to emulate this feature periodically
reseting the first_scn manually for this standby capture - you can jump archives providing you jump to another
archive with built in data dictionary - or accept to create a capture on B only when C wakes up. The best would
be to consider C as a copy of B (multi-master DML+DDL?) and re-instantiate tables without transferring any data
the apply and capture on C and B to whatever SCN is found to be max on both sites when C wakes up.
All this is possible, with lot of fun and hard work.
As of the return of the Jedi, I mean A after its recovered from its crash you did not tell us if the re-sync C-->A
is hot or cold. Cold is trivial but If it is hot, it can be done configuring a downstream capture from C to A with
the init SCN set to around the crash and re-load all archives produced on C. But then C and A must have a different
DB_name or maybe setting a different TAG will be enough, to be tested. Also there will be the critical switch
the multi-master replication C<-->B to A<-->B. This alone is a master piece of re-sync tables.
In all cases, I wish you a happy and great project and eager to hear about it.
Last, there was a PDF describing how to deal with dataguard switch with a DB using streams, but it is of little help,
for it assumes that the switch is gentle : no SCN missing. did not found it but maybe somebody can point a link to it.
Regards,
Bernard Polarski