Question about Standby Concept

I'm reading Oracle docs that talk about the various configuration of standby dbs.

One setup it talks about is manually applying archive logs (versus managed, where it applies logs continuesly and automatically). One benefit it states for doing it in this manner is to protect from data corruption. In a situation where the primary database has become corrupted, the standby would still be intact because you have not yet applied the archive logs and would be able to activate the standby (unaffected by the corruption on the primary)

My question is, does anyone know if they are talking about corruption as in data FILE corruption (at the bit level) OR are they talking about data corruption where records or data were inadvertently changed/deleted, etc....

My common sense tells me corruption at the bit level on the primary database would have NO affect the standby because the standby applies changes to itself in a LOGICAL manner, meaning it applies the transactions, not copy physical media to itself....(except for the actual archive logs it needs to apply transactions from)

Can anyone confirm this??

Manually applying redo logs to prevent corruption is a hedge against 'logical' corruption, ie some user deleting, updating, or truncating something they shouldn't have. From a bit-level perspective there is no difference between manual and automatic application of redo logs.

Based on what you said, my assumptions would be correct. But what erks me is that the Oracle Doc makes a clear differentiation between what is a data corruptions and what is user transaction error (ie, inadventent changes to records).

Well...I'll just have to go by what my common sense tells me and what others (like you) agree on. Thanks.

Quote:

---

Originally posted by dbbyleo

My common sense tells me corruption at the bit level on the primary database would have NO affect the standby because the standby applies changes to itself in a LOGICAL manner, meaning it applies the transactions, not copy physical media to itself....(except for the actual archive logs it needs to apply transactions from)

---

Your common sense fares you well young padowan!! :o)

Basically, what Oracle are getting at is that the delaying of the application of logs by implementing a manual process allows you to correct a user error before it gets applied at the standby site.
There are various ways of setting up the 'managed' standby database, but some configurations mean that the transactions are immediately applied at the standby site, before being committed locally. In this situation any user error is propagated.
In my mind, you would correct it locally, and this correction would then be propogated across again!!
The main purpose of a standby site would generally be disaster recovery, in which case you want it as up to date as possible.

Brgds,

Andy

yup.. on my side.. we need to ensure that the archive logs are applied to both databases...

and if not, had to manually syncrhonize them

If you want your standby to help you protect from human error/logical corruption, you should delay your standby recovery, eg ,for several hours. Managed standby database also can help you do this.
Unix cron managed (that is, oracle manual recovery) can also do this.

For physical corruption, if the corruption happenes to datafiles only, standby can protect you from standby also corruption. If corruption happenes to logfile/archivelog, then standby also affect. It is useless and you have to refresh your standby db.

recover standby database

and recover managed standby database.

the difference between the two statements is that the second one will automatically applied the archive logs?