In DCT, policies at the group level influence all contained objects across any connected CD engine. For unique requirements within a group, set the group-level policies initially, then apply object-specific policies.

SnapSync policy

SnapSync policies dictate the frequency of source database snapshots. The default SnapSync policy schedules daily snapshots at 3:30 AM local time, with a four-hour completion window. If SnapSync fails to complete in this timeframe, it will attempt again at the next scheduled time. Modify the default policy by clicking the Edit icon or create new ones by clicking Add. Policies can be tailored using the Schedule date picker, by Interval, or with a `cron` expression.

SnapShot policy

Retention policy

The Retention policy determines the duration for keeping snapshots and log files, which are essential for rewinding or provisioning objects. Snapshot retention must be at least as long as log retention. Allocating more storage to the connected CD engine may be necessary for longer retention periods. The Retention policy, alongside the SnapSync policy, plays a critical role in the engine's performance and storage demands. Customize these to preserve data for a longer period of time, enabling access to earlier data points.

Rewind and rollback operations on a VDB generate new timeflow branches that behave as pinned snapshots. These rewind/rollback timeflows are not governed by container-level Retention policies or individual snapshot retention settings. They remain retained until the VDB is refreshed from its parent, after which the older timeflows become eligible for cleanup under the standard Retention policy.

Replica Retention policy

The Replica Retention policy outlines the retention span for snapshots on replicated namespaces after their deletion from the source. Generally, deletion on the source leads to deletion on the target; however, the new Replica Retention policy extends the life of these snapshots on the target. Apply this policy to an entire namespace or specific groups or objects within. These snapshots support provisioning or refreshing VDBs, but point-in-time provisioning might be limited to optimize disk space. Replica Retention policies are enforced automatically, either on a set schedule or when a replication job is received.

Replica Retention policy is designed to lengthen snapshot lifespans only. They can be deleted when:

  • Their policy duration is adjusted, and they fall outside the retention period.

  • The original dSource or VDB is deleted.

  • For Oracle virtual pluggable databases (vPDB), if the controlling container database (CDB) is removed or unreplicated, dependent snapshots on both the CDB and the vPDB are deleted. This could occur if a vPDB migrates from one CDB to another.

Benefits of longer retention

Extending the retention period for snapshots and logs enhances your ability to roll back to earlier data states. The advantages of a more prolonged retention timeline include:

  • Compliance with regulations: Meets standards like SOX compliance, where data preservation is crucial.

  • Supports development: Accommodates the needs of environments with frequent application updates and development cycles.

  • Controlled data progression: Allows for careful and deliberate data changes.

  • Risk mitigation: Reduces project risks by retaining critical data states.

  • Efficient recovery: Facilitates a quicker rollback or restoration to previous points in time, enhancing operational resilience.

Last updated
Oct 8, 2026