How can RECLAIM DATAVOLUME be executed when system replication is active?
With ALTER SYSTEM RECLAIM DATAVOLUME DEFRAGMENT you can reduce fragmentation on disk level and reclaim disk space. When system replication is used, there are typically snapshots preserved and as a consequence the RECLAIM DATAVOLUME command fails with:
general error: Shrink canceled, probably because of snapshot pages
In order to come around this issue you can remove the replication related snapshots as soon as they are no longer needed for replication purposes.
| Parameter | Site | Default | Unit | Proposed temporary value | Details |
| global.ini -> [system_replication] -> datashipping_snapshot_max_retention_time | Primary | 120 (SAP HANA 1.0) 300 (SAP HANA >= 2.00) | min | 0 | Per default system replication snapshots are preserved for 120 minutes before they are dropped. In order to drop them as soon as possible you can set this parameter to 0. |
| global.ini -> [system_replication] -> datashipping_min_time_interval | Secondary | 600 | s | 100000 | This parameter defines after how many seconds a new system replication related snapshot is created on primary site. To avoid the creation of the snapshot in this context you have to set it to a number of seconds that is longer than the expected RECLAIM runtime (e.g. 100,000). |
| global.ini -> [system_replication] -> datashipping_logsize_threshold | Secondary | 5368709120 | byte | 5368709120000 | This parameter defines after which generated log volume a new system replication related snapshot is created on primary site. To avoid the creation of the snapshot in this context you have to set it to a number of bytes that is longer than the log generation during the expected RECLAIM runtime (e.g. 5,368,709,120,000). |
Afterwards wait until snapshots are no longer visible in M_SNAPSHOTS, then execute the RECLAIM operation.
Once it is finished you can unset the parameters that you adjusted above.
The temporary parameter adjustments don't have a signficant negative impact on the system replication and takeover possibilities. The main limitations are slightly increased takeover times and that a failback to the primary site can't be supported by the snapshot and so a initial data transfer is required.
A RECLAIM DATAVOLUME on the secondary site isn't possible.
Be aware that the error can also be caused by a snapshot-based backup rather than system replication. So in order to make sure that a RECLAIM DATAVOLUME succeeds, you have to make sure that no backup based on snapshots is scheduled at the same time.