...
This option is ideal for companies that are using Oracle Standard Edition (SE,SE1, SE2) where they would like to have a "database that is read-only/read-write , but also being kept up to date" - we are not talking logical real-time replication here, but using an actual standby database to create a "logical container" consisting out of 2 or more (up to 4) read-only snapshots of a standby database at a time interval. In short, a snapshot is created and it is opened read-only, then the listener on the system is updated with a new service that points to this latest read-only snapshot. Then at a time interval, the next snapshot is created, opened read-only and the listener service is updated to point to this latest one. This process continues and the oldest snapshot is removed once the limit set (2,3 or 4) is reached. The effect that this creates is a logical database that is perceived to be updated. This is due to the standby (or cascading standby) database being updated on a regular basis. This is perfect for companies that need to run reports or data extractions on a regular basis.
...
The server in which snapshots are running has the following
...
Test/Dev Snapshots
The test/dev snapshots are single snapshots that can be used for reporting/testing purposes. These snapshots can also be used for DR testing purposes. The single snapshots can be retained based on the space available in the logical volume as the space occupied by the snapshots can increase based on the test/development happening on the database and also compensate for the changes happening in the DR database due to archivelogs being applied on the standby.
...
The settings for a Test/Dev Snapshot are largely the same as those used for Reporting Replicas (discussed above).
...