Using the PurgeLogs operation

This topic addresses scenarios in which the purgeLogs operation is used to clear expired and unused logs.

Log retention does not affect the logs in the following three cases:

If the logs are expired but are required for snapshots to be consistent
Logs generated after the most recent snapshot
Logs required to make retention-proof bookmark points provisionable

It is possible that the storage space is not freed by retention. In this scenario, there is only one snapshot and under that circumstance, it would continue to generate logs to the point that there was no storage space available. This prevents new snapshots from being taken. Additionally, retention does not delete expired logs that are required for snapshots to be consistent.

The purgeLogs operation does not function for CDBs or any non-Oracle data platforms at this time. In addition, this operation only functions for Oracle non-multitenant dSources, it does not function with VDBs.

Possible strategies

Strategy 1: It deletes all the expired logs associated with 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: It deletes logs beyond the last snapshot to free up space in which retention cannot free. Deletion is done in this order as opposed to deleting from the oldest logs 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 - This takes a non-zero amount of space to reclaim (eg; 20K, 5M etc). This is the target amount of space that the user will want to free up. This will be dependent on whether there will be enough objects to be freed. 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 this is set to true, then logs are deleted based on strategy 1. Even after completing that, if the target storage space to reclaim is not achieved, then logs are deleted based on strategy 2 until the target is achieved or the 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 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.
Step 7 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 9K 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 container using select example_container
Select operation purgeLogs
Set the target space to reclaim to 9K using set storageSpaceToReclaim=9K
(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. Use set dryRun=true to run operation and view the snapshots which will be affected. Affected snapshots will be listed under the section affectedSnapshots.
Use set dryRun=false to enable the operation.
Commit operation

The output should look like this:

CODE


delphixengine> /database
delphixengine database> select example_container
delphixengine database "example"> purgeLogs
delphixengine database "example" purgeLogs *> set storageSpaceToReclaim=9K
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.000Z

This 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.