Database Guide › Database Storage and Partitioning › Set Up Partitions and Purging › Run or Schedule a Partition-based Purge › Using a Third-party Scheduler

Using a Third-party Scheduler

If you have a separate schema owner for your CA DataMinder database, this is the method we recommend for scheduling a partition-based purge.

Using a third-party schedule such as Unicenter Autosys, you can run a sequence of CA DataMinder commands and Oracle scripts:

1. Suspend the CMS

   Add this command to suspend the CMS. This command must be run from the \System subfolder of the CA DataMinder installation folder on the CMS:

   wgninfra -exec wigan/infrastruct/Infrastruct Suspend
   

   If successful, the suspend mechanism returns zero; if unsuccessful, it returns a non-zero value, indicating an error. Errors are recorded in wgnlee.log; find this logfile on the CMS in the \System subfolder of the CA DataMinder installation folder.

2. Run the purge

   Add an Oracle script to purge the specified partitions. This script needs to execute the wgn_roll_partitions procedure.

   Automation

   Wgn_roll_partitions takes several date parameters. Your scheduler script must pass the correct parameters to wgn_roll_partitions to ensure the correct partitions are added and removed. If required, your script can derive these parameters from the Wgn3PurgeHistory database table.

   Purge failure

   If the purge fails to complete, you must also abort the remaining steps. That is, do not resume the CMS (see step 3) or delete the blobs (see step 4). After fixing the problem (see below), you can restart the purge from the point where it failed and then proceed to steps 3 and 4.

   Note: You can customize the ‘on failure’ procedure, for example, to alert your DBA if a purge fail.

   Purge failure continued

   To locate and fix the problem before restarting the failed purge, use information recorded in the Wgn3PurgeState and Wgn3PurgeHistory database tables.

   Most importantly, your scheduler script must include error handling to re-enable key constraints if it detects an error from wgn_roll_partitions. This ensures that data integrity is preserved. If your scheduler script fails to re-enable key constraints, you must do so manually—see page 51 for instructions.

   Note: Wgn_roll_partitions will re-enable key constraints if it detects a purge error, but we recommend that your scheduler script also includes error handling as a further safeguard.

3. Resume the CMS

   Add the following command. As for step 1, this must be run from the \System folder on the CMS:

   wgninfra -exec wigan/infrastruct/Infrastruct Resume
   

   If successful, the resume mechanism returns zero; if unsuccessful, it aborts and returns a non-zero value, indicating an error. As for step 1, errors are recorded in wgnlee.log.

4. Delete the blob files

   Add the following command. As before, run this from the \System folder on the CMS:

   wgninfra -exec wigan/infrastruct/database/DBManagement PurgeBLOBs
   

   If successful, the blob purge mechanism returns zero; if unsuccessful, it returns a non-zero value, indicating an error. If an error occurs, the scheduler can retry calling this command to delete the blob files. As for step 1, errors are recorded in wgnlee.log.

More information:

Manual Purges

Diagnostic Support