Using the PurgeLogs operation
Retention policy does not delete the archived logs which are
Older than the log retention period(can be referred as expired logs) but are required to keep the snapshots provisionable
Generated after the most recent snapshot
Required to make retention-proof bookmark points provisionable
Under certain conditions, it may become necessary to delete more archived logs which cannot be deleted by retention policy. The purgeLogs operation can be used to perform this task.
PurgeLogs operation is capable of deleting the archived logs which are older than the log retention period but were not deleted by retention policy to keep the snapshots provisionable. If required, it can also delete the logs which are generated after the most recent snapshot. This operation, however, will always retain the archive logs required to keep the retention proof bookmark points or snapshots marked with ‘keep forever’ (pinned snapshots) provisionable.
PurgeLogs operation is a CLI only operation. For a multitenant dSource, this operation should be performed for CDB only as logs for CDB and all associated PDBs are managed by the CDB itself.
Example scenario
The retention policy does not delete the logs which are generated after the most recent snapshot. If no new snapshots are being taken within a reasonable period for any reason, the archive logs will continue to accumulate in the Delphix engine. This can lead to high memory and disk usage and can also make the engine unstable. This can also prevents new snapshots from being taken. By clearing these logs, the purgeLogs operation can help to free up the storage space in the Delphix engine.
The purgeLogs operation does not function with VDBs or any non-Oracle data platforms at this time.
Strategies for archive logs deletion
Strategy 1
For non-multitenant dSources, it will delete all the expired logs associated with snapshots as required until the target space to reclaim is achieved.
For multitenant dSources, it will delete all the expired CDB logs associated with the CDB and PDB snapshots as required until the target space to reclaim is achieved.
It deletes the oldest snapshot logs and moves to the newest one in order for each Timeflow starting from the current Timeflow first. The logs required for retention proof bookmarks and pinned snapshots are not deleted.
Strategy 2
For non-multitenant dSources, it will delete the logs which are newer than the latest snapshot in the current Timeflow to free up space which retention cannot free.
For multitenant dSources, it will delete the logs which are newer than the latest PDB snapshot in the current Timeflow to free up space which retention cannot free. Here, the latest PDB snapshot indicates the most recent snapshot among all PDBs in CDB.
Deletion is done in the order from the most recent logs to the oldest one because of the possibility of Timeflow repair at a later time. The deletion is done based on the actual compressed file size of the log sequence on the Delphix Engine. If there is a retention proof bookmark, this operation preserves the logs required to provision from the retention proof bookmark This operation also spares the online in-flight log sequence since chunks of this sequence will keep coming in (this only applies for logsync mode set to Archive + Online Redo).
PurgeLogs operation takes three arguments :
storageSpaceToReclaim - The amount of space user wants to free up (eg; 20K, 5M, 1G etc). This is mandatory and non-zero. Actual space reclaimed is dependent on whether there are enough logs to be deleted. By default, Strategy 2 is always in effect. The user has the ability to run strategy 1 if their target space reclaim is not met, the user can run strategy 1 using the deleteSnapshotLogs argument.
deleteSnapshotLogs - This is set to false by default. If set to true, then logs are deleted based on strategy 1. It is possible that no more logs are available for deletion as per strategy 1 and the target storage space to reclaim is not yet achieved. In such a scenario, logs would be deleted as per strategy 2 until the target is achieved or there are no more logs to delete. If this is set to false, then deletion is done based on strategy 2 only.
dryRun - This is a boolean argument and set to true by default. If it is true, then the operation does not actually delete the logs. This argument can be used to see which snapshots and parts of the Timeflow will be affected by the operation. This operation returns the time flow point beyond which logs might be deleted and the set of non MT/PDB snapshots affected by this operation (and will not be provisionable afterwards). When the operation is run in non-dryrun mode, we compute the time range of the snapshot and provide the endpoint as the end of the truncated Timeflow. In dryrun mode, we return the endpoint of the first log which survived as the Timeflow point beyond which it has been truncated.
Use this operation with
setopt format=json, otherwise, the list of snapshots may be truncated if there are more than 3.Strategy 1 is an optional step and to be used in the event Strategy 2 does not clear enough space desired by the user. Please note that any snapshots affected by this step enabled can no longer be provisioned from. The user will be required to restore archivelogs to re-enable provisioning of the affected snapshot. To repair this function please use the TimeFlow Repair Tool.
VDB transaction logs can be manually removed from the archive filesystem mounted on the target for each VDB.
This example shows how to free 50GB of space from container "example_container" using strategies 1 and 2:
Log into the CLI.
Go to the container using
/database.Set the output format into json using this statement:
setopt format=json.Select the Oracle non-multitenant/CDB container using
select example_container.Select operation
purgeLogs.Set the target space to reclaim to 50GB using
set storageSpaceToReclaim=50G.(Optional Step)
deleteSnapshotLogs=true. Warning: this step should be used only in the event that Strategy 2 does not free enough space. This will remove the ability to provision from affected snapshots or require the restoration of archivelogs to enable provisioning. Useset dryRun=trueto view the snapshots which will be affected without deleting the logs. Affected snapshots will be listed under the sectionaffectedSnapshots.Use
set dryRun=falseto enable the operation.Commitoperation.
Example usage
delphixengine> /database
delphixengine database> select example_container <---- Non-MT/CDB Container ---->
delphixengine database "example"> purgeLogs
delphixengine database "example" purgeLogs *> set storageSpaceToReclaim=50G
delphixengine database "example" purgeLogs *> set deleteSnapshotLogs=true
delphixengine database "example" purgeLogs *> set dryRun=false
delphixengine database "example" purgeLogs *> commit
type: PurgeLogsResult
affectedSnapshots:
0:
type: OracleSnapshot
name: '@2014-08-05T23:29:57.576Z'
consistency: INCONSISTENT
container: dbdhcp3
creationTime: 2014-08-05T23:29:57.576Z
firstChangePoint:
type: OracleTimeflowPoint
location: 2825963
timeflow: dbdhcp3/default
timestamp: 2014-08-05T23:31:15.000Z
latestChangePoint:
type: OracleTimeflowPoint
location: 2826079
timeflow: dbdhcp3/default
timestamp: 2014-08-05T23:31:15.000Z
missingNonLoggedData: false
namespace: (unset)
reference: ORACLE_SNAPSHOT-75
retention: 0
runtime: (unset)
timeflow: dbdhcp3/default
timezone: America/New_York,EDT-0400
version: 11.2.0.2.0
truncatePoint:
type: OracleTimeflowPoint
location: 3176794
timeflow: dbdhcp3/default
timestamp: 2014-08-07T19:58:55.000ZThis output shows that the affected snapshot is '@2014-08-05T23:29:57.576Z' and the snapshot will not be provision-able. The truncate point indicates the last SCN/timestamp that can be provisioned.