3 followers Follow

DBVISIT Standby and Data file / block corruption


We would like to know how the DBVIST Standby handles corruption at block / data file level?

If the  primary database suffers from block corruption (logical or physical) and the database crashes how would that impact the DBVISIT standby?



Kamran Irshad Answered

Official comment


To best explain the question, we have to know what the difference is between logical corruption and physical corruption.

Logical is data corruption. For example nologging operations are performed on primary with end result no redo to recover standby database. You end up with logical corruption on standby. This can be normal operations during batch jobs / staging tables etc where nologging is used, so if the standby has logical corruption on these tables that is fine, it can be recreated. If a user by mistake update data on primary and it filters through to standby, which is also a form of logical corruption, we cannot control that.

Standby use archive logs to recover the standby database so if the primary is corrupt on a physical blocks then the archive logs will most likely not apply to the standby and stop there, oracle will not allow us to apply any archive log , if its corrupt.


The user can schedule dbverify checks on the database at any time outside the Standby product to add additional checks, or use RMAN scripts to do some validation checks.

Charmaigne Bezuidenhout
Comment actions Permalink

Please sign in to leave a comment.

1 comment