Enterprise Data Manager Guide

6.5
- 6.5.1
- 6.5 HotFix 1
- 6.4.4
- 6.4.3 HotFix 1
- 6.4.3

Back Next

Working with Partition Exchange

When to configure partition exchange depends on several factors. The main factor is the volume of data that you want to delete from the source. Other factors include the archive or restore use case, the processing time, and the database down time.

Configure partition exchange based on the following factors:

Amount of data to delete from the source: The biggest factor to determine if you should configure partition exchange is the amount of data that you want to delete from the source. Configure partition exchange when you want to delete a significant percentage of data from the source. For example, you want to delete twenty percent or more records from the source table.

Archive use case: You can enable or disable partition exchange based on the archive job requirements, such as initial archiving or frequency of archiving.
You may want to configure partition exchange for the initial archive run if you have a lot of data to archive and purge. Then, disable the partition exchange for next regularly scheduled archive jobs. For example, you have 10 years worth of data in your source. For the first archive run on the source, you want to archive and purge the last 7 years worth of data. Then, you schedule a job that runs on a monthly schedule. The monthly jobs will not archive a large percentage of data. You configure partition exchange for the first archive run because there is a significant amount of data to delete. You disable the partition exchange configuration for the remainder of the jobs as the volume of the data to archive and purge will be significantly less.
Use the frequency of how often you plan to run an archive job to determine if you should configure partition exchange or not. For example, you may want to configure partition exchange for archive jobs that are scheduled on a less frequent basis, such as annual archiving. You may not want to configure partition exchange for jobs that run on a more frequent basis, such as monthly archiving. However, you should still consider the volume of the data even for archive jobs that run on a frequent basis.

Restore use case: You can enable or disable partition exchange to restore and purge data from the history database to the source database. The type of restore job and the amount of data that you need to restore determines if you should configure partition exchange.
For transaction restore jobs, partition exchange is not relevant because the restore job does not involve a large amount of data.
For cycle restore jobs, you can configure partition exchange if the restore cycle restores and purges a large percentage of the data in the history table.

Processing time: The main steps in the partition exchange procedure include creating a keep table, swapping the partitions, and rebuilding the source indexes. The time it takes to swap the partitions is minimal. However, the processing time to create the keep table and to rebuild the source indexes depends on the size of the data that remains in the table and the amount of indexes on the source. The processing time increases with the size of the data and the number of indexes on the source.

Database down time: When the archive job deletes data from the source using partition exchange, the database must be off line to perform the partition exchange. To reduce the impact of the database down time, you can configure the job to pause before the delete from source step. Then, take the database off line.

Rename Saved Search

Table of Contents

Enterprise Data Manager Guide

Enterprise Data Manager Guide

Working with Partition Exchange

Working with Partition Exchange