A snapshot standby database is created from physical standby database. Once we create a snapshot standby database it continues to receive redo log from primary database and archive the redo logs but it does not apply redo log or archived redo log to the snapshot standby database.
Redo data received from the primary database is applied when a snapshot standby database is converted back into a physical standby database, after discarding all local updates to the snapshot standby database.
A snapshot standby database typically diverges from its primary database over time because redo data from the primary database is not applied as it is received. As once we create snapshot standby database in READ WRITE mode then we can update the database locally, so local updates to the snapshot standby database will cause additional divergence. The data in the primary database is fully protected however, because a snapshot standby can be converted back into a physical standby database at any time, and the redo data received from the primary will then be applied.
The snapshot standby database provide the following benefits:
1. Generate a test/dev database which is in READ WRITE mode. Updating this snapshot standby database will not impact production database, and when refreshing the snapshot, it can get the up-to-date data from production database.
2. Backing up the physical standby database. SInce the physical standby database is a backup copy of production database, the snapshot standby database can provide recovery for both physical standby and production database.
In case that your test/dev environment is under heavy workload, lots of the objects are updated, when you want to convert the snapshot standby database to physical standby database, it will take long time to flashback database to the original restore point. And then all unapplied redo logs need to be applied, also takes long time.
Thanks for your advice, Neil! Yes, it will take long time for reincarnation, any impact on discover of corrupted archived redo logs?
With a READ/WRITE standby database mode, redo logs are still received at the standby site, but will not be applied until physical standby mode is restored. So when the unapplied redo logs on standby site are corrupted and primary database is unavailable, the reincarnation will not be possible unless those logs can be recovered from some other source.