4.7.5 Capacity Planning for Oracle Database with Exascale Snapshots and Thin Clones
Exascale snapshots and thin clones provide fast, space-efficient copies of Oracle Database files. However, thin provisioning does not eliminate the need for capacity planning. A writable thin clone consumes additional storage as it diverges from the source database. If many clones are created and then modified, the resulting storage consumption can be much higher than the initial clone footprint suggests.
To reduce the risk that clone changes consume all available space in a shared Exascale vault, Exascale uses reserved clone space for updateable thin clones. Reserved clone space provides capacity for changes made to the clone. As additional previously unchanged blocks are modified in the clone, Exascale can increase the reserved space until enough space exists to materialize the full clone. Excluding additional data added to the database, a clone does not consume more storage than the original source database.
As a baseline for capacity planning, Oracle recommends reserving 20% to 25% of the size of the parent data files for each updateable clone. This reserve accounts for changes to clones, parents of snapshots, and associated metadata. It should be sufficient when approximately 5% to 10% of the cloned data changes. Workloads that modify a larger portion of the cloned data require additional capacity.
For example, if a parent database contains 100 TB of data files and you plan to maintain four updateable thin clones, reserve approximately 80 TB to 100 TB of additional storage for clone-related changes and metadata:
100 TB parent data files x 4 updateable clones x 20% to 25% = 80 TB to 100 TBThis reserve is in addition to the free space required for normal database growth, recovery files, storage pool maintenance, and protection against storage-device failures.
Use the following table to estimate snapshot and clone storage requirements for different amounts of changed data. The values are capacity-planning estimates and should not be interpreted as exact measurements for every workload.
| Snapshot or Clone Type | Amount of Changed Data | Estimated Size of Snapshot or Clone | Savings Compared with a Full Copy |
|---|---|---|---|
| Updateable thin clone | 0% to 6% | 10% to 20% of the parent | 80% to 90% |
| Updateable thin clone | 6% to 10% | 20% to 25% of the parent | 75% to 80% |
| Updateable thin clone | 10% to 20% | 25% to 40% of the parent | 60% to 75% |
| Updateable thin clone | 20% to 40% | 40% to 70% of the parent | 30% to 60% |
| Updateable thin clone | 40% to 60% | 70% to 100% of the parent | 0% to 30% |
| Updateable thin clone | 60% to 100% | 100% of the parent | 0% |
| Snapshot | Not applicable | 1% of the parent | 99% |
| Snapshot or clone of a read-only file | Not applicable | 0% of the parent | 100% |
Note that clone growth depends on the distribution of changed blocks, not only on the volume of write activity. Updating a block that was already modified in the same clone does not require additional reserved clone space. A workload that repeatedly updates the same working set can therefore consume less clone space than a workload that modifies new blocks across a larger portion of the database.
The final rows in the table show that snapshots are highly space efficient, and that files marked read-only in Exascale storage do not allocate additional reserved clone space when they are snapshotted or cloned. If write operations are later enabled on a cloned file that was originally marked read-only, normal clone space reservation behavior resumes.
When reviewing storage consumption, consider the number of updateable clones, the size of the parent data files, and the expected percentage of changed data in each clone. Use snapshot and clone lineage information to identify parent files that support multiple snapshots or clones. The ESCLI lssnapshots command can help identify snapshot and clone relationships.
@> lssnapshots @my-vault-name/my-clone-file --allYou can also use the ESCLI lsstoragepool command to review storage pool free space as part of the same planning process.
@> lsstoragepool my-pool1 --attributes spaceRaw,spaceUsedReserved clone space is managed automatically by Exascale. This topic provides planning guidance; it does not describe a user-visible setting for configuring clone space reservation.