hmmnn....nice explanation dear....sounds similar to log miner...where u can
see all the process being done on the database and you can audit which
table was being modified by what user and report some fraudulent tampering
of data Ok I try read it and give it a test....hhmmn i hope i wont be
able to sleep
Wasn't trying to do that. It's clear you have Jen eating from your hand.
hmmm... I believe that includes you, and boris, and some of us here.
Anyway, for the Oracle Streams which boris mentioned, from what I know
the improvement was more in AQ(Advance Queueing), I remember problems using AQs in 9i/10g
where in queued process sometimes can't continue when let's say the db server gets down abnormally
and restarted. Then most of the recomendation was to use Streams specially
when the version is already in 10g. And from what I've read from Tamil, Streams are not yet stable
if you are going to use it specifically for Replication.
Hi all....yes, I got what u meant now .
While I am testing our replication set-up I noticed that when the network
connection is broken(long enough) or the server is down. I got "BROKEN" status in my refresh group, and It does not automatically go back to "NORMAL"
status even when the connection is already GOOD. So, you have to manually
refresh it using OEM. and if u have a critical data that need to be replicated
immediately then u have to check the status often.
Did you encounter the same problem?
I thinking of a OS scheduled script the will check every minute if the refresh group is "BROKEN" then it will run the progem like this :
Well, it's like that
Replication tries to propagate changes. If that fails, rep tries it again say after 1 sec. If it fails again, it tries after 2 sec.If it fails again, it tries after 4 sec and so on, until a treshold is reached (don't remember but after several tries)
Then the rep gives up, marks the job broken and never tries again. Here u should manually restart the process when everything is fine again