Fifteen-Minute Immutable Snapshots for a 20 TiB Oracle Estate

Upper-bound arithmetic:

• 20 TiB estate × 1.2 %/hour = 240 GiB of changed tracks per hour.
• Seven days = 168 hours → 240 GiB × 168 ≈ 39.4 TiB of changed tracks across the retention window.
• Free SRP capacity = 120 − 76 = 44 TiB.

SnapVX is delta-based: each generation stores tracks changed since the previous generation, and overlapping generations share track space, so the true figure is below 39.4 TiB - but you must plan to the bound, not the average. At 4 % per hour during batch, a few heavy days can push consumption past the 44 TiB free space, and a full SRP blocks new allocation for production, not just snapshots. That is not an acceptable risk.

Alternative policy, multi-rule:

• 15-minute interval, retained 24 hours (≈ 240 GiB × 24 ≈ 5.8 TiB).
• Hourly, retained 72 hours.
• Daily, retained seven days (the compliance point).

This keeps a week of recovery points at roughly half the capacity of the original proposal, and the 15-minute granularity where it is actually useful - recent recovery.

A secure snapshot cannot be terminated before its expiry by anyone, including an administrator with symsnapvx. Marking every 15-minute generation secure for seven days means:

• No emergency reclamation. If the change rate runs above forecast, or a copy job or batch misfires and inflates deltas, you cannot delete the snapshots that are consuming the SRP. You would have to wait out the expiry while production capacity drains - the worst possible failure mode.
• No correction of mistakes. A policy that fires against the wrong storage group, or with a wrong interval, cannot be undone for seven days.
• Operational clutter. 672 immutable generations per device overwhelm any reasonable restore-point selection and make termination tracking an administrative burden.

Instead: keep the 15-minute and hourly generations non-secure and let them expire normally, and mark only the daily compliance generation secure with a seven-day expiry. That satisfies the 'cannot be deleted early' requirement for the audit-relevant points while leaving room to remediate an unexpected capacity event. Pilot the policy on one small storage group first, confirm the expiry semantics in Unisphere, and verify that you can extend but not shorten a secure snapshot's expiry.

Use a linked target rather than a restore:

1. Create target devices of identical size on the same array in a dedicated storage group (SG_ORA_VAL).
2. Link the newest snapshot to those targets in nocopy mode (Unisphere > Storage > SnapVX > Link, or symsnapvx link with the default nocopy behaviour). Only tracks that the validation host overwrites are copied to the target, so no full copy is made.
3. Create a masking view for SG_ORA_VAL against an initiator group containing only the validation host's WWNs, using a port group that does not carry production traffic if possible.
4. Rescan the validation host, start the instance, run RMAN validate/restore checks.

Verify:

• The link state shows as linked and target capacity consumption is tracked while the host writes.
• SG_ORA response time and port utilisation are unchanged - reads of snapshot data consume array resources, so schedule the check outside the batch peak.
• No production snapshot was terminated by the operation.
• After validation, terminate the link (this discards target data) and remove the targets, so the next run starts clean.