Currently, I synchronize the standby database from primary database by copying archive logs from primary server to the secondary server. I do this activity daily. I have heard that there are automated process for this are available.

But the problem is that, the primary data gets corrupted, then the same will be replicated to the secondary standby database. This will make the standby database of no use.

Is there any way of automated process so that only the data to be synchronized to the standby database which is not corrupted in the primary database ?


  • 1
    Standard or Enterprise Edition? By corrupt data, do you mean logical corruption? – Balazs Papp Jul 2 '15 at 8:42

No. This is not possible. There are various options that might help you recover from this situation or even prevent it from happening in the first place though.

Think about it like this: how do you determine when the "data gets corrupted"?

Imagine that you could decode and scan through the archived redo logs, before they get shipped to the standby. How would you determine what caused any "corruption" without knowledge of the database structure, contents of the tables and such?

Some options are:

  1. Set a delay on your standby receiving the data. If a logical (data) corruption is discovered during this window, stop the redo being shipped to the standby so it doesn't get affected.

  2. Set up flashback on either the primary or standby databases for an appropriate period. If a logical corruption is detected during this time, you may be able to recover using flashback query or flashback database - but it won't be easy if it's discovered a long time after.

  3. Set the database up so that logical corruptions are impossible/difficult to manage without intentionally introducing them. e.g. referential integrity, correct data types and c.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.